ブライダルフェアの予約から来館・成約までを、GA4とCRMで追う計測の設計

この記事の結論：予約から来館・成約までのブライダルフェアの計測は、「サイトの中」はGA4、「会場で起きること」はCRM（顧客管理）に記録し、予約の瞬間に2つをつなぐ鍵を残す設計にします。鍵は、GA4のクライアントIDと流入元（UTM）を、予約フォームの送信と一緒にCRMの予約の記録へ保存することです。来館と成約は、Measurement Protocol かオフラインイベントのインポートで、名前や連絡先を含めずにGA4へ戻せます。ただし、どちらも過去にさかのぼれる期間が短いので、媒体ごとの成約数はCRMの側で数え、GA4は広告や導線の傾向を見る場所として使い分けます。

フェアの予約は数分で終わりますが、来館は数日後、成約はさらに先になることがあります。この時間差と、会場で起きる出来事をサイトの計測にどう結びつけるかが、婚礼の計測のいちばん難しいところです。この記事では、イベントの名前、UTMの決め方、予約時に残す項目、成約の戻し方を、計測を組む側の手順として並べます。特定の会場の事例や、成約率などの数字は扱いません。

前提：株式会社bundlyzeでは、計測した数字をためて分析するAWSの基盤づくりと、予約管理の仕組みを企画の段階から運用まで手がける仕事をしており、この記事はそこで身につけた設計の考え方をもとにしています。

計測は2つの区間に分け、予約の瞬間に鍵を残す

フェアの計測は、予約の完了を境に2つの区間に分けて考えます。予約までをGA4、予約からあとをCRMが受け持ち、2つをつなぐ情報を予約の時点で保存します。

ここで決めておきたいのは、つなぐ鍵に個人情報を使わないことです。メールアドレスや電話番号で2つを照らし合わせる設計にすると、GA4の側に個人情報が入り込む原因になります。

イベントの名前と、送る項目を表にする

GA4に送るイベントは、名前と送る項目を先に表にしてから実装します。項目には、フェアの種類のような分類だけを入れ、個人や予約を特定できる値は入れません。

イベント名は英小文字とアンダースコアで書き、途中で名前を変えないようにします。名前を変えると、変更の前と後が別のイベントとして集計されます。キーイベントは、まず予約の完了だけにしておき、後から送る成約をキーイベントにするかは、下に書く期限の制約を確かめてから決めます。

UTMは、命名の決まりを先に作って小文字でそろえる

InstagramなどのSNS、広告、メールマガジンから予約ページに誘導するリンクには、UTMパラメータを付けます。GA4のヘルプでは、utm_source・utm_medium・utm_campaign をそろえて設定すること、値は大文字と小文字が区別されるので統一することがすすめられています。

決まりは表にして、リンクを作る人全員が同じ表を見ます。担当者ごとに Instagram と instagram のように書き方が揺れると、同じ媒体が別の行に分かれて集計されます。

予約フォームの送信と一緒に、クライアントIDと流入元をCRMへ保存する

GA4とCRMをつなぐには、予約フォームの送信のときに、GA4のクライアントIDと、最初に来たときのUTMを、予約の内容と一緒にCRMへ保存します。こうしておくと、来館や成約が起きたあとでも、その予約がどの媒体から来たかをCRMの中だけで数えられます。

クライアントIDは、gtag の get で取り出せます。取り出した値をフォームの隠し項目に入れて、予約の内容と一緒に送ります。

<input type="hidden" name="ga_client_id" id="ga_client_id">
<script>
  gtag('get', 'G-XXXXXXXXXX', 'client_id', (id) => {
    document.getElementById('ga_client_id').value = id;
  });
</script>

UTMは、ページを移るたびに消えてしまうので、最初に着いたページで読み取ってブラウザに一時的に覚えさせ、予約の送信時に取り出します。CRMの予約の記録には、次の列を用意しておきます。

電話や比較サイトの中で完了した予約は、GA4には記録されません。この列で入口を分けておけば、GA4の予約数とCRMの予約数が合わない理由を説明できます。

来館と成約は、2つの方法でGA4へ戻せるが、さかのぼれる期間が短い

CRMで記録した来館や成約は、Measurement Protocol で送るか、オフラインイベントのファイルを取り込むことで、GA4へ戻せます。どちらも名前や連絡先は送らず、予約時に保存したクライアントIDで、どの訪問者の出来事かを示します。

Googleの説明では、Measurement Protocol は gtag やタグマネージャーによる自動の収集を補うためのもので、置き換えるものではないとされています。また、オフラインイベントのインポートでは、個人情報をアップロードしたり統合したりすることは許可されていません。

婚礼で気をつけたいのは、成約が予約から何週間も後になることです。どちらの方法でも、成約の日付どおりにさかのぼって記録することはできず、送った時点の出来事として扱われます。そのため、「どの広告から成約が生まれたか」という数え方は、GA4ではなく、CRMに残した最初の流入元で出します。GA4に戻した来館・成約のイベントは、媒体ごとの大まかな傾向を見ることや、来館した人を広告の配信から外すといった使い方に向いています。

GA4に送るもの・送らないものを分ける

GA4に送ってよいのは、分類や件数につながる値だけです。名前・メールアドレス・電話番号といった、本人にたどり着ける情報は、Googleのポリシーに反するため送りません。

ユーザーIDの機能を使う場合も、GA4のヘルプでは、第三者が個人の特定に使える情報をユーザーIDに含めないよう求めています。CRMの顧客番号を使いたいときは、計測用に別の値を割り当てる形にします。

自社の中では、クライアントIDも個人情報と一緒に扱う

クライアントIDは、それだけでは誰のものか分かりません。ただ、CRMの中で氏名や連絡先と同じ記録に入れた時点で、自社の中では個人情報と同じように扱う必要があります。

個人情報保護委員会のガイドラインでは、ほかの情報と容易に照らし合わせることができ、それによって特定の個人を識別できるものも、個人情報に含まれるとされています。作る側としては、次の点を確かめてから列を追加します。

• プライバシーポリシーに、アクセス解析の結果を予約の対応やサイトの改善に使うことが書かれているか
• CRMの中で、クライアントIDや流入元の列を見られる人を、必要な担当者に絞っているか
• 来館や成約をGA4へ送る処理が、氏名や連絡先の列を読まない作りになっているか

組み上げる順番

計測は、一度にすべてを作らず、予約の完了から順に1つずつ確かめながら広げます。

1. イベントの表とUTMの決まりを作る。 関係者が同じ表を見られる場所に置く
2. 予約完了のイベントに、キーイベントの印を付ける。 テスト予約を1件入れ、GA4のリアルタイムで届いたかを見る
3. CRMに列を足し、隠し項目で値を受け取る。 テスト予約の記録に、クライアントIDと流入元が入っているかを見る
4. 入口ごとの数え方を決める。 電話・比較サイトの予約を、CRMで入口を付けて登録する
5. 来館・成約を戻す方法を1つ選ぶ。 毎日送れるならMeasurement Protocol、まとめて送るならインポート
6. 月に1回、GA4とCRMの予約数を比べる。 ずれが入口の違いで説明できるかを確かめる

計測の設計は、数字を見て次の手を決めるところまでつながって、初めて役に立ちます。計測の設計から数字の読み方、改善の進め方までを外部の担当として受け持つ形は、会社サイトの外部Web責任者（Web戦略）のご案内で説明しています。

出典と確認日

いずれも2026年10月2日の時点の公式の記載です。GA4の上限や画面は改定されることがあるので、実装の直前にもう一度目を通してください。

• Google「Measurement Protocol（Google アナリティクス 4）」
• Google「Measurement Protocol でイベントを送る」
• アナリティクス ヘルプ「オフライン イベントのインポート」
• アナリティクス ヘルプ「カスタム URL によるキャンペーン データの収集」
• アナリティクス ヘルプ「User-ID の送信」
• アナリティクス ヘルプ「PII を送らないためのベスト プラクティス」
• 個人情報保護委員会「ガイドライン（通則編）」