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

Chrome 主導のテスト

サードパーティ Cookie のサポート終了に備え、Google は Chrome を活用したテストモードを提供しています。このモードを使用すると、サイトはサードパーティ Cookie を使用せずにサイトの動作と機能をプレビューできます。このガイドでは、Chrome が提供を予定しているテストモードの概要と、テストグループのラベルにアクセスする方法について説明します。

ここでの Chrome ブラウザは、Chrome クライアント、つまりデバイスへの Chrome のインストールを指します。個々のユーザーのデータディレクトリは個別のクライアントを構成します。

テストグループ: 特定の機能が有効化、無効化、または設定される Chrome ブラウザのセット。Chrome を利用したテストのコンテキストにおいて、ラベルが設定されているブラウザのセット。

ラベル: この場合、テストグループに属するブラウザ用に設定するリクエストヘッダーの値。テストグループ内の各ブラウザは、Chrome を利用したテストの期間中、そのグループに属します。これにより、テスター間でブラウザのラベルの一貫性が保たれます。

次の 2 つのモードが用意されています。

モード A: 2023 年 11 月より、PS R&M API をテストする組織は、Chrome ブラウザのサブセットで一貫したラベルを受け取るようオプトインし、異なるテスター間で連携してテストできるようになりました。
モード B: 2024 年 1 月 4 日より、Chrome では一部の Chrome ブラウザに対してサードパーティ Cookie がグローバルに無効化されました。

モード B でサードパーティ Cookie が無効になっている場合、サードパーティ Cookie のサポートが段階的に廃止されるまで無効のままとなります。

Google は CMA と協力して、これらのテストモードが業界テストのガイダンスに記載されているサードパーティ向けのテストフレームワーク（およびタイムライン）と一致するようにしています。そのため CMA は、これらのモードでのテスト結果をプライバシーサンドボックスの評価に使用できると想定しています。CMA は、モード B ラベルとモード A コントロール 1 ラベルを使用するテスト設計 2 の結果に重点を置く可能性が高いことを示しています。試験運用版設計 2 について詳しくは、CMA の 10 月 26 日のガイダンスをご覧ください。

ラベルにアクセスするには、HTTP ヘッダーまたは JavaScript API から入手できる一時的な Cookie-Deprecation 値を使用します。実装の詳細については、後述の Cookie-Deprecation 値を使用してラベルにアクセスするをご覧ください。

この提案は、通常の Blink 開発プロセスを通じて送信され、そこで技術設計と Chrome リリースマイルストーンが確定されます。これは Google がリリースする実装ですが、さらなる議論と承認が必要になるため、これらの詳細はまだ変更される可能性があります。計画の進展に応じてこのページを更新していきますので、引き続きフィードバックやご質問をお寄せください。

モード A: ラベル付きブラウザグループ

テストに参加する組織は、Chrome ブラウザのサブセットに対して永続的なラベルセットを受け取ることをオプトインできます。これにより、同じブラウザセットで複数の広告テクノロジー間で調整されたテストが可能になります。たとえば、次の表に示すように、ブラウザが label_only_3 テストグループに属する場合、参加しているすべての広告テクノロジーは同じ label_only_3 ラベルを参照し、それに応じて調整できます。つまり、PS R&M API を使用しますが、サードパーティ Cookie は使用しないようにします。ページの参加者は、広告の選択と測定のプロセス全体で一貫したテストを行えるように、ラベルが他の参加者に転送されるようにしてください。

たとえば、複数の参加者が一貫したブラウザグループ間で、サードパーティ Cookie を使用せずに Protected Audience オークションを実施できます。オークション販売者の参加者は、確認されたラベルを購入者に転送し、調整されたテストを促進します。

ラベルは、サードパーティ Cookie の可用性など、Chrome のインスタンスの動作には影響しません。ラベルによって、独立して調整されたテストをグループ化できます。ただし、テストに関連するパラメータを適用するかどうかは各当事者に委ねられます。サードパーティ Cookie 削除の効果をテストする場合、各参加者は、そのラベルの付いたブラウザのサードパーティ Cookie データを除外する責任を負います。

通常の Chrome トラフィックを表すグループを作成することが目的です。つまり、サードパーティ Cookie と PS R&M API の両方を利用できる必要がありますが、一部のユーザーは設定や拡張機能を使用して機能を変更または無効にしている場合があります。

ラベルは通常、Chrome のブラウジングセッション中およびセッション間で維持されます。ただし、ブラウザを完全にリセットしても現在のラベルもリセットされることはまれであるため、保証はされません。

Chrome Stable ブラウザの 8.5% をモード A の対象に含めることを計画しており、最初の提案では、この集団を 9 つのグループに分けます。小さなサブグループは、広告テクノロジーがラベルを組み合わせてさまざまなサイズの独自のテストを柔軟に作成できるようにすることを目的としています。グループが重複することはありません。

control_1.* ラベルは、CMA の業界テストのガイダンスに記載されている「コントロール 1」として使用することを意図しているため、テスト参加者は、このトラフィックに対して Topics API を使用したり、Protected Audience オークションを実施したりしないでください。ラベルはブラウザの動作に影響しないため、control_1.* グループラベルを検出したときに、参加者は確認されたトピックを渡したり、Protected Audience のオークションを実施したりしないでください。

このグループの選定が参加組織のニーズを満たすかどうかについて、フィードバックをお寄せください。

ラベル	安定トラフィックの割合
`control_1.1`	0.25
`control_1.2`	0.25
`control_1.3`	0.25
`control_1.4`	0.25
`label_only_1`	1.5
`label_only_2`	1.5
`label_only_3`	1.5
`label_only_4`	1.5
`label_only_5`	1.5

モード A label_only_ のブラウザグループは 2023 年 11 月から、モード A の control_1_* グループは 2024 年 1 月 4 日から利用可能になりました。

モード B: サードパーティ Cookie の 1% を無効にする

2024 年 1 月 4 日より、Chrome Stable ブラウザの約 1% でサードパーティ Cookie が無効になりました（2023 年第 4 四半期は Dev、Canary、Beta の各ブラウザでも）。PS R&M API をテストする組織では、このモードはブラウザユーザー全体に均一に適用されるため、オプトインする必要はありません。当然ながら、サイトで CHIPS や関連ウェブサイトセットなどの代替ソリューションがまだ導入されていない場合は、サイトの一部の機能が影響を受ける可能性があります。

さらに、PS R&M API が無効になっているモード B 内のトラフィックのごく一部を提供する予定です。他の API（関連ウェブサイトセット、CHIPS、FedCM など）は無効になりません。この組み合わせは、サードパーティ Cookie がなく、PS R&M API も使用していないブラウザで、パフォーマンスのベースラインを確立するのに役立ちます。

モード B では、影響を受けるブラウザ用のラベルも提供しています。ラベルは、API が無効になっているときに使用できます。サードパーティ Cookie が無効になっている 3 つの treatment_1.* グループと、PS R&M API が使用できる 3 つの treatment_1.* グループと、サードパーティ Cookie と PS R&M API の両方が無効になっている 1 つの control_2 グループに人口を分割することを提案します。

Attribution Reporting API と Private Aggregation API の統合のデバッグを支援し、テスト参加者がノイズの影響を十分に理解できるように、ユーザーがサードパーティ Cookie を明示的にブロックしていない限り、モード B のブラウザでは引き続き ARA デバッグレポートとプライベート集計デバッグレポートを利用できます。そのスライスでは PS R&M API を使用できないため、control_2 ではデバッグレポートを使用できません。デバッグレポートは、サードパーティ Cookie の段階的廃止に伴い段階的に廃止されます。

Attribution Reporting API の場合、サードパーティ Cookie が無効になっているため、レポート送信元は ar_debug Cookie を設定できません。デバッグレポートの受信をオプトインまたはオプトアウトするには、debug_key フィールド（アトリビューション成功レポートの場合）と debug_reporting フィールド（詳細レポートの場合）を設定する必要があります。
Private Aggregation API の場合、レポート送信元は enableDebugMode() の呼び出しに依存して、デバッグレポートの受信のオプトインを制御する必要があります。企業は引き続き、デバッグレポートを含め、Attribution Reporting API と Private Aggregation API の使用に対して規制上の義務がどのように適用されるかを検討する必要があります。

モード A は引き続き実行され、これらのグループはモード A のグループとは区別されます。ユーザーがモード A かモード B になるか、どちらにもいられないためです。テストの参加者は、サードパーティ Cookie で現状を表すコントロールグループとして control_1.* トラフィックを使用する必要があります。

ラベル	安定トラフィックの割合
`treatment_1.1`	0.25
`treatment_1.2`	0.25
`treatment_1.3`	0.25
`control_2`	0.25

また、Chrome Canary、Dev、Beta のクライアントの 20% で Cookie の使用が制限されています。

ラベル	安定化前のトラフィックに占める割合
`prestable_treatment_1`	10%
`prestable_control_2`	10%

これらのテスト群のいずれかにテスト群を追加すると、安定版の同等のテスト群と同じ効果が得られます。

モード A と同様に、PS R&M API は、ユーザーが Chrome の [プライバシーとセキュリティ] の設定で無効にできるため、使用できるとは限りません。同様に、control_2 グループの全メンバーに対してサードパーティ Cookie が無効になるとは限りません。ユーザーがブラウザの UI にアクセスしてサイトのサードパーティ Cookie を許可する可能性があるためです。

テストのモニタリング

各トリートメントラベルとコントロールラベルの相対的なトラフィック量をモニタリングしてください。treatment_1.1 のトラフィックは、treatment_1.2 および treatment_1.3 とほぼ同じ量になります。

バージョン 120 より前の Chrome からのトラフィックについては、慎重に検討することをおすすめします。通常、無効なトラフィックを処理するチームが、無効なトラフィックの特性を示すユーザーエージェントを特定した場合は、テスト結果から除外したほうがよいでしょう。

期間前のラベル

2024 年 1 月までは、複数のテスト群で事前期間を実施しました。これは、Chrome で統計的に偏りのないグループのサイズを正確に設定し、選択するための期間です。この事前期間は、1 月に開始が予定されているすべてのテスト群（モード B 群と Control_1.* 群）で実施しました。この場合、デベロッパーやサイトの操作は必要ありません。これらの事前期間アームで動作や API の可用性が変わることはありませんが、状況によっては preperiod ラベルが返されることがあります。preperiod ラベルが割り当てられたブラウザはテストグループのいずれかに移行される可能性がありますが、必ずテストグループに移行できるとは限りません。そのため、このラベルの付いたブラウザがテスト対象であるとは限りません。

テスト群とは、調査対象の集団（この場合はラベル付きグループ）の一部です。

Cookie のサポート終了（Cookie-Deprecation）の値を使用してラベルにアクセスする

モード A とモード B の期間中、オプトインの HTTP ヘッダーと JavaScript API を使用してアクセスできる一時的な Cookie-Deprecation 値が導入されました。これにより、ブラウザに適用可能なモード A またはモード B のテストグループ（上記の割合で定義）のいずれかに分類されるラベルが提供されます。

ラベルへのアクセスには、ユーザーのデバイスに保存されている情報へのアクセスも含まれます。一部の地域（EU や英国など）では、この行為が Cookie の使用に類似しているため、ラベルへのアクセスにはエンドユーザーの同意が必要になる可能性が高いと Google は理解しています。ラベルのリクエストを開始する前に、この同意義務が適用されるかどうかについて法律上の助言を受けることをおすすめします。

Sec-Cookie-Deprecation リクエストヘッダーを受信するには、サイトでまず receive-cookie-deprecation Cookie を設定する必要があります。この Cookie では Partitioned 属性を使用する必要があります。つまり、ヘッダーの受信は、トップレベルサイトごとにオプトインする必要があります。

たとえば、3p-example.site が example.com に埋め込まれたリソースで Sec-Cookie-Deprecation ヘッダーを受け取る場合、3p-example.site はそのコンテキストに次の Cookie を設定する必要があります。

Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned;  Max-Age=15552000

Cookie 属性 Secure、HttpOnly、SameSite、Partitioned は必須です。他の属性（Domain、Path、Expires、Max-Age）はニーズに応じて設定できますが、Path=/ がデフォルトです。この例では、Cookie が 180 日間経過するまで有効期限が切れないように Max-Age=15552000 を設定しています。

receive-cookie-deprecation=1 Cookie の設定は、Chrome によるテスト期間が始まる前に設定することをおすすめします。これにより、テストグループ内のブラウザに、利用可能になり次第 Sec-Cookie-Deprecation リクエストヘッダーが含まれるようになります。

たとえば、ブラウザが example_label_1 グループに属しているとすると、この Cookie を含む後続のリクエストには、Sec-Cookie-Deprecation ヘッダーも含まれます。

Sec-Cookie-Deprecation: example_label_1

ブラウザがグループに属していない場合、ヘッダーは送信されません。ラベルは Cookie の存在と関連付けられるため、特定のサイトに対して Cookie が削除、完全にブロック、またはブロックされた場合は、ラベルは送信されません。Partitioned 属性は、サードパーティ Cookie が完全に廃止された後も引き続き使用することを想定しているため、サードパーティ Cookie がブロックされている場合は Partitioned Cookie が設定される可能性があります。

cookieDeprecationLabel JavaScript API にアクセスする

Cookie-Deprecation 値には、navigator.cookieDeprecationLabel.getValue() JavaScript API を使用してアクセスすることもできます。これにより、該当するグループラベルを含む文字列に解決される Promise が返されます。たとえば、ブラウザが example_label_1 グループに属している場合、次のようになります。

// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
 // Request value and resolve promise
 navigator.cookieDeprecationLabel.getValue().then((label) => {
   console.log(label);
   // Expected output: "example_label_1"
 });
}

ブラウザがグループに属していない場合、API を使用できないか、値が空の文字列になるため、機能の検出を必ず行ってください。

JavaScript API は、receive-cookie-deprecation Cookie の有無にかかわらず呼び出すことができます。ただし、サイトに対して Cookie が完全にブロックされている場合、または特定のサイトに対してブロックされている場合、API は利用できなくなるか、空の文字列を返します。

クライアントが提供する値と同様に、ヘッダーまたは JavaScript API の値は、使用前にサニタイズして検証します。

デモとテスト

Chrome 120 以降では、ラベルのリクエストと読み取りのローカルデベロッパーテストを有効にするフラグが用意されています。

chrome://flags/#tpc-phase-out-facilitated-testing フラグを使用すると、テストラベルの選択を有効にできます。実際のラベルと区別するため、これらのラベルには接頭辞 fake_ が付いています。このフラグを有効にしても、ブラウザはどのテストグループにもオプトインされません。

ラベルの動作は goo.gle/cft-demo で確認できます。

プライバシーサンドボックスの関連性と測定の API には登録が適用されているため、chrome://flags/#privacy-sandbox-enrollment-overrides を使用してデモオリジンを指定することで、ローカルテストの適用をオーバーライドしなければならない場合があります。また、ターミナルから Chrome を実行している場合は、--args --disable-features=EnforcePrivacySandboxAttestations というコマンドラインフラグを含めます。

chrome://flags/#tpc-phase-out-facilitated-testing — Chrome を利用したテストフラグの設定

フラグのプルダウンには複数のオプションがあります。テスターの主な関心事は [Force] とマークされたエントリです。これにより、他のデバイス設定に関係なくテストの動作が有効になります。

テストグループのラベルのみをテストするには、[Force Control 1 を有効にする] または [Enabled Force LabelOnly] を選択します。これにより、ブラウザは「fake_control_1.1」または「fake_label_only_1.1」のラベルを送信します。

Chrome M120 以降では、次のエントリも使用できます。

サードパーティ Cookie のブロックをテストするには、[有効な強制処理] を選択します。これにより、「fake_handle_1.1」テストグループラベルが送信されますが、サードパーティ Cookie をブロックするように Cookie 設定ページと現在の Cookie 設定も変更されます。

非公開広告 API を使用せずにサードパーティ Cookie のブロックをテストするには、[Force Control 2] を選択します。これにより、「fake_control_2」テストグループラベルが送信され、Cookie の設定ページが更新され、サードパーティの Cookie がブロックされ、新しい限定公開広告 API が抑制されます。

ただし、フラグを無効にしても、ブラウザに新しい Cookie の設定ページが残り、サードパーティ Cookie をブロックする設定が残るという問題があります。Google はこの問題の解決に取り組んでいますが、当面は、--user-data-dir=<new dir> コマンドラインフラグを使用して Chrome を起動することで、別の Chrome データディレクトリでこれらのフラグの値をテストできます。

フィードバック

質問を管理するには、GitHub のデベロッパーサポートリポジトリにある「chrome-testing」ラベルを使用します。最初の質問に対するフィードバックやディスカッションをぜひお寄せください。

また、「Chrome がサポートするテスト」テンプレートを使用して、リポジトリに新しい質問やディスカッションを行うこともできます。