このページは Cloud Translation API によって翻訳されました。

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 User ID の関連付けを簡単に作成、維持できます。また、ユーザーリストにデータを入力することもできます。

マッチテーブル

マッチテーブルを使用すると、ID などのデータを 1 つのドメインから別のドメインにマッピングできます。ビッダーは、Cookie マッチングサービスを使用して、特定のユーザーの 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 は指定されません。ホストされたマッチデータは引き続き受信され、入札ロジックの参考として使用できます。
ユーザーリスト: ユーザーリストには、Google ユーザー ID またはホストされたマッチデータを入力できます。

注意: プライバシーに関する制限が適用される米国の州を拠点とするユーザーが検出された場合は、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 マッチング 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_push、google_gid、google_cver、google_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_error パラメータは、Google の Google Pixel の一致ワークフローの一致タグに入力されないため、除外されます。

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

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

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

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

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

注: BIDDER_ACCOUNT_NID は、ビッダーアカウントの NID に置き換える必要があります。これは、ビッダーアカウントの Cookie マッチングの設定時にテクニカルアカウントマネージャーから提供されます。また、Real-time Bidding API のビッダーリソースで確認することもできます。

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

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

マッチタグにより、Google の Cookie マッチングサービスがユーザーのブラウザからリクエストを受信し、ビッダーの Cookie マッチング URL に HTTP 302 リダイレクトを送信します。リダイレクトには、Google ユーザー ID とそのバージョン番号を指定するクエリパラメータが URL に含まれます。また、ビッダーはリクエストヘッダーに含まれる 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 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 レスポンスを返す必要があります。

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

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

パラメータ	説明
`google_nid`	ビッダーアカウントのネットワーク ID（NID）。この ID は、Bidders リソースから取得できます。
`google_cm`	Google の Cookie マッチングサービスに、Cookie マッチングを実行するよう指示します。パラメータの値は無視され、省略できます。
`google_sc`	このパラメータは非推奨になりました。Cookie が存在しない場合は、ユーザーに Google の Cookie を設定します。パラメータの値は無視され、省略できます。パラメータを省略すると、Cookie が存在しない場合、エラーが発生します。
`google_no_sc`	このパラメータは非推奨になりました。これは、Cookie が存在しない場合はユーザーの Cookie を設定しないことを Google の 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 ユーザーの同意要件、または Authorized Buyers IAB TCF v2.0 のドキュメントのCookie マッチの利用資格への影響をご覧ください。例: `gdpr=1`
`gdpr_consent`	エンドユーザーの同意を表す TC 文字列。詳しくは、以下のEU ユーザーの同意要件、または Authorized Buyers 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 から構築されます。これには、google_ や、ビッダー定義のパラメータ（マッチタグで指定されたパラメータに応じて）が含まれます。次の google_ レスポンスパラメータが定義されています。

パラメータ	説明
`google_gid`	Google ユーザー ID。リクエストで `google_cm` が指定され、リクエストが成功した場合に設定します。
`google_cver`	Cookie のバージョン。リクエストで `google_cm` が指定され、リクエストが成功した場合に設定します。
`google_error`	全体的なリクエストエラーを示す整数値。受信すると、オペレーションが実行されていないことを示します。他の `google_` レスポンスパラメータは設定されません。サポートされているエラー値は次のとおりです。 `1`: ユーザーに Google Cookie が設定されているが、この Cookie を使用したトラッキングをオプトアウトしている。 `2`: 有効なオペレーションが指定されていません。たとえば、NOP リクエストが受信されました。 `3`: ユーザーに Google クッキーがありません。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 がホストすることを要求しているリージョンから送信された場合。そのため、このレスポンスには 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 を削除してサイトをブラウジングする

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

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

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

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

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

ウェブページがレンダリングされると、Google（アドマネージャー）はページにレンダリングされる広告をリクエストします。
広告オークション中に、Google は FinestDSP などの該当するビッダーに入札リクエストを送信します。
FinestDSP は、google_gid などのシグナルを含む入札リクエストを受信します。
FinestDSP はマッチテーブルで google_gid を検索し、1 週間前に作成された（シナリオ 1 の）ジェーンに関連付けられた Cookie を見つけます。
クッキーに関連付けられた情報に基づいて、FinestDSP の入札ロジックがインプレッションに入札し、オークションで落札します。
ジェーンには、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 は次のステップで抽出する必要があります。

ビッダーの 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: レポート 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" />

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

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

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

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

パラメータ	説明
`google_nid`	ビッダーアカウントのネットワーク ID（NID）。この ID は、Bidders リソースから取得できます。
`google_sc`	このパラメータは非推奨になりました。Cookie が存在しない場合は、ユーザーに Google の Cookie を設定します。パラメータの値は無視され、省略できます。パラメータを省略すると、Cookie が存在しない場合、エラーが発生します。
`google_no_sc`	このパラメータは非推奨になりました。これは、Cookie が存在しない場合はユーザーの Cookie を設定しないことを Google の Cookie マッチングサービスに指示します。パラメータの値は無視され、省略できます。
`google_hm`	ビッダーが Google がホストするマッチテーブルに保存するデータを格納します。注: 値はウェブセーフな base64 でエンコードされた文字列（パディングは省略可）で、23 バイト未満にする必要があります。たとえば、`Q29va2llIG51bWJlciAxIQ==` のようになります。
`google_redir`	Google が HTTP 302 リダイレクトを送信するエンコードされた URL。指定された URL には、エラーとオペレーションの成功の両方で `google_error` パラメータを含むリダイレクトが送信されます。
`google_ula`	既存のユーザーリストにユーザーを追加するために使用される文字列。値の形式は `userlistid[,timestamp]` です。 `userlistid`: 単一の数値のユーザーリスト ID。 `timestamp`: POSIX 形式のタイムスタンプ（省略可）。ユーザーがユーザーリストに追加された日時を示します。この URL パラメータを繰り返して、ユーザーを複数のリストに追加できます。
`gdpr`	リクエストにデータ使用に関する GDPR の制限が適用されることを示します。詳しくは、以下の EU ユーザーの同意要件、または Authorized Buyers IAB TCF v2.0 のドキュメントのCookie マッチの利用資格への影響をご覧ください。例: `gdpr=1`
`gdpr_consent`	エンドユーザーの同意を表す TC 文字列。詳しくは、以下のEU ユーザーの同意要件、または Authorized Buyers IAB TCF v2.0 ドキュメントの TC 文字列はどのように渡されますか？をご覧ください。
`process_consent`	Google の EU ユーザーの同意ポリシーに記載されているデータの使用について、ビッダーがエンドユーザーの同意を得ていることを示します。リクエストが EU ユーザーの同意ポリシーの対象外である場合、またはリクエストで使用可能な他の同意パラメータ（`gdpr_consent`）がある場合、このパラメータは無視されます。例: `process_consent=T`

パラメータ説明

パラメータ	説明
`google_error`	全体的なリクエストエラーを示す整数値。受信すると、オペレーションが実行されていないことを示します。他の `google_` レスポンスパラメータは設定されません。サポートされているエラー値は次のとおりです。 `1`: ユーザーに Google Cookie が設定されているが、この Cookie を使用したトラッキングをオプトアウトしている。 `2`: 有効なオペレーションが指定されていません。たとえば、NOP リクエストが受信されました。 `3`: ユーザーに Google クッキーがありません。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 がホストすることを要求しているリージョンから送信された場合。そのため、このレスポンスには Google ユーザー ID が含まれません。現在のところ、この機能はトラフィックのごく一部でのみ有効になっていますが、2020 年 6 月に完全に有効になる予定です。

google_error

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

1: ユーザーに Google Cookie が設定されているが、この Cookie を使用したトラッキングをオプトアウトしている。
2: 有効なオペレーションが指定されていません。たとえば、NOP リクエストが受信されました。
3: ユーザーに Google クッキーがありません。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 がホストすることを要求しているリージョンから送信された場合。そのため、このレスポンスには Google ユーザー ID が含まれません。現在のところ、この機能はトラフィックのごく一部でのみ有効になっていますが、2020 年 6 月に完全に有効になる予定です。

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

双方向ピクセルマッチングは、Google の Cookie マッチングサービスのワークフローです。Google は、リアルタイム入札オークションの落札者以外の、アルゴリズムによって選択されたビッダーと 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" />

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

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

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

警告: google_cm パラメータと google_push パラメータを、Google の Cookie マッチングサービスに対する同じリクエストに含めてはなりません。

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

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

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

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

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

パラメータ	説明
`google_gid`	Google ユーザー ID。プライバシーに関する制限が適用される米国の州に居住していないユーザーについては、常に Google のマッチタグで指定されます。
`google_cver`	Cookie のバージョン。これは常に Google の一致タグで指定されます。
`google_push`	このリクエストで Google Pixel の照合ワークフローが開始されることを示します。値は、ビッダーのリダイレクトレスポンスの対応するパラメータで返す必要があります。
`gdpr_consent`	エンドユーザーの同意を表す TC 文字列。詳しくは、下記の [EU のユーザーの同意要件](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) または [Authorized Buyers IAB TCF v2.0 のドキュメント](//support.google.com/authorizedbuyers/answer/9789378) の「TC 文字列はどのように渡されますか？」をご覧ください。

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

パラメータ	説明
`google_nid`	ビッダーアカウントのネットワーク ID（NID）。この ID は、Bidders リソースから取得できます。
`google_push`	このリダイレクトでピクセルマッチングワークフローが完了したことを示します。対応する Google マッチタグの値をここで指定する必要があります。
`google_hm`	ビッダーが Google がホストするマッチテーブルに保存するデータを格納します。注: 値はウェブセーフな base64 でエンコードされた文字列（パディングは省略可）で、23 バイト未満にする必要があります。たとえば、`Q29va2llIG51bWJlciAxIQ==` のようになります。
`google_ula`	既存のユーザーリストにユーザーを追加するために使用される文字列。値の形式は `userlistid[,timestamp]` です。 `userlistid`: 単一の数値のユーザーリスト ID。 `timestamp`: POSIX 形式のタイムスタンプ（省略可）。ユーザーがユーザーリストに追加された日時を示します。この URL パラメータを繰り返して、ユーザーを複数のリストに追加できます。
`gdpr_consent`	エンドユーザーの同意を表す TC 文字列。詳しくは、下記の [EU のユーザーの同意要件](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) または [Authorized Buyers IAB TCF v2.0 のドキュメント](//support.google.com/authorizedbuyers/answer/9789378) の「TC 文字列はどのように渡されますか？」をご覧ください。

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 からピクセルをリクエストする

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

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

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

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

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

広告を掲載する際、Google は参加しているエクスチェンジをアルゴリズムによって選択し、次の構造の Cookie Match Assist タグを配置します。
```
<img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
```
注意: プライバシー制限が適用される米国の州にお住まいのユーザーの場合、Cookie マッチアシストには google_gid パラメータが含まれません。
Google の CMA マッチタグにより、エクスチェンジの Cookie マッチング URL にピクセルリクエストが送信されます。

注: Google が開始するワークフローとは異なり、google_push パラメータは除外されます。
エクスチェンジの Cookie マッチングエンドポイントがリクエストを受信します。ここで、エクスチェンジ独自の Cookie マッチングサービスが、ユーザー ID とビッダーのいずれかを照合します。次の図は、エクスチェンジの Cookie マッチングサービスが、ビッダーのエンドポイントのいずれかにリダイレクトすることで、ユーザーのブラウザに応答する様子を示しています。
ビッダーは、リクエストと、ユーザー ID と Cookie を照合するためにエクスチェンジが指定したパラメータを受け取ります。

制限事項

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

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

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

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

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

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

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

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

注: マッチタグで指定されたビッダー定義パラメータ id は、Google がビッダーの Cookie マッチング URL にリダイレクトするときにそのまま渡されます。

1 人のユーザーのリストに追加する

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_ula の値は 12345,0 です。これは、ユーザーを ID 12345 のユーザーリストに追加する必要があることを示します。この場合、タイムスタンプは 0 に設定され、未指定であることを示します。または、ユーザーリスト ID のみを指定することもできます。

全体的なエラー（ユーザーの 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 に対しては失敗しています。

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 には google_hm 値が 2 になっています。これは、値をデコードできなかったためにオペレーションが失敗したことを示しています。

ビッダーと 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 で受け取ります。