GTMで電話タップを計測する4つの勘所。広告に乗らない電話CVを取り戻す

スマホで自社サイトを見た人が、画面の電話番号をタップして、そのまま電話をかける。問い合わせの入口として、これは珍しくない動きです。とくに来店・来院・現地相談が必要な業種だと、フォームよりも電話のほうが本命の見込み客だったりします。

ところが多くのサイトで、この「電話タップ」が計測されていません。フォーム送信は管理画面で件数が見えるのに、電話だけは数字に残らない。結果として広告の管理画面には「フォームCV」しか積み上がらず、電話で来た優良客は広告の成果として一切カウントされない状態になります。

これが地味に効いてきます。電話CVを取りこぼしたまま広告を評価すると、本当は電話を多く生んでいるキーワードや広告が「成果が薄い」と判定され、止められてしまう。広告予算の配分が、見えている数字に引っ張られて歪むわけです。

電話を全部見える化する考え方そのものは、サイトに来た電話トラフィックを可視化して広告判断に使う戦略で経営目線でまとめました。本記事はその実装編にあたります。サイト上の電話タップを、Google Tag Manager(GTM＝サイトに計測タグをまとめて設置・管理する仕組み)で確実に拾うための勘所を、つまずきどころと一緒に書きます。

結論：tel計測は「取りこぼし対策」が9割。4つの勘所で決まる

電話タップの計測でつまずく原因は、ほぼ1つです。タップした瞬間にブラウザが電話アプリへ切り替わるので、計測データを送る処理が「送り終わる前」に止まってしまう。普通のやり方だと、タップは起きたのに計測だけが消えます。

なので押さえどころは取りこぼし対策に集約されます。GTMでtel計測を組むときの勘所は、次の4つです。

これだけ押さえれば、GTMでの電話計測は難しくありません。逆にこの4つを知らずに組むと、「コードは正しいのに数字が増えない」で半日溶けます。以降で1つずつ、何をする部品なのかを説明します。

なぜ普通の計測だと電話タップを取りこぼすのか

電話番号のリンクは、HTMLではtel:という形式で書かれています(例：tel:0120-000-000)。これをタップすると、ブラウザは即座に電話アプリ、あるいは発信確認画面へ切り替わろうとします。

問題はこの切り替わりの速さです。計測タグは「タップされた」という情報をサーバーへ送ろうとしますが、よく使われる送信方法(fetchやXMLHttpRequest＝サイトからサーバーへデータを送る一般的な手段)は、送り終わるまでページが生きていることを前提にしています。電話アプリへの遷移でページの処理が中断されると、送信が完了する前にキャンセルされる。とくにスマホ環境でこれが起きやすい。

つまり「タップは起きたのに、計測データがサーバーに届かない」状態になります。広告のCV計測でこれが起きると、実際より少ない電話数しか見えません。冒頭で書いた「広告に乗らない電話CV」の正体は、多くの場合この送信キャンセルです。

ここで使うのがnavigator.sendBeacon(＝ページが閉じたり遷移したりしても、ブラウザが裏で送信を完了させてくれる送信専用の仕組み)です。電話アプリに切り替わってもデータが届く。tel計測のためにあるようなAPIで、勘所1の核になります。

ビフォーアフター：電話計測を入れると何が変わるか

実装の話に入る前に、入れる前と入れた後で何が変わるかを並べます。

効果が一番大きいのは2行目です。電話CVが見えていないと、電話を多く生む広告ほど「CPA(顧客1件あたりの広告費)が高い」と誤判定されます。計測を入れて電話を成果に乗せた瞬間、評価がひっくり返る広告も珍しくない。

実装の中身：トリガーとタグを何で組むか

GTMでの実装は、大きく「いつ動かすか(トリガー)」と「何を送るか(タグ)」の2つ。コードを全文貼るより、何をする部品かで説明したほうが早いはずです。実装する人向けの勘所は次章にまとめます。

トリガー：電話リンクのタップを検知する

GTMには「リンクのクリックを拾う」機能があります。そこに「クリックされたリンクの行き先がtel:で始まるとき」という条件をつけるだけです。これで電話番号のタップだけを狙って計測タグを動かせます。

トリガー種類：リンクのみ
発火条件：クリック先URL が「tel:」で始まる

タグ：タップ情報を組み立てて送る部品

計測タグの中身は、カスタムHTML(＝GTMに自分で書いた処理を持たせる枠)で作ります。やっていることは3つだけ。

1. タップされた電話番号と、ページの情報(URL・流入元など)を1つのデータにまとめる
2. そのデータをsendBeaconでサーバーへ送る
3. 万一sendBeaconが使えない環境なら、予備の送信方法に切り替える

送り先は、サーバーレス関数やCloud Run(＝サーバーを常時持たずに処理だけ動かす置き場)などで受け取って、BigQueryやデータベースに保存します。この送り先の話まで広げると長くなるので、本記事はサイト側のタップ計測に絞ります。タップを正しく拾えるようになった先に、実際の通話実績(電話交換機のログ)と突き合わせる段階がありますが、それはまた別の記事で。

実装者向けの勘所4つ：ここで取りこぼす

ここからは実装担当者、あるいは外注先に確認すべき要点です。tel計測で数字が合わない原因は、だいたいこの4つのどれかに行き着く。

勘所1：送信はsendBeaconを第一に、予備を必ず残す

繰り返しになりますが、電話タップの計測はsendBeaconで送るのが基本です。fetchやXMLHttpRequestを主役にすると、電話アプリへの遷移で送信がキャンセルされ取りこぼします。

ただしsendBeaconが使えない古い端末もゼロではありません。sendBeaconを第一にしつつ、それが失敗したときだけfetchのkeepaliveオプション（ページを離れても送信を続けさせる指定）に切り替える「予備」を1段用意しておく。これで取りこぼしをほぼ塞げます。

勘所2：訪問者IDと広告クリックIDは「使い回す」

計測タグの中で訪問者の識別IDを毎回新しく作ってしまうと、フォーム送信時のIDと電話タップ時のIDが別物になります。同じ人がフォームも見て電話もかけた、というつながりが追えなくなる。

正解は、サイトに先に入っている「訪問者ID生成タグ」「広告クリックID(gclid・yclidなど)取得タグ」の値を、電話計測タグが読みに行って使い回すこと。役割分担はこうなります。

先に動くタグA：訪問者IDを発行して共有の置き場に格納
先に動くタグB：広告クリックID・流入元を取得して同じ置き場に格納
電話計測タグ ：上の2つを読み込んでタップ情報と一緒に送信

こうしておくと、同じ訪問者IDで電話タップとフォーム送信が紐づき、「どの広告から来た人が電話したか」を後で復元できます。広告評価のためにtel計測を入れる以上、ここは外せません。

勘所3：電話番号は数字だけに整える

tel:0120-000-000のようにハイフン入りで書かれた番号を、0120000000のように数字だけに揃えてから送ります。表記がバラバラのままサーバーに溜まると、後で集計したり通話実績と突き合わせたりするときに、同じ番号が別物として扱われて困ります。地味ですが集計の精度に効きます。

勘所4：計測の成否を画面に出さない

最優先は「電話がかかること」です。計測データの送信が失敗しても、ユーザーの発信を1ミリも邪魔してはいけません。サーバーからの返事(成功でも失敗でも)は画面側で完全に無視する設計にします。計測のために本来のCV(電話発信)を犠牲にしたら本末転倒です。

どこまでやるか：ブラウザ側計測とその先

電話の計測には、本記事のサイト側(タップ)計測のほかに、電話交換機のログを使った着信側の計測もあります。両者は役割が違います。

理想は両方を取って突き合わせることですが、いきなり全部やる必要はありません。まずサイト側のタップ計測を入れて「電話を生む広告」を見えるようにするだけでも、広告判断の歪みはかなり減ります。タップ計測の先に通話実績との突合がある、という順番で捉えておけば十分です。

自社でやるか、外注するか

電話タップの計測は、GTMを触ったことがある人なら自社で組めます。判断材料を3点で整理します。

自社でやる場合の難所は、計測タグそのものより「送ったデータをどこで受けて、どう貯めるか」です。受け皿(サーバーレス関数やデータベース)が無いと、タグだけ作っても送り先がなくて完結しません。

逆に、電話タップをただ数えたいのではなく「どの広告から来た電話か」まで追って広告予算の判断に使いたいなら、訪問者IDの設計や流入元との紐づけが絡むぶん、計測設計の経験がある相手に任せたほうが早いです。

こんなケースは無理に入れなくていい

正直に書くと、tel計測の費用対効果が低い場合もあります。

• サイトに電話番号をほぼ載せていない(タップ自体が起きない)
• 電話よりフォーム問い合わせが圧倒的に多く、電話CVを評価に乗せる必要が薄い
• そもそも広告を出しておらず、CVを広告に紐づける動機がない

電話が問い合わせの主要な入口になっていて、かつ広告を回している。この2つが揃っているほど、tel計測の効果は大きくなります。

つまずきポイント：実際にここで詰まる

最後に、実装で実際につまずきやすい点を挙げます。外注先への確認項目にも使えます。

つまずき1：プレビューで動いたのに、本番で数字が増えない

GTMには変更を試す「プレビュー」機能があり、ここでタグの発火を確認して満足してしまうのが定番の落とし穴です。GTMはプレビューで動いても、「公開」ボタンを押してバージョンを公開するまで本番サイトには反映されません。「実装は終わったはずなのに1件も計測されない」の原因が、ただの公開漏れだったというのはよくある話。実装後は、プレビュー確認と公開、その後に実機のスマホで1回タップして数字が増えるかの確認までをワンセットにしてください。

つまずき2：データの送り先と「項目の形」がずれる

サイト側で送るデータの項目構成と、サーバー側で受け取って保存する項目構成は、完全に一致させる必要があります。片方だけ項目を増やすと、その項目が落ちたりエラーになったりします。項目を追加するときは、送る側と受ける側を必ずセットで直す。これは一般的な落とし穴です。

つまずき3：トリガー条件が広すぎてノイズが混ざる

tel:で始まるリンクだけを拾うよう条件を絞らないと、関係ないクリックまで計測タグが動いてしまうことがあります。トリガーの条件は「行き先がtel:で始まる」に限定する。これを忘れると、電話タップ以外のノイズが計測に混ざります。

まとめ：電話CVを広告に乗せる最初の一歩

サイト上の電話タップをGTMで計測する要点は、突き詰めると取りこぼし対策です。

1. sendBeaconで送り、古い端末向けの予備を1段残す
2. 訪問者IDと広告クリックIDは新規生成せず、既存タグの値を使い回す
3. 電話番号は数字に整え、計測の失敗は画面に出さない
4. まずサイト側のタップ計測から入れる。通話実績との突合はその先の話

電話で来た優良客が広告の成果に乗らないまま、見えている数字だけで予算を動かしている。心当たりがあるなら、tel計測はその穴を塞ぐ最初の一手になります。

電話CVの計測・トラッキング設計でお困りなら

電話問い合わせが多いのに、その電話が広告の成果に乗っていない。これは「電話を生む広告ほど低く評価される」という形で、広告判断を静かに狂わせます。GTMでの電話タップ計測は、その穴を塞ぐ入口です。

f2t.jpでは、GTMの計測タグ設置から、流入元との紐づけ・電話CVを含めた広告評価の設計までお手伝いしています。まずは「どの問い合わせが計測できていて、どこに穴があるか」を一緒に洗い出すところから始められます。お問い合わせフォームから、自社の電話CV計測についてご相談ください。