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

Chrome 主導のテスト

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

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

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

ラベル: このコンテキストでは、テストグループに属するブラウザに対して設定されるリクエストヘッダーの値。テストグループ内の各ブラウザは、Chrome によるテスト期間中はグループに残ります。これにより、ブラウザのラベルはテスター間で統一されます。

次の 2 種類のモードをご用意しています。

モード A: 2023 年 11 月より、PS R&M API をテストしている組織は、一部の Chrome ブラウザで一貫したラベルを受け取ることをオプトインし、さまざまなテスター間で調整されたテストを実施できるようになりました。
モード B: 2024 年 1 月 4 日より、Chrome ブラウザの一部でサードパーティ Cookie が全世界で無効になりました。

どちらのモードも、少なくとも 2024 年第 2 四半期までは継続されます。モード B でサードパーティ Cookie を無効にした場合、サードパーティ Cookie は廃止されるまで無効のままになります。

Google は CMA と協力して、これらのテストモードを、業界テストに関するガイダンスで規定されているサードパーティのテストフレームワーク（およびタイムライン）に合わせました。そのため、CMA は、これらのモードでのテスト結果をプライバシーサンドボックスの評価に使用できると見ています。CMA は、モード B のラベルとモード A のコントロール 1 のラベルを使用する試験運用版 2 の結果を重視する傾向を示しています。試験運用版 2 について詳しくは、CMA の 10 月 26 日ガイダンスをご覧ください。

また、この提案は通常の 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 の閲覧セッション中、およびセッションをまたいで保持されます。ただし、まれなケースですが、ブラウザを完全にリセットしても現在のラベルがリセットされることはまれであるため、必ずそうなるとは限りません。

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

control_1.* ラベルは、業界テストに関する CMA のガイダンスにあるように「コントロール 1」として使用することを想定しているため、テストの参加者は、このトラフィックに対して Topics API を使用したり、Protected Audiences オークションを実施したりしないでください。ラベルは機能に影響しないため、参加者は、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 日から利用可能です。2025 年初頭にサードパーティ Cookie が段階的に廃止されるまで、Google はモード A とモード B のすべてのラベルを引き続き送信します。

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

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

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

モード B の一環として、影響を受けるブラウザにラベルも提供されます。ラベルは、API を無効にすると同時に使用できるようになります。母集団を、サードパーティ Cookie が無効であるが PS R&M API は使用可能である treatment_1.* グループと、サードパーティ Cookie と PS R&M API の両方が無効になっている control_2 グループを 1 つに分けることを提案します。

Attribution Reporting API と Private Aggregation API の統合のデバッグを支援し、テスト参加者がノイズの影響をより深く理解できるように、ユーザーがサードパーティ Cookie を明示的にブロックしていない限り、モード B のブラウザで引き続き ARA デバッグレポートとプライベートアグリゲーションのデバッグレポートを利用できます。control_2 では PS R&M API を使用できないため、デバッグレポートは使用できません。デバッグレポートも、サードパーティ 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 が制限されています。

ラベル	Stable 以前のトラフィックの割合
`prestable_treatment_1`	10%
`prestable_control_2`	10%

これらのテスト群のいずれかに含めると、Stable の同等のテスト群と同じ効果があります。

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

テストのモニタリング

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

Chrome バージョン 120 より前のバージョンから送信されたラベルを含むトラフィックについては、慎重に判断することをおすすめします。無効なトラフィックを主に処理するチームが、無効なトラフィックの特性を示すユーザーエージェントを特定した場合は、これらのトラフィックをテスト結果から除外するのが合理的です。

事前期間のラベル

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

テスト群は、調査対象の母集団（この場合はラベル付きグループの 1）のサブセットです。

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 を設定しています。

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

たとえば、ブラウザが 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

フラグのプルダウンには複数のオプションがあります。「強制」とマークされたエントリは、他のデバイス設定に関係なくテストの動作が有効になるため、テスターにとって特に有用です。

テストグループのラベルのみをテストするには、[Enabled 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 設定も変更されます。

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

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

フィードバック

質問の管理には、GitHub のデベロッパーサポートリポジトリにある "chrome-testing" ラベルを使用します。最初の質問に対するフィードバックやディスカッションをお待ちしております。

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