Cookie マッチング

Cookie マッチングは、Cookie(ウェブサイトを閲覧したユーザーの ID など)を、対応する入札者固有の Google ユーザー ID と照合し、より効果的な入札方法を選択するためのユーザーリストを作成する機能です。このガイドでは、Cookie マッチングで使用される概念や、Cookie マッチングのさまざまなワークフロー、特定のユースケースで使われる場合のあるバリエーションについて説明します。

概念

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

デジタル広告のコンテキストでは、Google は doubleclick.net ドメインに属する Cookie でユーザーを識別します。また、リアルタイム ビッダーに参加するビッダーは、広告を表示したい一連のユーザーを定義する独自のドメインを持つ場合があります。Cookie マッチングにより、ビッダーは自分の Cookie と Google の Cookie を照合できます。これにより、ビッダーは入札リクエストで送信されたインプレッションがターゲットとなるユーザーの 1 人に関連付けられているかどうかを判断できます。その際、ビッダーは、独自の 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 の RTB プロトコルを使用するように構成されている場合、この値は BidRequest.hosted_match_data フィールドからデコードされたバイトとして受け取ります。Google の OpenRTB 実装では、BidRequest.user.buyeruid はこのデータをウェブセーフな Base64 エンコード文字列として返します。

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

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

ユーザーリスト

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

はじめに

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

  • Cookie マッチング ネットワーク 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 マッチングを統合しており、実装にはピクセル マッチング パラメータに加えて、事前に設定されたビッダー定義のパラメータが必要です(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 リダイレクトを発行します。リダイレクトには、URL 内の Google ユーザー ID とそのバージョン番号を指定するクエリ パラメータが含まれます。ビッダーは、リクエスト ヘッダーで Cookie も受け取ります。実際には、https://ad.network.com/pixel として指定された Cookie マッチング URL の場合、上記のシンプル マッチタグのリダイレクト 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 番目のステップで Google が指定したパラメータを含む、Cookie マッチング URL へのリダイレクトを受け取ります。また、HTTP ヘッダーで Cookie を受け取ります。オペレーションが成功した場合、独自のマッチテーブルをホストするビッダーは、レスポンスに含まれる Google ユーザー ID と Cookie を照合できます。ビッダーは Cookie マッチング サービスが返す文字列をそのまま保存することをおすすめします。

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

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

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

マッチタグの URL パラメータ

パラメータ 説明
google_nid ビッダー アカウントのネットワーク ID(NID)。この ID は、Bidders リソースで取得できます。
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 に HTTP 302 リダイレクトを送信するよう Google に指示する場合に指定できる、URL エンコードされた文字列。これにより、パートナーへのチェーン呼び出しで Google を最前面に配置できます。google_hm を指定せずに指定するか、google_cm とともに指定すると、エラーが発生します。
google_ula 既存のユーザーリストにユーザーを追加するために使用する文字列。値の想定形式は userlistid[,timestamp] です。
  • userlistid: 単一の数値形式のユーザーリスト ID。
  • timestamp: ユーザーがユーザーリストに追加されたタイミングを示す POSIX 形式のタイムスタンプ(省略可)。

この URL パラメータは、ユーザーを複数のリストに追加するために繰り返し指定できます。

gdpr リクエストに対して、データ使用量に関する GDPR 制限が適用されることを示します。詳しくは、下記の EU ユーザーの同意要件または 認定バイヤー IAB TCF v2.0 のドキュメントCookie マッチの利用資格への影響をご覧ください。

例: gdpr=1

gdpr_consent エンドユーザーの同意を表す TC 文字列。詳しくは、下記の EU ユーザーの同意要件または 認定バイヤー IAB TCF v2.0 のドキュメントTC 文字列を渡す方法をご覧ください。
process_consent Google の EU ユーザーの同意ポリシーで指定されているデータの使用について、ビッダーがエンドユーザーの同意を得ていることを示します。

リクエストが EU ユーザーの同意ポリシーの対象でない場合、またはリクエストで使用可能な他の同意パラメータ(gdpr_consent)がある場合、このパラメータは無視されます。

例: process_consent=T

上記のパラメータに加えて、ビッダーは独自のパラメータを指定できます。このパラメータは、リダイレクト 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 から作成されます。この URL には、マッチタグで指定されたパラメータに応じて、google_ とビッダー定義のパラメータが含まれます。次の google_ レスポンス パラメータが定義されています。

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

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

  • 1: ユーザーは Google の Cookie を持っていますが、この Cookie を使用したトラッキングを無効にしています。
  • 2: 有効なオペレーションが指定されていません(例: NoOps リクエストが受信された)。
  • 3: ユーザーは Google の Cookie を持っていません。Google が Cookie マッチング サービスを使って Cookie を設定することはありません。
  • 4: 競合するオペレーションが指定されています。google_push フラグと google_cm フラグを同じリクエストに指定することはできません。これらのフラグは目的が競合するためです。
  • 5: 双方向のピクセル マッチング リクエストの一部として、Google サーバーへのリダイレクトで無効な google_push パラメータが渡されました。リダイレクトでは、最初のピクセル リクエストで渡されたものと同じ値に 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 から Jane に FinestDSP の広告とマッチタグが配信されます。
  6. マッチタグが Google の Cookie マッチ サービスを呼び出して、google_nid パラメータと google_cm パラメータを指定します。
  7. Cookie マッチング サービスが、Jane の Google Cookie を読み取り、google_user_idgoogle_cver のパラメータを設定して、Jane のブラウザに FinestDSP の Cookie マッチング URL へのリダイレクトを送信します。
  8. Jane のブラウザは、FinestDSP の Cookie マッチング URL へのリダイレクトを読み込みます。
  9. FinestDSP の Cookie マッチング エンドポイントがリダイレクト リクエストを処理します。これには、Google によって設定された URL パラメータと、HTTP ヘッダー内の Jane の Cookie が含まれます。これで FinestDSP が、Cookie と google_user_id とのマッピングをマッチテーブルに保存できるようになりました。
  10. FinestDSP は、見えない 1×1 ピクセルでリダイレクトに応答します。
シナリオ 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 が保有する情報に基づいて、Jane に対して、興味 / 関心に合った広告が表示される可能性があります。

単方向 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 は次のステップで抽出されます。

ビッダーの 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 は、HTTP ヘッダー内の Google の Cookie に加えて、指定されたパラメータを含むリダイレクトを受信します。

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

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

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

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

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

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

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

プライバシーの制限がある米国の州のユーザーに対するデフォルトのワークフローを以下の図に示します。リクエストとレスポンスは矢印で示され、付随するデータ項目は括弧内にリストされています。

パラメータ 説明
google_nid ビッダー アカウントのネットワーク ID(NID)。この ID は、Bidders リソースで取得できます。
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 パラメータは、ユーザーを複数のリストに追加するために繰り返し指定できます。

gdpr リクエストに対して、データ使用量に関する GDPR 制限が適用されることを示します。詳しくは、下記の EU ユーザーの同意要件または 認定バイヤー IAB TCF v2.0 のドキュメントCookie マッチの利用資格への影響をご覧ください。

例: gdpr=1

gdpr_consent エンドユーザーの同意を表す TC 文字列。詳しくは、下記の EU ユーザーの同意要件または 認定バイヤー IAB TCF v2.0 のドキュメントTC 文字列を渡す方法をご覧ください。
process_consent Google の EU ユーザーの同意ポリシーで指定されているデータの使用について、ビッダーがエンドユーザーの同意を得ていることを示します。

リクエストが EU ユーザーの同意ポリシーの対象でない場合、またはリクエストで使用可能な他の同意パラメータ(gdpr_consent)がある場合、このパラメータは無視されます。

例: process_consent=T

パラメータ 説明
google_error

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

  • 1: ユーザーは Google の Cookie を持っていますが、この Cookie を使用したトラッキングを無効にしています。
  • 2: 有効なオペレーションが指定されていません(例: NoOps リクエストが受信された)。
  • 3: ユーザーは Google の Cookie を持っていません。Google が Cookie マッチング サービスを使って Cookie を設定することはありません。
  • 4: 競合するオペレーションが指定されています。google_push フラグと google_cm フラグを同じリクエストに指定することはできません。これらのフラグは目的が競合するためです。
  • 5: 双方向のピクセル マッチング リクエストの一部として、Google サーバーへのリダイレクトで無効な google_push パラメータが渡されました。リダイレクトでは、最初のピクセル リクエストで渡されたものと同じ値に 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 のユーザー ID と、リアルタイム ビッダー オークションの落札者以外のアルゴリズムによって選択されたビッダーとのマッチングを試みます。広告が掲載されると、Google がマッチタグを設置し、ユーザーのブラウザに、選択されたビッダーの Cookie マッチング URL から透明なピクセルを読み込むよう指示します。これにより、Google とビッダーの両方が、特定のユーザーのマッチテーブルに入力できるようになります。このワークフローの簡単な例を以下に示します。

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

参加しているパブリッシャーのページがユーザーのブラウザで読み込まれ、そのページの広告スロットが Google によって埋められた場合、アルゴリズムによって選択されたビッダーにピクセルをリクエストするマッチタグを配置できます。Google によって配置されたピクセル マッチング タグにより、ビッダーの Cookie マッチング URL と、入札者がマッチテーブルへのデータ入力に使用できる追加パラメータが組み合わされます。Cookie マッチング URL を https://ad.network.com/pixel として指定する場合、その 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 に似ています。ピクセル マッチングでは、google_cm パラメータは google_push パラメータに置き換えられます。その値は、リクエスト内で Google が指定した値と等しい必要があります。また、ビッダーが開始するワークフローと同様に、追加のパラメータを指定して、追加のユースケースを満たすことができます。

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

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

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

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

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

パラメータ 説明
google_gid Google ユーザー ID。プライバシーの制限が適用される米国の州以外のユーザーについては、必ず Google のマッチタグで指定されます。
google_cver Cookie のバージョン。これは常に Google のマッチタグで指定されます。
google_push このリクエストがピクセル マッチング ワークフローを開始していることを示します。 この値は、ビッダーのリダイレクト レスポンス内の対応するパラメータで返す必要があります。

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

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

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

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

この URL パラメータは、ユーザーを複数のリストに追加するために繰り返し指定できます。

Google 主導: 単方向ピクセル マッチング

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

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

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

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

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

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

ビッダーの 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

Google は、HTTP ヘッダー内の Google の Cookie に加えて、指定されたパラメータを含むリダイレクトを受信します。オペレーションが正常に完了した場合、後続の入札リクエストにおけるこのユーザーのインプレッションには、ビッダーのホストされたマッチデータ(Google プロトコルではBidRequest.hosted_match_data、Google の OpenRTB 実装ではBidRequest.user.buyeruid)が含まれます。ビッダーは、自身が指定したホストされた一致データを使用してユーザーリストを登録することもできます。

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

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 Match リクエストに対して、google_push パラメータを含むレスポンスで応答することが想定されています。これにより、Google は使用状況をモニタリングしてポリシーを適用できます。入札者のレスポンス率が 90% を下回ると、Google はアカウントに送信される Pixel Match リクエストの数を抑制します。

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

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

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

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

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

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

ビッダーのマッチタグで 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 マッチングを行って 1 回のリクエストでユーザーをユーザーリストに追加するには、ビッダーのマッチタグに 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 がホストするマッチテーブルにマッチを保存する

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

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

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

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

ビッダーと 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 実装の場合)で受け取ります。