GA4のランディングページが(not set)になる原因4パターンと修正手順｜広告流入の着地ページが消える時の切り分けフロー

Google 広告のレポートと GA4 のランディングページレポートを突き合わせたら、費用が乗っているはずのページが (not set) に化けていた——広告流入のLP分析をしている担当者なら、一度はこの場面に出くわしているはずです。どのページに広告費を使い、どのページが成果に貢献しているのかを判断する材料が、この一行のせいで丸ごと消えてしまいます。

(not set) は単一の原因で起きる現象ではありません。GA4の仕様に起因するものから、タグ実装の不備、広告のリダイレクト構造まで、性質の異なる複数の原因が同じラベルの下にまとめられています。原因を切り分けずに「とりあえずGTMを見直す」では、仕様由来の分をいくら追いかけても消えず、逆に実装起因の分を見落として放置してしまうことになりかねません。

この記事では、GA4のランディングページが (not set) になる仕組みを4パターンに整理し、広告流入で数値が消えたときに当日中に原因を特定できる切り分けフローを提示します。あわせて、修正で減らせる分と、仕様上どうしても残る分の線引きも示すので、闇雲な調査で消耗する状況から抜け出す手がかりにしてください。

この記事のポイント

• GA4のランディングページが(not set)になるのは、セッション先頭にpage_viewイベントが記録されていないことが直接の原因である
• 主因はセッションタイムアウト後の再開・page_view未発火・0時またぎ分割・SPAやボット等の特殊要因の4パターンに分類できる
• 広告流入で偏って発生している場合はgclidの欠落とリダイレクト構造を最初に確認するのが定石である
• (not set)は仕様上ゼロにはできないため、発生率で管理し許容ラインを決めておくべきである

GA4のランディングページが(not set)になる原因とは？

図1: session_startとpage_viewの依存関係

GA4のランディングページが (not set) になるのは、そのセッションの最初に記録されるべき page_view イベントに、ランディングページの情報が紐づいていないことが直接の原因です。GA4のランディングページディメンションは、セッションの起点となる page_view イベントのURLパラメータから生成されます。この起点イベントが欠落・遅延・分割されると、GA4はランディングページを特定できず (not set) として集計します。

仕様上の発生メカニズム（session_startとpage_viewの関係）

GA4のセッションは、原則として session_start イベントと page_view イベントがほぼ同時に発火することで開始します。ランディングページディメンションは、このセッション開始時点の page_view から取得されるページパスを参照する仕組みです。つまり session_start は発火したのに page_view が発火していない、あるいは発火順序が入れ替わったセッションが生まれると、ランディングページの参照先を失い (not set) になります。ユニバーサルアナリティクス時代にはあまり意識しなくてよかったこの依存関係が、GA4ではイベントベース計測の弱点として表面化しています。

原因4パターンの早見表

広告流入の (not set) は、性質の異なる4つの原因が混在して発生します。まずは全体像を俯瞰しておくと、後段の切り分けフローが理解しやすくなります。

原因パターン	発生トリガー	広告流入への影響度
セッションタイムアウト後の再開	30分間操作がなく再開した際にpage_view無しでイベントが発火	高（全流入に発生するが構成比が大きい）
page_view未発火・遅延	GTMトリガー設定不備、リダイレクトによるgclid欠落	非常に高（広告LP特有）
0時またぎのセッション分割	日付境界でセッションが強制的に2つに分割される	中（夜間配信アカウントで顕著）
SPA・ボット・オーディエンストリガー	実装や流入品質に起因する特殊要因	低〜中（サイト構成による）

(not set)と(other)・Unassignedの違い

(not set) とは、GA4がそのディメンションの値を取得できなかった場合に表示されるラベルであり、データそのものが欠落していることを意味します。似た表示に (other) と Unassigned がありますが、意味はまったく異なります。(other) は、GA4の集計処理でディメンションの組み合わせが行数上限を超えた際に、上限を超えた分をまとめて表示するラベルです。データが欠落しているわけではなく、集計側の丸めによって発生します。一方 Unassigned は、主にチャネルグループの判定に使われるディメンションで、参照元・メディアの情報が判定条件のどれにも合致しなかった場合に表示されます。ランディングページの文脈で問題になるのはほぼ (not set) のみで、この3つを混同すると原因調査の方向を誤ります。

原因1: セッションタイムアウト後の再開でpage_viewが発生していない

セッションタイムアウト後の再開は、広告流入・自然検索流入を問わず(not set)全体の中で最も構成比が大きいと考えられる原因です。GA4は初期設定でセッションタイムアウトを30分に設定しており、ユーザーがページを開いたまま30分以上操作をせず、その後スクロールやクリックといった操作を再開すると、そこで新しいセッションが始まります。

30分ルールで(not set)が生まれる流れ

新しいセッションの開始トリガーが「操作の再開」である場合、GA4は page_view ではなく scroll や user_engagement といったイベントを最初に記録することがあります。この場合、新セッションの先頭にランディングページの参照元となる page_view が存在しないため、そのセッションのランディングページは (not set) として記録されます。ページを開きっぱなしのブラウザタブや、離席後に戻ってきて操作を再開するユーザー行動が多いサイトほど、この現象の発生率は高くなる傾向があります。

タイムアウトを最大7時間55分へ延長する設定手順

この原因への対処として、セッションタイムアウトの時間を延長する方法があります。GA4の管理画面で「データストリーム」→対象のウェブストリームを選択→「イベントの詳細設定」→「セッションのタイムアウトを調整する」の順に進むと、セッションタイムアウトの時間を変更できます。設定可能な上限は7時間55分（475分）で、初期値の30分から延長することで、タイムアウト起点のセッション分割自体を減らせます。MeasureSchoolの解説記事でも、セッションタイムアウトの延長は(not set)対策の実装手段の一つとして紹介されています。

延長の副作用: セッション数・エンゲージメント率への波及

ただしこの設定変更には副作用があります。セッションタイムアウトを延長すると、これまで別セッションとしてカウントされていた再訪問が同一セッションに統合されるため、セッション数は減少します。同時に、1セッションあたりの滞在時間が長くなる分、エンゲージメント率や平均エンゲージメント時間といった指標も上振れします。設定変更の前後でこれらの指標を比較すると、施策の効果ではなく計測条件の変化による見かけ上の改善・悪化を誤読するリスクがあるため、変更した日付を必ず記録し、比較レポートには注記を入れておく必要があります。

原因2: page_viewイベントが発火しない・発火が遅れている

途中で途切れる信号のリレー

page_viewイベントの未発火・発火遅延は、広告流入のランディングページに限って(not set)が集中しているときに最も疑うべき原因です。セッションタイムアウトが仕様起因であるのに対し、こちらは実装起因であるケースが多く、修正の余地が大きい領域でもあります。

GA4設定タグを「初期化」トリガーにする理由

Google タグマネージャー（GTM）でGA4の計測タグを配信している場合、GA4設定タグのトリガーが「すべてのページ」ではなく「初期化」に設定されているかを確認します。トリガーの発火順序は「初期化」「ページビュー」「DOM Ready」「Window Loaded」の順ですが、GA4設定タグが「ページビュー」トリガーで他のタグと並列に配信されていると、コンバージョンタグなど他のタグの処理が先行し、page_view イベントの送信が遅れたり、ページ離脱によって送信されないまま欠落したりすることがあります。Analytics Maniaの解説では、GA4設定タグを「初期化」トリガーに変更することで、セッション開始時の session_start と page_view の欠落を防ぐ実装指針が示されています。

Tag Assistantでpage_viewが最初に飛ぶか確認する手順

実装が正しく機能しているかは、Google Tag Assistant（GA4のデバッグ用拡張機能）で確認できます。対象のランディングページにアクセスし、Tag Assistantのイベントタイムラインで最初に記録されるイベントが page_view であるかをチェックします。もし page_view より前に他のイベント（カスタムイベントやコンバージョンイベント）が記録されている場合、タグの発火順序に問題がある可能性が高いといえます。GTMのプレビューモードと併用し、どのタグがどの順序で発火しているかを合わせて確認すると、原因箇所を特定しやすくなります。

広告LPのリダイレクトでgclidとpage_viewが失われるケース

広告流入に限って(not set)が集中する場合、最も見落とされがちなのがリダイレクトによる gclid（Google 広告のクリックID）の欠落です。広告の最終リンク先URLから、中間ページや別ドメインを経由してランディングページへリダイレクトする導線を組んでいると、リダイレクトの過程で gclid パラメータがURLから引き継がれず失われることがあります。Alex Ignatenkoのブログ記事では、広告の最終URLとランディングページの間に中間LPやリダイレクトチェーンが挟まる構造そのものが、gclidと流入情報の紐づけを断ち切る要因になると指摘されています。日本の広告運用の現場でも、広告管理ツールやLPO(ランディングページ最適化)ツールを経由した多段リダイレクト構成でこの問題が起きやすく、タグの実装以前に導線設計自体を見直す必要があります。リダイレクト経由でのpage_view欠落を深掘りする場合は、GCLIDが遷移先LPで消える原因と3層切り分けで詳細な診断手順を解説しています。

原因3: 深夜0時またぎでセッションが分割される仕様

日付の境界で断ち切られる夜

0時をまたぐセッション分割は、日本語圏の解説記事ではほとんど扱われていない論点ですが、夜間配信の比率が高い広告アカウントほど無視できない影響を持ちます。

0時またぎセッションが(not set)になる理由

GA4のレポート上、セッションは日付が変わるタイミングで強制的に2つのセッションに分割されます。たとえば23時50分に始まったセッションが日をまたいで0時30分まで続いた場合、レポート上は「23時台のセッション」と「0時台のセッション」の2件として集計されます。Analytics Maniaの記事では、この分割によって生まれる後半側のセッションには session_start も page_view も記録されていないため、ランディングページが (not set) になると説明されています。ユーザーの実際の行動としては1回の連続したセッションであっても、GA4の集計仕様上は日付境界で機械的に切断される点が本質です。

夜間配信が多い広告アカウントで影響を確認する方法

この影響の規模を見積もるには、GA4の探索レポートで時間帯別に (not set) の発生比率を確認するのが有効です。「探索」→「自由形式」で、ディメンションに「時間(0-23)」、指標にセッション数と (not set) セッション数を設定し、23時台〜1時台の発生率が他の時間帯より明らかに高いかを見ます。深夜帯に配信量が多い業種(飲食のデリバリー、サブスクリプション系サービス、エンタメ系など)や、深夜割引を訴求する広告アカウントでは、この0時またぎ由来の(not set)が全体の一定割合を占めていることがあります。この原因は実装の不備ではなく仕様そのものによるものなので、修正よりも「どの程度の規模で発生しているか」を把握し、レポート解釈に織り込む対応が現実的です。

原因4: SPA・スパムボット・オーディエンストリガーなどの特殊要因

ここまでの3パターンでカバーしきれない残りの(not set)は、サイトの実装形式や流入品質に起因する特殊要因であることが多く、該当有無を切り分けて個別に対処する必要があります。

SPAでpage_viewが送られない実装の対処

シングルページアプリケーション（SPA）で構築されたサイトでは、ページ遷移時にブラウザの再読み込みが発生しないため、GTMやGA4のデフォルト設定では2ページ目以降の page_view イベントが自動送信されません。初回読み込み時のランディングページ自体は正しく記録されますが、その後の画面遷移がイベントとして計測されず、ユーザー行動の分析に穴が生まれます。対処としては、SPA内のルーティング変更(履歴APIのpushState等)を検知するトリガーをGTMに追加し、画面遷移のたびに page_view イベントを手動送信する実装が定石です。ランディングページの (not set) そのものへの直接的な影響は他の原因より小さいものの、SPA特有の計測漏れとして併せて確認しておく価値があります。

スパムボット流入を副ディメンションで見抜くパターン

スパムボットやクローラーによる流入も、不完全なイベント送信によって(not set)を発生させる要因の一つです。Root & Branch Groupの記事では、ボット流入の特徴として、国別に見たときのエンゲージメント時間やユーザーあたりのページビュー数が不自然に均一に揃っている点を挙げ、探索レポートに国・地域の副ディメンションを追加して目視で見抜く手順を紹介しています。日本国内向けのサイトで、特定の海外リージョンからの流入だけエンゲージメント指標が異様に整っている場合は、ボット流入によるノイズを疑ってよいでしょう。

オーディエンストリガーイベントが(not set)を増やすケース

見落とされやすいのが、GA4のオーディエンス設定に紐づくトリガーイベントの影響です。Optimize Smartの記事では、特定の条件に合致したユーザーに対してオーディエンストリガーで発火するイベントが、通常のセッションの外側(セッションが実質的に終了した後など)で記録されるケースがあり、これが (not set) を増やす一因になると指摘されています。この論点は日本語の解説記事ではほとんど触れられていませんが、複雑なオーディエンス設定を組んでいるアカウントでは確認しておく価値があります。あわせて同記事では、GA4のデータ処理には24〜72時間程度のタイムラグがあり、直近数日分のデータはまだ確定していない状態で (not set) 判定の対象から外して考えるべきだとも述べられています。集計してすぐの数値で一喜一憂しないという運用スタンスは、日本のレポート運用にもそのまま当てはまります。

広告流入のランディングページが(not set)になる時の切り分けフロー

図2: 広告流入(not set)の3ステップ診断フロー

ここまでの4原因を、広告流入で(not set)が急増したときに当日中に特定できる手順として統合します。順番に確認することで、原因を絞り込みながら対応を進められます。

手順1: 探索レポートで(not set)の発生率と偏りを確認する

まず「探索」→「自由形式」で、ディメンションにランディングページとセッションの参照元/メディア、指標にセッション数を設定し、(not set) の発生率を確認します。ここで見るべきは全体に占める比率と、特定のチャネル・時間帯への偏りの有無です。全流入に薄く均等に発生しているならセッションタイムアウトや0時またぎといった仕様起因の可能性が高く、Google広告経由のセッションだけ突出して発生しているなら、実装かリダイレクトの問題を疑う流れになります。

手順2: 広告経由に偏るならgclid・リダイレクトを検証する

Google 広告経由のセッションに偏って(not set)が発生している場合は、原因2で解説したgclidの欠落を優先して確認します。広告の最終リンク先URLから実際のランディングページまでの遷移を実機で辿り、URLパラメータに gclid が引き継がれているかを一つずつ確認します。中間LPやリダイレクトサービスを経由している構成であれば、その経由地点でパラメータが落ちていないかが最有力候補です。あわせて、計測タグが正しく設置されているLPかどうかも確認します。広告出稿後にLPだけ差し替えられ、GTMタグの設置が漏れているケースは実務でよく起きる失敗パターンです。

手順3: 全流入で発生するならタグ実装とタイムアウトを見直す

広告経由に限らず全体的に(not set)が発生している場合は、GTMのGA4設定タグのトリガーが「初期化」になっているかをまず確認し、Tag Assistantで page_view イベントの発火順序をチェックします。実装面に問題が見当たらない場合は、セッションタイムアウトの延長を検討する段階に移ります。ただし前述の通り延長には副作用があるため、変更前にはセッション数とエンゲージメント率への影響を関係者に共有したうえで実施するのが望ましいといえます。GTMのプレビューモードやTag Assistantでのつまずきが多い場合は、GTMプレビュー・Tag Assistantのつまずき診断フローで個別の診断手順を確認してください。

(not set)はどこまで減らせる?放置してよい水準の考え方

(not set) は原因を一つずつ潰していっても、仕様上の要因が残る限りゼロにはならないという前提で運用するのが現実的な考え方です。ここを理解しておかないと、消えない残余分を追いかけて調査コストだけがかさむことになります。

仕様上どうしても残る(not set)

0時またぎのセッション分割や、一定割合発生するタイムアウト再開型のセッションは、GA4の仕様そのものに起因するため、実装をどれだけ改善しても完全にはなくなりません。加えて、広告ブロッカーやプライバシー保護機能によってイベント送信自体がブロックされるケースも一定数存在し、これも実装側の対応では解消できない領域です。Optimize Smartの記事が指摘するように、(not set) の完全ゼロ化を目標に据えるのは現実的ではなく、発生率を継続的にモニタリングし、急激な悪化がないかを見張る運用に切り替えるべきだといえます。目安として、実装・タイムアウト設定を一通り見直した後でも、サイト全体のセッションのうち数%前後の (not set) は仕様上の残余として発生しうると捉え、施策判断に影響しない水準かどうかで許容ラインを検討するのが実務的です。

レポート運用でのカバー方法（ページパス併用など）

(not set) を完全に消せない前提に立つと、レポート側の工夫でその影響を緩和する視点が必要になります。具体的には、ランディングページ単体のディメンションだけでなく、ページパス+クエリ文字列や、イベント単位の page_location パラメータを併用したレポートを組んでおくと、(not set) に埋もれたセッションの一部を別角度から補足できることがあります。また、広告予算の配分判断のように影響の大きい意思決定では、(not set) の発生率が普段より跳ね上がっていないかを確認したうえで数値を読む、という運用ルールを決めておくと、レポートの信頼性を保ちやすくなります。

よくある質問

Q：GA4の(not set)と(other)、Unassignedは何が違いますか？ (not set) はディメンションの値そのものが記録されず欠落している状態を指します。一方 (other) はディメンションの組み合わせがGA4の行数上限を超えた際に、上限を超えた分を集約表示するラベルであり、データ自体は存在しています。Unassigned はチャネルグループの判定において、参照元やメディアの情報がどの判定条件にも合致しなかった場合に表示されるもので、こちらもデータの欠落とは性質が異なります。3つは似た見た目ですが原因も対処法もまったく別物です。

Q：GA4のセッションタイムアウトを延長すると何かデメリットはありますか？ デメリットとして、セッション数が減少する点とエンゲージメント率・平均エンゲージメント時間が上振れする点が挙げられます。これまで別セッションとして分割されていた再訪問が1セッションに統合されるため、施策の前後比較を行う際には、設定変更前後で計測条件が変わっていることを踏まえて数値を読む必要があります。設定を変更した日付は必ず記録し、比較レポートには注記を残しておくことをおすすめします。

Q：(not set)は完全にゼロにできますか？ 完全にゼロにすることは現実的ではありません。0時またぎのセッション分割や広告ブロッカーによるイベント送信のブロックなど、実装の改善だけでは解消できない仕様上の要因が存在するためです。実務では、ゼロを目指すのではなく発生率を継続的にモニタリングし、通常時の水準から大きく逸脱していないかを管理する運用が現実的だと言われています。

Q：広告経由のセッションだけランディングページが(not set)になるのはなぜですか？ 広告経由に限って発生している場合は、主に3つの要因を順に確認します。1つ目はリダイレクトによる gclid パラメータの欠落、2つ目は広告の最終リンク先と実際のランディングページの間に中間LPが挟まっている構造、3つ目は差し替えられたLPに計測タグの設置が漏れているケースです。いずれも導線設計かタグ実装の不備であることが多く、仕様由来の要因とは切り分けて対応する必要があります。

(not set) の切り分けは、原因の性質を見極めるまでが本番で、そこから先の対応は決して難しくありません。真策堂では、広告流入のランディングページ計測が崩れている状況について、原因の切り分けから実装修正までを含めたご相談を受けています。GA4のレポートで数値が消えて判断材料が揃わないとお困りの際は、お気軽にお問い合わせください。