Google広告の拡張コンバージョンタグにおける電話番号の指定方法を実験

Google広告
効果計測

記事公開日:

Google広告の拡張コンバージョンタグにおける電話番号の指定方法を実験

Google広告で昨年ベータローンチされた機能の1つに「拡張コンバージョン」があります。この機能は、Facebook広告における「コンバージョンAPI」に近い機能となっています。クッキーレス時代におけるコンバージョン計測を行うための機能であり、Cookieだけでなく、コンバージョンしたユーザーの電話番号やメールアドレスなどの個人情報に近い情報を用いて計測の精度を高めるための機能です。

そもそものこの機能の是非にについては各自色々な見解があると思いますし、この記事の主題とはズレるため解説しませんが、この機能を利用するときに気をつけるべき「フォーマット」についての話をしたいと思います。


拡張コンバージョンの概要

拡張コンバージョンの目的

Googleの公式ヘルプには、

拡張コンバージョンは、より正確なコンバージョン測定を可能にする機能です。この機能は既存のコンバージョン タグを補完するもので、自社のウェブサイトで取得したファースト パーティのコンバージョン データをハッシュ化し、プライバシーに配慮した方法で Google に送信します。SHA256 と呼ばれるセキュアな一方向のハッシュ アルゴリズムを使用し、Google に送信する前にファースト パーティの顧客データ(メールアドレスなど)をハッシュ化します。次に、ユーザーがログインしていた Google アカウントとハッシュデータを照合して、キャンペーン コンバージョンをクリックや視聴などの広告イベントと関連付けます。 https://support.google.com/google-ads/answer/9888656?hl=ja

のように説明されています。以前からiOS SafariのITPにおいてCookieの有効期間が短く設定されるようになってしまっています。さらに今後、Google Chromeなど他のブラウザにおいてもCookieに対する制限は強化されていきます。一方で、Google広告をはじめとする様々な広告プラットフォームでは計測やターゲティングのためにCookieを利用しています。Cookieに対する規制が強化されるに伴い、これらの計測やターゲティングの精度も下がってしまいます。

そのような状況下で計測精度を維持・向上させるための手段の1つとして「拡張コンバージョン」が開発されました。

拡張コンバージョンの仕組み

通常のコンバージョン計測は、広告のクリック時に付与されるID(gclid)を広告がクリックされたときにブラウザのCookie上に保存します。そして、コンバージョンタグが実行されるときに、Cookieに保持しているこのCookieの値を計測サーバーに送信します。このgclidは、広告クリック時に一意になるようにGoogle側で割り当てられているため、このgclidの値を見るだけでGoogle側は、「何月何日にどの広告アカウントのどの広告をクリックしたユーザーがコンバージョンしたか」を識別できるようになっています。これにより、コンバージョンが計測されています。

一方で、Cookieに対する規制が強化されると、一定期間でgclidの値が破棄されてしまいます。結果的に何も対処を行わないと、コンバージョンを送信するときにgclidが存在しないため、Google側は「コンバージョンは発生したが、そのユーザーは広告をクリックしていない」と判定してしまいます。つまり、これが計測精度が下がった状態となります。

これに対し、拡張コンバージョン機能を使うと、コンバージョンを送信するときにgclidだけでなくコンバージョンしたユーザーの個人情報をハッシュ化した状態で送信します。Google側はハッシュ化された個人情報を元に、Google内のユーザーデータベースから合致するものを探し出し、そのユーザーが過去一定期間内に広告をクリックしている場合、それをその広告からのコンバージョンと算出することで、計測精度を向上させます。

送信可能なユーザー情報

送信することが可能なユーザー情報は

  • メールアドレス
  • 電話番号
  • 名前と住所

    • 郵便番号
    • 地域
    • 市区町村
    • 番地

となっています。ハッシュ値を元にGoogle側で一致判定を行う関係上、表記のブレが発生しやすい住所(や名前)については(少なくとも日本では)設定したところで計測精度の向上は期待できないかと思います。そのため、基本的には「メールアドレス」「電話番号」を押さえておくのが良いでしょう。

実際、Google広告のヘルプページでも、「メールアドレス」の指定が推奨となっており、「電話番号」を利用する場合はその他の項目と組み合わせて利用する必要がある、といった旨の説明がされています。

グローバル サイトタグを使った拡張コンバージョンの手動導入

フォーマットの問題

問題の概要

拡張コンバージョンは、「ハッシュ化した情報を利用してユーザーマッチングを行う」ことが大前提となる機能なため、「ハッシュ」の仕組みに詳しい人であれば、「ハッシュ化する前のフォーマット」が異なっていれば、ハッシュ化された文字列も異なり、結果としてマッチングしにくいのでは?と気付く人も多いと思います。

実際、住所の表記には

  • マンション名、アパート名の省略の有無
  • 番地の表記方法の違い(-で繋ぐか、"番地"と記載するか、など)
  • 都道府県の省略
  • マンション、アパートの時の"室"の有無
  • 番地などの漢字表記や全角・半角の違い

などにより様々なバリエーションが存在してしまい、結果的にハッシュ化した値でのマッチングは難しいと思います。

一方で、メールアドレスについては、表記が違ってしまえばメールが届かなくなってしまいますので、(大文字・小文字の違い程度)しか表記の揺れパターンがなく、ハッシュ化した値でのマッチング精度は高くなるといえます。

では、電話番号の場合はどうでしょうか。

電話番号の表記にもいくつかのパターンがあります。特に拡張コンバージョンを実装するときに気をつけなければいけないのは、電話番号には、必ず国コードを含めた電話番号にする必要がある点です。つまり、普段みなさんが使っている03や06、090などから始まる電話番号ではマッチングされない点です。また、表記ゆれのパターンには、電話番号の"-"の入れる位置(または"-"を一切入れないパターン)も存在します。

これらのパターンの表記揺らぎに対して、Googleタグマネージャーではハッシュ化する前に事前にテキストクリーニングを行い正規化した上でハッシュ化してくれています。住所の表記については揺らぎパターンが多すぎて確認するのも難しく、また流石のGoogleとはいえ、住所の正規化を行っている気はしないので確認していないのですが、電話番号については表記ゆれのパターンも限定的であり、Google側もある程度の揺らぎには対応している、とのことだったため、本記事で調査してみました。

電話番号の表記揺らぎ調査

ここでは、「080-1111-2222」の電話番号をベースとして表記の揺らぎに対して、最終的にGoogle広告に送信されるハッシュ化済みの文字列がどのようになっているかを調査していきます。

まずは、国コードも正しく指定しているであろう4つのパターンを記載します。

入力値ハッシュ化パラメーターの値
+818011112222tv.1~pn.HO74SRUeQXr3DZNUD6yPpW_6hZpDTIImwxSCHgPcpWI
818011112222tv.1~pn.HO74SRUeQXr3DZNUD6yPpW_6hZpDTIImwxSCHgPcpWI
8180-1111-2222tv.1~pn.HO74SRUeQXr3DZNUD6yPpW_6hZpDTIImwxSCHgPcpWI
(+81)80-1111-2222tv.1~pn.HO74SRUeQXr3DZNUD6yPpW_6hZpDTIImwxSCHgPcpWI

「国コードである"+81"を先頭に追加し、もともとあった先頭の"0"を削除する」方法で国コード付きの電話番号を作成しています。また、作成した国コード付きの電話番号に、「ハイフンを入れる」「+を削除する」「国コードを括弧で囲う」などのバリエーションを試しました。結果、ハッシュ化されたパラメーターの値は全て同一となったため、これらのフォーマットは、「拡張コンバージョンでは同一である」と看做してくれそうです。

続いては、国コード"+81"をつけたものの、もともとあった先頭の"0"を削除していないバリエーションの確認です。

入力値ハッシュ化パラメーターの値
(+81)080-1111-2222tv.1~pn.nZyLkHpEmuFcbORJIuhReBYJqUqNJLpjemoNQ0RNvd4
8108011112222tv.1~pn.nZyLkHpEmuFcbORJIuhReBYJqUqNJLpjemoNQ0RNvd4

このバリエーションでは2つとも同一の値となりましたが、一番最初の「+818011112222」とは別のハッシュ値となってしまいました。結果、このようなフォーマットの電話番号では拡張コンバージョンには利用できない、となります。

続いては、国コードを入れなかった場合です。

入力値ハッシュ化パラメーターの値
080-1111-2222tv.1~pn.AetF62IW9xDPZKjdt9tZogyq4yKfPtODDe7pthdp8F8
08011112222tv.1~pn.AetF62IW9xDPZKjdt9tZogyq4yKfPtODDe7pthdp8F8
080-1-1-1-1-2-2-2-2-tv.1~pn.AetF62IW9xDPZKjdt9tZogyq4yKfPtODDe7pthdp8F8
080(1111)2222tv.1~pn.AetF62IW9xDPZKjdt9tZogyq4yKfPtODDe7pthdp8F8
(080)1111-2222tv.1~pn.AetF62IW9xDPZKjdt9tZogyq4yKfPtODDe7pthdp8F8
080−1111−2222tv.1~pn.e0

こちらも元々の「+818011112222」をハッシュ化した時とは異なるハッシュ値となったため、国コードなしの電話番号では拡張コンバージョンには利用できないようです。また、面白いところは、番号の間に"-"をたくさん入れたとしても、また括弧を入れたとしてもハッシュ値は同じになる点です。つまり、国コードさえ入っていれば、ハイフンの位置や括弧の有無はハッシュ値には影響しないといえます。また、半角でなく全角で電話番号を指定した場合、ハッシュ値は異なるものになってしまいました。おそらく、「tv.1~pn.e0」は電話番号がエラーなどでハッシュできなかったものを表していると考えています。つまり、国コードが入っていたとしても、数字が全角になっていた場合、ハッシュ値が変わってしまうため、拡張コンバージョンは使えないと考えられます。

最後はエラー系の文字列の確認です。

入力値ハッシュ化パラメーターの値
(空文字)tv.1
(null)tv.1
(undefined)tv.1
080_1111_2222tv.1~pn.e0

null文字列や空文字列、undefinedについては上記のような形になるようです。また、電話番号の区切りに"-"ではなく"_"を使った場合もハッシュ化されず、エラーのような結果になってしまいました。

まとめ

今回の記事では、拡張コンバージョンを実装するときの電話番号のフォーマットについて実験をしてみました。結果的に、電話番号に指定する値で気をつけるべきことは、

  • 電話番号の先頭には国コード"+81"を必ず付け、直後の"0"は省略すること。
  • 全角の数字は一切使わず、半角の数値・記号を用いること。

の2点が挙げられます。一方で、「ハイフンをどこで区切るか(またはハイフンを削除すべきか)」「括弧付きの番号」「国コードの先頭の"+"は必要か不要か」についてはGoogleタグマネージャーが自動で正規化してくれるため、一切気にしなくても良い、という結果になりました。

みなさんも、Google広告の拡張コンバージョンを設定する際は参考にしてみてはいかがでしょうか。