Cookie マッチングは、Cookie(ウェブサイトを閲覧したユーザーの ID など)を、対応する入札者固有の Google ユーザー ID と照合し、より効果的な入札方法を選択するためのユーザーリストを作成する機能です。このガイドでは、Cookie マッチングで使用される概念や、Cookie マッチングのさまざまなワークフロー、特定のユースケースで使われる場合のあるバリエーションについて説明します。
概念
Cookie マッチングとは
ドメイン所有者は通常、サイトを閲覧するユーザー用に Cookie の内容を設定します。 Cookie の内容は、ドメイン内のユーザーを識別するために使用されます。2 人のドメイン所有者がこのデータ交換に同意した場合でも、インターネット ブラウザのセキュリティ モデルにより、一方が別のドメインで設定された Cookie を読み取れないように制限されます。
デジタル広告のコンテキストでは、Google は doubleclick.net
ドメインに属する Cookie でユーザーを識別します。また、リアルタイム ビッダーに参加するビッダーは、広告を表示したい一連のユーザーを定義する独自のドメインを持つ場合があります。Cookie マッチングにより、ビッダーは自分の Cookie と Google の Cookie を照合できます。これにより、ビッダーは入札リクエストで送信されたインプレッションがターゲットとなるユーザーの 1 人に関連付けられているかどうかを判断できます。その際、ビッダーは、独自の Cookie データか、入札リクエスト内の doubleclick.net
Cookie の暗号化形式である入札者固有の Google ユーザー ID のいずれかを受け取ります。
このガイドで説明する Cookie マッチング サービスを使用すると、ビッダーの Cookie と Google ユーザー ID の関連付けを簡単に作成、管理できるほか、ユーザーリストへの入力も可能になります。
マッチテーブル
マッチテーブルを使用すると、あるドメインから別のドメインに ID などのデータをマッピングできます。ビッダーは Cookie マッチング サービスを利用して、特定のユーザーの Cookie をユーザーの Google ユーザー ID にマッピングすることで独自のマッチテーブル、または Google がホストするマッチテーブルにデータを入力します。マッチテーブルは、ビッダーの入札者がインプレッションが表示されているユーザーの Cookie データにアクセスするために必要です。
Google がホストするマッチテーブル
メンテナンスとレイテンシの改善、特定リージョンのユーザーのマッチング データへのアクセスを容易にするには、Google でマッチテーブルをホストするようにすることをおすすめします。これにより、特定のユーザーの Google ユーザー ID にマッピングされるウェブセーフな Base64 エンコード文字列(以下ではホスト型マッチデータと呼びます)を指定できます。一致が確立されると、次のように使用できます。
リアルタイム ビッダー: ユーザーに関連付けられたインプレッションに対する後続の入札リクエストで、Google ユーザー ID と一致するホスト型マッチデータが送信されます。入札エンドポイントが Google の RTB プロトコルを使用するように構成されている場合、この値は
BidRequest.hosted_match_data
フィールドからデコードされたバイトとして受け取ります。Google の OpenRTB 実装では、BidRequest.user.buyeruid
はこのデータをウェブセーフな Base64 エンコード文字列として返します。ユーザーリスト: ユーザーリストには、Google ユーザー ID またはホストされたマッチのデータを追加できます。
- プレターゲティング: ホストされたマッチデータを含む入札リクエストのみを受信するようにプレターゲティングを設定できます。これにより、Cookie 領域の外部にいるユーザーに対して、関連性の低いインプレッションを除外することができます。
ユーザーリスト
ユーザーリストは、Real-Time Bidding API を使って作成、管理できます。 作成したリストは、後述の Cookie マッチング ワークフローや一括アップロード サービスを使って作成できます。
はじめに
Cookie マッチングを開始するには、担当のテクニカル アカウント マネージャーにお問い合わせください。特定のワークフローを有効にして、以下の設定を行うお手伝いをいたします。
- Cookie マッチング ネットワーク ID(NID): Cookie マッチングなどの関連オペレーションを行うビッダー アカウントを一意に識別する文字列 ID です。
- Cookie マッチング URL: Cookie マッチング ワークフローの一環として受信リクエストを受け入れて処理するエンドポイントのベース URL。ビッダーは、この URL にマクロを埋め込むことで、Cookie マッチング ワークフローで渡されるパラメータの順序を管理できます。
- マッチタグ: ビッダーが開始した Cookie マッチング ワークフローでユーザーのブラウザに配置する必要があるタグ。これは広告とともに配信することも、広告以外のウェブ プロパティに配置することもできます。
- Cookie マッチング レポート URL(省略可): 単方向 Cookie マッチング ワークフローにおいて、HTTP 302 リダイレクトによって Cookie マッチングが失敗した場合にエラーの詳細を受け取るエンドポイントを指定するために指定できる URL です(省略可)。デフォルトでは、Cookie マッチング オペレーションでエラーが発生した場合にのみ、この URL にレスポンスが送信されますが、ビッダーはリダイレクトを常に送信するようにリクエストできます。
- Cookie Match Assist URL: Cookie Match Assist ワークフローを実装するエクスチェンジの場合、受信リクエストに応答するエンドポイントのベース URL です。
- Cookie Match Assist 割り当て: Cookie Match Assist ワークフローを実装しているエクスチェンジの場合、これは Cookie マッチング URL が 1 秒間に受信できるリクエストの最大数です。これは、CMA リクエストによってエクスチェンジのサーバーが過負荷になるのを防ぐためです。
Cookie マッチング マクロ
サポートされている Cookie マッチング ワークフローでは、通常、ビッダーの 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
Cookie マッチング サービスのワークフロー
Google の Cookie マッチング サービスでは現在、以下で説明するさまざまなユースケースに対応するための 3 つのワークフローをサポートしています。
ビッダー開始: 双方向の Cookie マッチング
双方向の Cookie マッチングは、ビッダーが開始するワークフローで、ユーザーのブラウザにマッチタグを設置して Google に誘導します。このワークフローにより、Google とビッダーの両方がマッチテーブルにデータを入力できます。このワークフローの簡単な例を以下に示します。
ステップ 1: マッチタグを配置する
このフローを開始するには、ビッダーはユーザーのブラウザにレンダリングされるようにマッチタグを配置する必要があります。ビッダーに Google ユーザー ID のみを返す単純なマッチタグは、次のように構成できます。
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />
マッチタグに追加パラメータを含めることで、さまざまなユースケースに対応できます。これらのパラメータについて詳しくは、マッチタグの URL パラメータをご覧ください。
ステップ 2: Google が一致データを含むリダイレクトを応答する
このマッチタグにより、Google の Cookie マッチング サービスはユーザーのブラウザからのリクエストを受け取り、ビッダーの Cookie マッチング URL への HTTP 302
リダイレクトを発行します。リダイレクトには、URL 内の Google ユーザー ID とそのバージョン番号を指定するクエリ パラメータが含まれます。ビッダーは、リクエスト ヘッダーで Cookie も受け取ります。実際には、https://ad.network.com/pixel
として指定された Cookie マッチング URL の場合、上記のシンプル マッチタグのリダイレクト URL は次のようになります。
https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
google_gid
パラメータで渡される Google ユーザー ID は、パディングされていないウェブセーフな base64 エンコード文字列です。マッチテーブルをホストする場合は、Cookie マッチング サービスで返される文字列をそのまま保存することをおすすめします。後続の入札リクエストでは、Google の RTB プロトコルの BidRequest.google_user_id
または Google の OpenRTB 実装の BidRequest.user.id
で指定された値に対応します。
google_cver
で指定されたバージョンは、Google ユーザー ID のバージョン番号を示します。特定のユーザーの Google ユーザー ID はめったに変更されず、その後は増分されます。
一致リクエストの処理中に Google がエラーが発生した場合は、代わりに google_error
パラメータを指定します。
ステップ 3: ビッダーがリダイレクトを処理し、ピクセルで応答する
ビッダーは、最初のステップで指定したパラメータと、2 番目のステップで Google が指定したパラメータを含む、Cookie マッチング URL へのリダイレクトを受け取ります。また、HTTP ヘッダーで Cookie を受け取ります。オペレーションが成功した場合、独自のマッチテーブルをホストするビッダーは、レスポンスに含まれる Google ユーザー ID と Cookie を照合できます。ビッダーは Cookie マッチング サービスが返す文字列をそのまま保存することをおすすめします。
オペレーションが失敗した場合、ビッダーはリダイレクトで google_error
パラメータを受け取ります。これは、発生した特定のエラーを識別するさまざまなエラー状態に対応する数値です。可能性のあるエラー値の詳細については、こちらをご覧ください。エラーが発生した場合は、新しいマッチタグを配置してそのユーザーとのマッチングを再度行うことができます。
ビッダーは常に 1×1 の非表示ピクセルの画像を配信するか、HTTP 204
コンテンツなしレスポンスを返す必要があります。
Cookie マッチングのワークフロー図
以下の図はこのワークフローを示しています。ここで、リクエストとレスポンスは矢印で表され、それに付随するデータ項目は括弧内にリストされています。
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_matching.png?authuser=8&hl=ja)
マッチタグの URL パラメータ
パラメータ | 説明 |
---|---|
google_nid |
ビッダー アカウントのネットワーク ID(NID)。この ID は、Bidders リソースで取得できます。 |
google_cm |
Cookie マッチングを実施するよう Google の Cookie マッチング サービスに指示します。パラメータの値は無視され、省略できます。 |
google_sc |
このパラメータは非推奨になりました。Google の Cookie が存在しない場合は、ユーザーの Cookie を設定します。パラメータの値は無視され、省略できます。このパラメータを省略すると、Cookie が存在しない場合はエラーが発生します。 |
google_no_sc |
このパラメータは非推奨になりました。これにより、Google の Cookie マッチング サービスに、Cookie が存在しない場合はユーザーの Cookie を設定すべきではないことを伝えます。パラメータの値は無視され、省略できます。 |
google_hm |
ビッダーが Google がホストするマッチテーブルに保存したいデータです。
値は、ウェブセーフな Base64 でエンコードされた文字列です(パディングは省略可)。元データは 40 バイト以下にする必要があります。例: |
google_redir |
ビッダーが、このマッチタグのエンコード済み URL に HTTP 302 リダイレクトを送信するよう Google に指示する場合に指定できる、URL エンコードされた文字列。これにより、パートナーへのチェーン呼び出しで Google を最前面に配置できます。google_hm を指定せずに指定するか、google_cm とともに指定すると、エラーが発生します。 |
google_ula |
既存のユーザーリストにユーザーを追加するために使用する文字列。値の想定形式は userlistid[,timestamp] です。
この URL パラメータは、ユーザーを複数のリストに追加するために繰り返し指定できます。 |
gdpr |
リクエストに対して、データ使用量に関する GDPR 制限が適用されることを示します。詳しくは、下記の
EU ユーザーの同意要件または
認定バイヤー IAB TCF v2.0 のドキュメントの Cookie マッチの利用資格への影響をご覧ください。 例: |
gdpr_consent |
エンドユーザーの同意を表す TC 文字列。詳しくは、下記の EU ユーザーの同意要件または 認定バイヤー IAB TCF v2.0 のドキュメントの TC 文字列を渡す方法をご覧ください。 |
process_consent |
Google の EU ユーザーの同意ポリシーで指定されているデータの使用について、ビッダーがエンドユーザーの同意を得ていることを示します。 リクエストが EU ユーザーの同意ポリシーの対象でない場合、またはリクエストで使用可能な他の同意パラメータ( 例: |
上記のパラメータに加えて、ビッダーは独自のパラメータを指定できます。このパラメータは、リダイレクト URL にパラメータとして追加されます。google_
接頭辞が付いたビッダー定義パラメータは無視されます。これらのパラメータは今後の開発用に Google によって予約されるためです。また、パラメータの順序の保持は保証されません。ビッダー定義のパラメータを含むマッチタグは次のようになります。
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />
リダイレクト URL パラメータ
リダイレクト URL は、ビッダーのアカウント用に設定されたベース Cookie マッチング URL から作成されます。この URL には、マッチタグで指定されたパラメータに応じて、google_
とビッダー定義のパラメータが含まれます。次の google_
レスポンス パラメータが定義されています。
パラメータ | 説明 |
---|---|
google_gid |
Google ユーザー ID。リクエストで google_cm が指定され、リクエストが成功した場合に設定されます。 |
google_cver |
Cookie のバージョン。リクエストで google_cm が指定され、リクエストが成功した場合に設定されます。 |
google_error |
リクエスト全体のエラーを示す整数値。受信時には、オペレーションが実行されておらず、他の
|
google_hm |
Google がホストするマッチテーブルへの書き込みが失敗した場合にのみ表示されます。その場合、この値は次のいずれかのステータス コードになります。
|
google_ula |
ユーザーリストの追加操作のステータス。リクエストで複数の 例:
|
Cookie マッチング ワークフローのサンプル
以下のシナリオでは、ウェブページを閲覧している一般的なユーザーによる Cookie マッチングがどのようなものかを説明します。
シナリオ 1: ユーザーが Cookie を削除してサイトを閲覧する
Jane はすべての Cookie のキャッシュを消去しました。その後、ExampleNews.com のホームページにアクセスします。
変更点は次のとおりです。
- ExampleNews.com は広告を表示して、Google(アド マネージャー)から広告を呼び出します。
- この広告ユニットはダイナミック アロケーションに対応しているため、Google はリアルタイム ビッダー サービスを介して FinestDSP とその他の入札者に入札リクエストを送信します。
- FinestDSP のビッダー アプリケーションが、入札リクエストを受信して処理し、入札レスポンスを送信します。
- Google はビッダーから入札レスポンスを受け取ります。これには、マッチタグ(ピクセル)を含む広告を指定する FinestDSP のレスポンスも含まれます。
- FinestDSP がオークションで勝ちました。Google から Jane に FinestDSP の広告とマッチタグが配信されます。
- マッチタグが Google の Cookie マッチ サービスを呼び出して、
google_nid
パラメータとgoogle_cm
パラメータを指定します。 - Cookie マッチング サービスが、Jane の Google Cookie を読み取り、
google_user_id
とgoogle_cver
のパラメータを設定して、Jane のブラウザに FinestDSP の Cookie マッチング URL へのリダイレクトを送信します。 - Jane のブラウザは、FinestDSP の Cookie マッチング URL へのリダイレクトを読み込みます。
- FinestDSP の Cookie マッチング エンドポイントがリダイレクト リクエストを処理します。これには、Google によって設定された URL パラメータと、HTTP ヘッダー内の Jane の Cookie が含まれます。これで FinestDSP が、Cookie と
google_user_id
とのマッピングをマッチテーブルに保存できるようになりました。 - FinestDSP は、見えない 1×1 ピクセルでリダイレクトに応答します。
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie-matching-schematic.png?authuser=8&hl=ja)
シナリオ 2: 既存のマッピングを持つユーザー
シナリオ 1 の 1 週間後に、Jane が ExampleNews.com に再びアクセスしました。Jane はビッダーとアド マネージャーの両方の Cookie を自分のマシンに保存しました。次にマッチングの仕組みについて説明します。
- ウェブページがレンダリングされると、Google(アド マネージャー)はページでレンダリングされる広告をリクエストします。
- 広告オークションの間、Google は FinestDSP を含む該当する入札者に入札リクエストを送信します。
- FinestDSP が、
google_user_id
などのシグナルを含む入札リクエストを受信します。 - FinestDSP はマッチテーブルで
google_user_id
を検索し、1 週間前に作成された Jane に関連付けられている Cookie を見つけます(シナリオ 1)。 - FinestDSP の入札ロジックは、Cookie に関連付けられた情報に基づいてインプレッションに入札を行い、オークションを落札します。
- FinestDSP が保有する情報に基づいて、Jane に対して、興味 / 関心に合った広告が表示される可能性があります。
ビッダー開始: 単方向 Cookie マッチング
単方向 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 は次のステップで抽出されます。
ステップ 2: Google の 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
ステップ 3: ユーザーのブラウザが Google の Cookie マッチング サービスにリダイレクトされる
Google は、HTTP ヘッダー内の Google の Cookie に加えて、指定されたパラメータを含むリダイレクトを受信します。
ステップ 4: Google は成功時またはエラーのリダイレクト時にピクセルを配信します(レポート URL が指定されている場合)
Cookie マッチングが成功した場合、またはビッダーのアカウントで Cookie マッチング レポート URL が指定されていない場合、Google はデフォルトで 1×1 の透明なピクセルを配信し、ワークフローはここで終了します。後続の入札リクエストにおけるこのユーザーのインプレッションには、ビッダーのホスト型マッチデータが含まれます(Google プロトコルの場合は BidRequest.hosted_match_data
、Google の OpenRTB 実装の場合は BidRequest.user.buyeruid
)。ビッダーは、自身が指定したホスト型マッチデータを使用してユーザーリストを登録することもできます。
それ以外の場合は、google_error
パラメータで指定されたエラーの原因を記載した、ビッダーの Cookie マッチング レポート URL にリダイレクトが送信されます。ビッダーの Cookie マッチング レポート URL が https://ad.network.com/report
の場合、リダイレクト URL は次のようになります。
<img src="https://ad.network.com/report?google_error=ERROR_ID" />
ステップ 5: ユーザーのブラウザからビッダーの Cookie マッチング レポート URL にリダイレクトされる
ユーザーのブラウザは、ビッダーの Cookie マッチング レポート URL にリダイレクトされます。この URL には、google_error
パラメータで指定されたエラーの理由(該当する場合)が含まれます。エラーコードの解釈の詳細については、パラメータの説明をご覧ください。
ステップ 6: ビッダーが 1×1 の透明ピクセルを配信する
ビッダーは、ユーザーのブラウザに 1×1 の透明なピクセルを配信することで応答する必要があります。
プライバシーに関する制限がある米国の州のユーザーに対する Cookie マッチングのワークフローの図
プライバシーの制限がある米国の州のユーザーに対するデフォルトのワークフローを以下の図に示します。リクエストとレスポンスは矢印で示され、付随するデータ項目は括弧内にリストされています。
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_matching_ca.png?authuser=8&hl=ja)
ビッダーの URL パラメータが Google の Cookie マッチング サービスにリダイレクトされる
パラメータ | 説明 |
---|---|
google_nid |
ビッダー アカウントのネットワーク ID(NID)。この ID は、Bidders リソースで取得できます。 |
google_sc |
このパラメータは非推奨になりました。Google の Cookie が存在しない場合は、ユーザーの Cookie を設定します。パラメータの値は無視され、省略できます。このパラメータを省略すると、Cookie が存在しない場合はエラーが発生します。 |
google_no_sc |
このパラメータは非推奨になりました。これにより、Google の Cookie マッチング サービスに、Cookie が存在しない場合はユーザーの Cookie を設定すべきではないことを伝えます。パラメータの値は無視され、省略できます。 |
google_hm |
ビッダーが Google がホストするマッチテーブルに保存したいデータがある。 |
google_redir |
Google から HTTP 302 リダイレクトを送信するためのエンコードされた URL。指定された URL は、エラーと成功したオペレーションの両方に対して、google_error パラメータを使用してリダイレクトを受け取ります。 |
google_ula |
既存のユーザーリストにユーザーを追加するために使用する文字列。値の想定形式は userlistid[,timestamp] です。
この URL パラメータは、ユーザーを複数のリストに追加するために繰り返し指定できます。 |
gdpr |
リクエストに対して、データ使用量に関する GDPR 制限が適用されることを示します。詳しくは、下記の
EU ユーザーの同意要件または
認定バイヤー IAB TCF v2.0 のドキュメントの Cookie マッチの利用資格への影響をご覧ください。 例: |
gdpr_consent |
エンドユーザーの同意を表す TC 文字列。詳しくは、下記の EU ユーザーの同意要件または 認定バイヤー IAB TCF v2.0 のドキュメントの TC 文字列を渡す方法をご覧ください。 |
process_consent |
Google の EU ユーザーの同意ポリシーで指定されているデータの使用について、ビッダーがエンドユーザーの同意を得ていることを示します。 リクエストが EU ユーザーの同意ポリシーの対象でない場合、またはリクエストで使用可能な他の同意パラメータ( 例: |
Google の URL パラメータがビッダーの Cookie マッチング レポートの URL にリダイレクトされる
パラメータ | 説明 |
---|---|
google_error |
リクエスト全体のエラーを示す整数値。受信時には、オペレーションが実行されておらず、他の
|
Google 主導: 双方向のピクセル マッチング
双方向のピクセル マッチングは Google の Cookie マッチング サービスのワークフローであり、Google のユーザー ID と、リアルタイム ビッダー オークションの落札者以外のアルゴリズムによって選択されたビッダーとのマッチングを試みます。広告が掲載されると、Google がマッチタグを設置し、ユーザーのブラウザに、選択されたビッダーの Cookie マッチング URL から透明なピクセルを読み込むよう指示します。これにより、Google とビッダーの両方が、特定のユーザーのマッチテーブルに入力できるようになります。このワークフローの簡単な例を以下に示します。
ステップ 1: Google がマッチタグを配置する
参加しているパブリッシャーのページがユーザーのブラウザで読み込まれ、そのページの広告スロットが Google によって埋められた場合、アルゴリズムによって選択されたビッダーにピクセルをリクエストするマッチタグを配置できます。Google によって配置されたピクセル マッチング タグにより、ビッダーの Cookie マッチング URL と、入札者がマッチテーブルへのデータ入力に使用できる追加パラメータが組み合わされます。Cookie マッチング URL を https://ad.network.com/pixel
として指定する場合、その URL は次のように構成されます。
<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />
ステップ 2: ビッダーは Google の Cookie マッチング サービスの URL にリダイレクトして応答する必要がある
ピクセル マッチング リクエストを受け取ったビッダーは、次のような構造の Google の Cookie マッチング サービスにリダイレクトして応答する必要があります。
https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA
なお、このリダイレクト URL は、ビッダーが開始した Cookie マッチング ワークフローのマッチタグで使用されている URL に似ています。ピクセル マッチングでは、google_cm
パラメータは google_push
パラメータに置き換えられます。その値は、リクエスト内で Google が指定した値と等しい必要があります。また、ビッダーが開始するワークフローと同様に、追加のパラメータを指定して、追加のユースケースを満たすことができます。
ステップ 3: Google がリダイレクトを処理してピクセルで応答する
Google はユーザーとのマッチが作成されたことを記録し、クエリ パラメータを介してリクエストされた追加のオペレーションを処理します。最後に、Google は 1×1 の透明なピクセルで応答します。
Google Pixel マッチングのワークフロー図
以下の図はこのワークフローを示しています。ここで、リクエストとレスポンスは矢印で表され、それに付随するデータ項目は括弧内にリストされています。
![](https://developers.google.cn/static/authorized-buyers/rtb/images/pixel_matching.png?authuser=8&hl=ja)
Google マッチタグのリクエスト パラメータ
パラメータ | 説明 |
---|---|
google_gid |
Google ユーザー ID。プライバシーの制限が適用される米国の州以外のユーザーについては、必ず Google のマッチタグで指定されます。 |
google_cver |
Cookie のバージョン。これは常に Google のマッチタグで指定されます。 |
google_push |
このリクエストがピクセル マッチング ワークフローを開始していることを示します。 この値は、ビッダーのリダイレクト レスポンス内の対応するパラメータで返す必要があります。 |
ビッダーのピクセル マッチング リダイレクト パラメータ
パラメータ | 説明 |
---|---|
google_nid |
ビッダー アカウントのネットワーク ID(NID)。この ID は、Bidders リソースで取得できます。 |
google_push |
このリダイレクトがピクセル マッチング ワークフローを完了していることを示します。対応する Google マッチタグの値がここで指定する必要があります。 |
google_hm |
ビッダーが Google がホストするマッチテーブルに保存したいデータがある。 |
google_ula |
既存のユーザーリストにユーザーを追加するために使用する文字列。値の想定形式は userlistid[,timestamp] です。
この URL パラメータは、ユーザーを複数のリストに追加するために繰り返し指定できます。 |
Google 主導: 単方向ピクセル マッチング
単方向ピクセル マッチングの場合、双方向のワークフローとは異なり、Google のマッチタグには Google ユーザー ID を指定するパラメータは含まれていませんが、Google がホストするマッチテーブルに引き続きデータが入力されます。これは、ビッダーが独自のマッチテーブルで Google ユーザー ID をホストすることが許可されていない場合に使用します。改訂されたワークフローの簡単な例を以下の手順に示します。
ステップ 1: Google がマッチタグを配置する
Google は、アルゴリズムによって選択されたビッダーに対してマッチタグを配置します。マッチタグには google_push
パラメータが含まれます。次の例をご覧ください。
<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />
ステップ 2: ユーザーのブラウザがビッダーの Cooking Matching URL からピクセルをリクエストする
ユーザーのブラウザが、HTTP ヘッダーにビッダーの Cookie を含む、ビッダーの Cookie マッチング URL からのピクセルをリクエストします。
ステップ 3: Google の 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_push=PUSH_DATA
ステップ 4: ユーザーのブラウザが Google の Cookie マッチング サービスにリダイレクトされる
Google は、HTTP ヘッダー内の Google の Cookie に加えて、指定されたパラメータを含むリダイレクトを受信します。オペレーションが正常に完了した場合、後続の入札リクエストにおけるこのユーザーのインプレッションには、ビッダーのホストされたマッチデータ(Google プロトコルではBidRequest.hosted_match_data
、Google の OpenRTB 実装ではBidRequest.user.buyeruid
)が含まれます。ビッダーは、自身が指定したホストされた一致データを使用してユーザーリストを登録することもできます。
最後に、Google はユーザーのブラウザに 1×1 の透明なピクセルを返します。
Cookie マッチング アシスト
Open Bidding では、エクスチェンジは入札者(ビッダー)が開始したワークフローと Google が開始した Cookie マッチング ワークフローを使用して、Google ユーザー ID と Cookie を照合できます。Cookie マッチング アシスト(CMA)は、エクスチェンジが独自のビッダーとのマッチテーブルを構築できるようにする、エクスチェンジ向けの追加機能です。
Cookie マッチ アシストの仕組み
広告を掲載する際、Google は参加するエクスチェンジをアルゴリズムによって選択し、次のような構造の Cookie マッチング アシストタグを配置します。
<img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
Google の CMA マッチタグにより、エクスチェンジの Cookie マッチング URL はピクセル リクエストを受け取ります。
- エクスチェンジの Cookie マッチング エンドポイントがリクエストを受信し、そこで独自の Cookie マッチング サービスが、ユーザー ID をいずれかのビッダーとマッチングします。次の図では、エクスチェンジの Cookie マッチング サービスが、ユーザーのブラウザに対してビッダーのエンドポイントの 1 つにリダイレクトして応答します。
- ビッダーは、ユーザー ID と Cookie を照合するために、エクスチェンジが指定したパラメータとともにリクエストを受け取ります。
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_match_assist_diagram.png?authuser=8&hl=ja)
制限
新しい一致のリクエストの頻度に上限を設定する
ビッダーは、Google がホストするマッチテーブルに新しいエントリが追加されたユーザーについて、Cookie マッチング サービスの呼び出し回数を制限する責任を負います。ホスト型マッチテーブルのエントリは、14 日間で有効期限が切れたと見なされ、その後更新できるようになります。
すべてのピクセル一致リクエストに応答する
ピクセル マッチング ワークフローを使用するビッダーは、受信したすべての Pixel Match リクエストに対して、google_push
パラメータを含むレスポンスで応答することが想定されています。これにより、Google は使用状況をモニタリングしてポリシーを適用できます。入札者のレスポンス率が 90% を下回ると、Google はアカウントに送信される Pixel Match リクエストの数を抑制します。
HTTPS エンドポイントを使用する
Cookie マッチング ワークフローで使用されるエンドポイントでは、HTTPS を使用する必要があります。
HTTPS 経由で送信された Google Pixel Match リクエストに応答する場合は、HTTPS 経由で Cookie マッチング サービスにリダイレクトする必要があります。同様に、ビッダーにリダイレクトする Cookie Match Assist エンドポイントも HTTPS を使用する必要があります。HTTP 経由で Google に 2 分に 1 回以上頻繁にリクエストを送信すると、アカウントに送信される一致リクエストの数が抑制されます。
EU ユーザーの同意要件
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 パラメータをご覧ください。
単一のユーザーリストに追加する
ビッダーのマッチタグで google_ula
パラメータを指定して、指定された ID のユーザーリストにユーザーを追加できます。Google またはビッダーがホストするマッチテーブルにユーザーの新しいエントリがある場合、ビッダーは google_nid
パラメータと google_ula
パラメータを含むマッチタグを配置して、Cookie マッチング ワークフロー全体を開始しなくても、指定されたリストにユーザーを追加できます。Cookie マッチング サービスの呼び出しについて詳しくは、制限事項をご覧ください。対応するマッチタグは次のようになります。
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />
レスポンスが成功した場合、ビッダーの Cookie マッチング URL が https://ad.network.com/pixel
の場合、Google のリダイレクト URL は次のようになります。
https://ad.network.com/pixel?google_ula=12345,0
全体的なエラーがある場合(ユーザーの Google Cookie が存在しないなど)、リダイレクト URL に google_error
パラメータが含まれます。
https://ad.network.com/pixel?google_error=3
リストへのユーザーの追加に関するエラーが発生した場合は、リダイレクトで google_ula
を受け取ります。対応するマッチタグ パラメータとは異なり、タイムスタンプをステータス コードに置き換えて、オペレーションの成功を示します。たとえば、ビッダー アカウントが指定のユーザーリストにアクセスできないためにリクエストが失敗した場合、リダイレクト URL は次のようになります。
https://ad.network.com/pixel?google_ula=12345,2
複数のユーザーリストに追加
ビッダーは、マッチタグに複数の google_ula
パラメータを含めることで、ユーザーを複数のユーザーリストに追加するよう指定できます。実際には、次のようになります。
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />
各ユーザーリストのオペレーションのステータスも、リダイレクト内の個別の google_ula
パラメータを介してレポートされます。
https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0
上記のリダイレクトで、ID 45678
のユーザーリストではオペレーションが成功しましたが、ユーザーリスト ID 12345
ではビッダーにアクセス権がないため、オペレーションが失敗したことがわかります。
Cookie マッチングのワークフローに沿ってユーザーリストに追加
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 がホストするマッチテーブルにマッチを保存する
ビッダーが Google がホストするマッチテーブルに Cookie データを保存し、Google ユーザー ID とのマッチを独自のマッチテーブルに保存しない場合は、マッチタグに google_hm
パラメータを含める必要があります。その際、値はウェブセーフな Base64 でエンコードされた文字列にする必要があります。入札者のエンコードされていない Cookie データが Cookie number 1!
であるユーザーの場合、エンコードされた値は Q29va2llIG51bWJlciAxIQ==
となり、次のようなマッチタグで使用されます。
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />
レスポンスが成功した場合、ビッダーの Cookie マッチング URL が https://cookie-monster.com/pixel
の場合、Google のリダイレクト URL は次のようになります。
https://cookie-monster.com/pixel
マッチタグに google_cm
が含まれておらず、正常なレスポンスに google_hm
が含まれていないため、google_gid
パラメータはリダイレクトに含まれません。今後、このユーザーのインプレッションに対する入札リクエストでは、ビッダーは BidRequest.hosted_match_data
(Google の RTB プロトコルの場合)または BidRequest.user.buyeruid
(Google の OpenRTB 実装の場合)でホストされたマッチデータを受け取ります。
ビッダーが google_hm
の値が Base64 でエンコードされていないマッチタグ(chocolate_chunk!
など)を使用した場合、リダイレクト URL は次のようになります。
https://cookie-monster.com/pixel?google_hm=2
上記のリダイレクト URL には google_hm
の値 2
が含まれています。これは、値をデコードできなかったためオペレーションが失敗したことを示しています。
ビッダーと Google がホストするマッチテーブル(ユーザーリストを含む)
ビッダーが Google がホストするユーザーリストに加えて独自の使用リストをホストしており、1 つのマッチタグで両方のテーブルを照合してユーザーを特定のユーザーリストに追加したい場合は、マッチタグに google_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 をターゲットとするよう設定されたビッダーのプレターゲティングで、ビッダーはユーザーからのインプレッションに対する入札リクエストを受け取るようになります。同様に、こうした入札リクエストでは、ビッダーはホストされたマッチデータを BidRequest.hosted_match_data
(Google の RTB プロトコルの場合)または BidRequest.user.buyeruid
(Google の OpenRTB 実装の場合)で受け取ります。