参考文献:
https://note.com/digitalift/n/n73c8bd16aa13
https://allis-co.com/allisblog/3926/

拡張コンバージョンとは

Google広告においてWebサイトのファーストパーティのデータをGoogle広告のエンドポイントに送信することで、ユーザーがGoogleにログインしている場合にそのログインしているユーザーのGoogleアカウント情報(メールアドレスや電話番号)と照合し紐づけることで、より正確にコンバージョン測定を行うための機能である。

ログインしているGoogleアカウントとユーザーが入力したファーストパーティデータは一致する必要はなく、一致していなくても拡張コンバージョンを使用しない場合と同様にコンバージョンとして計測される。
ただし、Googleのアカウント情報と紐付けられることで、以下の事項が最適化されるため、ユーザーが提供したものであれば、Googleアカウント情報とは異なるものでも有用となる(つまりAIに餌を与えるイメージ)。

  • ユーザーの属性情報
  • トランザクションデータ
  • オフラインでのコンバージョン
  • クロスデバイスのコンバージョン追跡
  • 広告のパーソナライズ
  • より詳細なレポーティングと分析

拡張コンバージョンを使用しない場合でも基本的なコンバージョン追跡は依然として機能するが、拡張コンバージョンを使用することによって、サードパーティCookieの廃止によって制限される機能を補完する追加情報を提供することができる。

データ保護について

ファーストパーティデータとGoogleアカウントの情報はハッシュ化され、また現在のユーザーがログインしているGoogleアカウントの情報のみが照合されるため、プライバシーに配慮した安全な仕組みとなっている。
ハッシュ化はAPIにて行われるため、APIにデータを送信する際には平文で送ることができるが、正規化およびハッシュ化されたデータを送信することもできる。

拡張コンバージョンにおける留意点

Google広告をクリックした時点で、ユーザーのログインしているGoogleアカウント情報は取得される。
そのため、ユーザーがGoogle広告をクリックした時点でGoogleにログインしていないと拡張コンバージョンは機能しない。

Google Chromeを使用する場合、いつでもデータの照合を行うことができるにもかかわらず、なぜこういった仕組みを一貫して提供しているかというと、あくまで筆者の推測だが、ブラウザはWebページを閲覧するためのソフトウェアであり、Webページ以外のネットワークトラフィックをブラウザがデフォルトで発生させる、つまりあらゆる行動をGoogleアカウントに紐づけるような挙動は、プライバシーの懸念やブラウザパフォーマンスの低下などを引き起こし、ひいてはブラウザシェアの低下にもつながりかねない。
そのためGoogle広告のクリックというアクション時のみデータの照合を行うことで必要最低限のトラフィックにすることで、ユーザーに安心感とブラウザのパフォーマンスの維持を両立させているGoogleの専売特許的なシステム構造となっていると推察される。

2024/01/25 追記

よく考えるとChromeのシェアが圧倒的ではあるが、それ以外のブラウザを考慮したり、またサードパーティを禁止しているからこそ、ログインしたタイミングしかデータを取得できないため、この構造から逃れることができないのだ。
Chromeを使用する場合は、最初にGoogleアカウントのログインを選択させる画面が出てくるので、これを確実に拡張コンバージョンを取得できるようにするためだと推測できる。

カスタムJavaScriptとは

Google Tag Managerにおける変数をJavaScriptを用いて動的に設定するための仕組みである。

カスタムJavaScriptは値を返す匿名関数の形式の必要があるため、JavaScriptの記述は「function(){」で始まり「}」で終わる形にして、戻り値を設定する必要がある(アロー関数が使えるかどうかは試していない)。

function () {
  return {
    hoge: 100,
  };
}

GTMのトリガーのタイミングを考慮する必要があるが、DOMやグローバル変数、組み込み関数から値を取得することができるため、いわばどのような情報でも取得できるようになる極めて柔軟な機能である。

拡張コンバージョンとカスタムJavaScriptの連携方法について

  1. Google広告にてコンバージョン作成時に「拡張コンバージョンをオンにします」にチェックを入れる
  2. GTMでGoogle広告のコンバージョントラッキングタグの編集画面内の「自社のウェブサイトでユーザーから提供されたデータを含める」にチェックを入れる
  3. 出現するプルダウンから「新しい変数」を選択
  4. ユーザー提供データという変数を作る画面に移動するため、そこで「Type」の選択肢にある「Code」を選択
  5. データソースで任意の「カスタムJavaScript」を選択

変数の「Type」の選択肢である「Code」はひとつの変数で複数の値、つまりカスタムJavaScriptの場合はオブジェクト形式の戻り値を設定し、そのオブジェクトに指定されたキー(任意のキーを送信することはできない)で情報を埋め込む必要がある。
具体的には以下のようなキー名が指定されている。

function () {
  return {
    "email": 'example@gmail.com',
    "phone_number": '81-090-1234-5678',
    // "sha256_email_address": 'ハッシュ化されたメールアドレスを使う場合',
    // "sha256_phone_number": 'ハッシュ化された電話番号を使う場合',
  }
}

公式には一意性が高いとされるメールアドレスを使用することが推奨されており、メールアドレスのみの送信でも拡張コンバージョンは利用することができる。
電話番号のみの送信も許可されているものの、メールアドレスと一緒に送信することが望ましいとされている。
住所などを使用する場合は、氏名、郵便番号、国の情報が揃っている必要がある。

また電話番号を送信する場合、正規化する必要がある。
その場合は、以下の点に留意する必要がある。

①電話番号には「国コード」を含める必要があります
いわゆる、E.164形式と呼ばれるものですが、最初の「0」は別に消す必要ないです。また、最初の「+」もいらないです。
例えば、「090-1234-5678」に国コードつけると、通常は「+81-90-1234-5678」のようになると思いますが、今回使う変数としては「81-090-1234-5678」が取得できていればOKということです。
ちなみに「-」もGoogle側で後で削除しちゃうので、はじめから「-」がなくても構いません。

https://note.com/digitalift/n/n73c8bd16aa13

その他のデータを正規化する場合は以下を行う必要がある。

  • 先頭や末尾の空白文字を削除
  • テキストを小文字に変換

またハッシュ化する場合は、16 進数SHA256を使用する。

その他、詳しくは公式ヘルプを参照いただきたい。
https://support.google.com/google-ads/answer/13262500
https://support.google.com/google-ads/answer/11347292
https://support.google.com/adspolicy/answer/9755941

連携パターン

大前提

どの場合であってもJavaScriptで取得できる形式にする必要があるため、適切なセキュリティ対策と法規制(GDPRやCCPAなど)を遵守しなければならない。

ユーザーデータがあるページのページビュー をコンバージョンとする場合

たとえば、購入確認画面などをコンバージョンとする場合は、メールアドレスなどの文字列がDOMに含まれている状況が多い。
その場合は、GTMのカスタムJavaScriptで対象のDOMのデータを取得することが望ましい。
この場合、セキュリティリスクが大幅に低減される。

フォーム送信後のサンクスページのページビューをコンバージョンとする場合

サンクスページにユーザーデータがない場合、実装としてはユーザーがフォームを送信時に入力したデータをJavaScriptを使用して捕捉し、セッションストレージまたはクッキーなどに一時的に保存して、そのデータをGTMのカスタムJavaScriptで取得する方法が考えられる。
ブラウザを閉じるとデータが自動的に消去されることもあり、セッションストレージの方がセキュリティが高い場合が多い。
いずれにしても持続的にデータを保持する場合は、あらかじめデータをハッシュ化することが望ましい。

またサンクスページから入力データのPOST値を取得できる場合は、サーバーサイドプログラムで直接JavaScriptの変数を記述する方法も考えられ、値のサニタイズなどを考慮する必要があるものの、データを保持する必要がなくなるため、よりセキュリティリスクを軽減することができる。

GTMは通常、ページがロードされると同時にトリガーされる。
つまり、ページのHTMLがブラウザによって解析され、DOMが構築された直後に実行される。
このためページビュートリガーを使用する場合、GTMのカスタムJavaScriptは静的に記述されたHTML内のすべてのJavaScriptコードのグローバル変数にアクセス可能(bodyタグの最後に配置された場合であっても)な状態である。

ひとつの汎用的なアプローチとして、サンクス画面に送信されたメールアドレスや名前などの情報を表示し、このメールアドレスに自動送信メールが届くことを明示することで複雑な実装を回避することができる。

またそのようにすることで、カスタムJavaScriptを使わずとも、GTM内で「拡張コンバージョンの設定方法を確認します」から「CSSセレクタ」によって指定することができるため、JavaScriptがわからなくても簡単に拡張コンバージョンを導入することができる。

任意のボタンクリックをコンバージョンとする場合

たとえば電話番号をタップしたタイミングをコンバージョンとする場合を考慮すると、電話番号のタップが直接的なユーザーの行動(フォームの送信などの情報送信操作)とは異なり、Webページ上でメールアドレスなどの情報と直接関連付けられないことが問題として挙げられる。

もしWebサイトにログインシステムが導入されていればそのデータを利用することができるが、そうでない場合、フォーム送信という入力操作を伴うより高度なコンバージョンが行われたユーザーのみが拡張コンバージョンの対象となるため、多くのユーザーで適切に拡張コンバージョンが機能しない可能性があることに留意する必要がある。

2024/02/22追記

自動拡張コンバージョンについて

拡張コンバージョンには3つの設定方法が提供されており、それぞれ以下のようになっている。

  1. コード(自前のプログラムからユーザー情報を送信)
  2. 手動設定(GTMの設定でCSSセレクタなどを使用してHTMLに記載されているユーザー情報を送信)
  3. 自動収集(Googleのプログラムがユーザー情報を自動的に判定して送信)

https://support.google.com/google-ads/answer/13262500?hl=ja
>Google タグ マネージャーで拡張コンバージョンの設定を完了する

いままではいわばマニュアル操作での方法を見てきたが、自動で情報収集する方法もあり、自動拡張コンバージョンと呼ばれている。
自動拡張コンバージョンはGoogle広告のCookieを使用して、任意のタイミングで取得したユーザー情報をコンバージョンのタイミングでGoogleに送信する機能である。
次のうちの後者である。

標準の自動拡張コンバージョン: コンバージョン イベントのページでユーザー提供データ(メールアドレス、電話番号、住所)を取得できる場合は、この方法を使用します。たとえば、コンバージョン イベントのページが購入確認ページで、このページにユーザーのメールアドレスが表示される場合は、この方法を使用します。

ユーザー提供データのイベントタグを使った自動拡張コンバージョン: コンバージョン イベントのページでは顧客データ(メールアドレス、電話番号、住所)を取得できないものの、その前のページでは取得できる場合は、この方法が適しています。たとえば、コンバージョン イベントのページが購入確認ページで、その前のページでユーザーがメールアドレスを入力している場合は、この方法を使用します。

注: ユーザー提供データのイベントタグを使う方法を選択した場合は、ユーザーがコンバージョン ページに到達する前にアクセスしたページで、メールアドレス、電話番号、住所などの広告主様所有の顧客データが自動的に検出されます。この設定では、Google が広告主様の代理として、広告 Cookie を使ってハッシュ化された広告主様所有の顧客データを収集することを許可します。また、そのデータと、以降に同じユーザー セッション内で発生したコンバージョン イベントを関連付けることも許可することになります。コンバージョンに関連付けられていないデータはすべて削除されます。同意モードを実装すると、広告 Cookie は、同意モード機能の ad_storage 同意ステータス(実装されている場合)の対象となります。

https://support.google.com/google-ads/answer/13262500

ユーザー提供データのイベントタグを使った自動拡張コンバージョンでは、コンバージョンのタイミングではなく、その前の画面(フォーム入力画面など)のユーザー情報の取得が可能なため、銀の弾丸のように思えるが、個人的に留意すべきことが3つある。

ひとつ目は計測精度である。
さきほど挙げた3つの方法は計測精度の順であり、自動収集がもっとも計測精度が低くなるよう設計されている。

ふたつ目は、自動収集によって検出されるユーザー情報である。
現状ではメールアドレスのみとなっているため、たとえばメールアドレスがないフォームには使えない。

みっつ目は、Cookieである。
自前のプログラムを用意する場合、Cookieを使わずにして拡張コンバージョンを実装することができる場合があるが、前述のようにCookieを使用するためにセキュリティ対策の見直しやCookieの競合、プライバシーポリシーの改変などが必要になるかもしれない。
Cookieの保存期間は、以下のようになっているそうだ。

Q:拡張コンバージョン導入の際、Googleのサーバーへハッシュ化した個人情報を送付することとなりますがデータの保持期間等ありますか?
A:照合で一致しなかったデータは 63 日以内、照合で一致したデータは 140 日以内に自動的に削除とのことです。

https://ishigurodo.com/2023/12/12/post-1090/
https://x.com/listing_ppc/status/1727872733202338271?s=20

余談だが、サーバーセッションなどのサーバーの保存領域にある情報についてもGDPRではプライバシーポリシーに明記しなければならないらしい。
ちなみにCookieやローカルストレージがサーバーセッション以上に言及されるのはブラウザの保存領域、つまりユーザーが確認できる場所に個人情報を忍ばせており、ユーザーに指摘される懸念があるということが理由である(セキュリティについてもサーバー領域の方がリスクが低いとされる)。

設定方法に関しては以下を参照していただきたい。

https://support.google.com/google-ads/answer/13262500?hl=ja#Automatic_collection&zippy=%2C%E6%A8%99%E6%BA%96%E3%81%AE%E8%87%AA%E5%8B%95%E6%8B%A1%E5%BC%B5%E3%82%B3%E3%83%B3%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%82%92%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%99%E3%82%8B%2C%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E6%8F%90%E4%BE%9B%E3%83%87%E3%83%BC%E3%82%BF-%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%82%BF%E3%82%B0%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E8%87%AA%E5%8B%95%E6%8B%A1%E5%BC%B5%E3%82%B3%E3%83%B3%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%82%92%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%99%E3%82%8B

標準の自動拡張コンバージョンはGoogle広告のコンバージョンタグに設定を追加するが、ユーザー提供データのイベントタグを使った自動拡張コンバージョンの設定は、タグを追加する必要があるが、すべてのコンバージョンに一括で設定可能である。
どちらも容易に設定することができる。
ただし、前述の通り計測精度の懸念や他の計測方法のコスパの考慮なども必要なため、基本的にはクライアントの意向に沿うこと望ましい。

Google Analytics 4 の拡張コンバージョン

Googleシグナルの削除に伴い、代替機能としてGA4でも拡張コンバージョンが導入されている。
詳しくは以下のページを参照いただきたい。

https://ishigurodo.com/2024/02/16/post-1305/

自分の言葉で説明できるようになったタイミングで本記事に追記する。