GA4のitemsが(not set)になる原因と修正手順｜purchaseは計測されるのに商品名が出ない時の切り分け

この記事のポイント

• GA4のitemsが(not set)になる原因は、収集側（dataLayer・GTM）とレポート表示側（スコープ不一致）の2系統に大別できる
• DebugViewでpurchaseイベントのitems配列を開けば、5分でどちらの系統の問題かを判定できる
• ecommerce: nullのpush忘れは、別商品のitemsが混入する事故につながる盲点になりやすい
• 修正しても過去の(not set)データは遡って直らないため、修正日以降のデータで評価する運用に切り替える
• Shopifyや国産カートASPではプラットフォーム特有の確認箇所があり、汎用手順だけでは原因にたどり着けないことがある

「purchaseイベントの数はGA4に正しく入っている。なのに商品別レポートを開くと、商品名の欄がすべて(not set)になっている」——この症状で手が止まる担当者は少なくありません。イベント自体は計測できているので、GTM（Google タグマネージャー）の発火設定を疑ってもタグは正常に動いている。ここで原因を一つの箇所に絞り込もうとすると、かえって遠回りになります。

GA4のitemsが(not set)になる原因は、大きく分けて「収集側」と「レポート表示側」の2系統です。収集側はdataLayer（データレイヤー）やGTMの設定不備でそもそもitem_idやitem_nameが送られていないケース、レポート表示側はデータ自体は正しく送られているのに、探索レポートの指標とディメンションのスコープが噛み合わずに(not set)と表示されるケースです。この2つは原因も直し方もまったく異なるため、切り分けを間違えると修正が空振りします。

この記事では、DebugViewを使った5分判定フローから、収集側・表示側それぞれの具体的な修正手順、Shopifyや国産カートASP特有の落とし穴、そして修正後の検証と過去データが直らない理由までを順に解説します。

GA4のitemsが(not set)になる原因とは？2系統で切り分ける

図1: (not set)の原因は収集側と表示側の2系統

GA4のitemsが(not set)になる原因は、データが送られていない「収集側の問題」と、データは送られているのに集計時に弾かれる「レポート表示側の問題」の2系統に分かれます。この切り分けを最初に行わないと、正しく動いているGTMタグを疑い続けて時間を浪費することになります。

収集側の問題（dataLayer・GTM）

収集側の問題は、purchaseイベント自体は発火しているものの、items配列そのものが空だったり、item_idやitem_nameが欠落した状態で送信されているケースです。UA（ユニバーサルアナリティクス）時代のdataLayer構造がそのまま残っている、GTMタグの設定でeコマースデータの送信がオフになっている、といった原因が典型です。

レポート表示側の問題（スコープ不一致）

レポート表示側の問題は、items配列に正しいデータが入っているにもかかわらず、探索レポート上でアイテムスコープの指標とイベントスコープのディメンションを組み合わせてしまい、GA4の仕様上(not set)や空行として表示されるケースです。タグの実装を何度見直しても解決しないのはこのパターンが多いと言われます。

最初の5分でやる判定：DebugViewでitemsは送られているか

DebugViewでitemsの中身を確認する

items欠落の原因を切り分ける最短ルートは、GA4のDebugView（デバッグビュー）でpurchaseイベントの中身を直接確認することです。DebugViewとは、GA4管理画面上でリアルタイムに送信中のイベントとパラメータを確認できる機能で、items配列の有無を数分で判定できます。

DebugViewでpurchaseイベントを展開する手順

GTMのプレビューモードを起動した状態、またはChrome拡張機能のGA Debuggerを有効にした状態で購入完了画面まで進み、GA4の管理画面から「DebugView」を開きます。左側のイベントストリームに表示されるpurchaseイベントをクリックし、右側のパラメータ一覧からitemsの項目を展開します。ここでitems自体が存在しない、あるいは配列が空であれば収集側の問題、items配列に商品データが入っていれば表示側の問題という一次判定ができます。

items配列に item_id / item_name が入っているかの見方

items配列を展開した際、各商品オブジェクトの中にitem_idとitem_nameの両方があるかを確認します。どちらか一方でも値が入っていれば計測自体は成立しますが、欠けている側のディメンションはレポート上で(not set)になります。DebugViewで値が正しく入っているのにレポートで(not set)が出る場合は、収集側ではなく表示側のスコープ不一致を疑う段階に進みます。

収集側の原因4パターンと修正手順（GTM・dataLayer）

収集側でitemsが欠落する原因は、実務上はおおむね4パターンに収束します。ひとつずつ潰していけば、多くの場合は当日中に解消できます。

パターン	症状	主な原因箇所
UA形式の残存	items自体が存在しない	productsやnameキーのdataLayer
必須項目の欠落	item_id/item_nameがundefined	変数マッピングの誤り
GTMタグ設定不備	eコマースデータが送られない	タグのeコマース設定オフ
タイミングのズレ	イベントごとに欠落が不安定	dataLayer.pushの発火順序

UA形式（products/name）のdataLayerが残っている

UA時代のeコマース計測では、dataLayerにproductsやnameといったキーを使う構造が一般的でした。GA4のGTMタグはitemsという配列名とitem_id・item_nameというプロパティ名を前提にしているため、UA形式のdataLayerがそのまま残っているとGA4タグ側では何も読み取れません。サイトのソースコードやGTMのタグ設定でdataLayer.pushの中身を確認し、itemsという配列名に統一されているかをまず見ます。

items配列のitem_id・item_nameがundefinedになっている

items配列自体は存在しているのに、中身のitem_idやitem_nameがundefinedになっているケースもよくあります。原因の多くは、GTMの変数（データレイヤーの変数）がdataLayer内の実際のキー名と一致していないことです。DebugViewでundefinedと表示された場合は、GTMのプレビューモードでデータレイヤーの中身を確認し、変数名のスペルミスや階層のズレを照合します。

GTMタグの『eコマースデータを送信』設定とデータソースの確認

GTMのGA4イベントタグには「eコマースデータを送信」というチェック項目があります。これがオフになっている、あるいはデータソースが「データレイヤー」ではなく手動設定のままになっていると、items配列自体がイベントに含まれません。タグの設定画面を開き、eコマースのデータソースが正しくデータレイヤーを参照しているかを確認します。

dataLayer.pushがGTM読み込み・タグ発火より後になっている

dataLayer.pushの実行タイミングがGTMのコンテナ読み込みやタグの発火より後ろになっていると、GTMがpushの内容を取得できずに空のitemsが送信されることがあります。特にシングルページアプリケーションや非同期で商品情報を取得するサイトで起きやすく、Networkタブでリクエストの発生順序と実際のdataLayerの内容を突き合わせて確認するのが確実です。

ecommerce: null を忘れるとどうなる？別商品のitemsが混ざる問題

図2: ecommerce: null未実行でitemsが混入する流れ

ecommerce: nullのpushを忘れると、直前のイベントで送信したitemsが次のイベントに引き継がれ、買っていない商品がpurchaseに混入することがあります。この原因は日本語の実装解説ではあまり触れられていない盲点です。

GA4タグが直近のecommerceオブジェクトを参照する仕様

Simo Ahava氏のブログでは、GA4のGTMタグはdataLayer内の直近のecommerceオブジェクトを自動的に参照する仕様であると解説されています。つまり、view_itemやadd_to_cartでpushしたitemsをクリアしないまま次のイベントをpushすると、GA4タグは前のイベントのitemsを引き続き参照してしまいます。日本のGTM実装現場でも同様に、複数のeコマースイベントを1ページ内で扱う構成では、各pushの直前にecommerce: nullを入れてオブジェクトをクリアする対応が実質的に必須と考えられます。

purchaseに買っていない商品が付くときの確認方法

購入完了ページのitemsに、カートに入れていない商品や以前閲覧しただけの商品が混ざっている場合は、このクリア忘れが濃厚です。DebugViewでpurchase直前のイベント（view_itemやadd_to_cartなど）のitemsと、purchaseのitemsを見比べ、重複する商品IDがないかを確認します。修正はシンプルで、各eコマースイベントのdataLayer.pushの直前に dataLayer.push({ ecommerce: null }); を追加するだけです。

収集は正常なのにレポートで(not set)になるのはなぜ？

DebugViewでitemsに正しい値が入っているのに探索レポートで(not set)が出る場合、原因はほぼディメンションのスコープ不一致です。GA4のディメンションには、イベント全体に紐づく「イベントスコープ」と、商品ごとに紐づく「アイテムスコープ」の2種類があります。

2023年変更：アイテムスコープ指標の組み合わせ制限

Analytics Manaiaの記事では、2023年1月のGA4仕様変更以降、アイテムの収益や数量といったアイテムスコープの指標は、アイテムスコープのディメンションとしか正しく組み合わせられなくなったと指摘されています。探索レポートで「ページタイトル」のようなイベントスコープのディメンションと、アイテムの購入数のようなアイテムスコープの指標を同時に使うと、収集自体は正常でも(not set)や空行として表示されます。日本国内でこの制約に言及した記事はまだ少なく、タグを何度見直しても解決しない場合はこの仕様変更を疑う価値があります。

探索レポートをテンプレートから作り直す手順

一度スコープが混在した状態で組んだ探索レポートは、後からディメンションを差し替えても表示が崩れたままになることがあります。この場合は既存のレポートを修正するのではなく、GA4の「探索」メニューから「eコマース購入数」テンプレートを選び直し、必要なディメンションと指標をアイテムスコープで統一して組み直すのが確実な対応です。

2025年8月のアイテムスコープ開放で変わったこと

inimino.orgの記事によると、2025年8月25日にGoogleはアイテムスコープのディメンションと指標を、従来のeコマース購入レポート（収益化レポート）に限らず標準レポートを含む幅広いレポートツールで扱えるように仕様を開放しました。この変更により、スコープ不一致による(not set)の出方も従来とは変わりつつあります。2026年時点でレポートを組む際は、この開放を前提に最新のヘルプ記載を確認しながら設計するのが実務的です。

Shopify・カートASP利用時はどこを確認するか

利用しているECプラットフォームによって、items欠落の原因箇所は変わります。汎用的なGTM設定の確認だけでは見つからない落とし穴がある点に注意が必要です。

Shopify（カスタムピクセル・チェックアウト）の確認ポイント

Shopifyでは、テーマのアップデートやアプリの追加によって、カスタムピクセルやチェックアウト画面のdataLayer出力が意図せず変わることがあります。特にチェックアウト画面はShopify標準のイベント構造に依存する部分が大きいため、テーマ改修やアプリ導入のタイミングでpurchaseイベントのitemsが崩れていないか、DebugViewで都度確認する運用が実務では推奨されます。

国産カートASPでdataLayerを触れない場合の現実解

国産のカートASPの中には、dataLayerの出力構造を自由にカスタマイズできないものもあります。この場合は、ASP側が標準で出力しているdataLayerの構造を先に確認し、GTM側の変数マッピングをそのASPの仕様に合わせて調整するのが現実的な対応です。構造自体を変更できないのであれば、無理にUA形式の整形を試みるより、GA4タグ側の変数設定でASPの出力に合わせ込む方が手戻りが少ないと言えます。

修正後の検証手順と、過去の(not set)が直らない理由

修正が完了したら、DebugView・リアルタイムレポート・翌日以降の通常レポートの順に3段階で検証します。GA4は遡及処理を行わない仕様のため、修正前に発生した(not set)データは後から直りません。

検証の3ステップと反映までの時間目安

まずDebugViewで、修正後のpurchaseイベントのitemsにitem_idとitem_nameが正しく入っているかを確認します。次にGA4の「リアルタイム」レポートで、該当イベントが集計され始めているかを見ます。最後に、探索レポートや収益化レポートの商品別データが通常どおり表示されるかを翌日以降に確認します。GA4の標準レポートは集計に数時間から1日程度のタイムラグが生じることが一般的なため、当日中にすべてを判断しようとせず、翌日の反映まで待つ前提で計画するのが無難です。

動的リマーケティング・広告レポートへの波及

itemsの欠落は、GA4のレポートだけでなく、Google 広告の動的リマーケティングや商品フィード連携にも影響します。item_idが正しく送られていないと、閲覧・購入した商品に基づく広告配信の精度が下がる可能性があります。広告運用の観点では、GA4のレポート表示だけでなく、連携先の広告アカウント側でコンバージョンに紐づく商品データが正しく反映されているかも合わせて確認しておくと安心です。

なお、(not set)の症状は流入経路の計測でも起こり得ます。似た切り分けが必要な場合は、ランディングページが(not set)になる場合の切り分けも参考にしてください。また、items欠落の根本原因がGTMの変数取得にある場合は、GTMのデータレイヤー変数がundefinedになる原因と確認手順で詳しく扱っています。DebugView自体にイベントが表示されない場合は、DebugViewにイベントが表示されない時の対処を先に確認する必要があります。GTMと直実装が混在している環境では、items欠落とあわせてGA4イベントが重複計測される時の切り分けも併発しやすいため、心当たりがあれば合わせて見ておくとよいでしょう。

よくある質問

Q：GA4でpurchaseイベントは計測されているのに商品名だけ(not set)になるのはなぜですか？ purchaseイベントの計測とitems配列のデータは別の仕組みです。イベント自体はdataLayerのpush内容に関わらず発火しますが、items配列にitem_idやitem_nameが含まれていなければ商品名は(not set)になります。本文の収集側・表示側の切り分けフローに沿って、DebugViewでitemsの中身を確認するところから始めてください。

Q：item_idとitem_nameはどちらか一方だけでも計測されますか？ 最低どちらか一方が入っていれば計測自体は成立します。ただし、欠けている側のディメンションを使ったレポートは(not set)として表示されるため、両方を確実に送信する実装にしておくことが推奨されます。

Q：修正すれば過去の(not set)データも直りますか？ 直りません。GA4は過去の生データに対して遡及的な再計算を行わない仕様です。修正後は、修正日以降のデータのみを商品別分析の対象として扱い、修正前後でレポート期間を分けて評価する運用に切り替える必要があります。

Q：商品名は出るのに収益（購入による収益）が0になるのはなぜですか？ これはitems欠落とは別の原因である可能性が高いです。currencyパラメータがitemsの中ではなくecommerceオブジェクト直下（イベントレベル）に置かれていない場合や、valueが文字列型で送信されている場合に、収益が正しく集計されないことがあります。items欠落と収益ゼロは併発しやすいため、片方だけを直して満足せず、両方を個別に確認してください。

Q：ecommerce: null のpushは必ず必要ですか？ 1ページ内でview_item、add_to_cart、purchaseのような複数のeコマースイベントを扱う実装であれば、実質的に必須と考えるべきです。各イベントのdataLayer.pushの直前にecommerce: nullを入れておくことで、前のイベントのitemsが次のイベントに混入する事故を防げます。

---

GA4のitems(not set)は、原因箇所さえ特定できれば当日中に修正まで到達できるトラブルです。ただし収集側とレポート表示側のどちらが原因かによって対応がまったく異なるため、切り分けを誤ると修正の手が止まりやすい領域でもあります。真策堂では、GA4のeコマース計測が正しく機能しているかという観点から、広告運用データとの連携も含めた設計・診断のご相談を受けています。