電話・チャット問い合わせを広告CVに組み込む計測設計実務｜GTM×Google広告フォワーディング×Meta CAPI連携の実装フロー

この記事のポイント

• コール計測の実装経路はフォワーディング番号・GTMクリックイベント・CAPIオフラインインポートの3種があり、計測精度と実装コストの組み合わせで使い分ける。
• GCLIDとfbclidをCookieに保持してGTMから読み取る設計が、Google・Meta双方の電話問い合わせCV計測の共通起点となる。
• 電話・チャットをスマート入札の学習データとして統合するには、プライマリCV昇格の判断基準とコンバージョン価値の設計を先に決めておく必要がある。
• Meta CAPIで電話問い合わせをオフラインCVとして送る際は、fbclid保持とevent_idによる重複排除をセットで設計することがマッチ率確保の前提条件となる。
• 計測設計はチャネル別（電話・チャット・フォーム）に分けて構築し、マイクロCVとプライマリCVの役割を分けてスマート入札へ段階的に統合するのが定石とされている。

なぜ電話・チャット問い合わせが広告CVとして計測できていないのか

計測されない接触が入札学習を歪める

広告運用でコンバージョン（CV）を設定する際、フォーム送信を計測のゴールとして設定するケースは多い。しかしBtoB・高単価BtoCの業種では、問い合わせの相当数が電話・チャットによって発生しており、フォームCVだけを見ると広告の本当の貢献が見えなくなる。これは計測設計の選択の問題というより、実装難度の差から来る構造的な計測漏れである。

フォーム送信だけ計測している運用の死角

フォーム送信はサンクスページへの遷移やdataLayerへのpushで比較的容易に計測できる。一方、電話問い合わせはユーザーがtel:リンクをタップして電話アプリを起動した瞬間にブラウザのセッションが分断されるため、広告クリックとの紐付けが困難になる。チャットも同様で、外部チャットウィジェットが別フレームで起動する構造をとっていれば、標準的なGTMの設定だけではイベント発火を捕捉できない。

この結果、広告管理画面には電話・チャット問い合わせが一切反映されず、フォーム送信だけのコンバージョンアクションで入札が設計されることになる。

計測漏れがスマート入札学習に与える構造的悪影響

スマート入札（目標CPA・目標ROASなど）はコンバージョンデータの質と量に依存している。電話・チャット問い合わせが計測されていない場合、広告が実際には高頻度のコールを獲得していても管理画面上はゼロCVに見え、入札アルゴリズムはそのトラフィックを「成果のない流入」として低く評価するリスクがある。

Google広告のドキュメントでは、スマート入札が安定して機能するためには一定期間内に十分なCV数が必要とされている。計測漏れによるCV数不足は、学習不足期間の長期化・目標CPAからの乖離・特定媒体の過小評価という形で現れる傾向があるとされている。

電話・チャット・フォームを統一設計する必要性

3チャネルを個別に計測するのではなく、「問い合わせ」という事業ゴールに対してどのチャネルがどれだけ貢献しているかを一元的に把握できる設計が求められる。コンバージョンアクションの種類・価値・プライマリ/セカンダリの分類設計を最初に決めておくことで、後から追加する電話・チャット計測をスマート入札の学習データとしてスムーズに統合できる。計測設計は実装後から遡って直すことが困難なため、この順序が重要になる。

---

計測経路の全体マップ：3ルートの役割と選択基準

図1: コール計測3ルートの選択基準マップ

電話・チャット問い合わせのコール計測には大きく3つの実装経路がある。それぞれ計測精度・実装コスト・対応媒体が異なるため、自社環境と優先度に応じて選択または組み合わせる。

ルート①：Google広告フォワーディング番号（自動コール計測）

Google広告が発行する動的な転送電話番号をWebサイトのLPに表示し、広告経由のクリックと電話発信を自動的に紐付ける仕組みがGoogle広告フォワーディング番号である。広告クリック後にLPを訪問したユーザーが表示番号に電話をかけると、Googleのトラッキングシステムを経由して実際の電話番号に転送され、同時にコンバージョンが記録される。

この方式の利点は、GCLIDを手動で引き回す必要がなく、Google広告管理画面で直接コールデータが確認できる点にある。一方でMeta広告・オーガニック流入など他媒体でのコール貢献は把握できないため、Google広告専任の計測経路として位置付ける必要がある。

ルート②：GTMクリックtoコールトリガー（手動イベント計測）

WebページのtelリンクへのクリックをGoogle Tag Manager（GTM）のクリックトリガーで捕捉し、Google広告コンバージョンタグまたはGA4カスタムイベントとして送信する方式。GCLID保持設計と組み合わせることで、広告クリックと電話タップを後から紐付けられる。

ユーザーが実際に発信したかどうかをクリックだけでは検証できないというトレードオフがあるが、実装コストが低く、Google・Metaを含む複数媒体に横断して対応できる点が強みである。

ルート③：オフラインコンバージョンインポート（CRM着電データ連携）

CTIシステムやCRMに蓄積された着電ログ・商談データを、GCLIDまたはfbclidと紐付けてGoogle広告・Meta広告にオフラインCVとして送り返す方式。この方式は計測精度が最も高く、「架電ではなく実際の商談化」などビジネスゴールに直結したCVを定義できる。

CRMとの連携設計・GCLIDの保存期間管理・定期的なCSVインポートまたはAPI連携の構築が必要で、実装コストは3ルート中最も高い。ただし顧客リストのマッチ率を改善する実務手順で整理した通り、ファーストパーティデータ活用の観点でも最も媒体親和性が高い経路である。

3ルート使い分けマトリックス（計測精度×実装コスト×媒体対応）

ルート	計測精度	実装コスト	Google対応	Meta対応	適した状況
フォワーディング番号	高（発信確認あり）	低	◎	×	Google広告専任・LP型サイト
GTMクリックイベント	中（クリック計測）	低〜中	○	○	複数媒体・早期導入
オフラインCVインポート	最高（CRM着電連携）	高	○	○（CAPI経由）	高単価BtoB・商談CV設計

---

【実装手順】GTM×Google広告フォワーディング番号の設定フロー

図2: GTM×フォワーディング番号の実装フロー

フォワーディング番号の発行条件と日本市場での注意点

Google広告フォワーディング番号は日本市場でも利用可能である。Google広告アカウントで「コンバージョン」→「新しいコンバージョンアクション」→「電話」→「ウェブサイトでの通話コンバージョン」を選択する経路で設定を進める。発行される番号は050番台のIP電話番号になるケースがあるため、業種・サービスによっては固定電話番号との使い分けに配慮が必要なケースもある。なお通話発信型広告（コール専用広告）とはセットアップのプロセスが異なるため、LP表示型のコール計測では「ウェブサイトでの通話コンバージョン」として設定する。

GTMでのクリックトリガー設定とGCLID引き回し設計

フォワーディング番号を使わずGTMでクリックtoコールを計測する場合、まずGCLIDをCookieに保存する設計から着手する。Google広告のクリックURLにはgclidパラメータが付与されるため、GTMのカスタムJavaScript変数でこれを取得し、Cookie（名前は任意、有効期限90日が一般的）に書き込むタグをすべてのページで発火させる。既にCookieに値がある場合は上書きしないロジックを入れることで、最初の広告クリック時のGCLIDを維持できる。

次に、tel:で始まるリンクのクリックを検知するGTMトリガーを作成する。クリックURLが^tel:に一致する正規表現のトリガーを設定し、Google広告コンバージョンタグと紐付ける。コンバージョンタグにはGCLID Cookie変数を渡すことで、広告クリックと電話タップが紐付けられる。

コンバージョンアクション「通話の長さ」しきい値の設計判断

フォワーディング番号を利用したコール計測では、何秒以上の通話をコンバージョンとして扱うかのしきい値を設定する。短すぎるしきい値だと誤発信や間違い電話も含まれ、スマート入札の学習データの質が下がるリスクがある。業種ごとに商談の通話時間が異なるため、初期段階では一般的な目安として60〜90秒以上をコンバージョンと定義し、データが蓄積されてから段階的に引き上げるアプローチが多いとされている。

設定後の動作確認チェックリスト

実装後は以下の順で動作を確認する。

• GTMプレビューモードでtel:リンクのクリックイベントが発火していることを確認
• Google広告管理画面「コンバージョン」でステータスが「データを記録中」になっていること
• Google Tag Assistantで各タグの発火順序とGCLID変数の値が取得できていることを確認
• 実際のスマートフォンで該当リンクをタップし、テストコンバージョンが管理画面に届くか確認（通常24〜48時間のラグがある）

---

【実装手順】Meta広告：CAPIオフラインイベント経由での電話CV送信設計

Cookie規制後の広告計測を守る三層整備実務でも整理した通り、Meta広告においてはサーバーサイド計測であるMeta Conversions API（CAPI）の活用が計測の安定性に直結する。電話問い合わせのCAPIオフラインイベント送信も、この計測基盤の延長として設計する。

fbclidをURLパラメータとして保持するGTM設計

Meta広告からのクリックにはfbclidパラメータがURLに付与される。これをGTMのカスタムHTML変数で取得し、CookieまたはlocalStorageに保存するタグを全ページで発火させる。fbclidの有効期限は7日間が推奨されるが、Meta広告クリックとコンバージョンの時間差を考慮して設計する。

Meta PixelがfbclidをCookieに自動保存する場合もあるが、電話問い合わせのような非ページイベントのオフライン送信ではCRM側からfbclidを手動で引き出す必要があるため、独自名CookieにfbclidをUTF-8文字列として明示的に保存しておく設計が安全とされている。

CAPI「潜在顧客」イベントへの電話問い合わせマッピング設計

CAPIで電話問い合わせを送信する際はLead（潜在顧客）イベントが一般的な選択肢となる。送信するイベントパラメータには最低限event_name・event_time（UnixTimestamp）・user_data（fbclidまたはIPアドレス・UserAgent等のハッシュ化情報）・event_id（重複排除用）を含める必要がある。

user_dataに含めるマッチングキーの精度がマッチ率に直結するため、電話番号・メールアドレス・氏名などのCRM保有データをSHA-256ハッシュ化して一緒に送信することで、Meta Events Managerでの受信精度が向上するとされている。

手動バッチ送信とリアルタイムCAPI送信の選択基準

電話問い合わせデータをCAPIに送信する方式は、CSVを手動でアップロードする「手動バッチ送信」とAPIを経由してリアルタイムに送る「CAPIリアルタイム送信」の2種類に分かれる。

手動バッチ送信はCRMデータを定期エクスポートしてMeta Events Managerからアップロードする方式で、エンジニアリングリソースが少ない環境でも導入できる。ただしイベントタイムスタンプと実際の発生時刻にラグが生じるため、Meta広告の最適化タイミングが遅れる傾向があるとされる。コールが日次で数件程度であれば手動バッチから始め、月次コール数が安定してきた段階でAPI連携に移行する段階的な進め方が現実的とされている。

Meta Events Managerでの受信確認と重複排除設計

CAPIでイベントを送信した後はMeta Events Managerの「テストイベント」機能でペイロードが正しく受信されているか確認する。同一コンバージョンがMeta Pixel経由とCAPI経由で二重カウントされる事態を防ぐ重複排除のため、event_idを両経路で統一した値にする必要がある。一般的にはLPのサーバーサイドで生成したUUIDをlocalStorageに保存し、ブラウザ側のPixelイベントとCAPIの両方に同じevent_idを渡す設計が採用される。

---

チャット問い合わせをCVに組み込む設計パターン

チャットツール別のGTMイベント発火パターン

チャットツールの種類によってGTMでのイベント捕捉方法が異なる。主要なツール別の傾向は以下の通りである。

• Intercom：windowオブジェクト上でemitされる独自イベント（例：intercom:show・intercom:new-conversation）をGTMのカスタムHTMLタグで購読し、dataLayerにpushする
• Zendesk Chat（Zopim）：$zopimオブジェクトのコールバック（例：$zopim.livechat.window.onShow）をGTMタグ内で購読する
• 自社実装チャット：「送信」ボタンへのクリックイベントまたはフォームsubmitイベントをGTMのクリックトリガーで取得し、dataLayerに渡す

GTMで要素が表示されたときに発火するトリガーの設定方法も参照しながら、チャットの「完了」イベントをどのDOMイベントで定義するかを最初に確定させることがGTM設定の先決条件となる。

チャット開始とチャット完了のCV価値設計の判断基準

チャットにはユーザーが入力を開始した「チャット開始」と、オペレーターとの会話が成立した「チャット完了（有人対応）」の2種類のイベントが設計できる。この2つのどちらをプライマリCVとするかは、業種のコールクオリティ（チャット開始者がどの割合で商談化するか）に依存する。

単価が高く商談化率が高い業種では、チャット完了をプライマリCV・チャット開始をマイクロCVとして設定し、スマート入札への統合はチャット完了データを使う設計が多いとされている。チャット開始だけをプライマリCVに設定すると、入札アルゴリズムが質の低い接触を量産する方向に最適化されるリスクがある。

マイクロCVとしてのチャット計測設計とスマート入札学習への活用

スマート自動入札の学習期間を短縮するマイクロCV設計手順でも詳述している通り、CV数が少ない業種ではマイクロCVを段階的に設定することで入札学習を加速させる設計が有効とされる。チャット開始イベントをマイクロCV（セカンダリコンバージョン）としてGoogle広告に設定しておくことで、将来的にスマート入札の入力として活用する準備ができる。この際、チャット開始とチャット完了のCV価値設定を別にしておくことで、入札最適化の方向をコントロールしやすくなる。

---

複数媒体横断の計測統合と運用フロー

複数媒体のデータを統合する視点

GA4カスタムイベントでチャネル別コール数を可視化する設計

電話・チャット問い合わせを媒体別に可視化するためには、GTMからGA4にカスタムイベントを送信する設計が軸になる。イベント名（例：call_click・chat_start・chat_complete）と媒体パラメータ（UTMソースやセッション情報）をセットで送ることで、GA4の探索画面で「チャネル別コール数」を集計できるようになる。

GA4カスタムチャネルグループで有料広告を正確に分離する設定ガイドで解説しているカスタムチャネルグループと組み合わせることで、Google広告・Meta広告・オーガニック検索それぞれのコール貢献を正確に分離して確認できる。

Looker Studio統合ダッシュボードへの接続設計

GA4・Google広告・Meta広告のデータをLooker Studioに統合することで、チャネル別の「コール数・フォーム数・費用・CPA」を一画面で確認できるダッシュボードが構築できる。コール計測のデータが複数ソースに分散している場合は、GA4をデータハブとしてGTMから統一的に送信し、Looker StudioではGA4コネクタを一本化するシンプルな設計が保守しやすいとされている。Looker Studioのフィルタ機能でコンバージョンアクション名を絞り込むことで、電話・チャット・フォームそれぞれの件数を媒体別に並べたレポートが容易に作れる。

月次PDCAフロー：コール計測データを予算配分判断に使う

月次の広告レビューでは、フォームCVに加えてコール数・チャット数を媒体別に集計し、「コール込みのCPA」を評価軸に加える。電話・チャット問い合わせを除いた場合と含めた場合でCPAが大きく変わる媒体があれば、そこがこれまで過小評価されていたチャネルである可能性が高い。この差分を判断材料として予算配分を見直す場合は、BtoB問い合わせLPの「質の低いリード」を減らすフォーム設計実務で整理したリード品質の議論と合わせて、「計測できているCVの質」と「計測漏れのCVの量」を同時に評価する観点が重要となる。

---

計測精度の検証とよくある実装ミス5選

Google広告管理画面でのコンバージョン受信確認手順

Google広告でコール計測の動作確認を行う際は、管理画面の「コンバージョンアクション」詳細ページを確認する。ステータスが「データを記録中」であれば計測が開始されているが、「一致するコンバージョンがありません」が続く場合はタグの発火条件・GCLID受け渡し・コンバージョンアクション設定の対応確認が必要となる。Google Tag Assistantを使ってタグの発火シーケンスをリアルタイムで確認する方法が診断の基本手順とされている。

よくある実装ミス5選と診断チェックリスト

電話・チャットCV計測でよく見られる実装上の落とし穴を整理する。

1. GCLIDのCookie有効期限不足：GCLIDは90日間有効だが、Cookie設定を30日にしてしまい、クリックから時間をおいたコールの紐付けが失敗するケース
2. tel:リンクのhref表記ゆれ：ハイフン・スペースの差異（tel:03-0000-0000とtel:0300000000）でGTMの正規表現トリガーが一致しないケース
3. CAPIのevent_id不一致：ブラウザのMeta PixelとCAPIサーバー送信で異なるevent_idを使い、重複排除が機能せず同一CVが2件カウントされるケース
4. コンバージョンアクションのプライマリ/セカンダリ設定ミス：チャット開始をプライマリCVに設定してしまい、スマート入札が接触数を最大化する方向に最適化するケース
5. フォワーディング番号とGTMクリックイベントの二重計測：同一の電話クリックに対してフォワーディング番号とGTMイベントの両方でCVが記録され、コール数が水増しされるケース

スマート入札統合後の学習期間と入札目標再設定の判断タイミング

電話・チャットCVを新たにプライマリCVとして追加・変更すると、スマート入札の学習が再起動されることがある。この期間はCV定義変更前後のデータを並行して確認しながら変化を観察するアプローチが一般的とされている。入札目標の数値変更は学習期間が安定してから行うのが定石とされており、変更直後の数値の乱れを見て過剰に入札目標を動かすと学習がさらに不安定になるリスクがある。

---

よくある質問

Q：Google広告のフォワーディング番号は日本でも利用できますか？

Google広告フォワーディング番号は日本市場でも利用可能です。Google広告アカウントで「コンバージョン」→「新しいコンバージョンアクション」→「電話」→「ウェブサイトでの通話コンバージョン」を選択することで設定できます。発行される番号は050番台のIP電話番号になるケースがあるため、業種・サービスによっては固定電話番号との使い分けを検討する必要があります。通話発信型広告（コール専用広告）とはセットアップのプロセスが異なる点にも注意が必要です。

Q：GTMで電話番号クリックをGoogle広告のコンバージョンとして計測するにはどう設定しますか？

まずGCLIDをCookieに保存するGTMタグ（カスタムHTML）をすべてのページで発火させます。次に「クリックURL」が^tel:に一致する正規表現のトリガーを作成し、このトリガーを使ってGoogle広告コンバージョンタグを発火させます。コンバージョンタグにはGCLIDのCookie変数をコンバージョンID・ラベルと合わせて渡す設定が必要です。GTMプレビューモードでtel:リンクをクリックして、コンバージョンタグが発火しGCLID変数に値が入っていることを確認してから公開します。

Q：Meta広告のCAPIで電話問い合わせをオフラインCVとして送ることはできますか？

はい、可能です。Meta CAPIのLead（潜在顧客）イベントを使い、電話問い合わせが発生したタイミングでfbclid・event_id・event_time・user_dataをCAPIエンドポイントに送信します。fbclidはCRMシステムに着電ログと合わせて保存しておく設計が必要です。まずはCRMデータをCSVでMeta Events Managerにアップロードする手動バッチ送信から始め、データが安定してからAPIリアルタイム送信へ移行する段階的な導入が現実的とされています。

Q：電話問い合わせ計測でGCLIDはどうやって引き回せばよいですか？

URLに付与されたgclidパラメータをGTMのカスタムJavaScript変数で取得し、document.cookieを使ってCookieに書き込む方法が一般的です。有効期限は90日が推奨されます。Safariのブラウザ制限によってlocalStorageが短期間でクリアされるリスクがあるため、CookieとlocalStorageの両方に保存する二重設計を採用するケースも多いとされています。既にCookieに値がある場合は上書きしないロジックを入れることで、最初の広告クリック時のGCLIDを維持できます。

Q：チャット問い合わせとフォーム送信を同じコンバージョンとして扱っていいですか？

原則として別のコンバージョンアクションに分けて設計することを推奨します。チャット問い合わせとフォーム送信では商談化率・問い合わせ内容の質が異なることが多く、同一CVとして扱うとスマート入札が最適化する方向がずれる可能性があります。Google広告では各コンバージョンアクションにCV価値を設定できるため、チャット・電話・フォームをそれぞれ別アクションで作成し、価値重み付けを行ったうえでtROAS入札に統合する設計が精度向上につながるとされています。チャット開始はマイクロCV（セカンダリ）、フォーム・チャット完了はプライマリCVとして役割を分けるのが定石とされています。

---

真策堂では、電話・チャット問い合わせのコール計測設計から、GTM・Meta CAPI実装のレビュー、スマート入札との統合設計まで、広告計測の構造的な課題に関するご相談を受け付けています。「フォームCVしか計測できていない」「媒体ごとの電話貢献が不明なまま入札している」といった状況にある場合は、計測設計の相談から始めることができます。