Cookie マッチング

Cookie マッチングは、Cookie（例: ウェブサイトを閲覧したユーザーの ID）と、対応する入札者固有の Google ユーザー ID をマッチングし、ユーザーリストを構築して、入札をより効果的に行うことができる機能です。このガイドでは、Cookie マッチングで使用される概念と、Cookie マッチングに関するさまざまなワークフローと、そのワークフローが特定のユースケースで使用される可能性があるバリエーションについて説明します。

コンセプト

Cookie マッチングとは

ドメイン所有者は通常、サイトを閲覧するユーザーの Cookie のコンテンツを設定します。この内容は、ドメイン内のユーザーを識別するために使用されます。2 人のドメイン所有者がこのデータ交換に同意した場合でも、インターネット ブラウザのセキュリティ モデルでは、別のドメインが設定した Cookie の読み取りはドメイン所有者によって制限されています。

デジタル広告の文脈では、Google は doubleclick.net ドメインに属する Cookie を使用してユーザーを識別します。リアルタイム入札に参加するビッダーは、広告を表示するユーザーのセットを識別する独自のドメインを持つ場合があります。Cookie マッチングにより、ビッダーは Cookie を Google の Cookie と照合して、入札リクエストで送信されたインプレッションがターゲティングされているユーザーのいずれかに関連付けられているかどうかを判断できます。ビッダーは、独自の Cookie データまたは、入札リクエストの doubleclick.net Cookie の暗号化された形式であるビッダー固有の Google ユーザー ID を受け取ります。

このガイドで説明する Cookie マッチング サービスでは、ビッダーの Cookie と Google ユーザー ID の関連付けを簡単に作成して管理できます。また、ユーザーリストにユーザー ID を登録することもできます。

マッチテーブル

マッチテーブルを使用すると、ID などのデータを 1 つのドメインから別のドメインにマッピングできます。ビッダーは、Cookie Matching Service を使用して、特定のユーザーの Cookie をユーザーの Google ユーザー ID にマッピングすることで独自のマッチテーブルにデータを入力したり、Google がホストするマッチテーブルにデータを入力したりできます。マッチテーブルは、ビッダーのビッダー アプリケーションがインプレッションが表示されたユーザーの Cookie データにアクセスするために必要です。

Google がホストするマッチテーブル

メンテナンスの容易化、レイテンシの改善、特定の地域のユーザーの一致データへのアクセスを実現するには、Google に一致テーブルをホストすることをおすすめします。これにより、特定のユーザーの Google ユーザー ID にマッピングされるウェブセーフの Base64 でエンコードされた文字列（以下、ホスト型マッチデータ）を指定できます。一致が確立されると、次のように使用できます。

• リアルタイム入札: ユーザーに関連付けられたインプレッションのその後の入札リクエストで、Google は、Google ユーザー ID と照合したホスト型マッチデータを送信します。Google の OpenRTB 実装では、BidRequest.user.buyeruid はウェブセーフな base64 エンコード文字列として指定されます。非推奨の Google RTB プロトコルを使用するように入札エンドポイントが構成されている場合、この値は BidRequest.hosted_match_data フィールドを介してデコードされたバイトとして受信されます。

• ユーザーリスト: ユーザーリストには、Google ユーザー ID またはホストされたマッチデータを入力できます。

• プレターゲティング: ホストされたマッチデータを含む入札リクエストのみを受信するようにプレターゲティングを設定できます。これにより、Cookie 領域外のユーザーに対する関連性の低いインプレッションを除外できます。

ユーザーリスト

ユーザーリストは Real-Time Bidding API で作成、管理できます。 作成したリストには、後述の Cookie マッチング ワークフローまたは一括アップロード サービスを使用してデータを入力できます。

スタートガイド

Cookie マッチングを開始するには、テクニカル アカウント マネージャーにお問い合わせください。テクニカル アカウント マネージャーは、特定のワークフローを有効にして、以下の設定をサポートします。

• Cookie マッチング ネットワーク ID（NID）: Cookie マッチングとその他の関連操作でビッダー アカウントを一意に識別するために使用される文字列 ID。
• Cookie マッチング URL: Cookie マッチング ワークフローの一部として受信したリクエストを許可して処理するエンドポイントのベース URL です。ビッダーは、この URL にマクロを埋め込んで、Cookie マッチング ワークフローで渡されるパラメータの順序を制御できます。
• マッチタグ: ビッダーが開始する Cookie マッチング ワークフローのためにユーザーのブラウザに配置する必要があるタグ。広告とともに配信することも、広告以外のウェブ プロパティに配置することもできます。
• Cookie マッチング レポート URL（省略可）: 一方向の Cookie マッチング ワークフローでは、この URL は省略可能な URL です。この URL を使って、HTTP 302 リダイレクトが原因で Cookie マッチングが失敗したときにエラーの情報を受け取るエンドポイントを指定できます。デフォルトでは、Cookie のマッチング オペレーションでエラーが発生した場合にのみ、この URL にレスポンスが送信されますが、ビッダーはリダイレクトを常に送信するようリクエストできます。
• Cookie Match Assist URL: Cookie Match Assist ワークフローを実装しているエクスチェンジの場合、これは受信リクエストに応答するエンドポイントのベース URL です。
• Cookie マッチング アシストの割り当て: Cookie マッチング アシストのワークフローを実装しているエクスチェンジの場合、これは Cookie マッチング URL が 1 秒あたりに受信できるリクエストの最大数です。これは、CMA リクエストがリクエストでエクスチェンジのサーバーを過負荷状態にすることを防ぐことを目的としています。

Cookie マッチング マクロ

サポートされている Cookie マッチング ワークフローでは、通常、ビッダーの Cookie マッチング URL に非保証型の順序でパラメータが付加されます。パラメータの順序を一定に保つ必要がある統合を使用しているビッダーは、Cookie マッチング URL にマクロを配置して、プレースメントを確実にすることができます。

サポートされるマクロ

ビッダーは、Cookie マッチング URL を構成して、%%GOOGLE_<PARAM_NAME>%% または %%GOOGLE_<PARAM_NAME>_PAIR%% の形式で 1 つ以上のマクロを含めることができます。サポートされているマクロと展開された値は次のとおりです。

マクロの例

ビッダーには https://user.bidder.com.cookies でホストされているエンドポイントとの Cookie マッチングが統合されます。実装には、google_push、google_gid、google_cver、google_error の順序で、Pixel Matching パラメータに加えて、事前に設定されたビッダー定義のパラメータが必要です。ビッダーは、Cookie マッチング URL を次のように設定することで、この処理を実行できます。

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

後で Google がこのビッダーにマッチリクエストを送信すると、次のように拡張されます。

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

Cookie マッチング サービスのワークフロー

Google の Cookie マッチング サービスは現在、以下の異なるユースケース向けに 3 つのワークフローをサポートしています。

ビッダー主導: 双方向 Cookie マッチング

双方向 Cookie マッチングとは、ビッダーが開始するワークフローを指します。ビッダーは、ユーザーのブラウザにマッチタグを配置し、Google に誘導します。このワークフローでは、Google とビッダーの両方がマッチテーブルにデータを入力できます。以下に、このワークフローの簡単な例を示します。

ステップ 1: マッチタグを配置する

このフローを開始するには、ビッダーがマッチタグを配置して、ユーザーのブラウザにレンダリングされるようにする必要があります。Google ユーザー ID のみをビッダーに返すシンプルなマッチタグは、次のように構成できます。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

マッチタグには、さまざまなユースケースに対応するために追加のパラメータを組み込むことができます。これらのパラメータの詳細については、マッチタグの URL パラメータをご覧ください。

ステップ 2: Google が一致データを含むリダイレクトに応答する

このマッチタグにより、Google の Cookie マッチング サービスはユーザーのブラウザからリクエストを受け取り、ビッダーの Cookie マッチング URL への HTTP 302 リダイレクトを発行します。リダイレクトには、Google ユーザー ID とそのバージョン番号を指定するクエリ パラメータが URL に含まれます。また、ビッダーはリクエスト ヘッダーに含まれる Cookie も受け取ります。Cookie マッチングの URL が https://ad.network.com/pixel として指定されている場合、上記の単純なマッチタグのリダイレクト URL は次のようになります。

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

google_gid パラメータで渡される Google ユーザー ID は、パディングなしのウェブセーフの Base64 でエンコードされた文字列です。入札者がマッチテーブルをホストする場合は、Cookie Matching Service から返された文字列をそのまま保存することをおすすめします。以降の入札リクエストでは、これは OpenRTB の BidRequest.user.id または非推奨の Google RTB プロトコルの BidRequest.google_user_id で指定された値に対応します。

google_cver で指定されたバージョンは、Google ユーザー ID のバージョン番号を示します。各ユーザーの Google ユーザー ID は頻繁に変更されないため、変更後は値が増加します。

マッチ リクエストの処理中にエラーが発生した場合は、代わりに google_error パラメータが指定されます。

ステップ 3: ビッダーがリダイレクトを処理し、ピクセルで応答する

ビッダーは、最初のステップで指定したパラメータと、Google が 2 番目のステップで提供したパラメータを含む、Cookie 一致 URL へのリダイレクトを受け取ります。また、HTTP ヘッダーでも Cookie を受け取ります。オペレーションが成功した場合、独自のマッチテーブルをホストしているビッダーは、レスポンスに含まれる Google ユーザー ID と自分の Cookie を照合できます。ビッダーは、Cookie Matching Service から返された文字列をそのまま保存することをおすすめします。

オペレーションが失敗した場合、ビッダーはリダイレクトで google_error パラメータを受け取ります。これは、発生した特定のエラーを識別するさまざまなエラー状態に対応する数値です。発生する可能性のあるエラー値について詳しくは、こちらをご覧ください。エラーが発生した場合は、新しいマッチタグを配置して、そのユーザーとのマッチングを再度試行できます。

ビッダーは常に、1x1 の非表示ピクセル画像を配信するか、HTTP 204 No Content レスポンスを返す必要があります。

Cookie マッチングのワークフロー図

このワークフローは次の図に示します。リクエストとレスポンスは矢印で表され、それに付随するデータ項目はかっこで囲まれています。

マッチタグ URL パラメータ

上記のパラメータに加えて、ビッダーは独自のパラメータを指定できます。このパラメータは、リダイレクト URL にパラメータとして追加されます。google_ 接頭辞が付いたビッダー定義パラメータは、将来の開発のために Google によって予約されているため、無視されます。また、パラメータの順序が保持される保証はありません。ビッダー定義のパラメータを含むマッチタグは次のようになります。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

リダイレクト URL パラメータ

リダイレクト URL は、ビッダーのアカウント用に設定されたベース Cookie マッチング URL から構築されます。これには、google_ や、ビッダー定義のパラメータ（マッチタグで指定されたパラメータに応じて）が含まれます。次の google_ レスポンス パラメータが定義されています。

Cookie マッチングのワークフローの例のシナリオ

次のシナリオは、ウェブページを閲覧する一般的なユーザーの Cookie マッチングを示しています。

シナリオ 1: ユーザーが Cookie を削除してサイトをブラウジングする

Jane はすべての Cookie のキャッシュをクリアします。その後、ExampleNews.com のホームページにアクセスします。

変更点は次のとおりです。

1. ExampleNews.com は、Google（アド マネージャー）から広告をレンダリングして呼び出します。
2. この広告ユニットは動的割り当ての対象であるため、Google はリアルタイム ビッダー サービスを通じて FinestDSP や他の入札者に入札リクエストを送信します。
3. FinestDSP のビッダー アプリケーションは、入札リクエストを受信して処理し、入札レスポンスを送信します。
4. Google は、マッチタグ（ピクセル）で広告を指定する FinestDSP のレスポンスを含む、ビッダーから入札レスポンスを受け取ります。
5. FinestDSP がオークションで落札します。Google は、Jane に FinestDSP の広告とマッチタグを配信します。
6. マッチタグは、google_nid パラメータと google_cm パラメータを指定して Google の Cookie Match Service を呼び出します。
7. Cookie Match Service は、ジェーンの Google Cookie を読み取り、google_gid パラメータと google_cver パラメータを設定した FinestDSP の Cookie マッチング URL へのリダイレクトをジェーンのブラウザに送信します。
8. Jane のブラウザに、FinestDSP の Cookie マッチング URL へのリダイレクトが読み込まれます。
9. FinestDSP の Cookie マッチング エンドポイントは、リダイレクト リクエストを処理します。これには、Google が設定した URL パラメータと、HTTP ヘッダー内の Jane に対する Cookie が含まれます。FinestDSP は、Cookie と google_gid のマッピングをマッチテーブルに保存できるようになりました。
10. FinestDSP は、目に見えない 1×1 ピクセルでリダイレクトに応答します。

シナリオ 2: 既存のマッピングがあるユーザー

シナリオ 1 の 1 週間後、ジェーンは ExampleNews.com に再度アクセスします。これで、ビダーとアド マネージャーの両方の Cookie がユーザーのマシンに保存されました。マッチングの仕組みは次のとおりです。

1. ウェブページがレンダリングされると、Google（アド マネージャー）はページにレンダリングされる広告をリクエストします。
2. 広告オークションの際、Google は FinestDSP を含む該当する入札者に入札リクエストを送信します。
3. FinestDSP は、google_gid などのシグナルを含む入札リクエストを受信します。
4. FinestDSP はマッチテーブルで google_gid を検索し、1 週間前に作成された（シナリオ 1 の）ジェーンに関連付けられた Cookie を見つけます。
5. クッキーに関連付けられた情報に基づいて、FinestDSP の入札ロジックがインプレッションに入札し、オークションで落札します。
6. この場合、FinestDSP が所有する情報に基づいて、ユーザーの興味や関心に合わせた広告が表示される可能性があります。

入札者による開始: 単方向 Cookie マッチング

一方向 Cookie マッチングは、双方向ワークフローに似ていますが、Google のみがマッチテーブルをホストして入力するように変更されています。これは、ビッダーが独自のマッチテーブルに Google ユーザー ID をホストすることを許可されていない場合に使用できます。このフローを使用するには、ビッダーは Google がマッチテーブルをホストすることを許可する必要があります。Google の Cookie マッチング サービスへのリクエストで google_cm を指定することはできなくなり、その結果、独自のマッチテーブルに入力する google_gid を受け取ることもできなくなります。Google が特定のユーザーとの一致を確立すると、ビッダーは独自の Cookie データを使用してそのユーザーをユーザーリストに追加できます。同様に、これらのユーザーの入札リクエストでは、Google ユーザー ID は除外されますが、ホストされているマッチデータが含まれます。改訂されたワークフローの簡単な例を、次の手順にまとめます。

ステップ 1: ビッダーの Cookie マッチング URL にリダイレクトするマッチタグを配置する

このフローを開始するには、ビッダーがマッチタグを配置して、ユーザーのブラウザにレンダリングされるようにする必要があります。プライバシー制限のある米国の州に居住していないユーザー向けのワークフローと異なり、マッチタグはユーザーのブラウザを Cookie マッチング URL に誘導する必要があります。たとえば、Cookie マッチング URL が https://ad.network.com/pixel に設定されている場合は次のようになります。

<img src="https://ad.network.com/pixel" />

ユーザーのブラウザで読み込みを行うときに、ビッダーの Cookie マッチング URL のピクセルがリクエストされます。このリクエストでは、HTTP ヘッダーに Cookie が含まれ、次のステップで抽出する必要があります。

ステップ 2: Google の Cookie マッチング サービスにリダイレクトする

ビッダーの Cookie マッチング エンドポイントは、ウェブセーフな Base64 でエンコードされた Cookie データが入力された google_hm パラメータを含む Google の Cookie マッチング サービスにリダイレクトする必要があります。リダイレクト URL は次のようになります。

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

ステップ 3: ユーザーのブラウザが Google の Cookie マッチング サービスにリダイレクトされる

Google は、HTTP ヘッダー内の Google の Cookie に加えて、指定したパラメータを含むリダイレクトを受け取ります。

ステップ 4: レポート URL が指定されている場合、成功またはエラーのリダイレクト時に Google がピクセルを配信します

Cookie のマッチング オペレーションが成功した場合、またはビッダーのアカウントに Cookie マッチング レポートの URL が指定されていない場合、デフォルトで 1x1 の透明ピクセルが配信され、ワークフローはここで終了します。以降の入札リクエストでこのユーザーのインプレッションには、OpenRTB の場合は BidRequest.user.buyeruid、非推奨の Google RTB プロトコルの場合は BidRequest.hosted_match_data に、ビッダーがホストするマッチデータが含まれます。入札者は、指定したホストされたマッチデータを使用してユーザーリストにデータを入力することもできます。

エラーが発生した場合は、google_error パラメータで指定されたエラーの原因とともに、ビッダーの Cookie マッチング レポート URL へのリダイレクトが送信されます。ビッダーの Cookie マッチング レポート URL が https://ad.network.com/report の場合、リダイレクト URL は次のようになります。

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

ステップ 5: ユーザーのブラウザがビッダーの Cookie マッチング レポート URL にリダイレクトされる

ユーザーのブラウザは、Google が google_error パラメータで指定したエラーの理由（該当する場合）を含む、ビッダーの Cookie マッチング レポートの URL にリダイレクトされます。エラーコードの解釈の詳細については、パラメータの説明をご覧ください。

ステップ 6: ビッダーが 1×1 の透明ピクセルを配信する

ビッダーは、ユーザーのブラウザに 1x1 の透明ピクセルを配信することで応答する必要があります。

プライバシーの制限がある米国の州のユーザー向けの Cookie マッチングのワークフロー図

プライバシー制限のある米国の州に居住するユーザーのデフォルト ワークフローは、次の図のとおりです。リクエストとレスポンスは矢印で表され、それに付随するデータ項目はかっこで囲まれています。

Google の Cookie マッチング サービスへのビッダー リダイレクト用の URL パラメータ

ビッダーの Cookie マッチング レポート URL への Google リダイレクトの URL パラメータ

Google が開始: 双方向ピクセル マッチング

双方向ピクセル マッチングは、Google の Cookie マッチング サービスのワークフローで、Google ユーザー ID と、アルゴリズムによって選択されたリアルタイム ビッダー オークションの落札者以外のビッダーとのマッチングが試みられます。広告が配信されると、Google はマッチタグを配置し、選択したビッダーの Cookie マッチング URL から透明ピクセルを読み込むようユーザーのブラウザに指示します。これにより、Google とビッダーの両方が、特定のユーザーのマッチテーブルにデータを入力できるようになります。以下に、このワークフローの簡単な例を示します。

ステップ 1: Google がマッチタグを配置する

参加しているパブリッシャーのページがユーザーのブラウザで読み込まれ、そのページの広告スロットが Google によって埋められると、アルゴリズムによって選択されたビッダーにピクセルをリクエストするマッチタグを配置できます。Google が配置するピクセル マッチング タグにより、ビッダーの Cookie マッチング URL と、入札者がマッチテーブルにデータを入力するのに使用できる追加パラメータが組み合わされます。https://ad.network.com/pixel として指定された Cookie マッチング URL の構造は次のとおりです。

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

ステップ 2: ビッダーは、Google の Cookie Matching Service URL へのリダイレクトを含むレスポンスを返す必要があります

ピクセル マッチング リクエストを受信したビッダーは、Google の Cookie Matching Service へのリダイレクトを含むレスポンスを返す必要があります。このレスポンスの構造は次のとおりです。

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

上記のリダイレクト URL は、ビッダー主導型 Cookie マッチング ワークフローのマッチタグで使用される URL と類似しています。ピクセル マッチングでは、google_cm パラメータは google_push パラメータに置き換えられ、その値はリクエストで Google から提供された値と等しくする必要があります。入札者が開始するワークフローと同様に、追加のユースケースに対応するために追加のパラメータを指定できます。

ステップ 3: Google がリダイレクトを処理し、ピクセルで応答する

Google はユーザーについてマッチが作成されたことを記録し、クエリ パラメータを通じてリクエストされた追加のオペレーションを処理します。最後に、Google は 1x1 の透明なピクセルで応答します。

Google Pixel のマッチングのワークフローの図

このワークフローは次の図に示されています。リクエストとレスポンスは矢印で表され、それに付随するデータ項目はかっこで囲まれています。

Google マッチタグのリクエスト パラメータ

ビッダー ピクセル マッチングのリダイレクト パラメータ

Google が開始: 単方向ピクセル マッチング

単方向ピクセル マッチングの場合、Google のマッチタグには Google ユーザー ID を指定するパラメータは含まれず、Google がホストするマッチテーブルに引き続きデータが入力されるという点で、Bidirectional ワークフローとは異なります。これは、入札者が独自のマッチテーブルに Google ユーザー ID をホストすることを許可されていない場合に使用できます。改訂されたワークフローの簡単な例を次の手順にまとめます。

ステップ 1: Google がマッチタグを配置する

Google は、アルゴリズムによって選択されたビッダーにマッチタグを配置します。マッチタグには google_push パラメータが含まれています。次の例をご覧ください。

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

ステップ 2: ユーザーのブラウザがビッダーのクッキング マッチング URL のピクセルをリクエストする

ユーザーのブラウザが、入札者の Cookie マッチング URL からピクセルをリクエストします。このリクエストには、HTTP ヘッダーに含まれる入札者の Cookie も含まれます。

ステップ 3: Google の Cookie マッチング サービスにリダイレクトする

ビッダーの Cookie マッチング エンドポイントは、ウェブセーフな Base64 でエンコードされた Cookie データが入力された google_hm パラメータを含む Google の Cookie マッチング サービスにリダイレクトする必要があります。リダイレクト URL は次のようになります。

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

ステップ 4: ユーザーのブラウザが Google の Cookie マッチング サービスにリダイレクトされる

Google は、HTTP ヘッダー内の Google の Cookie に加えて、指定したパラメータを含むリダイレクトを受け取ります。オペレーションが成功すると、後続の入札リクエストでこのユーザーのインプレッションに、OpenRTB の場合は BidRequest.user.buyeruid、非推奨の Google RTB プロトコルの場合は BidRequest.hosted_match_data に、ビッダーのホストされたマッチデータが含まれます。ビッダーは、指定したホスト型マッチデータを使用して、ユーザーリストを作成することもできます。

最後に、Google は 1x1 の透明なピクセルをユーザーのブラウザに返します。

Cookie マッチング アシスト

Open Bidding では、エクスチェンジはビッダーが開始する Cookie マッチング ワークフローやGoogle が開始する Cookie マッチング ワークフローを使用して、Google ユーザー ID と Cookie を照合できます。Cookie Match Assist（CMA）は、エクスチェンジが独自のビッダーを使用してマッチテーブルを構築できる追加機能です。

Cookie Match Assist の仕組み

1. 広告を掲載する際、Google は参加しているエクスチェンジをアルゴリズムによって選択し、次の構造の Cookie Match Assist タグを配置します。

   <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

2. Google の CMA マッチタグにより、エクスチェンジの Cookie マッチング URL がピクセル リクエストを受け取ります。

3. エクスチェンジの Cookie マッチング エンドポイントがリクエストを受信します。ここで、エクスチェンジ独自の Cookie マッチング サービスが、ユーザー ID とビッダーのいずれかを照合します。次の図は、エクスチェンジの Cookie マッチング サービスが、ビッダーのエンドポイントのいずれかにリダイレクトすることで、ユーザーのブラウザに応答する様子を示しています。
4. ビッダーは、リクエストと、ユーザー ID と Cookie を照合するためにエクスチェンジによって指定されたパラメータを受け取ります。

制限事項

新しい一致のリクエストの頻度を制限する

Google がホストするマッチテーブルに新しいエントリがあるユーザーに対して、ビッダーは Cookie マッチング サービスの呼び出し回数を制限する責任があります。ホストされたマッチテーブルのエントリは、14 日経過すると期限切れと見なされ、その後更新できます。

すべてのピクセル マッチ リクエストに応答する

ピクセル マッチング ワークフローを使用するビッダーは、受信したすべてのピクセル マッチ リクエストに、google_push パラメータを含むレスポンスで応答する必要があります。これにより、Google は使用状況をモニタリングしてポリシーを適用できます。ビッダーのレスポンス率が 90% を下回ると、そのビッダーのアカウントに送信される Pixel Match リクエスト数が抑制されます。

HTTPS エンドポイントを使用する

すべての Cookie マッチング ワークフローで使用されるエンドポイントは HTTPS を使用する必要があります。

HTTPS 経由で送信された Pixel Match リクエストに応答する場合、HTTPS で Cookie マッチング サービスにリダイレクトする必要があります。同様に、ビッダーにリダイレクトする Cookie Match Assist エンドポイントも HTTPS を使用する必要があります。HTTP 経由で Google にリクエストを送信する頻度が 2 分間に 1 回を超えると、アカウントに送信される一致リクエストの数は制限されます。

EU ユーザーの同意に関する要件

Google の EU ユーザーの同意ポリシーの対象となる Cookie マッチング リクエストでは、エンドユーザーの同意を示す必要があります。このようなリクエストは、次のいずれかの方法で同意を取得したことを示すために必要です。

• TCFv2: gdpr パラメータと gdpr_consent パラメータが含まれます。詳しくは、 認定バイヤーの IAB TCF v2.0 のドキュメントをご覧ください。
• process_consent: 入札者が必要なユーザーの同意を得たことを宣言する。

例

以下の例は、Cookie Matching サービスを使用して特定の目標を達成する方法を示しています。特に明記されていない限り、措置の対象となるユーザーは、プライバシーに関する制限が適用される米国の州に居住していないと見なされます。

ビッダーがホストするマッチテーブルにデータを入力する

ビッダーは、Cookie マッチング ワークフローを使用して、マッチタグに google_nid パラメータと google_cm パラメータのみを指定して、独自のマッチテーブルにデータを入力できます。次に例を示します。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

ビッダーの Cookie マッチング URL が https://ad.network.com/pixel?id=1 に設定され、Cookie マッチング オペレーションが成功した場合、ビッダーのマッチタグに応答して Google から送信されるリダイレクトは次のようになります。

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

ユーザーに Google Cookie がないため、Cookie の照合オペレーションが失敗した場合、レスポンスは次のようになります。

https://ad.network.com/pixel?id=1&google_error=3

エラーコードは、エラーの根本的な原因によって異なります。Cookie マッチング ワークフローで発生する可能性のあるエラーコードの詳細については、リダイレクト URL パラメータをご覧ください。

単一のユーザーリストに追加

google_ula パラメータをビッダーのマッチタグで指定すると、指定した ID のユーザーリストにユーザーを追加できます。Google またはビッダーがホストするマッチテーブルにユーザーの新しいエントリがある場合、ビッダーは google_nid パラメータと google_ula パラメータを含むマッチタグを配置して、Cookie マッチングの完全なワークフローを開始せずに、指定されたリストにユーザーを追加できます。詳しくは、Cookie Matching Service の呼び出しに関する制限事項をご覧ください。対応するマッチタグは次のようになります。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

レスポンスが成功した場合、ビッダーの Cookie マッチング URL が https://ad.network.com/pixel の場合、Google のリダイレクト URL は次のようになります。

https://ad.network.com/pixel?google_ula=12345,0

全体的なエラー（ユーザーの Google Cookie がないなど）が発生した場合、リダイレクト URL には google_error パラメータが含まれます。

• https://ad.network.com/pixel?google_error=3

ユーザーのリストへの追加に固有のエラーがある場合は、リダイレクトで google_ula が返されます。対応するマッチタグ パラメータとは異なり、タイムスタンプはステータス コードに置き換えられ、オペレーションの成功を示します。たとえば、ビッダー アカウントが指定されたユーザーリストへのアクセス権がないためリクエストが失敗した場合、リダイレクト URL は次のようになります。

https://ad.network.com/pixel?google_ula=12345,2

複数のユーザーリストに追加する

ビッダーは、マッチタグに複数の google_ula パラメータを指定することで、ユーザーを複数のユーザーリストに追加するよう指定できます。実際には、次のようなようになります。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

各ユーザーリストの操作ステータスは、リダイレクト内の個別の google_ula パラメータを通じて同様にレポートされます。

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

上記のリダイレクトでは、ID 45678 のユーザーリストに対してオペレーションが成功しましたが、ビッダーにアクセス権がないため、ユーザーリスト ID 12345 に対しては失敗しています。

Cookie マッチングのワークフローを進め、ユーザーリストに追加する

1 回のリクエストで Cookie マッチングを実行し、ユーザーをユーザーリストに追加するには、ビッダーのマッチタグに google_cm と google_ula を含める必要があります。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

Google が指定するリダイレクト URL には、google_gid、google_cver、google_ula が含まれます。次のようになります。

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

Google がホストするマッチテーブルにマッチを保存する

ビッダーが Google がホストするマッチテーブルに Cookie データを保存し、Google ユーザー ID とのマッチを独自のマッチテーブルに保存する予定がない場合は、マッチタグに google_hm パラメータを含める必要があります。このパラメータの値は、ウェブ用 Base64 でエンコードされた文字列にする必要があります。ビッダーの未エンコード Cookie データが Cookie number 1! のユーザーの場合、エンコードされた値は Q29va2llIG51bWJlciAxIQ== になります。これは、次のようなマッチタグで使用されます。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

レスポンスが成功した場合、ビッダーの Cookie マッチング URL が https://cookie-monster.com/pixel の場合、Google のリダイレクト URL は次のようになります。

https://cookie-monster.com/pixel

マッチタグに google_cm が含まれていないため、google_gid パラメータはリダイレクトには含まれません。また、google_hm は成功したレスポンスには含まれません。このユーザーのインプレッションに対する今後の入札リクエストでは、OpenRTB プロトコルの場合は BidRequest.user.buyeruid、サポートが終了した Google RTB プロトコルの場合は BidRequest.hosted_match_data でホストされたマッチデータがビッダーに送信されます。

入札者が、google_hm の値が base64 エンコードされていないマッチタグ（chocolate_chunk! など）を使用した場合、リダイレクト URL は次のように表示されます。

https://cookie-monster.com/pixel?google_hm=2

上記のリダイレクト URL には 2 という google_hm 値が含まれており、値をデコードできないためにオペレーションが失敗したことを示しています。

ユーザーリストを含むビッダーと Google がホストするマッチテーブル

ビッダーが Google がホストするユーザーリストに加えて独自のユーザーリストをホストしており、1 つのマッチタグで両方のテーブルを照合してユーザーを特定のユーザーリストに追加する場合は、マッチタグに google_cm、google_hm、google_ula パラメータを含める必要があります。ビッダーの Cookie データが Cookie number 1! の場合、エンコードされた値は Q29va2llIG51bWJlciAxIQ== になり、次のようなマッチタグが生成されます。

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

成功したレスポンスで、ビッダーの Cookie マッチング URL が https://cookie-monster.com/pixel の場合、Google のリダイレクト URL は次のようになります。

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

リダイレクトを受け取ったビッダーは、google_gid で指定された Google ユーザー ID を、マッチテーブルの Cookie データと照合できます。また、Google がホストするマッチテーブルとユーザーリストのオペレーションが正常に完了したことを確認できます。そのため、指定したユーザーリスト ID をターゲットにするようにビッダーが構成されているプレターゲティングでは、ビッダーがユーザーからインプレッションの入札リクエストを受け取るようになります。同様に、これらの入札リクエストでは、ビッダーはホストされたマッチデータを OpenRTB の場合は BidRequest.user.buyeruid、非推奨の Google RTB プロトコルの場合は BidRequest.hosted_match_data で受け取ります。