MA（マーケティングオートメーション）とGA4を併用していても、「サイト上の匿名行動が、どのようにリード化・商談化へ効いたのか」を説明できない——この状態は珍しくありません。
理由は単純で、MAは“リード（既知）”の履歴に強く、GA4は“行動（匿名を含む）”に強いものの、両者は同じID・同じ粒度で自動的にはつながらないからです。
本記事の目的は、連携ツールの機能比較ではなく、匿名行動とリードを“つなぐ”ための計測設計を、実務で迷わない形に落とすことです。
結論として押さえるべきは次の3点です。
まず「匿名→既知」に切り替わる瞬間（既知化点）を決める。
次に、既知化点以降の行動を束ねるための識別子（User-IDや内部ID）を決める。
最後に、改善判断に使う重要行動（キーイベント／イベント）を決める。
これらを、同意・欠損がある前提で運用に乗せると、GA4の“行動”とMAの“リード”が一本の線になります。
匿名行動が成果につながらない理由
BtoBでは、リード化（問い合わせ・資料DL・会員登録・セミナー申込など）の前に、比較検討の行動が集中します。
ところが、MAで見えるのは原則として“既知になってから”の履歴です。
一方、GA4で見えるのは“匿名を含む行動”ですが、誰がホットか（営業が動けるか）までは直結しません。
この断絶があると、改善が「PVの多いページを直す」「メール配信を増やす」といった“成果との距離が分かりにくい打ち手”に寄ります。
逆に、匿名行動→既知化→成果の筋が見えると、改善対象は「成果に効く導線」「意図の濃い行動」に絞れます。
さらに、同意取得やブラウザ制約で計測は欠損しやすくなっています。
だからこそ、100%の把握を狙うよりも、欠けても判断できる設計（KPIの置き方・検証手順・変更管理）が重要になります。
最初に押さえる前提 GA4で“やっていいこと／ダメなこと”
PIIは送らない（メール、電話番号など）
GA4では、個人を特定できる情報（PII）をGoogleに送信しないことがポリシーとして求められています。
メールアドレスや電話番号などはもちろん、URLパラメータやフォーム値、検索語に混入する形でも問題になり得ます。
「自社では意図していないのに混ざる」ケースが多いので、実装時だけでなく運用でも点検できる前提を置きます。
User-IDにPIIを使わない
User-IDとは、GA4に搭載されている機能の一種で、自社の会員IDやログインIDなど、ユーザーごとに一意に割り当てられたIDをGA4に連携する機能です。
この機能を使うと、ユーザーが異なるデバイスやブラウザからwebサイトにアクセスした場合でも「同一人物」として計測可能になります。
重要なのは、User-IDにメールアドレス等のPIIを入れないことです。PIIを送らないという原則は、User-IDを使う場合でも同様に守る必要があります
一致率100%は狙わない
GA4（ユーザー／セッション／イベント）と、MA（リード／反応／スコア）は粒度が異なり、同意状況によっても差が出ます。
数値の完全一致を目標にすると設計が止まります。
先に「この数字で何を判断するか」を決め、判断可能な精度まで整えるのが現実的です。
MA×GA4で“できること”を5つに整理
MA×GA4で狙える成果を、実務で使える形に5つへ絞ります。
- 匿名行動からリード化までの導線（流入→回遊→重要ページ到達→フォーム完了）を見える化できる
- キーイベントを軸に改善できる
- ホット化に近い行動（価格・導入条件・比較など）を定義し、MAのスコアリングや配信分岐に戻せる
- チャネルを“量”ではなく“質”（キーイベント率や重要ページ到達率）で評価できる
- ナーチャリングの次の一手を「どこで止まったか」「何を見たか」から具体化できる
“つなぐ”設計の全体像 匿名→既知→成果を一本の線にする
「つなぐ」は、匿名の全行動を個人へ完全紐付けすることではありません。
BtoBでは同一企業内の複数人・共有端末などがあり、個人単位の精密さは限界があります。
代わりに目指すのは、次の3段を“運用ルールとして”成立させることです。
- 匿名の行動をイベントとして計測する（GA4）
- 既知化点でIDを確定し、以降の行動を束ねる（User-ID／内部ID）
- MA/CRM側の成果（MQL→SQL→商談など）と結び付け、改善に使う
このとき、実装パターンは大きく3つに分かれます。
①User-IDで統合する、②クロスドメインで分断を防ぐ、③BigQueryで外部結合して分析する、の3パターンです。
設計の進め方：最小構成で始める4ステップ
最初から全ての成果を追おうとすると、GA4でのイベントが増え、ID設計が揺れ、運用が破綻します。
おすすめは「問い合わせ完了」など1つの成果だけを対象に、匿名→既知→成果の線を1本通すことです。
設計の進め方の例
※イベントやユーザープロパティをリアルタイムに近い形で確認できるツール。利用にはデバッグモードの有効化が必要。
この4ステップが回ると、計測が「報告」から「改善の武器」に変わります。
“つなぐ”設計① User-IDで「既知ユーザーの行動」を統合する
User-IDの要点は、「サインイン等で既知化した後の行動」を同一ユーザーとして扱えるようにすることです。
実務で重要なのは、技術より運用です。
- 既知化点を明確にする（どの瞬間からUser-IDを付与するか）
- 付与漏れをなくす（ページによって付いたり付かなかったりしない）
- User-IDが途中で変わらないようにする（複数IDの混在を避ける）
- User-IDにPIIを入れない（メール等は不可）
MA側のリードIDと結合する場合も、メールアドレスではなく「問い合わせID」「会員ID」などの内部IDを起点に設計します。
“つなぐ”設計② クロスドメインで「分断」を防ぐ
フォームや予約システムが別ドメインの場合、セッションが切れて参照元が崩れやすくなります。
クロスドメイン計測は、関連ドメイン間のユーザー行動を統合するための設定として、GA4管理画面（データストリーム）から設定する手順が示されています。
誤解が多いポイントは前提条件です。
クロスドメインを成立させるには、各ドメインが「同一GA4プロパティの同一Webデータストリーム（同じ測定ID）」へ送信している必要があります。
ここがずれると、ドメインごとに新しいセッションが始まり、流入評価もキーイベント評価も歪みます。
“つなぐ”設計③ BigQueryで「匿名行動×MA/CRM」を結合して分析する
ログインがなくUser-IDが使いづらい場合は、GA4データをBigQueryへエクスポートし、MA/CRMデータと外部で結合して分析する方法があります。
BigQuery exportは公式にスキーマが提示されており、ユーザー識別の代表例としてuser_pseudo_idやuser_idが扱われます。
ここでの狙いは“個人追跡”ではなく、意思決定に直結する集計です。
例えば、次のような問いに答える形が現実的です。
- キーイベント（問い合わせ等）に至るまで、どのページ群がよく見られるか
- チャネル別に、キーイベント率や重要ページ到達率はどう違うか
- 既知化点の前後で、回遊の深さや閲覧順に差があるか
- 商談化したリードは、既知化前にどんな行動を取りやすいか
同意・欠損前提での読み方 数字が合わないのは“設計”で減らせる
同意が取れないユーザーが増えると、欠損は増えます。
そこで、KPIを「絶対数」から「率・比較」へ寄せます（チャネル別キーイベント率、重要ページ到達率、ステップ間遷移率など）。
欠けても判断できる尺度を先に置くと、改善が止まりません。
実務チェック 明日からの改善に直結する“計測の型”
最後に、運用で迷いがちな論点を「型」としてまとめます。
まず、キーイベントを1つ決め、イベント→キーイベントの順で整備します。
イベント名は命名ルールに従い、予約語・表記揺れを避けます（先頭は英字、英数字とアンダースコア、スペース不可等）。
次に、既知化点でのID設計（User-ID／内部ID）と、クロスドメインなど分断要因を点検します。
最後に、DebugViewで検証し、変更が入るたびに再検証できる運用へ落とし込みます。
まとめ MA×GA4は「統合」ではなく「設計」で成果が決まる
MA×GA4で成果を出す近道は、連携方式の比較より先に、既知化点・ID・キーイベントを決め、同意・欠損前提で読めるKPIを作ることです。
まずは問い合わせなど1つの成果を起点に、定義→実装→検証→改善→MAへの反映という“1本の改善ループ”を回してください。
ループが回り始めると、広告・サイト・メールの議論が同じ指標でつながり、施策の優先順位が自然に決まってくるでしょう。
シーサイドでは、MAツールの導入設計から改善まで幅広く対応させていただいております。
お困りやご相談がありましたら、まずはお気軽にお問い合わせください。
