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

Cookie マッチング

Cookie マッチングは、Cookie マッチングを可能とする機能です。たとえば、ウェブサイトを閲覧したユーザーの ID と、入札者固有の Google ユーザー ID の確認、オーディエンスリストの作成に役立つより効果的な入札方法を選択できますこのガイドでは、Cookie で使用される概念について説明します。マッチング、Cookie マッチングのワークフロー、バリエーション理解しておくことが重要です

コンセプト

ドメイン所有者は通常、ブラウジングするユーザーの Cookie の内容を設定するそのドメイン内のユーザーを識別するために使用されます。たとえドメイン所有者は、そうでなければこのデータの交換に同意するでしょう。セキュリティモデルは、他が設定した Cookie の読み取りを制限しているインターネットブラウザの割合できます。

デジタル広告のコンテキストでは、Google は Cookie を使用してユーザーを識別します。 doubleclick.net ドメインに属するもの、およびビッダー独自のドメインを使用する場合があります広告を表示するユーザーグループを特定する。Cookie マッチングビッダーは Google の Cookie と照合して、入札リクエストで送信されたインプレッションがユーザーは自分の Cookie データやビッダー固有の Google ユーザー ID です。入札リクエストに doubleclick.net 個の Cookie が含まれています。

このガイドで説明する Cookie マッチングサービスを使用すると、入札者の Cookie と Google Cloud の関連付けの管理 User-ID。また、ユーザーリストへの入力にも使用されます。

マッチテーブル

マッチテーブルを使用すると、あるドメインの ID などのデータを別のものです。ビッダーは Cookie マッチングサービスを使用して、独自のデータを入力できるマッチングテーブルを作成します。具体的には、そのユーザーの Cookie をユーザーの Google ユーザー ID、または Google がホストするマッチテーブルにデータを入力する。マッチテーブルはユーザーの Cookie データにアクセスするためにビッダーのビッダーアプリケーションが必要となる場合設定されます

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

容易なメンテナンス、レイテンシの改善、使用する場合は、Google がインターネットでホストできるように Google の使用します。これにより、ウェブセーフの Base64 エンコード文字列を指定できます。以下「ホストされたマッチデータ」と呼ぶことができ、指定されたユーザーの Google ユーザー ID。一致が確立されたら使用しないでください。

リアルタイムビッダー: インプレッションに対する後続の入札リクエスト関連する場合、Google はホストされているマッチデータを Google ユーザー ID と照合されます入札エンドポイントが Google の RTB プロトコルを使用する場合は、 BidRequest.hosted_match_data フィールド。Google の OpenRTB BidRequest.user.buyeruid がこれを返します。ウェブセーフな Base64 エンコード文字列として変換できます。
<ph type="x-smartling-placeholder">
</ph> キーポイント: プライバシー制限のある米国の州に在住していると検出されたユーザーについては、 Google ユーザー ID は入札リクエストで指定されません。引き続きホストされたマッチデータを受け取ります。このデータを入札に使用し、
ユーザーリスト: ユーザーリストにデータを入力できます。 Google ユーザー ID またはホストされているマッチデータとの照合に使用されます。
<ph type="x-smartling-placeholder">
</ph> 注意: プライバシー上の制限がある米国の州から発信されたことが検出されたユーザーについては、ユーザーリストを作成するための Google ユーザー ID のサポートは終了し、最終的に日の入りに合わせてビッダーのユーザーリストに、ホストされているホストマッチングデータを確認できます。
プレターゲティング設定: 入札リクエストのみを受信するようにプレターゲティングを設定できます。データを格納できます。これにより、関連性の低い Cookie 領域外のユーザーに対するインプレッション数です。

ユーザーリスト

ユーザーリストは Real-Time Bidding API で作成、管理できます。作成したリストは、Cookie マッチングのワークフローで入力できます。または一括アップロードサービスを使用して行うことができます。

スタートガイド

Cookie マッチングの使用を開始するには、テクニカルアカウントマネージャー。特定のワークフローを実現し、お客様のサポートを提供します。次のように構成します。

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

で確認できます。

サポートされている Cookie マッチングのワークフローで、次のことを行います。ビッダーの Cookie マッチング URL には通常、非保証型オーダーの場合です整合性を必要とする統合を行うビッダー Cookie マッチング URL にマクロを配置して、プレースメントを保証できます

サポートされるマクロ

ビッダーは、必要に応じて Cookie マッチング URL に 1 つ以上の複数のマクロを %%GOOGLE_<PARAM_NAME>%% または %%GOOGLE_<PARAM_NAME>_PAIR%%。サポートされているマクロと展開された値は次のとおりです。

マクロ	展開された値
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`

マクロの例

ビッダーは、次の URL でホストされているエンドポイントと Cookie マッチングを統合しています。 https://user.bidder.com.cookies があり、その実装にはピクセルマッチングに加えて、ビッダー定義のプリセットパラメータ次の順序でパラメータを指定します: 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 マッチングサービスは現在、以下で説明するとおりです。

双方向の 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 マッチングサービスにリクエストがユーザーのブラウザから発行され、HTTP 302 が発行されます。ビッダーの Cookie マッチング URL にリダイレクトされます。リダイレクトには次のクエリが含まれます URL に含まれる Google ユーザー ID とそのバージョン番号を指定するパラメータビッダーはリクエストヘッダーに含まれる Cookie も受け取ります。イン Cookie マッチング URL が https://ad.network.com/pixel として指定されている場合、上記のシンプル一致タグのリダイレクト URL は、次のようになります。次のとおりです。

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

google_gid パラメータで渡される Google ユーザー ID は次のようになります。パディングなしのウェブセーフ base64 エンコード使用します。マッチテーブルをホストする場合は、 Cookie マッチングサービスから返された文字列をそのまま格納する。後続の BidRequest.google_user_id で指定された値に対応します。 Google の RTB プロトコル、または BidRequest.user.id OpenRTB の実装。

google_cver で指定されたバージョンは、 Google ユーザー ID のバージョン番号です。各ユーザーの Google ユーザー ID は低い頻度で変更され、その後は増加します。

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

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

ビッダーは、次を含む Cookie マッチング URL へのリダイレクトを受け取ります。パラメータと、Google が 2 つ目の手順に進みます。また、HTTP リクエストで Cookie を受信します。使用します。操作が成功した場合、独自のマッチテーブルをホストしているビッダー Cookie とレスポンスに含まれる Google ユーザー ID を照合する内容 Cookie マッチングで返された文字列をそのまま保存することをおすすめします。。

オペレーションが失敗した場合は、ビッダーに google_error が送信されます。パラメータを使用します。この値は、発生したエラーを特定するエラー状態を示します。学習内容発生する可能性のあるエラー値について詳しくは、こちらをご覧ください。エラーが発生した場合は、次の方法でもう一度そのユーザーとのマッチングを試みることができます。新しいマッチタグを配置します

ビッダーは常に 1×1 の非表示ピクセル画像を配信することで応答する必要がある。 HTTP 204 No Content レスポンスを返します。

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

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

パラメータ	説明
`google_nid`	ビッダーアカウントのネットワーク ID（NID）。この ID は入札者（ビッダー）からリソースです。
`google_cm`	Google の Cookie マッチングサービスに、実行すべきことを通知します Cookie マッチングを使用します。パラメータの値は無視されるため、省略されます。
`google_sc`	このパラメータは非推奨となりました。次のドメインに Google の Cookie を設定します: 表示されます。パラメータの値は無視されるため、省略できます。Cookie がない場合にパラメータを省略するとエラーになるあります。
`google_no_sc`	このパラメータは非推奨となりました。これは、Google の Cookie マッチングサービスに基づき、ユーザーに対して Cookie を設定しない存在しないことに注意してください。パラメータの値は無視されるため、省略されます。
`google_hm`	ビッダーが Google がホストするマッチテーブルに保存するデータです。値は、ウェブセーフの Base64 エンコード文字列（パディングは任意）です。元データは 40,000 以内である必要がありますバイト以下にする必要があります。例: `Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u`
`google_redir`	URL エンコードされた文字列で、ビッダーが URL エンコードを Google が、エンコードされた URL に `HTTP 302` リダイレクトを送信します。使用します。これにより、Google をチェーン接続の最前線に配置できます。呼び出します。指定せずに指定するとエラーが発生します。 `google_hm`、または `google_cm` と一緒に使用できます。
`google_ula`	既存のユーザーリストにユーザーを追加する際に使用する文字列です。値の `userlistid[,timestamp]` の形式で指定してください。 <ph type="x-smartling-placeholder"> </ph> `userlistid`: 単一の数値のユーザーリスト ID。 `timestamp`: POSIX 形式のタイムスタンプ（省略可）。は、ユーザーがユーザーリストに追加されたことを示します。この URL パラメータを繰り返すことで、ユーザーを複数のできます。
`gdpr`	リクエストがデータに関する GDPR 制限の対象となることを示しますできます。詳しくは、をご覧ください。 EU ユーザーの同意に関する要件、または Cookie マッチングへの影響 <ph type="x-smartling-placeholder"></ph> 認定バイヤーの IAB TCF v2.0 ドキュメントをご覧ください。例: `gdpr=1`
`gdpr_consent`	エンドユーザーの同意を表す TC 文字列。詳しくは EU ユーザーの同意に関する要件をご覧ください、または How will the TC string is pass?」を参照してください。 <ph type="x-smartling-placeholder"></ph> 認定バイヤーの IAB TCF v2.0 ドキュメントをご覧ください。
`process_consent`	ビッダーが、 <ph type="x-smartling-placeholder"></ph> 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 は、次の URL に設定されたベース Cookie マッチング URL から作成されます。ビッダーのアカウント（google_ とビッダーで定義されたパラメータを含む）マッチタグで指定した内容に応じて自動的に配信されます次の google_ 次のように定義されます。

パラメータ	説明
`google_gid`	Google ユーザー ID。`google_cm` がリクエストで指定され、リクエストが成功した場合に設定されます。
`google_cver`	Cookie のバージョン。`google_cm` がリクエストで指定され、リクエストが成功した場合に設定されます。
`google_error`	リクエスト全体のエラーを示す整数値。日時オペレーションは実行されておらず、他に何も実行されていないことを示します。 `google_` レスポンスパラメータが設定されます。サポートされているエラー次のような値があります。 `1`: ユーザーに Google の Cookie はありますが、いずれの Cookie もオプトアウトしていますこの Cookie を使用してトラッキングを行います。 `2`: 有効なオペレーションが指定されていません。たとえば NoOps の受信しました。 `3`: ユーザーに Google の Cookie が設定されていません。Google は Cookie マッチングサービスを通じて Cookie を設定する。 `4`: 競合するオペレーションが指定されています。あなたは `google_push` と `google_cm` の両方を指定できます。使用すると、目的が矛盾しているため、フラグを付けることができません。 `5`: 無効な `google_push` パラメータが使用されていました。双方向プロセスの一環として 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 を消去してサイトを閲覧する

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

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

ExampleNews.com がレンダリングし、Google（アドマネージャー）から広告を呼び出します。
この広告ユニットはダイナミックアロケーションの対象であるため、入札単価は FinestDSP や他のビッダーにリアルタイムビッダー経由でリクエストを送信できます。
FinestDSP のビッダーアプリケーションが入札リクエストを受信して処理し、入札レスポンスを送信します
Google が入札者からの入札レスポンス（FinestDSP のレスポンスを含む）を受け取るは、マッチタグ（ピクセル）を使用して広告を指定します。
FinestDSP がオークションの落札者となります。Google が FinestDSP の広告とマッチタグを Jane、
マッチタグは Google の Cookie マッチングサービスを呼び出し、 google_nid パラメータと google_cm パラメータ。
Cookie マッチングサービスは、Jane の Google の Cookie を読み取って、Jane のブラウザが FinestDSP の Cookie マッチング URL にリダイレクトし、 google_user_id パラメータと google_cver パラメータが設定されている。
Jane のブラウザに、FinestDSP の Cookie マッチング URL へのリダイレクトが読み込まれます。
FinestDSP の Cookie マッチングエンドポイントがリダイレクトリクエストを処理し、これには Google が設定した URL パラメータと、 HTTP ヘッダー。FinestDSP では、Cookie のマッチテーブルで「google_user_id」と入力されました。
FinestDSP は、目に見えない 1×1 ピクセルでリダイレクトに応答します。

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

シナリオ 1 の 1 週間後、Jane は ExampleNews.com に再度アクセスしました。Jane がビッダーとアドマネージャーの Cookie の両方が設定されている場合は、機能します。

ウェブページが表示されると、Google（アドマネージャー）はページ上にレンダリングされます
広告オークションの際、Google は該当する入札者に入札リクエストを送信し、これには FinestDSP が含まれます
FinestDSP が入札リクエストを受信します。これには google_user_id。
FinestDSP がマッチテーブルで google_user_id を検索します。 1 週間前に作成された Jane に関連付けられた Cookie が（シナリオ 1）
Cookie に関連付けられた情報に基づいて、FinestDSP の入札がロジックでインプレッションに入札し、オークションの落札者となります。
情報に基づいて、ユーザーの興味や関心に合わせた広告を表示する場合があります FinestDSP が提供しています

単方向 Cookie マッチングは、双方向ワークフローに似ており、ただし、Google のみがマッチをホストして入力するように変更される表しますこれは、ビッダーがホストを許可していない場合に使用できます。固有のマッチテーブルに含まれる Google ユーザー ID です。このフローを使用するためにマッチテーブルをホストすることを Google に許可する必要があります。 Google の Cookie マッチングサービスへのリクエストで google_cm そのため、自身のデータを入力する google_gid を受け取ることはありません。使用します。Google がユーザーのマッチングを確立すると、入札者はユーザーリストに登録できます。同様に Google ユーザー ID は除外されますが、ホスト型マッチデータが含まれます。改訂後のワークフローの簡単な例を以下の手順で説明します。

このフローを開始するには、ビッダーはマッチタグを配置して、ユーザーのブラウザに表示されます。プライバシー上の制限がある米国の州以外のユーザーのワークフローとは異なり、マッチタグにより、ユーザーのブラウザが広告主様の Cookie に転送されるようにする必要がある一致する URL。たとえば、Cookie マッチング URL が https://ad.network.com/pixel は次のようになります。

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

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

ビッダーの Cookie マッチングエンドポイントは、Google の Cookie にリダイレクトする必要があります次の要素が入力された google_hm パラメータを含むマッチングサービスウェブセーフな Base64 エンコード 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 がない場合ビッダーのアカウント（Google）に、一致するレポート URL が指定されていますでは 1×1 の透明なピクセルがデフォルトで配信され、ここでワークフローは終了します。以降の入札リクエストでのこのユーザーのインプレッションには、ビッダーの Google Workspace のBidRequest.hosted_match_data またはBidRequest.user.buyeruid（Google の OpenRTB 用）説明します。ビッダーはホストされているマッチデータを使ってユーザーリストを作成することも可能ですできます。

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

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

ユーザーのブラウザがビッダーの Cookie マッチングレポート URL にリダイレクトされ、エラーの原因（ある場合）を google_error パラメータ。エラーの解釈について詳しくはパラメータの説明をご覧ください。

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

ビッダーは、1x1 の透明なピクセルをユーザーのできます。

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

パラメータ	説明
`google_nid`	ビッダーアカウントのネットワーク ID（NID）。この ID は入札者（ビッダー）からリソースです。
`google_sc`	このパラメータは非推奨となりました。次のドメインに Google の Cookie を設定します: 表示されます。パラメータの値は無視されるため、省略できます。Cookie がない場合にパラメータを省略するとエラーになるあります。
`google_no_sc`	このパラメータは非推奨となりました。これは、Google の Cookie マッチングサービスに基づき、ユーザーに対して Cookie を設定しない存在しないことに注意してください。パラメータの値は無視されるため、省略されます。
`google_hm`	ビッダーが Google がホストするマッチングに保存するデータを含む。表します注: 値はウェブセーフの Base64 エンコード文字列（パディングは任意）で、23 バイト未満にする必要があります。たとえば、例: `Q29va2llIG51bWJlciAxIQ==`。
`google_redir`	Google が HTTP 302 リダイレクトを送信するエンコード済み URL。「指定した URL が、`google_error` でリダイレクトを受け取ります。パラメータを使用して、エラーと正常なオペレーションの両方を記録します。
`google_ula`	既存のユーザーリストにユーザーを追加する際に使用する文字列です。値の `userlistid[,timestamp]` の形式で指定してください。 <ph type="x-smartling-placeholder"> </ph> `userlistid`: 単一の数値のユーザーリスト ID。 `timestamp`: POSIX 形式のタイムスタンプ（省略可）。は、ユーザーがユーザーリストに追加されたことを示します。この URL パラメータを繰り返すことで、ユーザーを複数のできます。
`gdpr`	リクエストがデータに関する GDPR 制限の対象となることを示しますできます。詳しくは、をご覧ください。 EU ユーザーの同意に関する要件、または Cookie マッチングへの影響 <ph type="x-smartling-placeholder"></ph> 認定バイヤーの IAB TCF v2.0 ドキュメントをご覧ください。例: `gdpr=1`
`gdpr_consent`	エンドユーザーの同意を表す TC 文字列。詳しくは EU ユーザーの同意に関する要件をご覧ください、または How will the TC string is pass?」を参照してください。 <ph type="x-smartling-placeholder"></ph> 認定バイヤーの IAB TCF v2.0 ドキュメントをご覧ください。
`process_consent`	ビッダーが、 <ph type="x-smartling-placeholder"></ph> Google の EU ユーザーの同意ポリシー。リクエストが EU ユーザーの同意ポリシーの対象でない場合、またはリクエストで使用できる他の同意パラメータ（`gdpr_consent`）の場合、このパラメータは無視されます。例: `process_consent=T`

パラメータ説明

パラメータ	説明
`google_error`	リクエスト全体のエラーを示す整数値。日時オペレーションは実行されておらず、他に何も実行されていないことを示します。 `google_` レスポンスパラメータが設定されます。サポートされているエラー次のような値があります。 `1`: ユーザーに Google の Cookie はありますが、いずれの Cookie もオプトアウトしていますこの Cookie を使用してトラッキングを行います。 `2`: 有効なオペレーションが指定されていません。たとえば NoOps の受信しました。 `3`: ユーザーに Google の Cookie が設定されていません。Google は Cookie マッチングサービスを通じて Cookie を設定する。 `4`: 競合するオペレーションが指定されています。あなたは `google_push` と `google_cm` の両方を指定できます。使用すると、目的が矛盾しているため、フラグを付けることができません。 `5`: 無効な `google_push` パラメータが使用されていました。双方向プロセスの一環として 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 もオプトアウトしていますこの Cookie を使用してトラッキングを行います。
2: 有効なオペレーションが指定されていません。たとえば NoOps の受信しました。
3: ユーザーに Google の Cookie が設定されていません。Google は Cookie マッチングサービスを通じて Cookie を設定する。
4: 競合するオペレーションが指定されています。あなたは google_push と google_cm の両方を指定できます。使用すると、目的が矛盾しているため、フラグを付けることができません。
5: 無効な google_push パラメータが使用されていました。双方向プロセスの一環として 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 とユーザー ID のマッチングを試みるサービスリアルタイムビッダーオークションの落札者以外の入札者広告がマッチタグが配置され、ユーザーのブラウザに選択されたビッダーの Cookie マッチング URL からの透明なピクセル。有効にすると Google とビッダーの両方で、特定のユーザーのマッチテーブルにデータを入力します。以下は、このワークフローの簡単な例です

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

プログラムに参加しているパブリッシャーのページがユーザーのブラウザで読み込まれ、 Google によってコンテンツが埋められる場合は、該当のページにマッチタグがアルゴリズムによって選択されたビッダーのピクセルをリクエストします。ピクセルマッチングタグにより、ビッダーの Cookie マッチング URL と追加パラメータマッチテーブルへの入力に使用できます。Cookie マッチング URL の場合 https://ad.network.com/pixel として指定されている場合、次のように構成されます。次のようになります。

<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 マッチングワークフローのマッチタグ。ピクセルマッチングでは、google_cm パラメータは google_push パラメータ。その値はリクエスト内で Google から提供される情報です。ビッダーが開始したクリエイティブとワークフロー、追加のパラメータ指定することで、追加のユースケースに対応できます。

</ph> 警告: google_cm と google_push Google の Cookie マッチングへの同じリクエストにパラメータを含めないようにするサービス。

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

Google はそのユーザーについてマッチが作成されたことをログに記録し、追加のオペレーションがリクエストされた場合、Google は最後に、 1×1 の透明なピクセルを使用します

ピクセルマッチングのワークフロー図

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

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

パラメータ	説明
`google_gid`	Google ユーザー ID。プライバシー上の制限がある米国の州以外のユーザーの場合は、常に Google のマッチタグで指定されます。
`google_cver`	Cookie のバージョン。これは、常に Google のマッチタイプで指定されます。できます。
`google_push`	このリクエストによってピクセルマッチングワークフローが開始されていることを示します。この値は、ビッダーの自動的にリダイレクトされます。

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

パラメータ	説明
`google_nid`	ビッダーアカウントのネットワーク ID（NID）。この ID は入札者（ビッダー）からリソースです。
`google_push`	このリダイレクトでピクセルマッチングが完了することを示します説明します。対応する Google マッチタグの値は、指定します。
`google_hm`	ビッダーが Google がホストするマッチングに保存するデータを含む。表します注: 値はウェブセーフの Base64 エンコード文字列（パディングは任意）で、23 バイト未満にする必要があります。たとえば、例: `Q29va2llIG51bWJlciAxIQ==`。
`google_ula`	既存のユーザーリストにユーザーを追加する際に使用する文字列です。値の `userlistid[,timestamp]` の形式で指定してください。 <ph type="x-smartling-placeholder"> </ph> `userlistid`: 単一の数値のユーザーリスト ID。 `timestamp`: POSIX 形式のタイムスタンプ（省略可）。は、ユーザーがユーザーリストに追加されたことを示します。この URL パラメータを繰り返すことで、ユーザーを複数のできます。

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

単方向ピクセルマッチングは、双方向ワークフローと次の点で異なります。 Google のマッチタグに Google ユーザーを指定するパラメータが含まれないことを Google がホストするマッチテーブルに引き続きデータが入力されます。これはビッダーが Google ユーザー ID を独自のマッチテーブルを作成できます改訂されたワークフローの簡単な例は、手順は次のとおりです。

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

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

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

ステップ 2: ユーザーのブラウザがビッダーのクッキングマッチング 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 に追加されます。オペレーションが成功した場合、以降の入札リクエストでのこのユーザーのインプレッション数には以下が含まれます。 BidRequest.hosted_match_data のビッダーがホストするマッチデータ: Google プロトコル、または Google のプロトコル BidRequest.user.buyeruid OpenRTB の実装。ビッダーは、ホストされている一致します。

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

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

広告を掲載する際、Google のアルゴリズムに基づいて Cookie マッチングアシストタグがストラクチャ:
```
<img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
```
注意: プライバシー制限のある米国の州のユーザーの場合、Cookie は Match Assist に google_user_id パラメータは含まれません。
Google の CMA マッチタグにより、エクスチェンジの Cookie マッチング URL が受信します。

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

で確認できます。

制限事項

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

ビッダーには Cookie への呼び出し回数を制限する責任がある Google がホストするマッチングで新たにエントリが追加されたユーザーを対象としたマッチングサービス表しますホスト型マッチテーブルのエントリは、14 日後に期限切れと見なされる場合があります。更新できるようになります。

すべてのピクセル一致リクエストに応答する

ピクセルマッチングワークフローを使用するビッダーは、受信した Pixel Match リクエストと google_push を含むレスポンスパラメータを指定します。これにより、Google は使用状況をモニタリングしてポリシーを適用できます。もしレスポンス率が 90% を下回った場合、Google はレスポンス率をアカウントに送信されたピクセルの一致リクエスト。

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

すべての Cookie マッチングワークフローで使用するエンドポイントでは、提供します。

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

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

TCFv2: gdpr、gdpr_consent などあります。詳しくは、 <ph type="x-smartling-placeholder"></ph> 認定バイヤーの 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

ユーザーが 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 マッチングを実行し、単一のユーザーリストにユーザーを追加する。リクエストには、ビッダーのマッチタグに 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_gid パラメータはリダイレクトに含まれていません。これは、マッチタグに google_cm が含まれておらず、google_hm が成功したレスポンスに含まれません。インプレッションに対する今後の入札リクエストに指定した場合、ビッダーはホストされたマッチデータを Google の RTB プロトコルの場合は BidRequest.hosted_match_data 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_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 ユーザー ID と照合するマッチテーブルに Cookie データが追加されている「google_gid」。イン Google がホストするマッチテーブルとユーザーリストを成功しました。そのためビッダーのプレターゲティング設定では指定したユーザーリスト ID をターゲットにするよう設定されている場合、ビッダーはユーザーからのインプレッションに対する入札リクエストを受信できる。同様にリクエストすると、ビッダーはホストされたマッチデータを Google の RTB プロトコルの場合は BidRequest.hosted_match_data BidRequest.user.buyeruid（Google の OpenRTB 実装）