このページは 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 マッチングサービスを使用して、特定のユーザーの Cookie をそのユーザーの Google ユーザー ID にマッピングすることで、独自の照合テーブルにデータを入力したり、Google がホストする照合テーブルにデータを入力したりできます。マッチテーブルは、入札者の入札者アプリケーションがインプレッションが表示されているユーザーの Cookie データにアクセスするために必要です。

Google ホスト型マッチテーブル

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

リアルタイムビッディング: ユーザーに関連付けられたインプレッションの以降の入札リクエストで、Google は、Google ユーザー ID と一致したホスト型マッチデータを送信します。Google は BidRequest.user.buyeruid をウェブセーフな Base64 エンコード文字列として指定します。

重要: プライバシー制限のある米国の州に居住していると検出されたユーザーの場合、入札リクエストで Google ユーザー ID は指定されません。ホストされた一致データは引き続き受け取ることができ、入札ロジックの判断に使用できます。
注意: デフォルトでは、buyeruid の値はウェブセーフな base64 エンコード済み文字列であり、google_hm で送信する値と同じである必要があります。入札リクエストで予期しない buyeruid 値が返される場合は、エンコードされていない google_hm 値を送信している可能性があります。入札リクエストでエンコードを無効にするには、テクニカルアカウントマネージャーにお問い合わせください。
ユーザーリスト: ユーザーリストには、Google ユーザー ID またはホストされている一致データを使用できます。

注意: プライバシー規制のある米国の州に居住していると検出されたユーザーについては、ユーザーリストの作成に Google ユーザー ID を使用することは非推奨となり、最終的には廃止されます。入札者は、これらのユーザーのホスト型マッチデータをユーザーリストに登録することをおすすめします。
プレターゲティング: ホストされている照合データを含む入札リクエストのみを受信するように、プレターゲティングを設定できます。これにより、Cookie スペース外のユーザーに対して関連性の低いインプレッションを排除できます。

ユーザーリスト

ユーザーリストは、リアルタイムビッダー 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 マッチングアシスト URL: Cookie マッチングアシストワークフローを実装しているエクスチェンジの場合、これは受信リクエストに応答するエンドポイントのベース 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 マッチング統合を行っており、実装では Pixel マッチングパラメータに加えて、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 の 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 マッチングの設定時にテクニカルアカウントマネージャーから提供されます。また、リアルタイムビッダー API の Bidders リソースで確認することもできます。

マッチタグに含めることができる追加のパラメータがあり、さまざまなユースケースに対応できます。これらのパラメータの詳細については、マッチタグの 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 マッチングサービスから返された文字列をそのまま保存することをおすすめします。以降の入札リクエストでは、これは BidRequest.user.id で指定された値に対応します。

google_cver で指定されたバージョンは、Google ユーザー ID の数値バージョン番号を示します。特定のユーザーの Google ユーザー ID は頻繁には変更されませんが、変更された場合はこの値が増加します。

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

ステップ 3: 入札者のプロセスがリダイレクトし、ピクセルで応答する

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

オペレーションが失敗した場合、入札者はリダイレクトで google_error パラメータを受け取ります。これは、発生した特定のエラーを識別するさまざまなエラー状態に対応する数値です。エラー値の詳細については、google_error URL パラメータの説明をご覧ください。エラーが表示された場合は、新しい照合タグを配置して、そのユーザーの照合を再度試みることができます。

入札者は、常に 1x1 の非表示ピクセル画像を配信するか、HTTP 204 No Content レスポンスを返すことで応答する必要があります。

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

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

パラメータ	説明
`google_nid`	入札アカウントのネットワーク ID（NID）。この ID は、入札者リソースから取得できます。
`google_cm`	Google の Cookie マッチングサービスに Cookie マッチングを実行するよう指示します。パラメータの値は無視され、省略できます。
`google_sc`	このパラメータは非推奨になりました。ユーザーの Cookie が存在しない場合は、Google の 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 ユーザーの同意に関する要件、または 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`

入札者は、上記のパラメータに加えて、独自のパラメータを指定することもできます。このパラメータは、リダイレクト 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 マッチングリクエストの一部として、Google サーバーへのリダイレクトで無効な `google_push` パラメータが渡されました。リダイレクトでは、最初のピクセルリクエストで渡された値と同じ値を `google_push` に設定する必要があります。 `6`: マッチタグで無効な NID が指定されました。 `7`: 無効な Cookie が検出されました。 `8`: 非推奨。Cookie が見つかりませんでした。 `9`: Cookie が見つからなかったため、テスト Cookie の設定が試行されます。 `10`: `google_hm` を指定せずに `google_redir` パラメータが使用されたか、`google_cm` に加えて使用されました。 `15`: リクエストは、Google が一致テーブルを Google でホストすることを義務付けているリージョンから送信されています。そのため、このレスポンスには Google ユーザー ID が含まれません。
`google_hm`	Google ホストの照合テーブルへの書き込みが失敗した場合にのみ表示されます。その場合、値は次のいずれかのステータスコードになります。 `1` - Forbidden: お客様は、ホストされている照合テーブルエントリを書き込む権限を持っていません。 `2` - デコードエラー: パラメータ値をデコードできませんでした。 `3` - ペイロードが長すぎます: パラメータ値が 40 バイトを超えるデータにデコードされました。 `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 のホームページにアクセスします。

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

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

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

シナリオ 1 の 1 週間後、ジェーンは ExampleNews.com に再びアクセスします。Jane のマシンにビッダー Cookie とアドマネージャー Cookie の両方が保存されている場合、照合は次のように行われます。

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

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

ステップ 1: 入札者の Cookie マッチング URL に転送されるマッチタグを配置する

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

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

ユーザーのブラウザで読み込まれると、入札者の Cookie マッチング URL からピクセルがリクエストされます。このリクエストには HTTP ヘッダーに Cookie が含まれています。次のステップでこの 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 が指定されていない場合、Google はデフォルトで 1x1 の透明なピクセルを配信し、ワークフローはここで終了します。以降の入札リクエストでこのユーザーのインプレッションには、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 が google_error パラメータで指定したエラー理由（ある場合）が含まれます。エラーコードの解釈の詳細については、パラメータの説明をご覧ください。

ステップ 6: 入札者が 1x1 の透明なピクセルを配信する

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

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

パラメータ	説明
`google_nid`	入札アカウントのネットワーク ID（NID）。この ID は、入札者リソースから取得できます。
`google_sc`	このパラメータは非推奨になりました。ユーザーの Cookie が存在しない場合は、Google の Cookie を設定します。パラメータの値は無視され、省略できます。パラメータを省略すると、Cookie が存在しない場合にエラーが発生します。
`google_no_sc`	このパラメータは非推奨になりました。これは、Google の Cookie マッチングサービスに対して、Cookie が存在しない場合はユーザーに Cookie を設定しないよう指示します。パラメータの値は無視され、省略できます。
`google_hm`	入札者が Google ホスト型の照合テーブルに保存するデータを格納します。注: 値はウェブセーフな Base64 エンコード文字列（パディングは省略可）で、40 バイトを超えてはなりません。たとえば、`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`: 有効なオペレーションが指定されていません。たとえば、no-op リクエストが受信されました。 `3`: ユーザーに Google Cookie がありません。Google は Cookie マッチングサービスを通じて Cookie を設定しません。 `4`: 競合するオペレーションが指定されています。`google_push` フラグと `google_cm` フラグは目的が競合するため、同じリクエストで両方を指定することはできません。 `5`: 双方向の Pixel マッチングリクエストの一部として、Google サーバーへのリダイレクトで無効な `google_push` パラメータが渡されました。リダイレクトでは、最初のピクセルリクエストで渡された値と同じ値を `google_push` に設定する必要があります。 `6`: マッチタグで無効な NID が指定されました。 `7`: 無効な Cookie が検出されました。 `8`: 非推奨。Cookie が見つかりませんでした。 `9`: Cookie が見つからなかったため、テスト Cookie の設定が試行されます。 `10`: `google_hm` を指定せずに `google_redir` パラメータが使用されたか、`google_cm` に加えて使用されました。 `15`: リクエストは、Google が一致テーブルを Google でホストすることを義務付けているリージョンから送信されています。そのため、このレスポンスには Google ユーザー ID が含まれません。

google_error

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

1: ユーザーは Google Cookie を持っているが、この Cookie を使用したトラッキングをオプトアウトしている。
2: 有効なオペレーションが指定されていません。たとえば、no-op リクエストが受信されました。
3: ユーザーに Google Cookie がありません。Google は Cookie マッチングサービスを通じて Cookie を設定しません。
4: 競合するオペレーションが指定されています。google_push フラグと google_cm フラグは目的が競合するため、同じリクエストで両方を指定することはできません。
5: 双方向の Pixel マッチングリクエストの一部として、Google サーバーへのリダイレクトで無効な google_push パラメータが渡されました。リダイレクトでは、最初のピクセルリクエストで渡された値と同じ値を google_push に設定する必要があります。
6: マッチタグで無効な NID が指定されました。
7: 無効な Cookie が検出されました。
8: 非推奨。Cookie が見つかりませんでした。
9: Cookie が見つからなかったため、テスト Cookie の設定が試行されます。
10: google_hm を指定せずに google_redir パラメータが使用されたか、google_cm に加えて使用されました。
15: リクエストは、Google が一致テーブルを Google でホストすることを義務付けているリージョンから送信されています。そのため、このレスポンスには Google ユーザー ID が含まれません。

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 マッチタグのリクエストパラメータ

パラメータ	説明
`google_gid`	Google ユーザー ID。プライバシー制限のある米国の州に在住していないユーザーについては、常に Google のマッチタグで指定されます。
`google_cver`	Cookie のバージョン。これは常に Google のマッチタグで指定されます。
`google_push`	このリクエストがピクセルマッチングワークフローを開始することを示します。値は、入札者のリダイレクトレスポンスの対応するパラメータで返される必要があります。
`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 は、入札者リソースから取得できます。
`google_push`	このリダイレクトがピクセルマッチングワークフローを完了することを示します。対応する Google の照合タグの値を指定する必要があります。
`google_hm`	入札者が Google ホスト型の照合テーブルに保存するデータを格納します。注: 値はウェブセーフな Base64 エンコード文字列（パディングは省略可）で、40 バイトを超えてはなりません。たとえば、`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: ユーザーのブラウザが入札者の Cookie マッチング URL からピクセルをリクエストする

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

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

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

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

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

広告を配置する際、Google のアルゴリズムは参加しているエクスチェンジを 1 つ選択し、次の構造の Cookie マッチアシストタグを配置します。
```
<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% 未満の場合、Google はそのアカウントに送信されるピクセルマッチリクエストの数を制限します。

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

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

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

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 にリダイレクトする際にそのまま渡されます。

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

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 に対するオペレーションは失敗しています。

Cookie マッチングを実行して、1 回のリクエストでユーザーをユーザーリストに追加するには、入札者のマッチタグに 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 ホスト型マッチテーブルにマッチを保存する

入札者が 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 パラメータはリダイレクトに含まれていません。このユーザーのインプレッションの今後の入札リクエストでは、入札者はホストされている照合データを BidRequest.user.buyeruid で受け取ります。

入札者が 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" />