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

Cookie マッチング

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

コンセプト

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

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

このガイドで説明する Cookie マッチングサービスを使用すると、ビッダーの Cookie と Google ユーザー ID の関連付けを簡単に作成、維持できます。また、ユーザーリストにデータを入力することもできます。

マッチテーブル

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

注: 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 も受け取ります。オペレーションが成功すると、独自のマッチテーブルをホストしているビッダーが、Cookie とレスポンスに含まれる Google ユーザー ID を照合できます。ビッダーは、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_push` パラメータが、双方向の Pixel Matching リクエストの一部として、Google サーバーへのリダイレクトで渡されました。リダイレクトでは、`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 サービスは、Jane の Google Cookie を読み取り、Jane のブラウザに google_gid パラメータと google_cver パラメータが設定された FinestDSP の Cookie マッチング URL へのリダイレクトを送信します。
Jane のブラウザに、FinestDSP の Cookie マッチング URL へのリダイレクトが読み込まれます。
FinestDSP の Cookie マッチングエンドポイントは、リダイレクトリクエストを処理します。これには、Google が設定した URL パラメータと、HTTP ヘッダー内の Jane に対する Cookie が含まれます。FinestDSP は、Cookie と google_gid のマッピングをマッチテーブルに保存できるようになりました。
FinestDSP は、リダイレクトに応答して目に見えない 1x1 ピクセルを返します。

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

シナリオ 1 の 1 週間後、ジェーンは ExampleNews.com に再度アクセスします。Jane のマシンにビッダーとアドマネージャーの Cookie の両方が作成されたので、マッチングの仕組みを説明します。

ウェブページが表示されると、Google（アドマネージャー）はページにレンダリングされる広告をリクエストします。
広告オークション中に、Google は FinestDSP などの該当するビッダーに入札リクエストを送信します。
FinestDSP は、google_gid などのシグナルを含む入札リクエストを受信します。
FinestDSP はマッチテーブルで google_gid を検索し、1 週間前に作成された Jane に関連付けられた Cookie を見つけます（シナリオ 1）。
クッキーに関連付けられた情報に基づいて、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 マッチングエンドポイントは、ウェブセーフな 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 ユーザーの同意に関する要件、または認定バイヤーの 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_push` パラメータが、双方向の Pixel Matching リクエストの一部として、Google サーバーへのリダイレクトで渡されました。リダイレクトでは、`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_push パラメータが、双方向の Pixel Matching リクエストの一部として、Google サーバーへのリダイレクトで渡されました。リダイレクトでは、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 ユーザー 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 Matching Service へのリダイレクトを含むレスポンスを返す必要があります。このレスポンスの構造は次のとおりです。

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)、または [認定バイヤーの IAB TCF v2.0 のドキュメント](//support.google.com/buyers/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 マッチングサービスが、ユーザーのブラウザに対し、ビッダーのエンドポイントの 1 つへのリダイレクトを返します。
ビッダーは、リクエストと、ユーザー 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 マッチングサービスを使用して特定の目標を達成する方法を示しています。なお、特に記載のない限り、操作の対象となるユーザーは、プライバシー上の制限がある米国の州に在住していないものとします。

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

ビッダーは、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 マッチングサービスの呼び出しに関する制限事項をご覧ください。対応するマッチタグは次のようになります。

<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_hm が含まれていないため、google_gid パラメータがリダイレクトに含まれていません。今後、このユーザーのインプレッションに関する入札リクエストで、ビッダーは 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 で受け取ります。