Cookie マッチング

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Cookie マッチングは、Cookie(ウェブサイトを閲覧したユーザーの ID など)と、それに対応するビッダー固有の Google ユーザー ID を照合して、より効果的な入札単価の設定に役立つユーザーリストを作成できます。このガイドでは、Cookie マッチングで使用されるコンセプト、さまざまな Cookie マッチング ワークフロー、特定のユースケースに対するバリエーションについて説明します。

コンセプト

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

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

このガイドで説明する Cookie マッチング サービスでは、ビッダーの Cookie と Google ユーザー ID の関連付けの作成とメンテナンスを容易にし、ユーザーリストへの入力も許可します。

マッチテーブル

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

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

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

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

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

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

ユーザーリスト

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

はじめに

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

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

サポートされている Cookie マッチングのワークフローでは、通常、ビッダーの Cookie マッチング URL には非保証型の順序にパラメータが追加されます。統合で使用するパラメータの順序に一貫性を持たせる必要があるビッダーは、Cookie マッチング URL にマクロを配置して配置を保証できます。

サポートされるマクロ

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

マクロ 展開された値
GOOGLE_GID GOOGLE_USER_ID
GOOGLE_GID_PAIR &google_gid=GOOGLE_USER_ID
GOOGLE_CVER COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR &cver=COOKIE_VERSION_NUMBER
GOOGLE_ERROR ERROR_ID
GOOGLE_ERROR_PAIR &google_error=ERROR_ID
GOOGLE_PUSH PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR &google_push=PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID

マクロの例

ビッダーには、https://user.bidder.com.cookies でホストされているエンドポイントとの Cookie マッチングが統合されています。実装では、Pixel Matching パラメータに加えて、google_pushgoogle_gidgoogle_cvergoogle_error の順序で、ビッダーが定義したパラメータが必要です。そのためには、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

Google の Cookie マッチング サービスでは現在、以下で説明するユースケースに対応した 3 つのワークフローがサポートされています。

双方向の 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 マッチング サービスによって返された文字列をそのまま保存することをおすすめします。後続の入札リクエストでは、Google の RTB プロトコルの BidRequest.google_user_id または Google の OpenRTB 実装の BidRequest.user.id で指定された値に対応します。

google_cver で指定されたバージョンは、Google ユーザー ID のバージョン番号を示します。特定のユーザーの Google ユーザー ID は、頻繁に変更され、以降は増分されます。

一致リクエストの処理中に Google がエラーが発生した場合は、代わりに google_error パラメータを指定します。

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

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

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

ビッダーは常に 1x1 の目に見えないピクセル画像を配信するか、HTTP 204 コンテンツなしのレスポンスを返す必要があります。

このワークフローを以下の図に示します。リクエストとレスポンスは矢印で示され、関連するデータ項目はかっこ内に記載されています。

一致タグの URL パラメータ

パラメータ 説明
google_nid ビッダー アカウントのネットワーク ID(NID)。この ID は、Buyer REST API アカウントのリソースである cookieMatchingNid フィールドで取得できます。
google_cm Cookie マッチングを実行するよう、Google の Cookie マッチング サービスに指示します。パラメータの値は無視され、省略できます。
google_sc このパラメータは非推奨です。ユーザーの Google の Cookie が存在しない場合は、Cookie を設定します。パラメータの値は無視され、省略できます。Cookie が存在しない場合、パラメータを省略するとエラーが発生します。
google_no_sc このパラメータは非推奨です。これにより、Google の Cookie マッチング サービスに、そのユーザーに Cookie が存在しない場合は Cookie を設定しないようにできます。パラメータの値は無視され、省略できます。
google_hm

ビッダーが Google がホストするマッチテーブルに保存するデータ。

値はウェブセーフの Base64 エンコード文字列です(パディングは省略可)。元データは 40 バイト以下である必要があります。例: Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u

google_redir URL エンコードされた文字列。この一致タグのエンコードされた URL への HTTP 302 リダイレクトを Google に送信するようビッダーに指定できます。これにより、パートナー様へのチェーン コールで Google を前面に出すことができます。これにより、google_hm が指定されていないか、google_cm が指定されていると、エラーが発生します。
google_ula 既存のユーザーリストにユーザーを追加するために使用される文字列。想定される値は userlistid[,timestamp] です。
  • userlistid: 単一の数値ユーザーリスト ID。
  • timestamp: POSIX 形式のタイムスタンプ(省略可)。ユーザーがユーザーリストに追加された時刻を示します。

この 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_ レスポンス パラメータが定義されています。

パラメータ 説明
google_gid Google ユーザー ID。リクエストで google_cm が指定され、リクエストが成功した場合に設定します。
google_cver Cookie のバージョン。リクエストで google_cm が指定され、リクエストが成功した場合に設定します。
google_error

リクエスト全体のエラーを示す整数値。受信した場合は、オペレーションが実行されていないことを示し、他の google_ レスポンス パラメータは設定されていません。サポートされているエラー値は次のとおりです。

  • 1: ユーザーは Google Cookie を持っていますが、この Cookie を使ったトラッキングを無効にしています。
  • 2: 有効なオペレーションが指定されていない(no-op リクエストが受信されたなど)。
  • 3: ユーザーに Google Cookie がありません。Google では、Cookie マッチング サービスを使用して Cookie を設定することはありません。
  • 4: 競合するオペレーションが指定されています。同じリクエストに対して google_push フラグと google_cm フラグの両方を指定することはできません。目的が矛盾しているからです。
  • 5: 双方向の Pixel Matching リクエストの一部として、無効な google_push パラメータが Google サーバーへのリダイレクトで渡されました。リダイレクトでは、google_push を最初のピクセル リクエストで渡されたものと同じ値に設定する必要があります。
  • 6: 無効な NID がマッチタグで指定されました。
  • 7: 無効な Cookie が検出されました。
  • 8: 非推奨。Cookie が見つかりません。
  • 9: Cookie が見つかりません。テスト Cookie の設定を試みます。
  • 10: google_redir パラメータは、google_hm を指定せずに使用されたか、google_cm に加えて使用されたものです。
  • 15: このリクエストは、Google がマッチテーブルをホストする必要があるリージョンから送信されます。そのため、このレスポンスには Google ユーザー ID は含まれません。この機能は現在、ごく一部のトラフィックに対してのみ有効になっていますが、2020 年 6 月には完全に有効になる予定です。
google_hm

Google がホストするマッチテーブルへの書き込みが失敗した場合にのみ表示されます。その場合、値は次のいずれかのステータス コードになります。

  • 1 - 禁止: お客様は、ホストされたマッチテーブル エントリを書き込む許可リストに登録されていません。
  • 2 - デコード エラー: パラメータ値をデコードできませんでした。
  • 3 - ペイロードが長すぎる: パラメータ値が 24 バイト以上のデータにデコードされました。
  • 4 - 内部エラー: データの保存中に内部エラーが発生しました。
  • 5 - スロットル: 書き込みがスロットル処理されているため、処理されませんでした。
google_ula

ユーザーリスト追加オペレーションのステータス。リクエストで複数の google_ula が指定されている場合は繰り返されます。形式は次のとおりです。
userlistid,status code

例: google_ula=1234567890,0

google_ula オペレーションは、次のいずれかのステータス コードを返すことができます。

  • 0 - エラーなし。ユーザーがユーザーリストに追加されました。
  • 2 - 権限が拒否されました。指定されたユーザーリストにユーザーを追加する権限がありません。
  • 5 - 無効なユーザーリスト ID。無効なユーザーリスト ID が無効です。
  • 6 - 閉じた属性の ID です。指定されたユーザーリスト ID が閉じられています。
  • 10 - 内部エラー。Cookie マッチング サービスで内部エラーが発生しました。ユーザーの再マッチングをもう一度お試しください。

以下のシナリオでは、一般的なウェブページを閲覧する Cookie マッチングの例について説明します。

シナリオ 1: ユーザーが Cookie を削除してサイトを閲覧

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

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

  1. ExampleNews.com がレンダリングされ、Google(アド マネージャー)から広告が呼び出されます。
  2. 広告ユニットはダイナミック アロケーションの対象であるため、Google はリアルタイム ビッダー サービスを通じて FinestDSP とその他の入札者に入札リクエストを送信します。
  3. FinestDSP のビッダー アプリケーションが入札リクエストを受信して処理し、入札レスポンスを送信します。
  4. Google はビッダーから入札レスポンスを受け取ります。これには、一致タグ(ピクセル)を含む広告を指定する FinestDSP' レスポンスも含まれます。
  5. FinestDSP がオークションで落札します。Google が FinestDSP の広告とマッチタグをタグに配信します。
  6. マッチタグは、Google の Cookie マッチ サービスを呼び出し、google_nid パラメータと google_cm パラメータを指定します。
  7. Cookie マッチ サービスは、Jane の Google Cookie を読み取り、Jane のブラウザに、google_user_id パラメータと google_cver パラメータが設定された FinestDSP の Cookie マッチング URL にリダイレクトします。
  8. Jane のブラウザが FinestDSP の Cookie マッチング URL にリダイレクトされる。
  9. FinestDSP の Cookie マッチング エンドポイントはリダイレクト リクエストを処理します。リダイレクト リクエストには、Google が設定した URL パラメータと、Jane の Cookie が HTTP ヘッダーに含まれています。FinestDSP で、Cookie と google_user_id とのマッピングをマッチテーブルに格納できるようになりました。
  10. FinestDSP は、見えない 1x1 ピクセルでリダイレクトに応答します。
シナリオ 2: 既存のマッピングが割り当てられているユーザー

シナリオ 1 の 1 週間後、Jane は再び ExampleNews.com にアクセスし、Jane は入札者とアド マネージャーの両方の Cookie をパソコンに保存しました。次に、マッチングの仕組みについて説明します。

  1. ウェブページのレンダリングが行われると、Google(アド マネージャー)はそのページでレンダリングする広告をリクエストします。
  2. 広告オークションの過程で、Google は該当する入札者(FinestDSP を含む)に入札リクエストを送信します。
  3. FinestDSP は、google_user_id などのシグナルを含む入札リクエストを受信します。
  4. FinestDSP はマッチテーブルで google_user_id を検索し、1 週間前に作成された Jane に関連付けられている Cookie を見つけます(シナリオ 1 を参照)。
  5. FinestDSP の Cookie に関連付けられている情報に基づいて、インプレッションに入札し、オークションで落札します。
  6. FinestDSP が所有する情報に基づいて、興味や関心に合わせてカスタマイズされた広告が表示されます。

単方向 Cookie マッチングは、Google のみがマッチテーブルをホストしてデータを入力するように変更される点を除き、双方向ワークフローと似ています。これは、ビッダーが独自のマッチテーブルで Google ユーザー ID をホストすることを許可しない場合に使用できます。このフローを使用するには、入札者が Google にマッチ テーブルのホストを許可し、Google の Cookie マッチング サービスに対するリクエストで google_cm を指定できないようにする必要があります。そのため、google_gid が独自のマッチ テーブルを設定することがなくなります。Google がユーザーに対して一致を設定したら、ビッダーは独自の Cookie データを使用してユーザーをユーザーリストに追加します。同様に、こうしたユーザーからの入札リクエストには Google ユーザー ID は含まれませんが、ホストされたマッチデータは含まれません。改定されたワークフローの簡単な例を下のステップにまとめています。

このフローを開始するには、ビッダーがユーザーのブラウザに表示されるようなマッチタグを配置する必要があります。カリフォルニア州以外のユーザー向けのワークフローとは異なり、マッチタグは、ユーザーのブラウザを Cookie マッチング URL にリダイレクトする必要があります。たとえば、Cookie マッチング URL が https://ad.network.com/pixel として構成されている場合、次のようになります。

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

ユーザーのブラウザに読み込む際に、ビッダーの Cookie マッチング URL にピクセルがリクエストされます。このリクエストでは HTTP ヘッダーに Cookie が含まれ、次のステップで抽出されます。

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

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

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

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

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

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

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

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

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

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

カリフォルニア州のユーザーのデフォルトのワークフローは、次の図に示されています。リクエストとレスポンスは矢印で示され、付随するデータ項目はかっこ内に表示されています。

パラメータ 説明
google_nid ビッダー アカウントのネットワーク ID(NID)。この ID は、Buyer REST API アカウントのリソースである cookieMatchingNid フィールドで取得できます。
google_sc このパラメータは非推奨です。ユーザーの Google の Cookie が存在しない場合は、Cookie を設定します。パラメータの値は無視され、省略できます。Cookie が存在しない場合、パラメータを省略するとエラーが発生します。
google_no_sc このパラメータは非推奨です。これにより、Google の Cookie マッチング サービスに、そのユーザーに Cookie が存在しない場合は Cookie を設定しないようにできます。パラメータの値は無視され、省略できます。
google_hm

ビッダーが Google がホストするマッチテーブルに保存するデータが含まれています。

google_redir Google に HTTP 302 リダイレクトの送信を許可する URL をエンコードします。指定された URL は、エラーと正常なオペレーションの両方の google_error パラメータを含むリダイレクトを受け取ります。
google_ula 既存のユーザーリストにユーザーを追加するために使用される文字列。想定される値は userlistid[,timestamp] です。
  • userlistid: 単一の数値ユーザーリスト ID。
  • timestamp: POSIX 形式のタイムスタンプ(省略可)。ユーザーがユーザーリストに追加された時刻を示します。

この URL パラメータを繰り返して、ユーザーを複数のリストに追加することもできます。

パラメータ 説明
google_error

リクエスト全体のエラーを示す整数値。受信した場合は、オペレーションが実行されていないことを示し、他の google_ レスポンス パラメータは設定されていません。サポートされているエラー値は次のとおりです。

  • 1: ユーザーは Google Cookie を持っていますが、この Cookie を使ったトラッキングを無効にしています。
  • 2: 有効なオペレーションが指定されていない(no-op リクエストが受信されたなど)。
  • 3: ユーザーに Google Cookie がありません。Google では、Cookie マッチング サービスを使用して Cookie を設定することはありません。
  • 4: 競合するオペレーションが指定されています。同じリクエストに対して google_push フラグと google_cm フラグの両方を指定することはできません。目的が矛盾しているからです。
  • 5: 双方向の Pixel Matching リクエストの一部として、無効な google_push パラメータが Google サーバーへのリダイレクトで渡されました。リダイレクトでは、google_push を最初のピクセル リクエストで渡されたものと同じ値に設定する必要があります。
  • 6: 無効な NID がマッチタグで指定されました。
  • 7: 無効な Cookie が検出されました。
  • 8: 非推奨。Cookie が見つかりません。
  • 9: Cookie が見つかりません。テスト Cookie の設定を試みます。
  • 10: google_redir パラメータは、google_hm を指定せずに使用されたか、google_cm に加えて使用されたものです。
  • 15: このリクエストは、Google がマッチテーブルをホストする必要があるリージョンから送信されます。そのため、このレスポンスには Google ユーザー ID は含まれません。この機能は現在、ごく一部のトラフィックに対してのみ有効になっていますが、2020 年 6 月には完全に有効になる予定です。

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

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

ステップ 1: Google がマッチタグを設定する

参加しているパブリッシャーのページがユーザーのブラウザに読み込まれ、そのページの広告スロットが Google によって埋められた場合、アルゴリズムによって選択されたビッダーにピクセルをリクエストする一致タグが設定されます。Google が設定した Pixel Matching タグでは、ビッダーの 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" />

ピクセル マッチング リクエストを受信するビッダーは、次のような構造の Google の Cookie マッチング サービスにリダイレクトして応答する必要があります。

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

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

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

Google はユーザーに対して一致が作成されたことをログに記録し、クエリ パラメータを介してリクエストされた追加のオペレーションを処理します。最後に、1x1 の透明なピクセルを返します。

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

このワークフローを以下の図に示します。リクエストとレスポンスは矢印で示され、関連するデータ項目はかっこ内に記載されています。

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

パラメータ 説明
google_gid Google ユーザー ID。カリフォルニア州以外のユーザーの場合、これは常に Google のマッチタグで指定されます。
google_cver Cookie のバージョン。これは常に Google のマッチタグで指定されます。
google_push このリクエストにより Google Pixel Matching ワークフローが開始していることを示します。この値は、ビッダーのリダイレクト レスポンスの対応するパラメータを介して返す必要があります。

ビッダーの Pixel Matching リダイレクト パラメータ

パラメータ 説明
google_nid ビッダー アカウントのネットワーク ID(NID)。この ID は、Buyer REST API アカウントのリソースである cookieMatchingNid フィールドで取得できます。
google_push このリダイレクトで Pixel Matching のワークフローが完了したことを示します。対応する Google マッチタグの値をここで指定する必要があります。
google_hm

ビッダーが Google がホストするマッチテーブルに保存するデータが含まれています。

google_ula 既存のユーザーリストにユーザーを追加するために使用される文字列。想定される値は userlistid[,timestamp] です。
  • userlistid: 単一の数値ユーザーリスト ID。
  • timestamp: POSIX 形式のタイムスタンプ(省略可)。ユーザーがユーザーリストに追加された時刻を示します。

この URL パラメータを繰り返して、ユーザーを複数のリストに追加することもできます。

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

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

ステップ 1: Google がマッチタグを設定する

アルゴリズムによって選定されたビッダーに Google がマッチタグを設定する。一致タグには google_push パラメータが含まれます。次に例を示します。

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

ステップ 2: ユーザーのブラウザがビッダーの Cooking Matching URL にピクセルをリクエストする

ユーザーのブラウザが、ビッダーの Cookie マッチング URL(HTTP ヘッダー内のビッダーの Cookie を含む)にピクセルをリクエストします。

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

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

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

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

Open Bidding を使用すると、エクスチェンジは 入札者(ビッダー)が開始し、Google が開始した Cookie マッチング ワークフローを使用して、Google ユーザー ID と Cookie をマッチングできます。Cookie マッチ アシスト(CMA)は、独自の入札者とのマッチテーブルを構築できるエクスチェンジ用の追加機能です。

  1. 広告を表示する際、Google は参加するエクスチェンジをアルゴリズムによって選択し、次の構造を持つ Cookie マッチ アシストタグを配置します。

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
  2. Google の CMA 一致タグにより、エクスチェンジの Cookie マッチング URL がピクセル リクエストを受信します。

  3. エクスチェンジの Cookie マッチング エンドポイントがリクエストを受信し、独自の Cookie マッチング サービスがユーザー ID とビッダーのマッチングを行います。下の図では、エクスチェンジの Cookie マッチング サービスが、ユーザーのブラウザにレスポンスとしてビッダーのエンドポイントの 1 つにリダイレクトされます。
  4. ビッダーはリクエストと、エクスチェンジが指定したユーザー ID と Cookie を照合するパラメータを受け取ります。

制限事項

新しい一致リクエストのフリークエンシー キャップ

ビッダーは、Google がホストするマッチ テーブルに新しいエントリが入力された場合の Cookie マッチング サービスへの呼び出し数を制限する役割を担います。ホスト型マッチテーブルのエントリは、14 日間で有効期限が切れていると判断され、その後更新できます。

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

Pixel Matching ワークフローを使用する入札者は、google_push パラメータを含むレスポンスですべての Google Pixel Match リクエストに応答する必要があります。これにより、Google は使用状況をモニタリングすることでポリシーを適用できます。入札者のレスポンス率が 90% を下回った場合、アカウントに送信される Pixel Match リクエスト数が抑制されます。

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

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

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

以下の例は、Cookie マッチング サービスを使用して特定の目標を達成する方法を示しています。特に明記されていない限り、処理対象のユーザーはカリフォルニア州以外のユーザーであるとみなされます。

ビッダーでホストされるマッチテーブルにデータを取り込む

ビッダーは 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 パラメータをご覧ください。

1 つのユーザー リストに追加

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

<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 マッチングを実行して単一のリクエストでユーザーリストにユーザーを追加するには、ビッダーのマッチタグに google_cmgoogle_ula を含める必要があります。

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

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

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

Google がホストするマッチテーブルへのマッチングの保存

ビッダーが Cookie データを Google がホストするマッチテーブルに格納し、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_hm が正常なレスポンスに含まれないため、google_gid パラメータはリダイレクトに含まれません。今後、このユーザーのインプレッションに対する入札リクエストでは、ビッダーは、ホストされているマッチデータを Google の RTB プロトコルの BidRequest.hosted_match_data、または Google の OpenRTB 実装の BidRequest.user.buyeruid で受信します。

ビッダーが代わりに google_hm の値が base64 でエンコードされていないマッチタグ(chocolate_chunk! など)を使用した場合、リダイレクト URL は次のようになります。

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

上記のリダイレクト URL には google_hm2 が含まれています。値がデコードできなかったため、このオペレーションは失敗しました。

ユーザーリストと入札者および Google がホストするマッチテーブル

ビッダーが Google がホストするユーザーリストに加えて、独自の使用リストをホストしていて、1 つのマッチタグを両方のテーブルに一致させ、指定されたユーザーリストにユーザーを追加する場合は、マッチタグに google_cmgoogle_hmgoogle_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 をターゲットに設定するように構成されたビッダーのプレターゲティングにより、ビッダーはユーザーからのインプレッションの入札リクエストを受信するようになります。同様に、これらの入札リクエストでは、ビッダーはホスト型マッチデータを BidRequest.hosted_match_data(Google の RTB プロトコルの場合)または BidRequest.user.buyeruid(Google の OpenRTB の実装の場合)で受信します。