体験レッスンの申込をInstagram広告で集めるとき、計測が切れる場所と直し方

この記事の結論：Instagram広告で体験レッスンの申込を集めると、「クリックはあるのに、申込が管理画面に戻ってこない」ことが起きます。原因はたいてい、広告の側ではなく、クリックから入会までの道のりのどこかで計測が途切れていることです。切れやすいのは、着地の時点でクリックIDが落ちる所、申込が別ドメインの予約画面で終わる所、「LINEで予約」でWebの外へ出る所、体験の当日や入会のように店舗で起きる所の4つ。ブラウザのピクセルだけで追いきれない区間は、自社のサーバーからコンバージョンAPIで送り、ピクセルと同じイベントIDを付けて二重計上を防ぐ。この形にしておくと、広告の配信が「申込や入会につながる人」に寄っていきます。

ジムやスタジオで、体験レッスンの申込をInstagram広告で集めるときの、計測の作り方をまとめます。素材の作り方や運用会社への頼み方ではなく、データがどこで途切れ、どうつなぐかという実装の話です。仕様はMetaとGoogleの公式の資料（2026年10月2日に確認）に沿って書いています。

広告のクリックから入会までを、区間に分けて見る

最初に、見込みのお客様が通る道を区間に分け、それぞれ何が計測を受け持つかを書き出します。どこかの区間に「何も受け持っていない」所があれば、そこが切れ目です。

下の4区間それぞれについて、直し方を順に書きます。

切れ目1：着いた時点で、クリックIDが残っていない

Instagram広告のリンクから来た人のURLには、通常、Meta が付ける fbclid というパラメータが入ります。ピクセルはファーストパーティCookieが有効ならこれを読み取り、_fbc という Cookie に残します。後でサーバーからコンバージョンAPIを送るときも、この値（fbc）が「どの広告のクリックか」を結びつける手がかりになります。

ところが、広告のリンク先に短縮URLや、別のURLを経由する転送を挟むと、転送のしかたによってはパラメータが落ちます。確かめ方は単純で、広告のプレビューから実際にリンクを開き、着いたページのアドレス欄に fbclid と UTM が残っているかを見ます。

Cookie が使えない場面に備えて、サーバー側で fbclid から fbc を組み立てる方法も、Meta の資料に書かれています。形式は fb.1.{作成時刻のミリ秒}.{fbclid} です。fbclid は大文字と小文字を区別するので、小文字にそろえるような加工はしないよう注意書きがあります。

const params = new URLSearchParams(location.search);
const fbclid = params.get('fbclid');
if (fbclid && !document.cookie.includes('_fbc=')) {
  // 値は加工しない（大文字・小文字を区別する）
  const fbc = `fb.1.${Date.now()}.${fbclid}`;
  sessionStorage.setItem('fbc', fbc);
}

UTM（utm_source や utm_campaign）は、GA4 で広告ごとの流入を見るための印です。Meta の広告で自動に付く fbclid とは別物なので、広告のURLに自分で付けておきます。

切れ目2：申込の完了を、どの瞬間で数えるかが曖昧

体験の申込を「送信ボタンが押されたとき」に数えると、入力の不備で弾かれた送信や、何度も押した分まで1件になります。数えるのは、サーバーが予約を受け付けて番号を返した後、完了の画面を出す時点にします。

イベントの名前は、Meta の標準イベントから選びます。日時を選んで来店の予約をする行動には Schedule（来店の予約）が用意されています。資料請求のように日時を伴わない申込なら Lead が近いでしょう。GA4 では、推奨イベントの generate_lead を使うと、見込み客の獲得として扱えます。

// bookingId はサーバーが予約を受け付けたときに返した番号
fbq('track', 'Schedule', {}, { eventID: `trial-${bookingId}` });
gtag('event', 'generate_lead', { method: 'trial_lesson' });

完了の画面を再読み込みすると、もう一度送られてしまいます。予約の番号ごとに「送信済み」を覚えておくか、完了の画面を一度表示したら別のURLに置き換えるなどして、同じ申込を2回数えないようにします。

切れ目3：申込が、別ドメインの予約サービスで終わる

体験の予約を外部の予約サービスで受けている場合、申込の完了画面は自社のドメインの外にあります。自社のページに入れたピクセルや GA4 のタグは、そこでは動きません。

直し方は、予約サービスが何を許しているかで変わります。

GA4 のクロスドメイン測定は、管理画面のデータストリームの「タグ設定」にある「ドメインの設定」で登録します。

切れ目4：「LINEで予約」を押すと、Webの外へ出る

体験の受付をLINE公式アカウントにしているジムでは、案内ページのボタンからLINEのアプリへ移ります。この時点で、ブラウザに入れたピクセルも GA4 も、その先を見られなくなります。友だち追加や、トークでの予約の確定は、Webの計測には戻ってきません。

つなぐには、LINEへ移る前に「どの広告から来た人か」をサーバーに預け、LINEの中の予約画面でそれを受け取ります。

1. ボタンを押したとき：サーバーで短い受付キーを発行し、そのキーに fbc、fbp、UTM をひも付けて保存する
2. LINE側の予約画面を、LIFF のURLにキーを付けて開く：たとえば https://liff.line.me/{LIFF ID}/trial?k={受付キー} の形にする。LIFF のURLに付けたパスやクエリは liff.state に入って届き、liff.init() が終わった後で読めるようになる
3. 予約画面からサーバーへ送るとき：LINEのユーザーを示すIDトークンと受付キーを一緒に送り、サーバーでトークンを検証してから、受付キーとLINEのユーザーをひも付ける
4. 予約が確定したとき：サーバーから、保存しておいた fbc などを付けてコンバージョンAPIで Schedule を送る

LIFF の資料には、LIFF のURLがどの環境で開かれるかは保証しない、とも書かれています。外部のブラウザで開かれてキーが受け取れない人も出るので、キーが無い予約は「広告由来か不明」として分けておき、数字を水増ししないようにします。

ボタンのタップそのものを数えておきたい場合は、Meta の標準イベントの Contact（チャットなどで連絡を始める）が近い意味を持ちます。ただし、タップは予約の確定ではないので、広告の最適化の目標にはせず、確定の手前を見るための補助の指標にとどめます（最適化の目標は、あくまで予約の確定）。

株式会社bundlyzeでは、体験の申込のような予約の情報とLINE公式アカウントを結びつける連携を、自社で開発しています。広告から来た人とLINEのユーザーをどの時点で結びつけるかは、そうした連携を作るときに最初に決める項目の一つです。

切れ目5：体験の当日と入会は、店舗で起きる

体験に来たか、その場で入会したかは、Webの外で決まります。ここを広告に返さないと、Meta から見えるのは「申込をした人」までで、「来て、入会した人」に似た人へ配信を寄せることができません。

店舗で起きた出来事は、受付や予約の記録から、サーバーがコンバージョンAPIで送ります。action_source には、店舗での出来事を表す physical_store があります。気をつけたいのは送る時期で、event_time は送信の7日前までしか受け付けられません。月末にまとめて送るような運用だと、古い分がエラーになります。来館の記録が付いた日のうちか、遅くとも毎日の処理で送るようにします。

{
  "data": [{
    "event_name": "TrialToMember",
    "event_time": 1759395600,
    "action_source": "physical_store",
    "event_id": "member-8F21C",
    "user_data": {
      "em": ["<メールアドレスを正規化して SHA-256 でハッシュ化した値>"],
      "ph": ["<電話番号を国番号付きの数字だけにして SHA-256 でハッシュ化した値>"],
      "fbc": "fb.1.1759300000000.AbCdEf..."
    }
  }]
}

em（メールアドレス）や ph（電話番号）はハッシュ化して送る決まりで、電話番号は記号や先頭のゼロを除き、国番号を付けた数字にそろえてからハッシュ化します。fbc や fbp はハッシュ化しません。入会のように標準イベントに当てはまるものが無い出来事は、例のように独自の名前を付けて送れます。

お客様の情報を広告の計測に使うことは、プライバシーポリシーに明記しておきます。申込のフォームの近くからポリシーを読めるようにしておきます。

二重に数えないために：ピクセルとサーバーで同じIDを使う

自社のフォームで申込が終わる場合、ピクセル（ブラウザ）とコンバージョンAPI（サーバー）の両方から同じ申込が届くことがあります。Meta は、event_name が同じで、ピクセルの eventID とサーバーの event_id が一致するものを重複として扱い、1件にまとめます。まとめる対象になるのは、最初の1件が届いてから48時間の間です。

そのため、イベントIDは「申込ごとに一意で、ブラウザとサーバーの両方が同じ値を知っている」ものにします。予約の番号がいちばん扱いやすく、上の例でも trial-{予約番号} の形にしています。Webサイトのイベントとしてサーバーから送る場合は、event_source_url（申込のページのURL）と client_user_agent（ブラウザの情報）も必要です。

直したあと、自分のスマホで通しで確かめる

設定を入れ終えたら、次の順番で、実際の道のりを1回通してみます。

1. 自分のスマホで広告のプレビューからリンクを開き、着いたURLに fbclid と UTM があるかを見る
2. 体験の申込を最後まで送り、Meta のイベントマネージャのテストイベントに、ピクセルとサーバーの両方の Schedule が届き、1件として扱われているかを見る
3. GA4 のリアルタイムで、generate_lead が1回だけ記録されているかを見る
4. LINE経由の道も通し、予約が確定したときにサーバーから Schedule が送られているかを見る
5. テストで作った予約は、予約の記録から消すか、テスト用と分かる印を付けておく

計測が整ってから、素材や配信の比べ方を考えます。広告の運用と計測の設定をまとめて見直したい場合は、bundlyzeのWeb広告のページで進め方を紹介しています。

参考にした公式の資料

確認日はいずれも 2026-10-02 です。

• コンバージョンAPIの概要（Metaのビジネス向けヘルプ）
• ピクセルの標準イベント一覧（Meta for Developers）（標準イベント Schedule・Lead・Contact の意味）
• ブラウザとサーバーのイベントの重複排除（Meta for Developers）（eventID と event_id、48時間）
• サーバーから送るイベントの項目（Meta for Developers）（event_time は7日前まで、action_source の値）
• fbc・fbp の形式（Meta for Developers）（fbc の形式、大文字・小文字の扱い）
• お客様の情報の送り方（Meta for Developers）（ハッシュ化の要否、電話番号の正規化）
• GA4 の推奨イベント（アナリティクス ヘルプ）（generate_lead）
• ドメインをまたぐ測定（アナリティクス ヘルプ）
• UTM でキャンペーンを見分ける（アナリティクス ヘルプ）
• LIFF のURLの開かれ方（LINE Developers）（liff.state、開かれる環境は保証されない）