BigQuery外注で失敗しない！発注前に確認すべき116のチェックリスト

GA4のデータを蓄積する仕組みを最初に有効にしておかないと、それ以前の数ヶ月分のサイト訪問データは永久に失われます。後から「半年前のキャンペーン効果を見たい」と言っても、参照すべき過去データが存在しません。

「GA4生イベントのBigQuery Export」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

過去行動・CV前行動・ユーザー単位分析の基礎の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

GA4の無料プロパティでは1日1回のエクスポートに制限されています。リアルタイム連携や1日あたりのデータ量上限が業務要件に合わない場合は、有料版GA4(=Google Analytics 360)の検討が必要になります。

訪問者がどのページを見たかの記録です。これが取れていないと、人気のあるページや改善すべきページの特定ができず、コンテンツ強化の判断材料がそもそも存在しなくなります。

「page_view」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

ページ別CVR・LP評価・コンテンツ貢献分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

従来のページ遷移型サイトであれば自動で取得されますが、SPA(=ページが切り替わってもURLが変わらないシングルページアプリ)や動的読み込みのサイトでは発火漏れや二重発火が頻繁に起きます。実装後にDebugViewで実際の動作を必ず確認してください。 当社が手がけたBtoB事業者2社の構築は拡張計測機能の「ブラウザの履歴イベントに基づくページ変更」設定が有効になっていましたが、別途相談を受けた1社のみこの設定が漏れていてpage_viewが正しく取れていない状態を発見しました。GA4の管理画面に入って同じレポートを開いても、設定有無の差で得られるデータが大きく違うため、納品前のチェックが重要です。

訪問者が行動した「時刻」の記録です。これがないと「初めてサイトに来てから問い合わせまで何日かかったか」「広告を見た日とコンバージョン日の間隔は何日か」といった検討期間の分析ができません。

「event_timestamp」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

時系列分析・リードタイム分析・後日CV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

GA4はデータをUTC(=協定世界時、日本時間より9時間遅れ)で保存します。日本のビジネスでは「何時から何時までが今日か」がGA4上で1日ずれて見えることがあるため、レポート作成時はタイムゾーン変換のルールをチームで統一しておく必要があります。

訪問者一人ひとりを区別するための「番号」です。これがないと、同じ人が何度サイトに来ても毎回別人として記録されるため、「ブログを見にきた人が、3回目の訪問で問い合わせをした」のような顧客行動の追跡ができなくなります。

「user_pseudo_id / client_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

匿名ユーザー単位の導線・再訪・CV前行動分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

個人を特定する情報ではありませんが、各ユーザーの行動を追跡できるIDのため、プライバシーポリシーの記載と同意取得の運用が必要です。同意状態が「拒否」のユーザーについては、このIDを使った分析範囲を限定する設計が必要になります。 当社が引き継いだBQでは、user_pseudo_idは正しく記録されていても、それと紐づく顧客IDが空のままで顧客単位の分析が成立しないケースがありました。匿名識別IDだけ取れていても、その先のCRM顧客IDとの紐づけ設計がなければ意味がないことを実案件で繰り返し経験しています。

会員登録した顧客に紐づく番号です。最初からこれを記録しておかないと、スマホで見て後でPCから購入した同じ顧客を「別人」として集計してしまい、顧客一人あたりの売上やリピート率が正しく見えません。

「user_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

匿名行動と顧客行動の橋渡しの用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

メールアドレスや電話番号など個人を直接特定できる情報を、そのままGA4に送ってはいけません。会員IDなど、社内で発行した「個人と紐づくが個人情報ではないID」を使う設計が必要です。 当社がBigQuery構築を引き継いだ某BtoB企業の案件では、user_idフィールドがBQに104,856件記録されていながら全てNULLという状態になっていました。「資料請求された山田様」と「半年後に高額受注された山田様」を同一人物として結合できないため、本来見えるはずの顧客LTVが永久に失われていました。

1回の訪問をひとまとまりとして識別する番号です。これが欠けると、「最初にどのページから入って、何ページ見て、どこで離脱したか」が一連の流れとしてつながらなくなります。

「session_id / ga_session_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

セッション単位のLP・CVR・回遊分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

GA4のセッション定義は30分間操作がないと切れる設定が標準ですが、業務要件によっては変更したくなる場合があります。日付が変わる0時を跨ぐ訪問の扱いも変わるため、集計ルールを事前に決めておく必要があります。

訪問者が一番最初にサイトを知ったきっかけ(=広告・自然検索・SNS・紹介など)を記録する情報です。最初に保存しておかないと、何度かサイトに来た後にコンバージョンした人について「最初の接点はどこだったか」が誰にも分からなくなります。

「初回流入元」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

初回接触別LTV・初回接触別受注率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

何度かサイトに来るユーザーの「最初に知ったきっかけ」を保存する設計です。2回目の訪問で上書きされてしまわないよう、Cookieやファーストパーティのデータベースに保存する仕組み(=first_touch設計)が必要です。

問い合わせや購入の直前に、訪問者がどこから来たかを示す情報です。これがないと「指名検索からの問い合わせが多い」「広告経由が成果につながっている」といった最終決め手の評価ができません。

「直前流入元」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CV直前の流入元・施策評価の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

CV直前の流入元を保存しますが、初回流入元と同じ場所に保存すると上書きされてしまいます。初回と直前は別項目として別々に保存する設計が必要です。

訪問者が最初に着地したページのURLです。記録していないと、SEO流入の入口ページや広告のランディングページの成果が見えず、「どのページを強化すべきか」の判断ができません。

「landing_page」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

LP別のCVR・LTV・流入品質分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

広告のクリックパラメータ(=?utm_source=…等)が付いたURLとそうでないURLを別ページとして集計してしまうケースがよくあります。URL正規化のルールを事前に決めて、集計時に同じページとして扱えるようにしておく必要があります。

問い合わせ・購入・資料請求といった「ゴール」となる行動を計測する設定です。そもそもゴールが設定されていない期間は、何件成果があったのか・どの施策が効いたのかが分析できません。

「CVイベント」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CVR分析・広告最適化・商談化分析の起点の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

一度設定したCVイベント名を途中で変更すると、変更前後のデータが別物として扱われ、過去比較ができなくなります。最初の段階で命名規則を決めて、運用中は変更しないルールが必要です。

コンバージョンが起きた瞬間に開いていたページのURLです。これを記録しないと「どのページで成果が出やすいか」が分からず、成果ページの強化や類似ページの量産ができません。

「CV時点のURL」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CVページ・フォーム別成果分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

送信完了ページが存在せず、画面遷移なしで非同期送信が完了するタイプのフォームでは、CV時点のURLがフォーム入力ページのままになります。フォームの実装方式によって計測設計が変わるため、実装後の動作確認が必要です。

コンバージョンの直前にユーザーが押したボタンやリンクの情報です。これがないと「どの導線・どのバナーが効いたか」が分からず、CTA(=申込ボタン等)の改善が手探りになります。

「CV時点のCTA情報」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CTA別CVR・導線改善の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ページ内のすべてのクリックを取ろうとするとデータが膨大になり、分析しにくくなります。問い合わせ・購入・資料請求など重要なCTAだけに絞って計測する運用が現実的です。

サイトの問い合わせデータと、CRM(=顧客管理システム)側の問い合わせデータを結びつけるための共通の番号です。発行していないと、「広告経由の問い合わせ」と「CRM上のお客様」が同じ人だと認識できず、商談化やLTVの源流を追えなくなります。

「フォーム送信ID」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CV後の商談・受注・LTV連携の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

フォーム送信完了時に、サイト側で一意のIDを発行できる仕組みになっているかを、フォーム制作会社に事前確認してください。WordPressプラグインや既製のフォームによっては発行できないものもあります。

CRMに登録される見込み客の番号です。サイト側のデータに連携していないと、問い合わせをくれた人がその後商談に進んだか、受注したか、いくら売上を生んだかが、広告経由ごとに見えません。

「lead_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

マーケ接点と商談・受注の結合の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

CRMから発行されるリードIDをGA4側に送る場合は、メールアドレスや氏名など個人を特定できる情報を含めない設計が必要です。社内で発行する独自IDのみを送る運用が安全です。

顧客マスタの番号です。これを早い段階でサイト計測と紐づけておかないと、顧客一人あたりのLTV(=生涯売上)や、リピート率を広告経由ごとに集計できなくなります。

「customer_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

顧客360・LTV・粗利分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

匿名のサイト訪問者(=user_pseudo_id)と、会員登録後の顧客(=customer_id)を紐づける橋渡しテーブル(=マッピング表)が必要です。会員登録の瞬間に両IDの対応関係を保存する仕組みを事前に設計してください。

受注や購入の取引番号です。これがサイト計測に渡っていないと、後の返品・キャンセル・粗利と突き合わせができず、表面の売上だけで広告評価することになります。

「order_id / transaction_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

購入重複排除・返金・売上照合の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ユーザーが完了ページをリロードしたり、戻るボタンで再表示したりすると、同じ注文が複数回計測されてしまいます。同じ注文IDを2回目以降は送信しない仕組み(=重複送信防止)が必要です。

Google広告がクリック1回ごとに発行する「印」です。LP到達時にすぐ保存しておかないと、後日コンバージョンや受注が起きてもGoogle広告側に成果として返せず、媒体の自動最適化が機能しません。

「gclid / gbraid / wbraid」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

広告クリック→商談→受注のオフラインCV連携の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

iOS環境やプライバシー保護機能の強いブラウザでは、これらのIDが保存できる期間が短くなっています。同意状態が「拒否」のユーザーについては保存しない判断も必要で、運用ルールを事前に決めてください。 当社相談に来られた別のBtoB SaaS企業様は、フリーランスに10万円台で初期設定を依頼して運用を開始されていました。1年後にgclidが取り戻せず、受注の半分以上がGoogle広告経由だったにもかかわらず広告予算判断が片足走りの状態が続き、最終的に再構築120万円とデータ損失(=過去1年分の顧客IDマッチング不能)を受け入れる判断になりました。

Meta(=Facebook/Instagram)・TikTok・Microsoft広告のクリックごとに発行される「印」です。Googleと同じく、LP到達時に保存しないと、これらの媒体側に成果を返せず広告効果が劣化します。

「fbclid / ttclid / msclkid」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

媒体別広告接触とCRM成果の接続の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

各広告媒体は独自の仕様変更を頻繁に行うため、新しいクリックIDが追加されたり、保存ルールが変わったりします。半年に1回程度、各媒体の公式ドキュメントで最新仕様を確認する運用が必要です。

ユーザーが「データ計測に同意したか」「広告利用に同意したか」の状態です。各時点で記録しておかないと、後から「このデータは法律上使ってよいか」を判断できず、過去データの利用可否が不明になります。

「同意状態」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

利用可能データ範囲の判断・法務確認の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

GA4タグや広告タグが発火する前の段階で、ユーザーの同意状態を確実に反映できる順序で実装する必要があります。順序が逆になると、同意なしのデータが計測されてしまい、コンプライアンス上の問題になります。

同意を取得した時に表示していた利用規約やプライバシー文言の版数です。後で文言を改定した時、「過去の同意者はどの版で同意したか」を追跡できないと、説明責任が果たせなくなります。

「consent_version」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

同意履歴の監査・法務確認の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

利用規約やプライバシーポリシーを改定した場合、改定前後で同意の意味が変わります。各時点でどの版の規約に同意したかを管理しておかないと、規約改定時に「過去の同意者は新版に同意したか」が説明できなくなります。

訪問者のスマホ/PC種別、ブラウザ、地域などの環境情報です。GA4で標準的に取れますが、保持期間設定や粒度の選び方によっては、後から細かい属性別の分析ができなくなります。

「デバイス・ブラウザ・地域」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

端末別CVR・表示崩れ・地域別分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

地域情報の粒度を細かくしすぎると(=市区町村単位など)、個人の特定リスクが上がります。プライバシーポリシーで明示する範囲と、内部で保持する粒度のルールを事前に決めてください。

訪問者がサイトに来る直前にいた外部ページのURLです。GA4標準で取れますが、リダイレクト経由や一部メールアプリ経由では欠落することがあり、欠けた分は復元できません。

「参照元URL / page_referrer」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

外部導線・内部導線・参照元分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

メールアプリ、一部スマホアプリ、HTTPSからHTTPへの遷移など、参照元が取得できないケースが一定割合で発生します。参照元が「(direct)」「(not set)」と表示されるデータも、特定のパターンとして分析対象に含める運用が必要です。

広告URLに付ける、媒体名を示す印です。これを付けていないと「Yahoo広告から来た」「メルマガから来た」のような流入元の区別ができず、媒体別の費用対効果が判定できません。

「utm_source」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

媒体別CVR・LTV・広告/SEO/SNS評価の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

「yahoo」と「Yahoo」と「YAHOO」を別物として集計してしまうトラブルがよくあります。社内で命名規則(=すべて小文字、ハイフン区切りなど)を統一して、広告URLの作成ルールに含めてください。

広告URLに付ける、流入種別の印です(=自然検索・リスティング広告・SNS・メール)。これがないと「自然検索の流入」と「有料広告の流入」が混ざってしまい、広告効果だけを抜き出して評価できません。

「utm_medium」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

チャネル別分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

「paid_social」と「social」と「sns」のように、似た意味の値が複数使われると集計が分散します。あらかじめ使用する値の一覧(=organic, cpc, paid_social, email, referralなど)を固定して、それ以外は使わない運用が必要です。

広告URLに付ける、キャンペーン名の印です。「春のセール」と「夏のセール」がどちらも同じ媒体経由だと、印を付けないと2つが混ざって集計され、施策別の成果評価ができなくなります。

「utm_campaign」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

キャンペーン別CVR・売上・LTV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

広告管理画面のキャンペーン名と一致させておくと、後でデータを突き合わせる時に手間が減ります。キャンペーン名の命名規則を社内で固定して、広告管理側とutm側の両方に同じルールを適用してください。

訪問者が一番最初にサイトに来た時の広告パラメータ一式を保存する仕組みです。最初に保存しないと、何度か訪問した後にコンバージョンしたユーザーについて「初回はどの広告で知ったか」が永久に分かりません。

「初回UTM」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

初回接触別LTV・ブランド貢献分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

一度保存した初回UTMの値を、2回目以降の訪問時に上書きしないよう注意してください。CookieやファーストパーティDBの保存ルールで「初回値は変更しない」ロジックを実装する必要があります。

コンバージョン直前の広告パラメータを保存する仕組みです。標準集計とは別に自社で保存しておくと、媒体別のクリック識別と組み合わせた精度の高い貢献度分析ができます。

「最終UTM」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

ラストタッチ別CV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

初回UTMとは別の項目として別々に保存してください。同じ場所に保存すると、CV直前に上書きされて初回情報が消えてしまいます。

Google・Meta・TikTok・Microsoftなど各広告媒体が発行する、クリックを識別する「印」の総称です。LP到達時に保存しないと、コンバージョン後に媒体側へ成果を返して学習させることができません。

「広告クリックID」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

広告最適化・オフラインCV連携の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同意状態によっては保存自体が許可されないことがあり、また広告媒体側の保存期間も媒体ごとに異なります(=90日や180日など)。各媒体の保存期間と同意ルールを事前に整理して、運用ドキュメントに残してください。

同じキャンペーン内のバナーや投稿の違いを区別する印です。これがないと「Aデザインのバナー」と「Bデザインのバナー」のどちらが効いたかの比較ができません。

「utm_content」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

広告素材別・投稿別・CTA別分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

広告クリエイティブの違いを細かく追跡したい気持ちは分かりますが、バリエーションを増やしすぎると後で集計や管理が破綻します。必要最低限の粒度(=主要クリエイティブ単位)に絞る運用が現実的です。

リスティング広告のキーワードを示す印です。これがないと「どの検索ワードからコンバージョンが出たか」が分からず、入札金額や除外キーワードの調整が手探りになります。

「utm_term」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

キーワード/検索意図別成果分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

リスティング広告では、Google広告などの自動タグ機能(=auto-tagging)がキーワード情報を自動で送ってくれるため、utm_termを手動で付けると重複や競合が起きます。自動タグと手動タグのどちらを使うかをチームで統一してください。

広告媒体側で発行されるキャンペーンの社内番号です。これも自社データに保存しておくと、媒体管理画面とサイト計測データを番号で突き合わせができ、キャンペーン名を変更しても集計が崩れません。

「campaign_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

媒体レポートとGA4/CRMの結合の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

キャンペーン名は運用中に変更されることがありますが、campaign_idは原則変更されません。名称ではなくIDで媒体管理画面と自社データを紐づける設計にしておくと、名称変更に強い分析基盤になります。

広告クリエイティブ(=バナー・動画・コピー)を識別する番号です。これを保存していないと、「どの動画が一番LTVの高い顧客を連れてきたか」のようなクリエイティブ別の深い分析ができません。

「ad_id / creative_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

広告素材別LTV・受注率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

Google広告、Meta広告、TikTok広告など、媒体ごとに独自のIDを持っています。複数媒体を運用する場合は、媒体名とIDの組み合わせで一意に識別できる運用ルールを整える必要があります。

広告クリックから、ランディングページ着地、コンバージョンまでの一連の流れを一人の人物として繋ぐ仕組みです。広告クリック識別と初回流入元の保存がないと、この道筋が分断されます。

「LP別広告接触」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

広告LP別の商談化・受注率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同じLPでも、末尾にパラメータが付いたURLと付いていないURLが別物として扱われると分析が崩れます。URL正規化(=パラメータの扱い方を統一する)のルールを事前に決めてください。

検索広告のキーワード単位の識別番号です。キーワード名は変更されることがあるため、IDで保存しておくとキーワード粒度の受注・LTV分析が長期で継続できます。

「keyword_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

検索意図別の受注・LTV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

検索広告では、媒体側の自動タグ機能でキーワード情報を取得できる場合があります。手動でkeyword_idを付けるかどうかは、自動タグの仕様と業務要件を確認してから判断してください。

フォーム送信ボタンを押した時点の記録です。ここを成果として計測できていないと、そもそも問い合わせ件数自体が把握できず、すべての広告評価の前提が崩れます。

「form_submit」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

問い合わせCVの基礎の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ブラウザ側でCV計測のタグが発火しても、サーバー側で実際にフォームが受信されていないケースがあります(=ユーザーが送信ボタン押下後に通信エラー等)。サーバー側の受信ログとブラウザ側の計測を月次で照合する運用を入れてください。

サイト内に複数あるフォームを区別する番号です。「無料相談」「資料請求」「見積依頼」など複数のフォームがある場合、これがないと「どのフォームから来た問い合わせが多いか」が見えません。

「form_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

フォーム別CVR・商談化率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

フォームの種類(=資料請求・無料相談など)とフォームIDは別の概念です。種類別の分析もしたいのであれば、form_idとform_typeの両方を持つ設計にする必要があります。

送信完了が独立した完了ページで起きるか、画面遷移なしの裏側送信か、サイトの仕組みの種別情報です。種別ごとに計測方法が変わるため、最初に把握していないと後から計測漏れが発覚します。

「completion_page」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CV発火条件の検品の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

完了ページが独立したURLになっている場合、ユーザーがリロードしたり、ブラウザの戻るボタンで再表示したりすると、同じCVが何度も計測されてしまいます。重複送信を防ぐ仕組み(=完了パラメータの確認等)が必要です。

問い合わせをくれたユーザーが、サイトに初めて来た時に着地したページです。コンバージョン直前のページだけ取っていても、最初に興味を持ったページの貢献は見えません。

「first_landing_page」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

初回LP別商談化・受注分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

Cookieが消えるとファーストランディングの情報も失われます。Cookieが消えた後に再訪したユーザーをどう扱うか(=新規ユーザー扱いにするか、別の方法で復元するか)のルールを事前に決めてください。

見込み客のステータス変遷(=リード→有望→商談→受注)の日時データです。CRMが上書き保存型(=過去ステータスが残らない)だと、ファネルのどこで詰まっているかの分析が成立しません。

「CRMステータス変更履歴」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

MQL/SQL/商談/受注までの時系列分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

多くのCRMはステータスを上書き保存する仕様になっており、ステータス変更履歴が残りません。履歴を残せるCRMを選定するか、変更があったタイミングでスナップショットを別テーブルに保存する仕組みが必要です。

受注が確定した日時です。広告クリックから受注までの所要日数を測るゴール地点で、これがないとマーケ施策のROIが正しく出せません。

「受注日時」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

初回接触→受注までの日数分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

「契約書を交わした日」「入金があった日」「会計上の売上計上日」のうち、どれを受注日とするかの定義が必要です。営業・経理・マーケで定義がバラバラだと、月次レポートが部門間で食い違います。

実際の受注額です。サイト計測側に金額を戻していないと、件数だけで広告を評価することになり、「高単価の顧客を連れてくる広告」と「低単価ばかりの広告」の区別ができません。

「受注金額」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

流入元別売上・顧客別LTV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

税込か税抜か、契約金額か実際の売上計上額か、初期費用込みか月額のみか、定義を最初に決めてください。会社全体で同じ定義を使わないと、広告ROIや顧客LTVの数字が部門ごとに食い違います。

フォームの最初の入力欄に手をつけた瞬間を記録する仕組みです。これがないと「フォームに到達したけど書き始める前にやめた人」と「書き始めたけど途中で離脱した人」の区別がつかず、フォーム改善のヒントが取れません。

「form_start」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

フォーム改善・入力開始率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

フォーム入力開始の判定条件を緩くしすぎると、フォーム周辺をスクロールしただけで発火するなどの誤検知が起きます。最初の入力欄に実際にフォーカスが入った時点で発火する条件にする実装が安全です。

フォームの種類を区分する情報です(=無料相談・資料請求・見積相談など)。区分情報がないと、すべての問い合わせが「同じ重み」として集計され、リードの質を分けた分析ができません。

「form_type」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

オファー別・CV種別別の質分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

イベント名(=generate_lead等)だけでフォーム種別を区別しようとすると、複数フォームがある場合に集計しにくくなります。イベント名は統一しつつ、form_typeパラメータで種類を区別する設計が運用しやすくなります。

フォーム送信時に取る「相談内容の種類」(=料金・導入・サポートなど)です。これがないと、件数は取れても「料金問い合わせと導入相談、どちらが受注につながりやすいか」のような質の分析ができません。

「inquiry_category」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

相談内容別商談化・受注率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

相談内容の選択肢として「その他(=自由記入)」を設けると、そこに個人情報が混入することがあります。GA4へ送る情報は選択肢のみに限定し、自由記入欄はCRM側のみで保持する設計が安全です。

マーケティング側で「有望リード」と判定した日時です。問い合わせをもらってから何日で有望と判断できたかの分析に使い、上書きされる前にスナップショットを残しておく必要があります。

「MQL日時」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

リード品質・マーケ貢献分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

MQL(=マーケティング有望リード)の判定基準が運用中に変更されることがあります。基準を変えた場合は変更日を明記し、基準変更前後のデータを分けて分析できるようにしてください。

営業側が「商談対象」として受け取った日時です。マーケから営業への引き渡しスピードを見る指標で、これがないと営業着手が遅れる原因の特定ができません。

「SQL日時」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

マーケ→営業移行の速度分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

MQLとSQL(=営業有望リード)の違いの定義が、マーケ部門と営業部門で食い違うことがよくあります。両部門で合意した定義を文書化し、定期的に見直す運用が必要です。

商談がCRMに登録された日時です。問い合わせから商談化までの所要日数を測る指標で、後から再現するのは困難です。

「商談作成日時」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

商談化率・リードタイム分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

営業担当者が商談を手動でCRMに登録する運用だと、登録忘れや遅延が起きます。「問い合わせから何日以内に商談化したか」のような分析の精度が落ちるため、CRMの自動化機能の活用を検討してください。

商談が失注した理由データです。マーケ側に戻ってくれば、LPの訴求やコピーの改善ヒントになりますが、CRM側で記録していないと永久に活用できません。

「失注理由」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

失注原因別のLP・広告・営業改善の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

自由記述だけだと集計が困難で、分析に活用できません。事前に失注理由の選択肢一覧(=価格・タイミング・競合選定・要件不一致など)を作って、選択式で記録する運用にしてください。

フォーム入力中にエラーが出た項目を記録する仕組みです。これを取らないと「どの入力欄でつまずいて諦める人が多いか」が分からず、フォームの離脱原因を改善できません。

「input_error」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

フォーム離脱原因分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

エラー内容にユーザーが入力した値そのもの(=メールアドレスや電話番号)を送らないでください。「エラーが起きた項目名」だけを送る設計にして、個人情報の混入を防ぐ必要があります。

送信前の確認画面に到達したことを記録する仕組みです。確認画面まで進んだのに送信せず去ったユーザーを把握するために必要で、これがないと「あと一歩で離脱した人」の数が見えません。

「confirmation_view」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

入力→確認→完了の離脱分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

画面遷移なしの非同期フォーム(=確認画面が同じURLで表示される)では、通常のページビュー計測では取れません。フォーム内の状態変化を検知してイベント発火する仕組みを実装する必要があります。

問い合わせ元の業種・企業規模情報です。BtoB事業では特に重要で、これがないと「どの業界のリードのLTVが高いか」が分からず、ターゲット業界の選定が経験頼みになります。

「company_type」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

ターゲット適合度・商談品質分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

会社名そのものを送ると個人情報扱いになる場合があります。GA4へ送るのは「業種コード」「規模カテゴリ」など匿名化された情報に限定し、会社名はCRM側のみで保持してください。

商談を担当した営業担当者の情報です。これがあると「マーケが連れてきたリードは良いが、営業の対応で取りこぼしている」のような切り分けができます。

「担当者」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

担当者差分を除いた施策評価の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

担当者別の数字を「個人の評価」に使うと、CRM入力が後ろ向きになりがちです。あくまで「マーケが連れてきたリードと、営業の対応のどちらが課題か」を切り分ける目的で使う運用ルールにしてください。

ページの種別を分類する情報です(=記事・ランディングページ・事例・料金ページ・FAQなど)。これを記録していないと、種別ごとの集計やコンバージョン貢献度の比較ができません。

「page_type」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

ページ種別別CVR・回遊分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ページのHTML構造から自動的に抽出する方式(=DOM抽出)よりも、CMSやテンプレート側からデータレイヤーに明示的に出力する方式の方が、サイトリニューアル時にも壊れにくく安定します。

記事や商品ごとに振る固定の番号です。記事のURLは後から変更されることがあるため、番号で管理しないと、URLが変わった瞬間に過去のアクセスデータと切れてしまいます。

「content_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

記事単位・商品単位の成果分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

記事URLは運用中にリライトや移動で変わることがありますが、content_idは固定にしてください。URLが変わってもIDで集計が継続できる設計が必要です。

記事カテゴリの情報です。これがないと、カテゴリ別のアクセス数やコンバージョン貢献が見えず、どの分野の記事を強化すべきかの判断ができません。

「article_category」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

カテゴリ別SEO・CV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

カテゴリの再編(=新カテゴリ追加・統合・廃止)が起きた場合、過去のデータをどう扱うかのルールを事前に決めてください。「カテゴリAは2026年4月以降はカテゴリBに統合」のような対応表が必要になります。

記事の公開日時です。「公開から3ヶ月の記事が一番CV率が高い」のような、公開後の経過日数と成果の関係を見るのに必要なデータです。

「published_at」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

公開後経過日数別の成果分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

日付の形式を「2026-05-16」のような国際標準に統一してください。「2026/5/16」「26.5.16」「May 16, 2026」のように形式が混在すると、集計時の並び替えが正しく動かなくなります。

記事の最終更新日時です。リライト前後のアクセス・コンバージョン変化を比較する起点となり、これがないとリライトの効果検証ができません。

「updated_at」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

リライト効果検証の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

誤字修正のような軽微な更新と、内容を大幅に書き直したリライトを同じ「更新日時」として扱うと、リライト効果の分析ができなくなります。大幅改修の場合のみupdated_atを変更する運用ルールが必要です。

記事の訴求テーマ(=コスト削減・効率化・売上向上など)の分類情報です。これがないと、どのテーマがコンバージョン・LTVに効くかが分からず、記事企画の優先順位が決められません。

「content_theme」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

テーマ別の受注・LTV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

記事を作る時に訴求テーマを設定するルールを最初に作っておくと、後の分析が圧倒的に楽になります。後から振り返って分類することも可能ですが、初期から運用する方が精度が高くなります。

記事の役割(=認知段階・比較段階・コンバージョン直前)を示す情報です。これがないと、認知記事と決定打記事の貢献度を分けて評価できません。

「funnel_stage」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

ファネル段階別コンテンツ貢献分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

1記事に「認知用」「比較用」など複数の役割を持たせると、分析時にどの集計に含めるかが曖昧になります。1記事1役割を基本としつつ、複数役割が必要な場合は明確な命名ルールを作ってください。

記事の中にあるコンバージョンボタンが押された瞬間の記録です。最終的にコンバージョンしなくても「興味は持った」というシグナルとして重要で、これがないと興味段階のユーザー数が見えません。

「cta_click」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CTA別CVR・導線分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ページ内のすべてのクリックを計測するとデータがノイズで埋もれます。問い合わせボタン、資料DLボタンなど主要なCTAのみに対象を絞る運用が現実的です。

サイト内に複数あるコンバージョンボタンを区別する番号です。同じページに複数ボタンがある時、どれが押されたかを分けて集計するために必要です。

「cta_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CTA別成果分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

CTAの文言(=「無料で相談する」「今すぐお問い合わせる」など)を後から変更しても、cta_idを変えなければ過去データと連続性を保てます。文言ではなくIDベースで管理する設計が必要です。

コンバージョンボタンの設置位置の情報です(=ファーストビュー・本文中・追従バー・フッターなど)。位置別の成果が見えないと、どこにボタンを置くべきかの判断ができません。

「cta_position」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

表示位置別CTA改善の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

PCとスマホで同じCTAの表示位置が違うこと(=PCでは右側追従、スマホでは下部固定など)があります。レスポンシブの場合の位置情報をどう扱うかのルールを事前に決めてください。

提供しているオファー(=資料DL・無料相談・診断ツールなど)を識別する番号です。オファー別のリード単価や、商談化率の比較に必要です。

「offer_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

オファー別CV品質・商談化分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

オファー(=資料DL・無料相談など)とフォーム種別はセットで管理してください。「資料DLオファー→資料DLフォーム」のような対応関係が分かるように、両方を同時に送信する設計が必要です。

電話番号をタップした瞬間の記録です。スマホで電話コンバージョンが発生する事業では必須で、これがないと電話経由の問い合わせが完全に計測漏れになります。

「tel_click」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

電話問い合わせの導線分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

電話番号タップの計測と、実際に通話が成立したかどうかは別物です。可能であればCTI(=電話と顧客管理を連携するシステム)やコールトラッキングサービスとの連携を検討してください。

資料やPDFがダウンロードされた瞬間の記録です。コンバージョンに準じる重要行動として扱い、これがないと資料DLから商談に至るまでの流れが組めません。

「file_download」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

資料別の見込み度・CV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

GA4の自動計測でPDFダウンロードが取れる場合がありますが、ファイル種別や設置場所によって計測漏れが起きます。重要な資料については個別にイベント設定で計測する運用が確実です。

料金ページが見られた瞬間の記録です。料金を見た後のコンバージョン率は購買意欲の重要指標で、これがないと料金ページの改善判断ができません。

「price_view」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

価格検討層のCVR・商談化分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

「料金ページを開いた」のか「料金表(=ページ内の特定の場所)を見た」のかで意味が違います。どちらを計測対象にするかの定義を事前に決めてください。

導入事例ページが見られた瞬間の記録です。事例を読むユーザーは信頼を確かめている段階で、コンバージョン直前の重要シグナルとして扱うべき行動です。

「case_view」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

事例接触後のCVR・受注率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

事例ページの閲覧と一緒に、どの事例ID(=A社事例・B社事例)を見たかも併せて取得してください。これがないと「事例閲覧者のCV率は高い」までは見えても、どの事例が効いたかは分析できません。

記事の著者情報です。著者別の成果分析や、Googleの評価指標であるE-E-A-T(=経験・専門性・権威性・信頼性)の観点で活用できます。

「author」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

著者別のコンテンツ貢献分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

著者が変更された記事(=リライトを別の著者が担当した場合)の扱いを決めてください。「過去のデータは元の著者のまま」「リライト後は新著者」のどちらにするかをチームで合意しておく必要があります。

コンバージョンボタンの文言情報です。「無料で相談する」と「今すぐお問い合わせる」のような文言テストの効果検証に使います。

「cta_text」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CTA文言別の成果比較の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同じ意味でも「無料相談」「無料で相談する」のように表記が揺れると別物として集計されます。表記の統一ルールを作るか、cta_idで補完する設計が必要です。

チャットウィジェットが起動された瞬間の記録です。チャットを設置している場合、起動から商談化までの貢献度が見えなくなります。

「chat_start」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

チャット起点CV・不安把握の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

チャット起動を取るだけでなく、その後の会話IDや商談化との紐づけも検討してください。チャット単体では「起動した人」と「商談化した人」の関係が見えません。

よくある質問のアコーディオン(=折りたたみ)が開かれた瞬間の記録です。「どの疑問がよく開かれているか」が分かれば、ユーザーの不安箇所をコンテンツで先回り解消できます。

「faq_open」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

よく見られる不安・疑問の把握の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同じFAQを連続で開閉するユーザーがいると、ノイズで集計が膨らみます。短時間の連続発火を除外するロジック(=デバウンス処理)の実装を検討してください。

ECサイトでの購入完了の標準的な記録です。これがないと売上が一切計測できず、EC事業の分析がすべて成立しません。

「purchase」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

EC購入・売上・広告ROAS分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ブラウザ側で計測したpurchaseイベントと、決済システム側の実際の売上が、ズレることがあります。決済システム側のデータを正として、月次で照合する運用を入れてください。

購入された金額の情報です。購入完了の記録と一緒に金額が送られていないと、件数は取れても売上の数字が取れず、投資対効果や顧客単価が分かりません。

「value」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

売上ベースのCV評価の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

税抜売上を送るか、税込売上を送るか、最初に統一してください。一度ルールを決めたら途中で変更しないでください。変更すると過去比較ができなくなります。

粗利の情報です。商品ごとの原価データと結合できないと、売上ベースでの最適化となり、本来見るべき粗利ベースの正しい投資判断ができません。

「gross_profit」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

粗利ROAS・利益貢献分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

粗利情報は機微情報のため、GA4に直接送ると外部公開リスクがあります。BigQuery側で売上データと原価データを結合して粗利を算出する方が、セキュリティ面で安全です。

通貨の種類を示す情報です。海外向けに複数通貨で販売している場合、これが欠けると円とドルが同じ数字として集計され、売上が完全に壊れます。

「currency」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

多通貨・海外分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

日本円のみの販売であってもcurrencyに「JPY」を明示しておくと、将来海外展開する時に過去データとの整合が取れます。

購入された商品の番号です。これがないと商品ごとの売上分析や、レコメンドの設計ができません。

「item_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

商品別CVR・LTV・広告評価の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

EC側の商品マスタとitem_idを一致させてください。バラバラだと、商品マスタを使った詳細分析(=原価、メーカー、仕入れ先など)との突き合わせができません。

商品のカテゴリ情報です。これがないとカテゴリ別のコンバージョン率やLTVが見えず、品揃え戦略の根拠が取れません。

「item_category」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

カテゴリ別収益分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

カテゴリの階層構造(=大カテゴリ・中カテゴリ・小カテゴリ)を事前に決めてください。「インテリア > 椅子 > オフィスチェア」のような階層を運用ルールで固定する必要があります。

商品単価の情報です。値引きと粗利の分析に必要で、合計金額だけでは単価別の分析ができません。

「price」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

商品別売上・割引影響分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

値引き前の単価と、値引き後の単価のどちらを送るかを統一してください。値引き効果を分析したい場合は、両方を別項目で送る設計が必要です。

返品・キャンセルの情報です。サイト側のデータと結合できないと、表面の売上で広告を評価して、返品込みの実利益で見ると赤字、という事態に気づけません。

「refund」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

実質売上・返品率分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

purchaseイベントが発火した後、返品が発生した場合の処理を決めてください。返品データを別イベントとして送り、後で突き合わせる方式が一般的です。

サブスクリプション(=月額・年額の継続課金)契約の番号です。継続課金型のビジネスでLTVを正しく測るために必須で、これがないと初回購入時点の売上だけで評価することになります。

「subscription_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

継続課金LTV・解約分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

サブスクリプションのIDも、メールアドレスや氏名など個人情報を含めない設計にしてください。社内で発行する独自IDのみを使う運用が安全です。

商品の名前情報です。番号と一緒に持っておくと商品名変更にも耐えやすく、レポートの読みやすさが上がります。

「item_name」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

商品別の可読性ある分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

商品名は変更される可能性があります。item_idで管理しつつ、item_nameの変更履歴も別途残しておくと、過去レポートの可読性が保たれます。

購入された数量の情報です。これがないと、客単価が高いのは「単価が高い商品が売れているから」なのか「まとめ買いされているから」なのかの区別ができません。

「quantity」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

購入数量・まとめ買い分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

単品販売と「○個セット」販売を同じquantityで扱うと、実際の販売個数が分からなくなります。セット商品の場合の扱いを事前に定義してください。

値引きやクーポンの利用情報です。これがないと、値引きが「リピート購入につながる効果的な投資だったか」「単発で終わってしまったか」の判定ができません。

「discount / coupon」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

クーポン別LTV・粗利分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

値引きやクーポンは粗利を直接圧迫するため、リピート効果や新規獲得効果を含めた費用対効果の分析が必要です。記録があるかどうかで判断の精度が大きく変わります。

サイト分析のためのCookieについて、ユーザーが利用に同意したかどうかの状態です。同意を示すデータをGoogle側に送らないと、Googleが同意状況を判断できず、コンバージョン計測の精度が落ちます。

「analytics_storage」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

計測可否・モデリング影響の把握の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同意管理タグ(=Consent Mode)を、GA4タグや広告タグより先に発火させる順序で実装してください。順序が逆だと、同意なしのデータが先に送信されてしまい、コンプライアンス違反になります。

広告配信のためのCookieについて、ユーザーが利用に同意したかどうかの状態です。同意がないユーザーのデータは広告配信に使えないため、これを正しく送らないとGoogle広告の最適化が劣化します。

「ad_storage」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

広告計測・リマーケ可否判断の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

広告クッキーの利用に関する同意は、法務部門と相談しながら同意文言を整える必要があります。GA4側の設定だけでなく、同意バナーの文言や利用規約との整合性を確認してください。

広告向けにユーザーデータを使うことへの同意状態です。2024年から世界的に必須項目となり、欠けると拡張コンバージョン等の高度な広告機能が使えなくなります。

「ad_user_data」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

拡張コンバージョン等の利用可否判断の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

欧州を含む海外展開を予定している場合、Consent Mode v2(=2024年から強化された同意管理仕様)への対応が必要です。地域や媒体ごとの要件を事前に確認してください。

広告のパーソナライズ(=ユーザー特性に合わせた配信)への同意状態です。これがないとパーソナライズ広告の配信が制限され、広告効果が下がります。

「ad_personalization」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

広告配信・リマーケの制御の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同意を「拒否」したユーザーに対する広告配信の挙動(=パーソナライズなし配信になる等)を、媒体ごとに事前に確認してください。同意拒否ユーザーの広告効果は別途集計する運用が必要です。

ユーザーが「自分のデータは計測に使わないでほしい」と申し出た状態の記録です。これを保存していないと、過去データの中から該当ユーザーを除外する処理ができず、コンプライアンス上のリスクが残ります。

「opt_out状態」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

除外処理・法務対応の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ユーザーが後から同意を撤回した場合、それまでに収集したデータをどう扱うか(=削除するか、利用停止のみか)のルールを事前に決めてください。法務部門と相談の上、運用フローを文書化しておく必要があります。

同意を取得した日時の情報です。後から「このデータが取得された時点で、ユーザーは同意していたか」を法的に確認するために必要です。

「consent_timestamp」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

同意履歴の監査の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同意した時刻の情報はブラウザ側のCookieだけに置かず、サーバー側のデータベースにも保存してください。Cookieは消えることがあるため、法的な説明責任を果たすにはサーバー側保管が必要です。

どこで同意を取得したかの情報です(=サイト上部の同意バナー・会員登録時・設定画面など)。同意の信頼性確認や、同意取得の方法を改善する分析に使います。

「consent_source」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

同意UI改善・監査の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同意取得画面のUIを変更する際は、変更前後で同意の意味が変わらないか確認してください。UI変更時にconsent_sourceの値が変わると、過去データとの連続性が崩れます。

実施したA/Bテスト一つひとつを識別する番号です。同時に複数のテストを走らせている場合、これがないと「どのテストのデータか」が混ざります。

「experiment_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

実験別成果分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

A/Bテストの名前(=「春のLP改善テスト」など)で識別すると、後でテスト名を変更した時に過去データと切れます。最初から数字や英字のIDで管理する設計が安全です。

A/Bテストの「Aパターン」と「Bパターン」のどちらを見たかを示す情報です。これがないとテストの結果集計そのものが成立しません。

「variant_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

バリアント別CVR・LTV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ユーザーがどちらのパターンに割り当てられたかと、実際にそのパターンを画面で見たかは別物です。割り当ての段階で計測するか、表示の段階で計測するかを事前に決めてください。

割り当てられたパターンが、実際に画面に表示されたかどうかの記録です。割り当てだけでなく実表示を取らないと、画面に出る前に離脱したユーザーが分析に混ざります。

「exposure_event」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

接触ベースの実験評価の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

割り当てだけでなく、ユーザーが実際にそのパターンを画面で見たことを記録してください。割り当て後すぐに離脱したユーザーを「テスト効果あり」として集計してしまうと、結果が歪みます。

LPを改修した前と後を区別するバージョン情報です。これがないと、リニューアル前後のパフォーマンス比較が「いつ切り替わったか」の境界が曖昧になります。

「page_version」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

改修前後のCVR・LTV比較の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

同じLPでも、テスト期間の前後で外部要因(=季節、広告予算、競合動向)が変わると単純な期間比較ができません。同時並行でA/Bテストを実施することで、外部要因の影響を排除できます。

A/Bテストでパターンが割り当てられた日時の情報です。時系列で見た時の効果検証に必要で、これがないと初日と数週間後の効果差を分析できません。

「assignment_timestamp」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

テスト期間・露出後行動分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

画面表示前の段階で割り当てだけが行われたユーザーは、実際にはテストの効果を受けていません。割り当て時刻だけでなく、後述のexposure_eventと組み合わせて分析してください。

SNS投稿一つひとつを識別する番号です。同じキャンペーンの投稿でも、投稿別の成果差を見るために、リンクに番号をパラメータとして付ける必要があります。

「SNS投稿ID」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

投稿別サイト流入・CV分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

SNS投稿には固有のURLがありますが、投稿管理ツール内のIDと突き合わせる対応表を別途残してください。SNS側のURLが将来変わる可能性に備えた運用が必要です。

配信した動画を識別する番号です。動画別のコンバージョン貢献度を見るために、YouTubeや自社プレイヤーから番号を送信する設計が必要です。

「動画ID」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

動画別CV・指名検索貢献分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

YouTube内での視聴データ(=平均視聴時間、視聴維持率など)は、GA4側では取得できません。YouTube StudioのデータをBigQueryへ別途連携する仕組みが必要になります。

広告がユーザーに表示された回数の情報です。クリックされなかった広告接触の効果(=見るだけでブランド認知が上がる効果)を見るために、媒体側データを取り込む必要があります。

「広告表示回数」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

ビュースルー・ブランド接触分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

クリックされなかった広告接触の効果(=ブランド認知の向上など)を測定したい場合、ユーザー単位での詳細追跡には媒体側の制約があります。集計レベルのデータでも有用な分析ができる前提で設計してください。

インフルエンサー一人ひとりに発行する識別番号です。これがないと「誰の投稿が一番効いたか」が分からず、インフルエンサーごとの予算配分が判断できません。

「influencer_id」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

インフルエンサー別成果分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

インフルエンサーごとの契約管理表(=報酬体系、契約期間、KPIなど)とinfluencer_idを対応させてください。これがないと、効果分析の結果を次回の予算配分判断につなげられません。

広告ではない自社オーガニックSNS施策の識別情報です。広告以外の自然投稿の効果測定で、専用の印を付ける設計が必要です。

「organic_social_campaign」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

オーガニックSNS施策別分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

広告ではない自然投稿の効果測定では、UTMパラメータの代わりに独自の識別子を投稿リンクに含める運用ルールが必要です。投稿単位での命名規則を事前に決めてください。

SNSのプラットフォーム上で投稿が表示された回数です。サイトに来ない接触はサイト側では計測できないため、各SNSの管理画面から別途取得して集約する必要があります。

「SNS内インプレッション」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

ブランド接触量・指名検索との時系列分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

SNSアプリ内での表示回数はGA4側からは取れません。各SNSの管理画面または公式APIから別途取得して、BigQueryに集約する必要があります。

SNS投稿への「いいね」「保存」「シェア」などのプラットフォーム内行動です。サイト外の行動なのでサイト側では取れず、SNSのAPIから取得する仕組みが必要です。

「SNS内エンゲージメント」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

反応率・保存・シェアと後日CVの分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

SNSの公式APIには無料利用枠の制限や、過去データの取得期間制限があります。データ取得を始める前に、各SNSのAPI仕様と料金体系を確認してください。

動画のどの時点で視聴を離脱したかの情報です。サイト側では取れず、YouTube Studioのデータを取り込む必要があります。

「YouTube視聴維持率」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

動画改善・視聴質分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

YouTube側のAPIまたはデータ転送機能を使って、視聴データをBigQueryへ連携する設計が必要です。YouTubeチャンネルとGoogleアカウントの権限設定も事前に整理してください。

サイト内検索でユーザーが入力した検索ワードです。これを取っていないと「ユーザーが何を探しに来ているか」が分からず、不足コンテンツの発見ができません。

「site_search_query」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

サイト内ニーズ・不足コンテンツ分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ユーザーが入力した検索ワードに、個人情報(=自分の名前、メールアドレスなど)を入力してしまうケースがあります。明らかに個人情報パターンの値を除外するフィルタを実装してください。

一覧ページで適用されたフィルタ条件です。EC・不動産・求人サイトで重要で、これがないと「どの条件で絞り込んだ人が買いやすいか」の分析ができません。

「filter_condition」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

絞り込み条件別ニーズ分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

フィルタ条件の値の粒度(=「価格1万円以上」と「価格範囲: 10000〜」の表記揺れ)が揃っていないと、後で集計しにくくなります。フィルタ値の正規化ルールを事前に決めてください。

「価格の安い順」「新着順」のような並び替え選択の情報です。ユーザーの優先度(=安さ重視か新しさ重視か)が見え、これがないとUI改善の根拠が取れません。

「sort_condition」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

比較検討行動分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ユーザーが並び替えボタンを連打すると、ノイズイベントが大量に発生します。短時間の連続発火を1回にまとめるロジック(=デバウンス処理)の実装を検討してください。

比較機能を使ったかどうかの記録です。比較表を見たユーザーは検討段階が深いシグナルで、コンバージョン率の高いセグメントとして特定できます。

「comparison_action」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

比較検討層のCVR分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

比較機能を使った場合、何と何を比較したか(=比較対象のアイテムID)も併せて保存しておくと、後で「どの組み合わせの比較がCVに繋がりやすいか」の分析ができます。

お気に入り登録や保存ボタンが押された瞬間の記録です。「後でもう一度検討したい」という意図のシグナルで、再訪促進施策のターゲット選定に使えます。

「favorite / save」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

検討度高い行動として分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

お気に入り機能はログイン会員のみが使える設計の場合、ログインIDと紐づけて保存する必要があります。匿名ユーザーのお気に入りもLocal Storage等で保存する場合は、ログイン後の引き継ぎ設計も必要です。

料金シミュレーターや見積ツールに入力された数値の範囲です。「どの予算帯のユーザーが多いか」が見え、価格設計や訴求の改善に使えます。

「calculator_input_range」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

診断結果別CVR分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

料金シミュレーターには、業種コード、想定売上規模など機微情報を入力させる場合があります。入力値そのものではなく、範囲カテゴリ(=「1000万〜5000万円」など)に変換して送る運用が安全です。

決済プロセスの成功・失敗の結果情報です。サイト側の購入完了イベントだけだと決済失敗も含まれて売上がズレるため、決済システム側の結果を突き合わせる必要があります。

「決済成功/失敗」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

売上の正確性・購入失敗分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

決済システム側の「成功」結果を正として、ブラウザ側のpurchaseイベントと照合してください。差分があれば、ブラウザ側計測のどこに問題があるかを月次で点検する運用が必要です。

サイト側で計測したコンバージョンと、サーバー側で実際に受信した時刻を突き合わせるための情報です。広告ブロッカーや離脱でサイト側が計測漏れした分を、サーバー側のログから後から検知できます。

「フォーム送信のサーバー受信時刻」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

CV発火漏れ検知・正確なCV数確認の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

ブラウザ側のGTMタグだけに依存していると、広告ブロッカーや通信エラーで計測漏れが起きてもサイト側で気づけません。サーバー側のフォーム受信ログと月次で照合する運用を入れてください。

予約システムが発行する予約番号です。サイト側のコンバージョンと予約システム側の記録を突き合わせるために必要で、これがないと「どの広告経由の予約が来店・受注したか」が見えません。

「予約完了ID」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

予約完了・来店・商談との接続の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

予約には変更・キャンセルが発生するため、予約IDだけでなくキャンセル履歴も別途連携する必要があります。「予約は取れたが結局来店しなかった」を分析するには両方のデータが必要です。

メール配信の各段階の行動ログです。MAツール(=マーケティングオートメーション)の管理画面ではなくデータベース側に集約しないと、サイト上の行動データと結合した分析ができません。

「メール到達/開封/クリック」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

メール施策別CV・商談化分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

メール開封率はメールクライアントの仕様変更(=Apple Mail Privacy Protection等)で精度が大幅に下がっています。開封率を主要KPIに据えるのは避け、クリック以降の行動を主軸にする設計が現実的です。

チャットでの会話を識別する番号です。これをCRMやサイト行動と紐づけないと、「チャット経由でどれだけ商談化したか」が見えません。

「チャット会話ID」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

チャット起点商談・受注分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

チャットの会話内容には個人情報が含まれることが多いため、会話内容そのものをBigQueryに保存するかどうかは法務部門と相談してください。IDだけ保存して内容は別管理する設計も検討対象です。

バックエンド側で起きるエラーの記録です。コンバージョン直前のエラーがUX問題か技術問題かの切り分けに使い、これがないと「フォーム送信失敗」の原因究明が手探りになります。

「APIエラー」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

フォーム/決済失敗原因分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

フロントエンド側のエラー(=JavaScript実行エラー等)と、サーバー側のエラー(=データベース接続失敗等)は原因が違うため、両者を分けて記録してください。同じ「エラー」として扱うと改善方針が立てられません。

ページの表示速度やJavaScriptエラーの情報です。コンバージョン率の低下が、コピーやデザインの問題なのか、サイトの技術的な問題なのかを切り分けるのに必要です。

「表示速度・エラー」は今回のスコープに含まれていますか。含まれない場合、後から追加する難易度を教えてください。

速度・エラーとCVRの関係分析の用途で使う前提が成立するか、納品前にDebugViewや実データで確認する。

表示速度のすべてのデータをBigQueryに連携すると、データ量が膨大になります。1日単位や1時間単位の集計値を連携するだけでも、改善のヒントは十分に得られます。