この記事の結論:予約から来館・成約までのブライダルフェアの計測は、「サイトの中」はGA4、「会場で起きること」はCRM(顧客管理)に記録し、予約の瞬間に2つをつなぐ鍵を残す設計にします。鍵は、GA4のクライアントIDと流入元(UTM)を、予約フォームの送信と一緒にCRMの予約の記録へ保存することです。来館と成約は、Measurement Protocol かオフラインイベントのインポートで、名前や連絡先を含めずにGA4へ戻せます。ただし、どちらも過去にさかのぼれる期間が短いので、媒体ごとの成約数はCRMの側で数え、GA4は広告や導線の傾向を見る場所として使い分けます。
この記事の内容のご相談は株式会社bundlyzeへbundlyzeのWEB戦略チーム代行について見てみる
フェアの予約は数分で終わりますが、来館は数日後、成約はさらに先になることがあります。この時間差と、会場で起きる出来事をサイトの計測にどう結びつけるかが、婚礼の計測のいちばん難しいところです。この記事では、イベントの名前、UTMの決め方、予約時に残す項目、成約の戻し方を、計測を組む側の手順として並べます。特定の会場の事例や、成約率などの数字は扱いません。
前提:株式会社bundlyzeでは、計測した数字をためて分析するAWSの基盤づくりと、予約管理の仕組みを企画の段階から運用まで手がける仕事をしており、この記事はそこで身につけた設計の考え方をもとにしています。
計測は2つの区間に分け、予約の瞬間に鍵を残す
フェアの計測は、予約の完了を境に2つの区間に分けて考えます。予約までをGA4、予約からあとをCRMが受け持ち、2つをつなぐ情報を予約の時点で保存します。
| 区間 |
起きること |
記録する場所 |
つなぐ鍵 |
| 予約まで |
広告・検索・SNSから来て、フェアを選び、予約する |
GA4 |
クライアントID、UTM |
| 予約の瞬間 |
フォームが送信され、予約番号が発行される |
GA4とCRMの両方 |
上の2つをCRMの予約の記録へ保存 |
| 予約のあと |
来館、見積もり、成約、取り消し |
CRM |
予約番号 |
ここで決めておきたいのは、つなぐ鍵に個人情報を使わないことです。メールアドレスや電話番号で2つを照らし合わせる設計にすると、GA4の側に個人情報が入り込む原因になります。
イベントの名前と、送る項目を表にする
GA4に送るイベントは、名前と送る項目を先に表にしてから実装します。項目には、フェアの種類のような分類だけを入れ、個人や予約を特定できる値は入れません。
| イベント名(例) |
いつ送るか |
送る項目(例) |
キーイベント |
fair_detail_view |
フェアの詳細ページを開いたとき |
フェアの種類 |
しない |
fair_form_start |
予約フォームの最初の項目に触れたとき |
フェアの種類 |
しない |
fair_reserve_complete |
予約の送信が成功したとき |
フェアの種類、予約の人数区分 |
する |
fair_visit |
CRMで来館を記録したとき(後から送る) |
フェアの種類 |
しない |
wedding_contract |
CRMで成約を記録したとき(後から送る) |
プランの区分 |
運用を決めてから |
イベント名は英小文字とアンダースコアで書き、途中で名前を変えないようにします。名前を変えると、変更の前と後が別のイベントとして集計されます。キーイベントは、まず予約の完了だけにしておき、後から送る成約をキーイベントにするかは、下に書く期限の制約を確かめてから決めます。
UTMは、命名の決まりを先に作って小文字でそろえる
InstagramなどのSNS、広告、メールマガジンから予約ページに誘導するリンクには、UTMパラメータを付けます。GA4のヘルプでは、utm_source・utm_medium・utm_campaign をそろえて設定すること、値は大文字と小文字が区別されるので統一することがすすめられています。
| パラメータ |
決めること |
決まりの例 |
utm_source |
どこから来たか |
サービス名を小文字の英字で1通りに書く |
utm_medium |
どの種類の流入か |
有料広告・SNSの投稿・メールなど、種類の一覧から選ぶ |
utm_campaign |
施策の名前 |
「年月」と「フェアの種類」を組み合わせる |
utm_content |
同じ施策の中のどの素材か |
必要なときだけ使う |
決まりは表にして、リンクを作る人全員が同じ表を見ます。担当者ごとに Instagram と instagram のように書き方が揺れると、同じ媒体が別の行に分かれて集計されます。
予約フォームの送信と一緒に、クライアントIDと流入元をCRMへ保存する
GA4とCRMをつなぐには、予約フォームの送信のときに、GA4のクライアントIDと、最初に来たときのUTMを、予約の内容と一緒にCRMへ保存します。こうしておくと、来館や成約が起きたあとでも、その予約がどの媒体から来たかをCRMの中だけで数えられます。
クライアントIDは、gtag の get で取り出せます。取り出した値をフォームの隠し項目に入れて、予約の内容と一緒に送ります。
予約フォームに隠し項目でクライアントIDを入れる(例)html <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の予約の記録には、次の列を用意しておきます。
| CRMの列 |
入れる値 |
使いみち |
| 予約番号 |
予約のときに発行した番号 |
来館・成約の記録とつなぐ |
| GA4のクライアントID |
隠し項目で受け取った値 |
来館・成約をGA4へ戻すとき |
| 最初の流入元 |
最初に着いたときのUTM(なければ参照元) |
媒体ごとの来館数・成約数 |
| 予約の入口 |
自社サイト・電話・比較サイトなど |
GA4に記録されない予約を分けて数える |
電話や比較サイトの中で完了した予約は、GA4には記録されません。この列で入口を分けておけば、GA4の予約数とCRMの予約数が合わない理由を説明できます。
来館と成約は、2つの方法でGA4へ戻せるが、さかのぼれる期間が短い
CRMで記録した来館や成約は、Measurement Protocol で送るか、オフラインイベントのファイルを取り込むことで、GA4へ戻せます。どちらも名前や連絡先は送らず、予約時に保存したクライアントIDで、どの訪問者の出来事かを示します。
| 方法 |
送り方 |
さかのぼれる期間 |
向いている使い方 |
| Measurement Protocol |
サーバーからイベントを1件ずつ送る。APIシークレットはサーバー側だけに置く |
72時間前まで。アトリビューションの処理には48時間以内に届くことが必要 |
来館を記録したその日に送る |
| オフラインイベントのインポート |
CSVファイルをGA4の管理画面から取り込む |
過去2営業日と当日まで。指定しなければ取り込んだ時刻 |
週に1回など、まとめて送る |
Googleの説明では、Measurement Protocol は gtag やタグマネージャーによる自動の収集を補うためのもので、置き換えるものではないとされています。また、オフラインイベントのインポートでは、個人情報をアップロードしたり統合したりすることは許可されていません。
婚礼で気をつけたいのは、成約が予約から何週間も後になることです。どちらの方法でも、成約の日付どおりにさかのぼって記録することはできず、送った時点の出来事として扱われます。そのため、「どの広告から成約が生まれたか」という数え方は、GA4ではなく、CRMに残した最初の流入元で出します。GA4に戻した来館・成約のイベントは、媒体ごとの大まかな傾向を見ることや、来館した人を広告の配信から外すといった使い方に向いています。
GA4に送るもの・送らないものを分ける
GA4に送ってよいのは、分類や件数につながる値だけです。名前・メールアドレス・電話番号といった、本人にたどり着ける情報は、Googleのポリシーに反するため送りません。
| 送ってよいもの |
送らないもの |
| フェアの種類、人数の区分、プランの区分 |
新郎新婦の氏名、メールアドレス、電話番号 |
| クライアントID(GA4が発行したもの) |
予約番号そのもの、CRMの顧客番号をそのままの形で |
| 予約の入口の区分 |
挙式予定日のような、組み合わせると個人に近づく細かい値 |
ユーザーIDの機能を使う場合も、GA4のヘルプでは、第三者が個人の特定に使える情報をユーザーIDに含めないよう求めています。CRMの顧客番号を使いたいときは、計測用に別の値を割り当てる形にします。
自社の中では、クライアントIDも個人情報と一緒に扱う
クライアントIDは、それだけでは誰のものか分かりません。ただ、CRMの中で氏名や連絡先と同じ記録に入れた時点で、自社の中では個人情報と同じように扱う前提で考えます。
個人情報保護委員会のガイドラインでは、ほかの情報と容易に照らし合わせることができ、それによって特定の個人を識別できるものも、個人情報に含まれるとされています。作る側としては、次の点を確かめてから列を追加します。
- プライバシーポリシーに、アクセス解析の結果を予約の対応やサイトの改善に使うことが書かれているか
- CRMの中で、クライアントIDや流入元の列を見られる人を、必要な担当者に絞っているか
- 来館や成約をGA4へ送る処理が、氏名や連絡先の列を読まない作りになっているか
組み上げる順番
計測は、一度にすべてを作らず、予約の完了から順に1つずつ確かめながら広げます。
- イベントの表とUTMの決まりを作る。 関係者が同じ表を見られる場所に置く
- 予約完了のイベントに、キーイベントの印を付ける。 テスト予約を1件入れ、GA4のリアルタイムで届いたかを見る
- CRMに列を足し、隠し項目で値を受け取る。 テスト予約の記録に、クライアントIDと流入元が入っているかを見る
- 入口ごとの数え方を決める。 電話・比較サイトの予約を、CRMで入口を付けて登録する
- 来館・成約を戻す方法を1つ選ぶ。 毎日送れるならMeasurement Protocol、まとめて送るならインポート
- 月に1回、GA4とCRMの予約数を比べる。 ずれが入口の違いで説明できるかを確かめる
自社でやる場合と、任せる場合
計測の設計は、数字を見て次の手を決めるところまでつながって、初めて役に立ちます。自社で進める場合は、イベントの表と UTM の決まりを作って関係者にそろえる計測の担当と、予約フォームの隠し項目から CRM の列へクライアントIDと流入元を保存し、来館・成約を Measurement Protocol かインポートで戻す処理を組める開発の担当が要ります。使い始めた後も、電話や比較サイトの予約に入口を付けて登録し、月に1回 GA4 と CRM の予約数を比べて、ずれが入口の違いで説明できるかを確かめる手間がかかります。クライアントIDを顧客の記録と一緒に持つときの扱いや、プライバシーポリシーの利用目的の書き方といった個人情報保護法に関わる判断は、個人情報保護委員会のガイドラインに当たり、迷うところは専門家に確かめてから決めます。
任せる場合、株式会社bundlyzeでは、計測の設計から数字の読み方、改善の進め方までを外部の担当として受け持つ形をとっています。法令の判断は扱わず、決めたイベントと UTM の決まり、予約の時点で残す鍵を、GA4 と CRM の仕組みに落とす部分を受け持ちます。結婚式場のWeb集客の一部として、フェアやプランのLP運用も行っています。大阪・兵庫を中心とした関西のほか、遠方のご相談もオンラインでお受けしています。受け持つ範囲は、会社サイトの外部Web責任者(Web戦略)のご案内で説明しています。予約から成約までを同じ数え方で追うことが、集客から成約後の業務までの流れのどこに当たるかは、結婚式場の業種別ガイドにまとめています。
出典(一次情報)
いずれも2026年10月2日の時点の公式の記載です。GA4の上限や画面は改定されることがあるので、実装の直前にもう一度目を通してください。