GA4の(not set)の原因と対処法｜参照元・ランディングページ別に診断
GA4の(not set)は、表示中のディメンションに値がないことを示すラベルです。UTMを足す、処理を待つ、といった対策を全項目へ当てはめても直るとは限りません。まず欠けている情報を特定し、その情報が必要なイベントに届いているかを確認します。ここでは流入元、入口ページ、カスタム定義を分けて診断します。
(not set)・(none)・(other)・Unassignedの違い
(not set)は原因名ではありません。選んだ項目を埋める情報が不足している状態を示します。一方、(none)は(direct)と組み合わせたメディアの表記などに使われ、(other)はテーブルの行数制限により値がまとめられた行です。Unassignedはチャネルグループの規則に当てはまらない状態で、別の問題です。
表示 | 意味・次に見るもの |
|---|---|
(not set) | 該当ディメンションの値。必要なイベント・定義・適用範囲を確認 |
(direct) / (none) | 明確な流入情報を得られない場合の分類。直接入力だけとは限らない |
(other) | 行数制限による集約。値の種類やレポートを確認 |
Unassigned | チャネル分類の条件。参照元／メディアの値を確認 |
例えば、page referrerが空でもUTMで流入元を指定できる場合があります。リファラー欠落だけを理由に(not set)と判断しないことが大切です。Googleの項目別説明と(other)の説明は切り分けて読みます。
最初にレポート・スコープ・期間・分母を固定する
調査ログにはプロパティ、レポート名、ディメンションの完全な名称、期間、ホスト、指標、フィルターを記録します。「参照元」だけではFirst user、Session、接頭辞なしのどれを見たか分かりません。直近だけの値と処理が進んだ過去期間も分けます。
入口の欠測を調べるなら分母はセッション、特定パラメータの欠測ならその値を送る対象イベントを分母にします。小さな割合でも登録成功などの重要なイベントだけに集中していれば優先度は高くなります。全体割合だけで放置を決めません。
セッションの参照元／メディア：session_startを調べる
セッションの参照元／メディアでは、公式資料が示すsession_startの欠落を確認します。対象端末で新しいセッションが始まる操作を再現し、送信先プロパティ、session_start、セッション情報とタグの開始順序を調べます。サーバー送信のイベントだけが届くなど、実装経路も記録してください。
Google広告に固有のディメンションが欠けている場合は、広告連携やクリックIDを調べる別の診断です。UTMがないアクセスすべてが(not set)になるわけではありません。また、接頭辞なしのSource／Mediumはキーイベントへの帰属を扱うため、非キーイベントとの組み合わせでは値がないことがあります。流入元のスコープをそろえて比較します。
ランディングページ：page_viewの有無を調べる
ランディングページはセッションの最初のページビューを基にします。セッションにpage_viewがない場合は(not set)になり得ます。「URLが確定する前だった」という推測だけで終わらせず、page_viewそのものとpage_locationが届いているかを確認してください。
- 入口ページでGoogleタグが想定どおり読み込まれるか確認する。
- SPAの初回表示と画面遷移、直接設置とGTMの重複、サーバー送信を区別する。
- 意図した本番ホストとプロパティへ送信されているか確認する。
- page_viewを追加する案では、既存の自動ページビューとの二重送信を避ける。
DebugViewは再現操作のイベントを確認するために使い、集計済みレポートの欠測率とは別の証拠として残します。
カスタム定義：送信・登録・適用イベントを照合する
カスタム定義は「送った値」と「レポートに登録した定義」の両方を調べます。架空のarticle_viewでarticle_category=analyticsを送る設計なら、同じ綴りのイベントパラメータをイベントスコープの定義に登録します。ユーザースコープへ変えるだけではイベント情報がユーザープロパティにはなりません。
対象項目 | 最初の確認 | 修正後の証拠 |
|---|---|---|
Session source / medium | session_startとセッション情報 | 同条件での新しいセッションと集計行 |
Landing page | page_viewとpage_location | 入口操作のpage_viewと後日の入口行 |
article_category | article_viewの送信値・同名のイベント定義 | DebugViewの値と対象イベントに絞った集計 |
接頭辞なしSource | キーイベントか・帰属の対象か | 適用対象にそろえたレポート |
article_categoryを送らない別イベントまで並べれば、(not set)があっても設計どおりの場合があります。カスタム定義の反映には通常24〜48時間の目安があり、待つことと送信不備の修正を混同しません。
同意実装・転送・タグ順序を安全に診断する
同意管理の変更、リダイレクト、タグの開始順序が疑わしいときは、同意状態と遷移経路を記録して再現します。拒否と許可で収集条件が異なる場合でも、同意制御を無効にして値を増やす対策にはしません。URL転送ではキャンペーン情報が途中で消えていないかを別途確認します。
GTMを使う実装では現行のGoogleタグとGA4イベントタグの役割を分けます。DebugViewの公式手順に沿って端末を選び、イベント名・時刻・値を保存します。そこに見えない場合も、同意状態やデバッグ設定を確認してから「本番でも未収集」と結論します。
欠測率の計算例と修正前後の検証チェックリスト
以下は説明用の架空データです。1,000セッションのうちランディングページ(not set)が40なら、欠測率は40÷1,000×100=4%です。一方、全10,000イベントのうち2,000件にarticle_categoryがなくても、20%をそのまま実装エラー率にはできません。対象article_view600件中30件が欠測なら、調査に使う割合は30÷600×100=5%です。
- 修正前の条件、実数、分母と対象イベントを保存する。
- 担当者が原因と変更案をレビューし、1つの変更を再現テストする。
- 処理後の新しいデータを同じ条件・同じ長さの期間で確認する。
- 欠測率だけでなく、重複送信や重要イベントへの影響も確認する。
- 残った欠測と調査できない経路を記録する。
過去の欠測が設定変更だけで埋まる保証はありません。まず1つのディメンションを選び、何が不足し、どの証拠で直ったと判断するかを明確にしてください。
関連記事
出典・仕様の確認日
仕様は2026年10月12日に以下の一次資料で確認しています。画面構成は権限やレポートコレクションによって異なります。
