フィードバック レポート - 2023 年第 4 四半期

2023 年第 4 四半期の四半期レポート。プライバシー サンドボックスの提案と Chrome の対応について受け取ったエコシステムからのフィードバックを要約しています。

CMA への取り組みの一環として、Google はプライバシー サンドボックスの提案の関係者エンゲージメント プロセスに関する四半期レポートを一般公開することに同意しました（コミットメントの第 12 項および第 17 項（c）（ii）を参照）。プライバシー サンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソースから Chrome に寄せられたフィードバックを集約して生成されます。たとえば、GitHub の問題、privacysandbox.com で入手できるフィードバック フォーム、業界関係者とのミーティング、ウェブ標準フォーラムなどです。Chrome ではエコシステムからのフィードバックを歓迎しており、学んだことをデザイン上の意思決定に取り入れる方法を積極的に検討しています。

フィードバック テーマは、API ごとの普及率によってランク付けされています。具体的には、特定のテーマについて Chrome チームが受け取ったフィードバックの量を集計し、量の多い順に並べ替えます。一般的なフィードバックのテーマは、公開ミーティング（W3C、PatCG、IETF）、直接フィードバック、GitHub、Google の社内チームや公開フォームを通じて表示されたよくある質問を確認することで特定されました。

具体的には、ウェブ標準団体会議の議事録が審査され、直接フィードバックについては、Google が行った 1 対 1 の関係者会議の記録、個々のエンジニアが受信したメール、API メーリング リスト、公開フィードバック フォームが考慮されました。Google は、これらのさまざまなアウトリーチ活動に関与したチーム間で調整を行い、各 API に関連して出現したテーマの相対的な普及率を判断しました。

フィードバックに対する Chrome の回答の説明は、公開されているよくある質問、関係者が提起した問題に対する実際の回答、特にこの公開報告のための立場の決定に基づいて作成されました。現在の開発とテストの焦点を踏まえ、特に Topics、Protected Audience、Attribution Reporting API に関する質問とフィードバックが寄せられました。

現在のレポート対象期間の終了後に受け取ったフィードバックには、Chrome の回答がまだ送信されていない可能性があります。

頭字語

チップ
Cookie に独立したパーティション状態がある場合
DSP
デマンドサイド プラットフォーム
FedCM
Federated Credential Management
FPS
ファーストパーティ セット
IAB
Interactive Advertising Bureau（IAB）
IDP
ID プロバイダ
IETF
インターネット技術特別調査委員会
IP
インターネット プロトコル アドレス
openRTB
リアルタイム ビッダー
OT
オリジン トライアル
PatCG
非公開の広告技術コミュニティ グループ
RP
証明書利用者
SSP
サプライサイド プラットフォーム
TEE
高信頼実行環境
UA
ユーザー エージェント文字列
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
意図的な IP ブラインドネス

全般的なフィードバック（特定の API やテクノロジーはなし）

フィードバックのテーマ まとめ Chrome レスポンス
3PCD のタイムライン 3PCD のタイムラインについて詳しく教えてください。 テストを容易にするため、Chrome では 2024 年 1 月 4 日より、ユーザーの 1% に対して 3 PC をデフォルトで制限しました。Chrome では、CMA に残された懸念に対処したうえで、2024 年第 3 四半期から 3PC のサポートを段階的に終了し、2024 年の残りの期間にかけて続行する予定です。
3PCD のタイムライン 2024 年第 4 四半期に 3PCD が導入される時期の影響。ホリデー シーズンと重なり、パブリッシャーに悪影響が及ぶ可能性がある。 3PC のサポートを終了する絶好のタイミングはありません。Google は 1 年以上にわたり、2024 年後半に 3PC のサポートを終了する予定であったことを明確にしてきました。停止期間の潜在的なタイミングなど、CMA に対する Google のコミットメントに変更はありません。第 4 四半期のタイミングに関する懸念は承知しておりますが、タイムラインを変更したことで業界への準備が整うことは少なくなり、それ以上の成果が得られません。
Chrome テスト（モード A/b） モード A とモード B のテスト設定はインスタンスごとですか、それとも Chrome プロファイルごとですか？ こちらのドキュメントに、この文脈における Chrome ブラウザとは Chrome クライアント（デバイスへの Chrome インストール）を指すことを明確に公開しています。個々のユーザー データ ディレクトリは、それぞれ個別のクライアントを構成します。
サポート終了トライアル 3PCD 試用版についての詳細をお知らせください。 3PCD の試用版について詳しくは、こちらをご覧ください。
サポート終了トライアル すべてのサイトで非推奨トライアル トークンを提供するのに十分な時間が 2024 年 1 月までにありません。 Google は、非推奨トライアルの登録が開始されてから、Chrome がサポートするテスト期間で Cookie の 1% がブロックされるようになるまでに一定の期間があることを Google は認識しています。こうした時間的制約に対応するため、Chrome では参加しているオリジンが非推奨トライアル トークンをデプロイする間、猶予期間を設けています。2024 年 4 月 1 日までの猶予期間中は、サポート終了トライアルに登録されたオリジンは、トークンをまだデプロイしていなくても Chrome で 3 台の PC にアクセスできます。この猶予期間の目的は、移行フェーズ中にウェブの互換性の問題を回避することです。参加しているオリジンは、猶予期間終了後も 3PC に引き続きアクセスするには、猶予期間の終了前に非推奨トライアル トークンをデプロイする必要があります。
Chrome テスト（モード A/b） モード B のサンプルが小さすぎるため、パフォーマンスの低下を正確に測定できません。 トラフィックの割合と、ウェブ全体でユーザーや機能に影響を与えるリスクとの間には、慎重なバランスをとる必要があります。
コントロールのテスト テスト中にパフォーマンスを把握し、CMA に伝えられるのは、相当な開発リソースを持つ非常に大規模なパブリッシャーのみです。 パブリッシャー サービス プロバイダはすでに広範なエコシステムで分析情報を公開しており、プライバシー サンドボックスのテストが増加するにつれて、これは今後も続くと予想されます。また、プライバシー サンドボックスの API を基盤とする広告テクノロジー企業は、引き続き、ラベルに基づくレポートなど、顧客が求める機能を開発し続けることが予想されます。
サードパーティのデータ サードパーティのデータ企業に対する懸念。 サードパーティ データ企業にはさまざまな種類があります。中には、さらに不透明なクロスサイト トラッキング手法に目を向ける組織もあります。また、プライバシー強化技術を活用し、顧客とともに新しい価値提案を行う企業もあります。Google は、ユーザーも規制当局もますます要求の厳しい方向に進んで後者を選び、方向性を定めることを願っています。変化は進化とイノベーションの機会を生み出します。
Google Ad Manager パブリッシャー様がプライバシー サンドボックスをテストする方法について、Google アド マネージャーでより詳しいガイダンスが必要です。レポートが不十分なため、パブリッシャー様が影響を把握できません。 Google アド マネージャーからのレスポンス:

Google アド マネージャーでは、Chrome で利用できるテストラベルを使用したテストの実施方法をヘルプセンターで説明しています。

アド マネージャーでは現在、Topics と Protected Audience の両方に関するレポートを提供しています。本フィードバック レポートの時点では、アド マネージャーでは Protected Audience API を介して配信されたインプレッションのレポートが可能で、Topics API のデータが特定のインプレッションに存在したかどうかが示されています。

Chrome で提供されるラベルに基づくレポートのセグメント化など、より高度なレポート作成機能が必要な場合は、Chrome から直接ラベルを読み取り（Chrome のドキュメントを参照）、アド マネージャーへの広告リクエストで Key-Value として渡し、ラベルに関するレポートを作成できます。Key-Value レポート
テスト特典 プライバシー サンドボックスのテストに十分な時間があることと、今後 API に重大な変更が生じる可能性を懸念している。 もっと時間をかけたいという方もいらっしゃると思いますが、タイムラインの変更はエコシステムの準備の低下につながるばかりでなく、むしろ減る可能性があるというご意見を業界から繰り返し寄せられています。3PC のサポート終了のタイムラインは、CMA が残した競争上の懸念事項に対処することを前提としますが、2024 年中の 3PCD の準備をすべての方におすすめします。

他のテクノロジーと同様に、プライバシー サンドボックス API は進化し続けています。この進化は、テクノロジーとエコシステムへの入力の進歩から生じています。Google は引き続き、変更を行う責任を負い、テクノロジーの変化が無期限に利用を妨げてはならないと考えます。
コネクテッド テレビ リニア動画または CTV 動画に対応する方法がない。 Google はコネクテッド テレビのユースケースをさらに模索していきたいと考えていますが、コネクテッド テレビ デバイス向けの API は Chrome における 3PCD の妨げになるとは考えていません。
広告主の広告サーバー Google は広告のターゲティングをディスプレイ&ビデオ 360 に移行しているようです。広告主の広告サーバーではどのようなサポートが提供されますか？ Chrome からのレスポンス:

PA API は、広告主の広告サーバーで iFrame / フェンス付きフレームとビーコン レポートを使用してユーザーに表示される広告を配信し、測定するためのものです。さらに、現在と同様に、アップストリームおよびダウンストリームの当事者と連携して、サービス提供フローに統合します。
Google 広告データ マネージャー 最近発表された「Google 広告データ マネージャー」は、カスタマー マッチと拡張コンバージョンを基盤として構築されたもので、広告主様が自社の顧客データを Google と共有して、3PC が実施するすべてのマーケティング機能を維持できるようにするものです。この新機能は、CMA に対する Google の取り組みとどのように合致していますか？ Google 広告からのレスポンス:

Google 広告データ マネージャーは、広告主様がカスタマー マッチ（CM）と拡張コンバージョン（EC）向けに広告主様のデータ ストレージ システム（クラウド システム）から自社データをアップロードして、技術リソースが少ない中小規模のビジネスでも簡単に利用できるようにするものです。Google 広告データ マネージャーは、Google が所有・運営するパブリッシャーまたは第三者のパブリッシャーを対象とした広告のアドレス指定性や測定可能性に関する、カスタマー マッチおよび拡張コンバージョン向けの新しい機能を一切提供しません。

Google の広告プラットフォームは、他の広告テクノロジー企業と同様に、プライバシー サンドボックス技術で利用できる機能にアクセスできます。
Chromeの設定 Cookie のサイズに関する詳細情報は、Chrome の内部設定ページでご確認いただけます。 要求された機能は、すでに Chrome デベロッパー ツールで利用可能です。この機能を優先すべき理由について、設定ページでフィードバックをお寄せください。
ヒューリスティック 3PCD で重要なユーザー エクスペリエンスを維持するために、Chrome はどのようなヒューリスティックを使用していますか？ GitHub でこちらの質問に対する回答をご覧ください。
ブラウザのバージョン Chrome ブラウザが安定版か非安定版かを区別する必要がありますか？ Chrome のメジャー バージョンと Stable リリース サイクルはおおむね一致します。
コンプライアンス Chrome では SOX 関連のレポートを提供できますか？ Chrome では SOX 関連のレポートは提供されません。プライバシー サンドボックス API は、ユーザーがアクセスするウェブサイトで Chrome で利用できる多くのウェブ API の一つです。他のウェブ API と同様に、API の呼び出し元は、プライバシー サンドボックス API の使用について Chrome と契約を締結しません。アクセスは、API の呼び出し元がなんらかの技術要件を満たしているか、ユーザーが適切な設定を有効にしているかによって異なります。その場合、保存するデータ、入札する入札、リクエストするレポートなど、API の使用方法を API 呼び出し元が単独で決定します。
コンプライアンス プライバシー サンドボックスのコンプライアンスに関するよくある質問を拡張し、より多くの質問に対処。 お寄せいただいたフィードバックをもとに、よくある質問にさらに改良を加えていきます。
Chrome に関する質問 Chrome の 3PC のサポート終了は、Android WebView（埋め込みブラウザ）での 3PC の提供状況に影響しますか？ 現在のところ、WebView は、3PCD または Privacy Sandbox API のロールアウトとテストのこの段階では、アプリとウェブのアトリビューション測定の有効化を除き、含まれていません。
API に関する質問 スポンサー商品のクリック数とインプレッション数をトラッキングする方法 このユースケースは Attribution Reporting API で対応できます。
タイムライン 3PCD のタイムラインが変更されたのはなぜですか？ 理由についてはこちらで説明しています。
Chrome 拡張機能の SSO 3PCD 以降、ウェブサイトと Chrome 拡張機能間のシングル サインオンのユースケースを許可する。 Google では現在、この問題について検討しています。他のユースケースに関するフィードバックをぜひお寄せください。
API の使用方法 Google は API をテストするパートナーのリストを確認できますか？ 一般公開されたテスターの詳細については、GitHub で以下の API をご確認ください。
- Topics API
- Protected Audience API
- Attribution Reporting API
- 共有ストレージ
- CHIP
UTIQ の取り組み Utiq イニシアチブに対する Chrome の見解を教えてください。 これについてはこちらで説明します。
Chrome に関する質問 3PC を使用せずにブラウジングしているユーザーを検出する方法 3PC のブロックを検出するための明示的な設定はありません。一般的な「機能検出」のアプローチでは、iframe / クロスサイト リクエストを作成し、必要なユースケースに同様の Cookie を設定することが、最も近いソリューションとなります。
Chrome に関する質問 シークレット モードでのブラウジングは、フラグテスト（--test-third-party-cookie-phaseout コマンドライン フラグを使用して Chrome を起動する）と同じものですか？ シークレット モードはフラグとは異なります。このフラグは 3PC をブロックするだけでなく、FedCM とサードパーティのストレージ パーティショニングも有効にします。
Chrome に関する質問 1% が発生した場合に、3PCD によって各地域/国にどのような影響が予想されるかを詳しく説明します。 この 1% の顧客は全世界でランダムに 1% に含まれますが、地域によって異なる場合があります。たとえば、デバイスと Chrome のバージョンの分布が異なる場合があります。
代替プライバシー強化技術 Chrome と Android でのデータの独占を防ぐために、代替のプライバシー保護強化技術を使用して、プライバシーに配慮したクロスドメイン トラッキングの実行を許可する必要があります。 デベロッパーの皆様には、Google が提供している構成要素やプライバシー サンドボックス以外の構成要素を基盤に、プライバシーを強化する技術サービスを構築できる機会が豊富にあります。
CookieGraph の調査 プライバシー サンドボックス フレームワーク内のこちらのホワイトペーパーで説明されている CookieGraph 手法に対する Chrome の見解を教えてください。 Google では現在、このホワイト ペーパーのレビューを行っています。ぜひフィードバックをお寄せください。

登録と認証

フィードバックのテーマ まとめ Chrome レスポンス
登録には制限があります Google は、プライバシー サンドボックス API に固有の利用規約を導入しました。利用規約により、同意を得た訪問者の認識をパブリッシャーの支援に専門とする企業が、プライバシー サンドボックス機能を自社の ID ソリューション内でテストまたは統合することを効果的に防止できるようになります。利用規約によって、プライバシー サンドボックス内での業務の能力が不当に制限されている。 登録と構成証明のプロセスでは、API 利用規約への同意は必要ありません。一方、登録と証明書は、どのデベロッパーがプライバシー サンドボックス API を呼び出すか、またアクセスするデータをどのように使用するかに関する透明性を向上させるためのメカニズムです。具体的には、この証明は、証明するデベロッパーが API を使用してサイトやアプリをまたいでユーザーを識別せず、API のプライバシー保護も回避しないことを示す公式声明です。この構成証明では、デベロッパーによる他のデータやテクノロジーの使用について言及する必要はありません。
プライバシー サンドボックスの登録 認証用の連絡先 / メールアドレスを更新する方法 登録情報は、登録フォームを使用して更新できます。詳しくは、こちらをご覧ください。
プライバシー サンドボックスの登録 証明書が利用できない場合のアクセスのカットオフのシナリオを教えてください。 プライバシー サンドボックスでは、技術担当者が登録されているサイトの証明書ファイルを 3 週間再確立してから、登録済みの企業による（Measurement API と Relevant API）へのアクセスを拒否します。
プライバシー サンドボックスの登録 非本番環境のエンドポイントを使用して、ローカル環境で API をテストするにはどうすればよいか？ この質問にはこちらで回答しています。

関連性の高いコンテンツと広告を表示

トピック

フィードバックのテーマ まとめ Chrome レスポンス
さまざまなタイプのステークホルダーにとっての有用性 パブリッシャーは、トピックがデータドリブンな販売に及ぼす影響について懸念を抱いています。大規模なサイトには一般的な「ニュース」トピックが割り当てられ、特定のニュース メディアに関連付けられるデータはありません。専門的なパブリッシャーは、限定的な情報を求める代わりにデータを提供する。 Google では、一般的なインタレスト カテゴリを含むサイトでは、ニッチなインタレスト カテゴリを含むサイトよりも掲載されるトピックの詳細度が低くなる傾向があります。しかし、すべてのニッチなサイトが商業的に価値のあるトピックを提供しているわけではありません。また、この動向は、3PC ベースの広告関連性システムでは、他のサイトよりも多くの価値を提供するという現状を反映しています。Topics（およびプライバシー サンドボックス全体）により、パブリッシャー様は、提携するアドテック企業によるお客様の情報の使用方法をより詳細に管理できます。さらに、Topics から得られる情報は、既存のシグナルよりもはるかに粗いです。
パブリッシャー広告サーバー 専用の広告サーバーを使用しているパブリッシャー広告サーバーは、Topics API を直接モニタリングできない可能性があります。 この問題についてこちらでご説明しておりますので、追加のフィードバックをお待ちしています。
宣誓 構成証明の要件を拡張して、コンテキストをまたいだ情報の転送による既知の望ましくない結果に対処 現時点では、構成証明は、この広範なカテゴリのリスクに対応することではなく、API の不正使用に対処することを目的としています。
Topics のトラフィック量 現在のインプレッション数ではテストに不十分です。 Chrome では、プログラマティック エコシステムで利用できる Topics の量に関するフィードバックを受け付けています。現在、ブラウザ内および関連するテスターを対象に、考えられる原因を調査しています。Chrome では、必要に応じて API 設計にどのような変更が可能かを評価し、ユーザーのプライバシーを保護しながらカバレッジ率を高め、十分な規模でテストできるようにします。
API の使用方法 Topics API のレート制限はありますか？ 不正行為を防止し、ウェブ上でのユーザー エクスペリエンスを保護するため、Topics のレート制限が設けられています。詳しくは こちらをご覧ください。
V2 の分類 オープン RTB プロトコルにトピックの詳細を含めることに関する IAB のガイドライン はい。Open RTB プロトコルへのトピックの追加に関する IAB のガイドラインは こちらでご確認いただけます。
自社シグナルへの影響 詳細なトピック分類 v2 と、このきめ細かいセグメンテーション（上位のトピック）の最も高い価値を返すプロセスを組み合わせると、広告用データ市場に混乱をもたらすことになります。 Google の対応は第 3 四半期から変わりません。

「Topics を細かく分類すると、他のソリューション（パブリッシャーの自社データに基づくソリューションや、直接取引に依存するソリューションなど）の魅力が間接的に低下する可能性があります。Topics API の開発にあたり、Google の主な目的は、3PCD 後のインタレスト ベース広告のユースケースをすべての関係者に対して可能な限り効果的にサポートできるようにすることです。Topics の有用性を高めることで、全体的な競争環境が改善し、エコシステム全体に利益があると確信しています。」
テスターのリスト パブリッシャーへの Topics と PA API の導入状況 このような情報を共有することはできません。パブリッシャーはテスト ステータスの共有を有効にできるテスター リストを参照できます。
トピックの選択 関心のあるトピックをユーザーが積極的に選択できるようにしますか？ Google では、ユーザーが事前にトピックを追加できるようにすることを検討してきました。短期的には対処する予定はありませんが、長期的に調査することを検討しています。
トピックの選択 広告テクノロジーがサイトにトピックをモニタリングするコードがある場合、観察される可能性のあるトピックを知ることができますか？ 広告テクノロジー企業は、サイトに関連付けられたトピックを特定できます。レイテンシ コストが発生する可能性があるため、API はこの情報をリアルタイムで共有しません。
V2 の分類 Topics は最大 3 つのトピックを返すことができますが、Taxonomy v2 のロールアウトに伴いどのような動作が想定されますか？ API から引き続き最大 3 つのトピックが返され、各トピックに関連する分類バージョンのレスポンスがレスポンスに含まれます。
（前の四半期でも報告）

トピックのモニタリング		 パブリッシャー様は、ページ コンテンツ（head、body など）に基づいてトピックを分類する権限を Chrome に付与できます。 Google の対応は第 3 四半期と同様です。

「以前、ページ コンテンツに基づいてサイトをトピックに分類する機能の提供を検討しておりましたが、プライバシーとセキュリティ上の懸念を理由に、アップグレードしないことに決めました。この提案により、これらの懸念の一部が軽減される可能性はありますが、どの程度の懸念があるのかは不明です。CMA のテスト期間が予定されているため、この変更が 3PCD より前に行われることはないと想定されています。こちらからフィードバックをお寄せください。」
トピックの選択 ドメインは一般的なトピックであるため、どのように Topics に分類されますか？ ホスト名は、サイトを Topics で分類するためにのみ使用されます。これにより、幅広く分類されているサイトに悪影響が及ぶことはありません。これは、サイトのコンテキスト情報が常にオークションで利用でき、広範なトピックに対してより具体的な情報が提供されるためです。
V2 の分類 他の標準（IAB など）とトピックの整合性を高めたい。 IAB と Topics の分類のより緊密な整合を同社が望んでいた理由について、詳しく知りたいと思います。Topics API の導入にはどのような手順が必要ですか。分類の分類が個別化した場合、それらの手順にどのような影響がありますか。Google では、Topics の分類と IAB のコンテンツ分類のマッピングの公開を検討しています。それによって、パブリッシャーが直面する課題に対処できるかどうかを確認させていただきたく存じます。
データの保存と使用量 データの保存方法や転送先に関する詳しい情報はありますか？ トピック情報は、ユーザーのデバイスにローカルに生成され、保存されます。リクエストに応じて、API は最大 3 つのトピックを呼び出し元に返します。Google の見解では、呼び出し元は、Topics 情報を処理および保存する際に地域の規制を遵守する責任があります。さらに、すべての呼び出し元は、サイト間でユーザーを再識別するために Topics を使用していないことを証明する必要があります。詳しくは、プライバシー関連のコンプライアンスに関するよくある質問をご覧ください。
V2 の分類 v1 から v2 に移行する際の Topics の分類のアップグレードとブラウザの状態の影響。 以前の分類から推測されたトピックは引き続き利用可能で、期限が切れるまで（4 週間前）まで広告テクノロジーが取得できます。
API の説明 Topics API のユーザー エクスペリエンスが誤解を招く。 こちらのフィードバックは UX チームと共有済みです。
API に関する質問 Yahoo ドメインは一般的であることを考慮して、どのように Topics に分類されますか？ ホスト名は、サイトを Topics で分類するためにのみ使用されます。これによって、幅広く分類されているサイトは影響を受けないことを理解することが重要です。
Topics の利用可能率が低い Google アド マネージャーからテスターが受信する Topics の量が少ない。 Google アド マネージャーでは、一致率を高めるためにさまざまな最適化が加えられました。これにより、購入者のカバレッジが拡大するはずです。カバレッジを制限する可能性のあるいくつかの要因（ユーザー設定、呼び出し元によるモニタリング要件、場合によってはレイテンシ/タイムアウト）が予想されます。

Protected Audience API（旧 FLEDGE）

フィードバックのテーマ まとめ Chrome レスポンス
差別化 新しいオークションで SSP がどのように差別化を図るのかが不明確である。 Protected Audience やその他のプライバシー サンドボックス API を中心とした複数の戦略的計画があると聞きました。

全体像として、ユビキタスなクロスサイト識別子の削減は、エコシステムのセルサイドにとって、プライバシー面だけでなく商業面においてもポジティブなステップであると見なされています。大小さまざまな規模の企業がこの変化を受け入れ、ビジネス チャンスを見いだすことができます。
広告レンダリング 広告を表示するための唯一の手段である Chrome がイノベーションを妨げます。Protected Audience のレンダリングでは、ネイティブ広告に関する最新の基準の実現可能性は低くなります。 ブラウザでの広告のレンダリングには、常にブラウザ技術が使用されてきました。それは変わりませんおそらく、この懸念は、将来的に Protected Audience とともにフェンス付きフレームの使用を必要とする計画に固有のものです。これらの計画が「将来」になる理由の一つは、広告レンダリングに関して、フェンス付きフレーム技術でエコシステムの革新と差別化をサポートしたいからです。ご興味をお持ちのデベロッパーや企業の皆様は、ネイティブ広告のアプローチをどのようにサポートできるかなど、フェンス付きフレームの方向性について意見を出し合います。
入力 Concern Protected Audience API（PA API）は、多くの広告テクノロジーがプライバシー サンドボックス API を検討し始める頃には、ある程度の完成度が高まっていました。 API は、利用から学んだことや、Chrome の内部と外部の両方から得られた新しいアイデアに基づいて進化し続けます。現在一般提供されている関連性と測定に関する API は安定していますが、開発が停止しているわけではありません。追加のフィードバックをお待ちしています。
オークションのデザイン Protected Audience の設計では、すべてのオーディエンス構築と広告選択のロジックをバイサイド プラットフォームが管理できるようにします。そのため、SSP は、SSP のプラットフォームで実行されるキャンペーンに対して、オーディエンスの構築と広告選択のロジックを提供できなくなります。 Protected Audience は、誰がオーディエンスを作成するのか、誰がオーディエンスに入札するのかに依存しません。SSP では、入札に使用できるインタレスト グループ（IG）を作成できます。また、SSP が入札ロジックを提供する場合もあります。これは、多くの SSP が代理店に直接連絡する方向と整合しているようです。ユースケースを追加する余地は常にありますが、Protected Audience の基盤はオーディエンスの作成と有効化のためのさまざまなアプローチに対応できる十分な柔軟性を備えています。また、これらの財団のプライバシーという特性により、ユーザー単位の元データがサイト間で共有されないことも意味します。
オークションのデザイン Protected Audience のオークションは、広告主とパブリッシャーの間の仲介者の総数や特定の広告機会の重複を削減するエコシステムのサプライパス最適化（SPO）の取り組みに反しますか？ いいえ。Protected Audience で落札された広告は、最大 2 つの販売者エンティティ（SSP とパブリッシャーの広告サーバーなど）を通過します。購入者がパブリッシャーと直接統合している場合は、ごく少数です。

複数の仲介者を介して同じリクエストを複製するかどうかは、パブリッシャーが引き続き選択できます。Protected Audience がこれになんらかの影響を与えることはありません。

Protected Audience オークションは、クロスサイトのユーザーデータが漏洩しないように、現在のサーバー間リアルタイム システムの外部で行われます。広告リクエストが重複しているという報告もあります。技術的に実証可能なプライバシーを実現するには、いくらかのトレードオフが必要です。ただし長期的には、エコシステムで従来のサーバーサイド オークションを使わずに Protected Audience を使用する場合もあります。これを選択すると、サプライパスをさらに最適化できる可能性があります。
オークションのデザイン Protected Audience は、SSP がページで実施される「最後の」オークションはめったにないモデルに移行しますが、API の設計上、強制的にこのモデルに移行されます。 同意できない。これまで見てきたアーリー アドプターの実装では、コンポーネント オークションに参加している SSP が、Protected Audience オークションが実行される前に発生するコンテキスト オークションの結果よりも優先されるようにしています。Protected Audience の SSP コンポーネント オークション出力は、完全なコンテキスト オークションの実行後、最後になると見なされます。
オークションのデザイン コンテキスト オークションは、オークションの機会に関するデータシグナルを提供して Protected Audience オークションに通知する場合にのみ関連している可能性があります。 取引、非自社オーディエンス ターゲティング キャンペーン、大量のコンテキスト シナリオなど、さまざまな理由からコンテキスト オークションが引き続き重要になると考えられます。また、IG がない場合や、Protected Audience の入札単価が最小価格に届かない場合や、広告品質のルールを守っていない場合にも効果を発揮します。
トラフィック パターン DSP が固定 QPS で動作している。Protected Audience オークションにふさわしいオークションを行うことで、従来のインフラストラクチャの有用性が低減する。 秒間クエリ数に関して変わっているのは、多くの SSP が、DSP にリクエストを送信するかどうかを判断する機能としてクロスサイト ID を使用していることです。これは、パブリッシャーが Protected Audience オークションの実施を希望するかどうかに関係なく該当します。

Google は多くの SSP と共同でトラフィック パターンを調査し、キャッシュ保存やコンテキスト ベースのフィルタリングなどのソリューションを見つけました。今後、開発者はプライベート アグリゲーションを利用して、DSP 入札の設定の理解をさらに深め、それに応じてフィルタできるようになる見込みです。

最終的に、クロスサイト識別子を中心に構築された従来のインフラストラクチャの一部は、使用できなくなります。
利用可能なシグナル オークション発生時に利用できるあらゆるシグナルが明確でなく、コンテキストに基づくオークションでどのように順序付けを行うことがデメリットになるかが不明確である。 一般的に、入札者に対しては、IG の作成時にコンテキスト オークションやリアルタイムの Key-Value ルックアップから情報を提供できます。スコアラーの場合、オークションの設定時に情報を提供できます。これには、ページやコンテキスト オークションに関するコンテキスト情報や、広告 renderUrls のリアルタイムの Key-Value ルックアップからの情報も含まれます。
（前の四半期に報告）

動画レンダリング		 Protected Audience と Fenced Frames を使用した動画レンダリングのサポート。 対応は前の四半期と変わりません。

「Protected Audience API は、iframe を使用するメカニズムを使用した動画のレンダリングをサポートしています。ただし、フェンス付きフレームと互換性のあるソリューションはまだ設計されていません。これが、フェンス付きフレームの適用を 2026 年まで延期することを決定した理由の一つです。つまり、パートナーが今すぐフェンス付きフレームを適用することを決定した場合、そのパートナーは動画に対応しません。」
動画レンダリング iframe 形式の動画に対する PA API のサポートは HTML5 動画に限定されており、広く使用されている VAST 標準には対応していません。 現在 Protected Audience で利用できる iframe レンダリング メカニズムを使用して、VAST ベースの広告を実装できます。これを実現するには、購入者、販売者、パブリッシャーの広告プラットフォームに新しいエンジニアリングが必要であることは認識しており、これまで VAST が機能していた方法からの移行を容易にするために引き続き取り組んでまいります。
（前の四半期にレポートされます）

トップレベル オークション		 トップレベルの PA API オークションを Google アド マネージャーに管理させることなく、Google のパブリッシャー広告サーバーを使用できます。 Google の対応は、これまでの四半期と変わりません。

「Google アド マネージャーから提供される回答:
Protected Audience API に関する Google アド マネージャーの計画では、次の理由から、トップレベルの Protected Audience オークションを管理せずに Google のパブリッシャー広告サーバーはサポートしていません。

パブリッシャー広告配信市場のお客様に適切にサービスを提供するには、Google のパブリッシャー広告サーバーがトップレベルの Protected Audience オークションを管理する必要があります。私たちの役割は、パブリッシャー広告サーバーとして、オーバーブッキングなしで直接販売キャンペーンの交渉を行い、直接予約の最適なペースと配信を実現できるよう、パブリッシャー様に予測機能を提供することです。そのためには、最終的なオークションを実施して、対象となるすべての直接的および間接的な需要を比較する必要があります。

予測とペースは、パブリッシャーが広告サーバーに期待するコア機能です。正確な予測を行わなければ、広告枠を過剰に売り込み、ビジネスの評判を損なう可能性があります。また、広告主との純広告契約を履行できないと、パブリッシャーと広告主の直接関係が損なわれ、パブリッシャーのビジネスに大きな影響を与える可能性があるため、ペース調整も重要です。

つまり、トップレベルの Protected Audience オークションを実行するパブリッシャー広告サーバーのアクティビティが、パブリッシャー広告サーバーの他のアクティビティと区別されることはありません。」
（前の四半期に報告）

directFrom
SellerSignals		 directFromSellerSignals
は、Google アド マネージャーがコンテキスト オークションの価格をパブリッシャーに開示しないようにするための仕組みです。		 Google の対応は前の四半期から変更されていません。

「Chrome のレスポンス:
runAdAuction() に渡される情報は、販売者が独自の iframe から runAdAuction() を呼び出しない限り、販売者からの情報はありません。複数販売者オークションでは、すべての販売者が runAdAuction() を呼び出すフレームを作成できなくなります。directFromSellerSignals では、販売者のオリジンから読み込まれたサブリソース バンドルからコンテンツを読み込むことで、この問題に対処しています。これにより、販売者のオークションの設定からオークションに渡される情報の真正性と完全性を操作できなくなります。技術プロバイダが Protected Audience API のオークションに渡している情報を把握するために Protected Audience API を使用したい場合は、技術プロバイダにこの機能を依頼できます。

Google アド マネージャーからのレスポンス:
Google は、オークションの公平性に長年注力してきました。これには、非保証型広告申込情報の価格など、パブリッシャーの非保証型広告ソースからの価格（非保証型広告申込情報の価格を含む）が、オークションで入札する前に他の購入者と共有されることは一切ありません。このことは、フランス競争当局とのコミットメントで再確認されました。

Protected Audience のオークションでは、directFromSellerSignals を利用して約束を守り、複数販売者オークションの完了前にオークション参加者の入札単価を他のオークション参加者と共有しないことを目指しています。今回の更新で説明しているように、コンテキスト オークションの価格を、Google のコンポーネント オークションと共有することはありません。」
（前の四半期に報告）

k-匿名性の値		 「K」から「k-匿名」の値はどのように決定され、いつ公開されますか？ Google は 2023 年 12 月にK-匿名性の値を公開しました。3PCD プロセスが開始した後、k-匿名性のしきい値を最終的な値 50（k=50）に引き上げ、更新期間を 1 時間（p=1）に設定する。k-匿名性の値 50 が、実用性とプライバシーの最適なバランスを提供していると評価されました。この値は、基本的な bot 攻撃を阻止し、差分プライバシーを維持するのに十分であると同時に、API が目的のユースケースで引き続き有用であるほど十分に低い値でもあります。
（前の四半期に報告）

forDebuggingOnly		 3PCD 後も引き続き使用する場合、forDebuggingOnly.reportAdAuctionWin が悪用される可能性があります。 こちらで、デバッグのユースケースを長期にわたってサポートし続ける方法の提案をお伝えしています。この提案について、ぜひフィードバックをお寄せください。
（前の四半期に報告）

同一オリジン ポリシー		 サブドメインを許可するために同一オリジン ポリシーを緩和するリクエスト。 このリクエストは検討中で、こちらでご説明いたしました。
（前の四半期に報告）

広告コンポーネントのサイズ		 広告コンポーネントの数を 20 から 40 に増やします。 このリクエストについては、 10 月 4 日の WICG 通話とこちらの GitHub の問題で検討しており、2024 年第 1 四半期末までに対応する予定です。
（前の四半期に報告）

Key-Value サーバーキーの有効期限		 対応する IG の有効期限が切れた後のサーバーキーの削除について検討しました。 複雑さを軽減するために、TTL の管理は TEE の外部で行うことをおすすめしますが、こちらから追加のフィードバックをお待ちしています。
InterestGroup のトリガー 1 つの IG が 1 つの（コンポーネントの）オークション内で複数の generateBid をトリガーすることはできますか？ ブラウザが IG の generateBid() 関数を呼び出すたびに、その IG は入札単価の値を返すことができます。たとえば、複数販売者オークションでは、コンポーネント オークションのいずれかで、IG が毎回複数回呼び出されることがあります。

この動作を有効化またはサポートするために、IG の所有者が明示的に行う操作は特にありません。
コンプライアンスに関する質問 ユーザーの Chrome ブラウザを通して収集される同意の範囲は？ 詳しくは、プライバシー関連のコンプライアンスに関するよくある質問の「プライバシー サンドボックスは Chrome のプライバシー関連のコンプライアンスにどのように取り組んでいますか」をご覧ください。
マルチタグ オークション マルチタグ オークションに対応する方法 Google ではこのリクエストを評価しています。ぜひこちらからフィードバックをお寄せください。
IP 保護の可用性 発表日までに IP 保護の準備が整っていない場合、フェンス フレームの適用やイベントレベル レポートの削除または削除など、Protected Audience 機能のタイムラインにどのような影響がありますか？ こちらでご案内しているとおり、Protected Audience のタイムラインは他のプライバシー保護機能のリリース タイムラインと関連づけるべきであると考えています。
modelingSignals ディスプレイとクリックの情報のみをエンコードできる modelingSignals に加えて、新しいフィールドをリクエストします。 Google では、この機能によって得られるメリットを理解しており、リクエストを検討しています。ぜひこちらからフィードバックをお寄せください。
否定的な IG 通常の IG で負の IG 名を指定することは可能ですか？ 現時点では、説明ではできませんが、これが要件である理由に関するエコシステムからのフィードバックをお待ちしています。
API の使用方法 generateBid() レベルで集計レポートを生成する プライベート集計は、generateBid 内で呼び出すことができます。
マクロ iframe のマクロを介して perBuyerSignals からのシグナルを第三者にルーティングします。 このユースケースについてはこちらで説明していますが、追加のフィードバックをお待ちしています。
API の使用方法 信頼できるスコアリング シグナルの取得でエラーが返された場合、scoreAd() は引き続き呼び出されますか？ フェッチ呼び出しが成功しなかった場合でも、ScoreAd() は実行されます。
API の使用方法 デルタ/スナップショット ファイルの riegeli ファイルに metadata.shard_num を書き込む。 ブロックを解除するには、現在 shard_num のサポートを追加しています。Riegeli は、たとえば Avro ほどには採用されていませんが、放棄されていません。TEE には制約とオーバーヘッドの方がはるかに多いため、ユーザー エクスペリエンスよりもパフォーマンスを優先するというトレードオフを行いました。Google では、リクエストからファイルを作成する gRPC サービスの提供を検討しています。また、Avro などの他の形式のパフォーマンスへの影響を評価することもできます。
API テスト PA API と Measurement API はインクリメンタリティ テストをどのようにサポートしますか？ プライバシー サンドボックスには、オークション前の反事実的条件でインクリメンタリティを測定する方法がない。共有ストレージとプライベート集計を使用できますが、反事実的条件はオークション後になります。
API の使用方法 日次更新に BiddingWasmHelperURL を使用すると、k-匿名性のしきい値に影響しますか？ IG の更新では k-匿名性は考慮されなくなったため、bidWasmHelperURL はしきい値に影響を与えることなく更新できます。
API の使用方法 PA API のエラー通知を受け取ることはできますか？ PA API の問題のトラブルシューティングでどのようなエラー通知が必要になるかについて、エコシステムからのフィードバックをお待ちしています。
広告サイズ 広告サイズはオークションに参加できず、レポートもできません。 Google は、この pull リクエストで問題に対処しています。
API の使用方法 更新 IG エンドポイントは、このオークションに参加していない場合、IG に対して呼び出されますか？ はい。updateURL は、特定のオークションに入札していなくても、該当の所有者のすべての IG に対して呼び出されます。要件は次のとおりです。
- 所有者が特定のオークションに参加している（オークション構成に購入者として含まれている）
- 所有者の InterestGroup が過去 24 時間以内に更新されていないこと。
PA API での事前入札 テストフェーズにはどのバージョンの Prebid.js が必要ですか？ Google の技術ドキュメントによると、バージョンは 8.9.0 以上である必要があります。
PA API での自社データの有効化 Instagram の定義と利用のために自社データをどのように活用すればよいでしょうか。 このタスクには、「権限の委任」と「否定的なインタレスト グループ」を使用できます。
PA API とサーバーサイド タグ設定 PA API はサーバーサイド タグ設定とどのように連携しますか？ ユーザーのブラウザのベースタグは、API 呼び出しをサーバーサイドの残りのタグにリダイレクトする必要があります。これにより、呼び出しも登録できるようになります。
Chrome テスト（モード A/b） SSP も RTB 入札リクエストでこれらのラベルを渡すことは想定されていますか？渡される場合、どのように受け取れますか？ はい。ラベルは SSP から DSP に渡されます。エンティティはラベルにアクセスし、このデバイス拡張機能を介して、変更しない値をパートナーと共有することが推奨されます。
データの保存と使用量 データの保存方法や転送先に関する詳しい情報はありますか？ 法的なガイダンスは提供しませんが、データの保存、保持、その他のプライバシーの問題に関するアプローチや全般的な考え方をお伝えします。プライバシー関連のコンプライアンスに関するよくある質問については、こちらをご覧ください。
API の安全性 generateBid() 関数の戻り値を操作する悪意のあるクライアント側コードについて懸念があります。 この問題についてこちら で検討しており、一部のフィードバックはプライベート アグリゲーションの提案に組み込まれています。
カスタムの宛先 カスタムのリンク先の reportEvent 呼び出しを使用する際、allowedReportingOrigins の IG の一部として事前登録したカスタム レポート送信元（購入者でも販売者でもない）を、DSP が registerAdBeacon を使用して reportWin で宣言する必要があるかどうかがわかりますか。 いいえ。reportWin に再登録する必要はありません。こちらに記載されているように、reportEvent で直接使用できます。
API の制限 作成時と更新時の IG サイズ。 アップデートのサイズは、IG 作成の新しい 1 MB の上限（50 KB から）に合わせて 1 MB に更新されました。
k-匿名性に関する制限 さまざまなサイズを含む広告用の k-匿名性。 Google は 2023 年 12 月にK-匿名性の値を公開し、K-匿名性で「2025 年以降」に広告サイズの確認を開始することを発表しました。10 月 11 日の WICG 呼び出しで説明したように、クロスサイト トラッキング ベクトルになる可能性があるため、サイズを除外する方法はありません。
API の安全性 悪意のあるプレーヤーがページの「ホスト名」を偽造する可能性はありますか？ この API では、パブリッシャーのホスト名に設定されたサブキーがサポートされています。ブラウザが鍵を設定しているため、このメカニズムを回避するのは難しいと思われます。
API の使用方法 ForDebuggingOnly 関数は本番環境での使用には推奨されません。 Google は、forDebuggingOnly 関数は 3PCD 以後のトラブルシューティング以外にはまったく適していないことをエコシステムに対して再度主張しようとしています。
追加のデバッグツールが必要 ForDebuggingOnly では、scoreAd() の前に発生する可能性のある問題を把握するには不十分です。 このギャップについてさらにフィードバックを収集しており、こちらから追加のフィードバックをお待ちしています。
インタレスト カテゴリ グループからの恒久的なオプトアウト ユーザーが特別な IG の作成を永続的にオプトアウトできるようにするリクエスト。 Google の戦略は、現状ではユーザーが意味を理解できないため、Instagram レベルでユーザーがオプトアウトできないというものでした。
ドキュメントを改善する 仕様と説明の renderUrls パラメータには同じ大文字小文字を使用します。 フィードバックをお寄せいただきありがとうございます。ドキュメントの更新については、追ってご連絡いたします。
Protected Audience の取引サポート Protected Audience のディール サポートの追加オプションをリクエストします。 Chrome チームは現在、3PCD によってこれをサポートするためにできることを評価しています。
マクロ IG のサイズを最大 IG サイズより小さくするには、マクロをサポートする必要がありました。 説明の最近の更新で、このリクエストの一部に対処しました。
イベントレベルの ReportLoss API イベントレベルの ReportLoss API のリクエスト。 イベントレベルの損失レポートは重大なプライバシー リスクをもたらしますが、Private Aggregation API に適切な変更を加えることで、このリクエストの基本的な目標を達成できると考えています。こちらからフィードバックをお寄せください。
API の使用方法 入札のスコアが 0 を超える場合、forDebuggingOnly メソッドはどのように動作しますか？ スコア <= 0 の場合は、自動的に負けとなります。そのため、reportAdAuctionloss が呼び出されます。
標準化 PA API の generateBid() 関数の入出力値のユーザー間のアライメントがありません。 パートナー様には、この問題（または同様の問題）を IAB Tech Lab に提起することをおすすめします。このグループは、特に Protected Audience などの API の業界標準に取り組んでいます。
API の安全性 Google は IG からどのようなデータを確認できますか？ k-匿名性は、強力なプライバシー保護によって、ユーザーのセンシティブ データが Google を含むあらゆる当事者に漏洩しないようにします。Google では、このリスクを最小限に抑えるため、サードパーティによるレイヤの実装（Fastly）も開発しています。
Chrome テスト（モード A/b） 「k-anon」制限されたユーザーをテストから除外できますか？ こちらで説明されているように、レポートには k-匿名性のステータスが表示されます。
ブランド保護 ブロックされているサイトやキーワードのリストによっては広告が配信されないブランド保護のユースケースをサポート このようなブランド保護のユースケースは、すでに PA API を使用して実現できます。

ある広告キャンペーンで特定のドメイン群をターゲットから除外するには、IG 自体にドメイン ブロックリストを保存します。それぞれのドメインを一覧表示するとスペースが大きくなる場合は、ブルーム フィルタを使用できます。あるいは、広告キャンペーンを識別するキーと Key-Value リクエストに含まれているドメイン名の組み合わせに基づいて答えを検索する UDF を使用して、Key-Value サーバーから許可または拒否の決定を返すこともできます。

Protected Audience API を使用すると、SSP と DSP の両方で、ページのコンテキストに関する情報をオークションに渡すことができます。たとえば、ページ上のデリケートなトピックやキーワードのリストなどがこれに該当します。DSP の入札ロジックでは、この情報と、広告を表示すべきでない場所について保存されている情報とを比較し、必要に応じて入札しないことを選択できます。

不可能と思われる特定のユースケースについて、エコシステムからのフィードバックをお待ちしております。
権限の委任 権限の委任の仕組み 権限の委任に関するドキュメントをこちらで公開しています。
バッチ リクエスト バッチ リクエストをサポートするため、一部の PA API の URL で POST リクエストを使用します。 ご提案を歓迎し、ぜひこちらからフィードバックをお寄せください。
API の改善 使用が推奨されないフィールド（X-fledge-bidding-signals-format-version など）。 この問題についてご説明いたしますので、こちらからフィードバックをお寄せください。
API の改善 GDPR への同意を第三者広告配信および測定ベンダーに渡すリクエスト。 この機能は、こちらで説明されているように、非推奨の ReplaceInURN マクロ置換 API を使用してサポートされています。
ダイナミック クリエイティブの最適化 Protected Audience はダイナミック クリエイティブの最適化をどのようにサポートしますか？ このユースケースについて説明し、考えられるソリューションについてもこちらで紹介しています。
API の改善 第三者広告配信 URL のリクエストで、主にオークションで落札した IG に対応する IG コンテキストの IG 名を取得できる。 このようなリクエストは、ユーザーのトラッキングのリスクを高める可能性があります。この問題についてご説明いたしますので、こちらからフィードバックをお寄せください。
API の安全性 「IG blob」のサイズにより、選択された IG に関する情報が漏洩することが懸念されます。 Chrome B&A API 説明の「プライバシーに関する考慮事項」セクションで説明したように、blob サイズは navigator.getInterestGroupAdAuctionData() へのどの入力にも依存しません。デバイス上のすべての IG をパッケージ化するだけです。これにより、blob サイズがページ上で比較的安定し、クロスサイト情報の漏洩が制限されます。それがまさにこのためです。
Chrome テスト（モード A/b） Cookie の設定と Chrome を利用したテストについて、最初の読み込みが行われないことに対する他の SSP の方針はどのようなものですか？ 重大な懸念は寄せられていませんが（他の関係者もこの状況を認めています）、これが重大な問題である場合は、エコシステムからのフィードバックを歓迎します。
A/B Testing のサポート PA API A/B テストのサポートをリクエストします。 11 月の WICG 会議でこのリクエストについて検討いたしました。追加のフィードバックをこちらでお待ちしております。
広告サイズ Protected Audience オークションの規模は誰が選ばれますか？ この質問は こちらのよくある質問で回答されています。
API の改善 /bid-signals/v1/getvalues パスを受け入れるように Key-Value サービスを設定するリクエスト。 この pull リクエストにサポートのパス プレフィックスを追加しました。
API の使用方法 広告主のベースに属すことが想定されている場合、パブリッシャーがコードで IG を作成し、広告主が入札できるようにするには、どうすればよいですか。 その答えは、広告テクノロジー パートナー（Protected Audience のオークションに参加し、オーディエンスが外部ソースからアクセスできるようにする方法を構築したい DSP または SSP）から提供される必要があります。これについては、こちらの GitHub の問題で詳しく説明しています。
API の改善 除外 IG を「肯定的なインタレスト グループ」の広告にリンクする可能性をリクエストします。 Google ではこのリクエストを検討し、こちらでサポート方法の提案をお知らせしています。
シャードの数 メタデータで「shard_num support」を渡すためのサポート リクエスト。 こうしたフィードバックを受け、shard_num のサポートを追加しました。
API の使用方法 K/V サーバーの鍵のオーバーヘッド見積もりのリクエスト。 こちらからご意見やご感想をお寄せください。ぜひフィードバックをお寄せください。
k-匿名性 K-匿名性カウンタの粒度の明確化と拡張のリクエスト。 K 匿名性カウンタの粒度について詳しくは、こちらをご覧ください。
デバッグ 最近提案された forDebuggingOnly に対して提案された変更に従い、PA API のデバッグ機能を改善するためのリクエスト。 リクエストについては、こちらで検討しています。追加のフィードバックをこちらでお待ちしています。
広告サイズ 追加の BTS シグナルとしての広告スロットサイズのリクエスト。 Google では、このリクエストに対応するための提案をこちらで公開しています。ぜひフィードバックをお寄せください。
API の安全性 オリジンに基づいて「runAdAuction()」の使用を制限できますか？ 詳細な回答をこちらに掲載しています。
IG ライフタイム IG の有効期間を 30 日間から 90 日間に延長するリクエスト。 現在リクエストを検討しております。こちらからフィードバックをお寄せください。
API の使用方法 Protected Audience オークションを、ヘッダー入札およびパブリッシャーの広告サーバー呼び出しと並行して実施することはできますか？ こちらで、このリクエストについて検討しています。追加のフィードバックをお待ちしています。
デバッグ DevTools と通信する Chrome PA API デバッグ拡張機能のサポート強化リクエスト。 私たちは、より多くのデバッグツールの提供を支持します。また、こちらから追加の提案を歓迎します。
API の使用方法 コンポーネント販売者からの入札がベストセラーに到達しない場合、損失通知がトリガーされません。 その理由については、こちらで説明しています。
API の改善 Protected Audience 入札ワークレットでの TextEncoder のサポートをリクエストします。 Google ではこのリクエストを検討しております。こちらからフィードバックをお寄せください。
API の使用方法 クライアントでのネットワーク呼び出しとロジックの実行がメインスレッドをブロックし、JS の実行が困難になり、SEO に影響する可能性があります。 この問題についてご説明いたしますので、こちらからフィードバックをお寄せください。
API の使用方法 DSP が現在のサーバーサイドの入札ファネルを使用して、デバイス上のオークションで使用する広告候補を perBuyerSignal の一部として評価して送信することはできますか？ この質問について検討しています。追加のフィードバックをこちらでお待ちしています。
入札機会データを拡張する ブラウザから SSP に渡される入札機会データを、ブラウザ内のアクティブな IG の一意のオリジン ドメインのリストとともに拡張するリクエスト。 こちらで、このリクエストについて検討しています。追加のフィードバックをお待ちしています。
オフライン ビッダー ORTB でのオークション構成と generateBid レスポンスの調整用の 2 つの新しいフックをリクエストします。 Google ではこの問題を調査しています。追加のフィードバックをこちらからお待ちしています。
前回の勝利 prevWinsTransformer を定義する IG のリクエスト。IG の以前の Win を受け取り、シリアル化可能なものを出力します。 Google ではこの問題を調査しています。追加のフィードバックをこちらからお待ちしています。
コンテンツ タイプ JSON から CBOR などへのコンテンツ タイプの進化に向けた戦略。 Google ではこの問題を調査しています。追加のフィードバックをこちらからお待ちしています。
Protected Audience API で事前入札 Protected Audience オークションのエンドツーエンドのフローを実行するために Prebid を使用するサンプルのパブリッシャー ページをリクエストします。 Google ではこのリクエストを検討しております。優先すべき理由について、エコシステムからの追加のフィードバックをお待ちしています。また、エコシステムの参加者の事例も、エコシステム内の他の関係者がデモとして利用できるパブリッシャー ページのサンプルを作成しています。

Protected オークションサービス

フィードバックのテーマ まとめ Chrome レスポンス
高信頼実行環境（TEE） 信頼できる実行環境をパブリック クラウドで運用するには、オンプレミスの広告テクノロジー データセンターと比べて費用がかかる？ Google の現在の TEE セキュリティ モデルでは、パブリック クラウドの実装の手法が活用されています。特に、現在のハードウェア ベースの TEE は、すべての物理攻撃に対して防御できるわけではありません。Google がサポートしている既存のパブリック クラウド プロバイダである AWS と GCP は、従業員によるものを含む物理的なアクセスリスクの軽減策を設計、実装しました。オンプレミス サポートの詳細については、下記 をご覧ください。

広告テクノロジーの担当者から、オンプレミスの広告テクノロジー データセンターよりもクラウド サービスを運用する方が費用がかかるという報告がありました。Google はこれらの声明を評価する立場にはありませんが、費用に関する追加のフィードバックを歓迎し、TEE サポートを拡大するためのオプションを引き続き評価します。
（前の四半期に報告）

オンプレミスの TEE		 TEE プロバイダになるための要件は何ですか？ 対応は前の四半期と同様です。

「Google は、セキュリティの観点からどのデプロイが許容されるのかを検討するなど、パブリック クラウドベースのソリューション以外のオプションのサポートを引き続き模索していますが、現在のところ、オンプレミスの TEE をサポートする計画はありません。現段階では、プライバシー サンドボックスのセキュリティ要件とオンプレミスでのデプロイに伴う重大な課題を考慮すると、クラウドベースのデプロイを継続的に拡大、改善することが、エコシステムにとって最も有益であると考えています。しかしながら、プライバシーとセキュリティ上の制約を考慮すると、なぜこのような要件が必要であり、実現可能であるのかについて、追加のフィードバックをお待ちしています。」
Key-Value サーバーの制限 サーバーごとのオークションあたりのキーの上限 この問題についてご説明いたしますので、こちらからフィードバックをお寄せください。
k-匿名性に関する制限 今後 K/V 鍵に k-匿名性が適用されないことの確認。 将来的に K/V サーバーを TEE に移行することを目標としているため、現時点では K/V サーバー リクエストのキーに k-匿名性を適用する予定はありません。
K/V サービスの構築 Google には K/V サービス用のビルド済みアーティファクトがありますか？ 現在、Protected Audience Key-Value サーバー用の事前構築済みアーティファクトはありませんが、エコシステムからこの機能に対する強い要望が寄せられた場合は、提供を検討する可能性があります。
B&A での EgId のサポート 入札とオークションのコード内、および BuyerFrontEnd から KeyValue サービスへのリクエストで、テスト フィールドの ExperimentsGroupId をサポートするリクエスト B&A では現在、experimentGroupId はサポートされていませんが、ベータ版 2（現在は 2024 年 2 月を予定）までに展開することを目指しています。こちらで追加情報をお知らせいたします。
API の使用方法 HTTP でのリクエストの統合は、パス上の攻撃者からの保護に役立ちますが、TEE のオペレーターはサイズを学習します。 こちらで、このリクエストについて検討しています。追加のフィードバックをお待ちしています。
ドキュメントを改善する k-v サーバーがどのようにアドレス指定されるかの仕様が不明確です。 この問題についてご説明いたしますので、こちらからフィードバックをお寄せください。
API の使用方法 「Ad-Auction-Result」と adAuctionHeaders の目的は何ですか？ この問題についてこちらでご説明しておりますので、追加のフィードバックをお待ちしています。
ドキュメントを改善する v2 の設計が FLEDGE.md に反映されているかどうかが不明確です。 FLEDGE.md は、Chrome が BYOS-KV にリクエストを送信する仕組みを示しています。v2 プロトコルの設計は TEE-KV のみに限定されており、現在のところ Chrome ではサポートされていません。

デジタル広告の測定

Attribution Reporting（およびその他の API）

フィードバックのテーマ まとめ Chrome レスポンス
クロス環境測定 Chrome モバイルから 3PC は廃止されましたが、Android 向けプライバシー サンドボックスはまだ提供されていません。この暫定フェーズで Chrome はクロス環境測定をどのようにサポートする予定ですか。 Android 側では、PSB/AAR の適用範囲の拡大に取り組んでいます。Attribution Reporting API（ARA）は Android 13 と 14 で利用できます。年内には Android 11 と 12 への拡大を開始する予定です（ただし、この状況は変更される可能性があります）。Android 10 以前には拡張できませんが、Android 10 以前を搭載した Android デバイスの割合は 3PCD で低めになり、ユーザーのアップグレードに伴い自然に減少することが予想されます。

このリクエストについて、エコシステムからのフィードバックをお待ちしています。
フィルタリング クリエイティブのスキャンから「コンバージョン」を除外します。 このステークホルダーに連絡して、リクエストをより深く理解するために連絡しました。この問題に関するエコシステムからのフィードバックをお待ちしています。
第三者広告サーバー PA API と ARA は第三者広告サーバー タグとどのように連携しますか？ ピクセルが現在のインプレッションタグやクリックタグで機能するのと同様に、広告サーバーでは、ARA のソースとトリガーの登録を独自に設定するか（Protected Audience オークションからの登録を含む）、またはリダイレクトを設定して、ARA のソースとトリガーの登録を渡して受け入れることが可能です。
DCM DCM と他の第三者広告サーバーによるアトリビューション src のサポート。 これは DCM に関連する問題で、こちらの GitHub の問題で DCM チームが対処しています。
階層集計キー 資金提供予算をすべての階層キーに分割する必要はありますか？ このステークホルダーに話し合い、回答を提示しました。階層的なキー構造を使用する場合、広告テクノロジーは、インプレッションに対するすべてのキー出力で資金提供予算が共有されることを考慮する必要があります。
別のサブドメインを使用する アトリビューション レポートを作成し、eTLD+1 が同じで異なるサブドメインに登録されているソースとトリガーを使用できるようにしますか？ この質問についてステークホルダーと話し合い、以下のソリューションを提案しました。ソースとトリガーでレポート元を同じになるように URL 設定を変更するか、登録を行う前に現在の URL から共通の URL にリダイレクトします。提案したソリューションがそのユースケースで機能しなかった場合は、エコシステムからのフィードバックもお待ちしています。
（前の四半期でも報告）

本番環境サポート		 ARA を使用しているパートナーをサポートするには、どのようなレベルのサービスを利用できますか？ Google の対応は前の四半期と変わりません。

「Google は、広告テクノロジーが技術的な問題を報告し、問題を解決するために必要なエスカレーションを可能にする幅広いチャネルを提供しています。さらに Chrome では、エコシステムの健全性に影響する技術的な問題やエスカレーションを解決するためのプロセスをさらに構築し、拡大していく予定です。Chrome では、この取り組みに必要なリソースを確保するよう努めています。
一般公開フォーラムと限定公開フォーラムでのフィードバックとエスカレーションについて詳しくは、デベロッパー向けの投稿をご覧ください。」
（前四半期にも報告されています）

タイムライン		 CMA 定量的テストの開始までに、「フェーズ 2 フル フレキシブル イベントレベル」の準備が整いますか？ フェーズ 2 のフル フレキシブルなイベントレベルは、2024 年第 1 四半期に Chrome で利用できるようになる予定です。ステータスはこちらで確認できます。
（前の四半期でもレポートされます）

コンバージョン プロセス		 コンバージョンに使用された複数のドメインを報告します。 このユースケースは、複数のデスティネーションを追加することにより実現できます。ぜひフィードバックをお寄せください。
テストラベルの報告 テスターはレポート機能を使用して、ユーザー（Chrome ブラウザ）が所属しているグループ（モード A/B）を報告できますか？ 現在、ARA で Chrome のテストラベルを取得するためのテストガイドの公開に取り組んでいます。
ドキュメント Attribution-Reporting-Register-Source のドキュメントには、有効期限は最も近い日付に丸められますが、どのように丸められますか？ 日付に最も近いものに四捨五入すると、1.5 日は 2 日に丸められます。
別のサブドメインを使用する ソースとトリガーの登録として別のサブドメインで Attribution Reporting API レポートを受信するリクエスト。 できません。HTTP リダイレクトは適用できますが、その設定はありません。このリクエストが有用である理由について、エコシステムからのフィードバックをお待ちしています。
イベントレベルのレポートの遅延 アトリビューションとレポートの対象期間は 7 日間ですが、イベント単位のレポートの遅延により、すべてのレポートが届くまでに 8 日以上かかる場合があります。 特に固定からフレキシブルなイベント レポート期間への移行については、このイベントレベル レポートの遅延が問題かどうかについて、エコシステムからのフィードバックと追加の意見を歓迎いたします。
コンバージョン トリガー 最初の event_report_window（1 時間）の終了から有効期限（1 日）までの間に発生したコンバージョン トリガーでは、レポートが生成されません。 固定から柔軟なイベント レポート期間に移行する、柔軟なイベントレベルの構成を導入しました。
ノイズ GitHub の説明で説明されているように、イベントレベル レポートにはノイズの多い偽のコンバージョンが含まれていますか？ はい。ノイズはイベントレベル レポートに適用され、さまざまな trigger_data など、考えられるすべての出力状態を表します。トリガーが実際に発生したときに何も報告されない、イベントに関する複数の偽のレポートが報告される可能性があるなど。ノイズの割合はオープンソースであり、イベントレベルの柔軟な構成を通じて柔軟に調整できます。
フィルタリング Attribution Reporting API でフィルタを使用すると、集計キーが記録されなくても寄付の予算を消費することになります。 aggregatable_trigger_data はトリガーキー自体に対するフィルタリングのみをサポートしており、値 / キーに対するフィルタリングはサポートしていないため、これは想定どおりの挙動です。トップレベル フィルタはキー自体のフィルタリングをサポートできますが、これはイベントと集計で共有されるため、ここでは適用できません。キーでフィルタする必要がある場合は、こちらからエコシステムからのフィードバックをお待ちしています。
ストレージ上限 レポート元も考慮する保存容量の上限を導入するリクエスト。 この上限は、M120 から 1,024 から 4,096 に引き上げられます。エコシステムからのフィードバックについては、こちらからぜひフィードバックをお寄せください。
直接アトリビューション ユーザーがパブリッシャーを経由せずに広告主に直接アクセスしたという状況の場合、標準のアトリビューション レポート プロセスでは対応できないので、どのように指標を取得しますか。 ARA はクロスサイト情報（パブリッシャーと広告主のサイト間で情報を結合）を復元することのみを目的としています。クロスサイト情報が必要なければ、ARA は役に立ちません。この問題についてご説明いたしますので、こちらからフィードバックをお寄せください。
レポート日時 ローカルマシンの時刻を使用する代わりに、タイムサーバーからスケジュールを設定して時刻を取得します。 現在、タイムサーバーを使用する予定はなく、広告テクノロジーからの要望はあまり多くありません。この機能が役立つかどうかについて、エコシステムからのフィードバックをさらにお聞かせください。

集計サービス

フィードバックのテーマ まとめ Chrome レスポンス
（前の四半期でも報告）

オンプレミス ソリューション		 集計サービスはオンプレミスのデータセンターにデプロイできますか。 クラウドベースのソリューション以外のオプションのサポートを検討していますが、プライバシー サンドボックスの評価に時間がかかるオンプレミスのセキュリティ制限を考えると、現時点ではオンプレミスの TEE をサポートすることは現実的ではありません。プライバシー サンドボックスのセキュリティ要件とオンプレミスでのデプロイがもたらす大きな課題を考慮すると、クラウドベースのデプロイを継続的に拡大および改善すること（たとえば、AWS に加えて GCP をサポートすること）が、エコシステムにとって最も有益であると考えています。ただし、このような要件が必要な理由について、こちらから追加のフィードバックをお待ちしています。
エンクレーブ エンクレーブが稼働していない場合や、突然エラーを受信した場合、Aggregation Service API はどのように処理されますか？ 起動時にエンクレーブが失敗した場合は再試行を使用し、インスタンスが正常でないと判断されると自動スケーリングによって新しいインスタンスを起動します。アドテックはログを使用してエラーを調査することもできます。

AWS でエンクレーブ障害をデバッグするために、広告テクノロジーは AWS Console Manager にログインして EC2 インスタンスのステータスを確認できます。広告テクノロジーは、Nitro Enclave ホスト インスタンスにログインし、nitro-cli ツールでエンクレーブのステータスを確認することもできます。エラーや障害が発生した場合は、AWS コマンドライン インターフェースを使用してログを表示し、さらに調査できます。

GCP でエンクレーブ障害をデバッグするために、アドテックは Cloud コンソールからインスタンスのステータスを確認できます。また、list-errors-command を使用してエラーを確認することもできます。
別のサブドメインを使用する 開発環境と本番環境の両方で集計サービスの複数のインスタンスを使用するために、複数の（サブ）ドメインを登録するリクエスト。 サイト登録機能がリリースされました。これにより、広告テクノロジーは 1 つの AWS アカウントまたは GCP プロジェクトで、同じサイトの複数のサブドメインを登録できるようになりました。また、複数の AWS アカウントや GCP プロジェクトで同じドメインを登録することもできます。エコシステムからのフィードバックをお待ちしています。
プライバシー バジェット プライバシー予算の枯渇に関連する問題をより適切にデバッグするにはどうすればよいですか？ 現在、Google は、使い果たされた予算についてより詳しい情報を提供するソリューションを検討しています。また、このエラーの発生を最小限に抑えるためにアドテックが使用できる戦略の概要を説明するドキュメントの改善も検討しています。提案が得られ次第、集計サービスの GitHub ページを更新いたします。
Epsilon 値 イプシロン値を増やすリクエスト。 集計サービスのイプシロン値は最大 64 の範囲で保持されるため、3PCD でのさまざまなパラメータのテストとフィードバックが容易になります。イプシロンの範囲の値が更新される前に、エコシステムに事前に通知します。
バイナリ 集計サービス リリース用の、より完全なバイナリ セットを公開します。 Google ではこのリクエストを確認し、追加のフィードバックをお待ちしています。
API の使用方法 コーディネーターの利用規約に照らし合わせて、コーディネーターとデータを共有する。 この問題について、明確化を図るため、追加のフィードバックをお待ちしています。

Private Aggregation API

フィードバックのテーマ まとめ Chrome レスポンス
デバッグ モード B テスト中のデバッグの追加オプションを有効にします。 GitHub のこの事象でお知らせしたとおり、モード B でデバッグモードをご利用いただけるようになりました。この適格性は、1 月 31 日より M121 ベータ版でモード B トラフィックの 50% で変更されます。Stable に移行する前に、お知らせします。

隠れたトラッキングの制限

ユーザー エージェントの情報量削減/ユーザー エージェント Client Hints

フィードバックのテーマ まとめ Chrome レスポンス
ChromeOS ChromeOS のビット数について User-Agent Client Hints をサポート。 本リクエストに対する回答をこちらに掲載いたしました。

IP 保護（旧 Gnatcatcher）

フィードバックのテーマ まとめ Chrome レスポンス
嫌がらせ行為 Google は、IP 保護を通じてユーザーの閲覧データを確認できる可能性があります。 IP Protection は、2 つのプロキシ（1 つは Google が実行、もう 1 つは別の会社が実行）を介してトラフィックをトンネルします。これにより、Google が閲覧データを確認できなくなります。Chrome とプロキシ間ですべてのトラフィックが暗号化されるため、Google プロキシはどのウェブサイトを閲覧しているかに関する情報を持ちません。さらに、システムではブラインド認証トークンを使用して、プロキシでのユーザー ID へのアクセスを最小限に抑えます。Google プロキシが認識するのは、特定の IP の不明なクライアントがプロキシ システムを使用していることだけです。アクセスしたウェブサイトや読み込まれた広告に関する情報はありません。
ヘッドレス モードのサポート プラグインとヘッドレス モードを使用する bot はどのように管理されますか？ IP 保護の不正使用の軽減は、チームにとっての最優先事項です。Google では、これらのシナリオを（他の多くの潜在的な脅威の中でも）慎重に検討し、不正使用や不正行為が成功する可能性を減らすためのオプションの開発に取り組んでいます。現時点では詳細をお伝えできませんが、近いうちにお知らせできる見込みです。引き続き検討を進めてまいりますので、どうぞご期待ください。
既存のプロキシ IP 保護と Chrome の既存のプロキシ設定はどのように連携しますか？ 既存のプロキシ構成は引き続きサポートされます。ユーザーは、以前と同様に独自のカスタム プロキシを構成できるようになります。
不正行為の報告 不正行為の報告はどのように処理されますか？ 詳細は近日中に発表する予定ですが、組織とユーザーが不正行為の報告と証拠を共有するメカニズムを設ける予定です。
規則 知的財産の保護は、どのように現地の法律や規制を遵守していますか？ Google は地域の法律および規制を遵守するよう努めており、このような国単位のブロックの回避は許可されない場合があります。この機能は技術的保護手段の回避を目的としたものではありません。
機能の制限 IP 保護はサイバー・レスポンスの妨げになるか？ Google は、ユーザーをウェブ全体で追跡されるのを IP アドレスに基づいて保護することと、不正使用防止のための IP アドレスの使用など、サーバーの通常の運用への影響を最小限に抑えることのバランスを取るよう努めています。現時点では詳細をお伝えできませんが、近いうちにお知らせできる見込みです。引き続き検討を進めてまいりますので、どうぞご期待ください。
タイムライン 2024 年末までにこの規制が適用される場合、準備はほぼ不可能です。 Chrome ではまず、特定の地域のユーザーに対するオプトイン設定として IP 保護機能をリリースします。これは、一部の企業が IP アドレスを利用する方法に大きな変化をもたらす可能性があることを理解したうえで、エコシステムが調整される中で混乱を最小限に抑えることを目指します。IP 保護は 2025 年までにデフォルトに移行されます。
API の使用方法 ユーザーは初めて Chrome を開いたときに IP 保護を切り替えるかどうかを選択できますか？ IP 保護を使用するかどうかをユーザーが選択できるようにする予定です。このオプションをユーザーに提示する仕組みは、現在も開発中です。
API の使用方法 記録されるデータの量とその期間は？ 今後詳細をお知らせしますが、記録するデータの量は最小限に抑える予定です。
低評価 ユーザーは必要に応じて VPN を使用できます。PS API は必要ありません。 IP 保護の目的は、クロスサイト トラッキングを目的とした IP アドレスの使用を防ぐことです。VPN サービスによるものではありません。
API の安全性 自社が IP アドレスにアクセスし、ヘッダーのパラメータを介して情報を転送することを防ぐにはどうすればよいですか？ Google ではまずサードパーティに重点を置いていますが、これは最も効果が高いと Google では判断しています。大規模な技術的保護手段の回避を防ぐためにアプローチを進化させる必要があるかどうかを判断するために、エコシステムを引き続きモニタリングします。
API の使用方法 API の使用方法を正しく理解している場合、確認が必要です。 IP 保護では、リストベースのアプローチを使用して、どのサードパーティ トラフィックがプロキシを通過するかを識別します。リストに含まれているが、ファーストパーティのコンテキストでアクセスされるオリジンは、それらの接続でこのサービスを介してプロキシされません。

たとえば、分析会社がドメインのリストに含まれている場合、ユーザーがサイトに直接アクセスした場合、そのサイトではプロキシされた IP アドレスではなく、引き続きユーザーの IP アドレスを監視できます。ただし、リスト内のドメインがサードパーティのコンテキストでネットワーク リクエストを行った場合は、接続がプロキシされ、ユーザーの元の IP アドレスがサイトに表示されません。

Google の最終的な目標は、ウェブ上のユーザーのクロスサイト トラッキングを防ぐことです。詳細を確認したうえで、まず注力する予定のサードパーティ ドメインについて詳細をお伝えします。
VPN Google の提案が他の VPN プロバイダにとって不利となる可能性があることを懸念している。 IP 保護の目的は、クロスサイト トラッキングを目的とした IP アドレスの使用を防ぐことです。VPN サービスによるものではありません。
タイムライン IP 保護のスケジュールについて教えてください。 IP 保護は最初に有効になります。これにより、プライバシーに関する意思決定をユーザーが管理できるようになり、Google は少ない量で行動をモニタリングすることが可能になります。IP アドレス保護は段階的に展開され、2025 年にはデフォルトに移行されます。Google は、他のプライバシーに関する提案と同様に、実施しながら学習し、地域的な考慮事項が存在する可能性があることを認識したいと考えています。Google はリストベースのアプローチを採用しており、サードパーティのコンテキストでリスト上のドメインのみが影響を受けます。これらの提案は、正当なユースケースに対して望ましくない混乱を引き起こす可能性があることを意識しているため、ユーザーをトラッキングしているとみなされるスクリプトとドメインのみに焦点を当てています。
機能の制限 ユーザーの IP アドレスを WHOIS で検索できなくなりました。 Google の見解は、IP アドレスは不変の識別子であり、ASN などの関連するメタデータの使用を含め、ユーザーのプライバシーに影響を及ぼす可能性があるためです。Google は、IP 位置情報へのアプローチなどにより、プライバシーとウェブ上での便利なユーザー エクスペリエンスのサポートとの間で適切なバランスを取ることを目指しています。このメタデータではお客様のユースケースに不十分な場合は、詳しくご説明いたします。
HTTP リファラー 元の HTTP リファラーは保持されますか？ こちらで説明しているとおり、IP 保護の一環としてリファラー ヘッダーを変更する予定はありません。
オープンソース IP 保護のソースコードはオープンソースになりますか？ ここで紹介するソフトウェアの大部分は、Chromium と Envoy Proxy プロジェクトの一部としてオープンソースです。ただし、こちらで説明されているように、一部のコンポーネントはクローズド ソースです。

バウンス トラッキング対策

フィードバックのテーマ まとめ Chrome レスポンス
ストレージの削除 バウンス トラッキング対策（BTM）によって共有ストレージと Attribution Reporting のストレージは削除されますか？ BTM がプライバシー サンドボックス API ストレージ（ARA、PA API、共有ストレージ、プライベート アグリゲーション、トピック）を削除する予定はなかった。BTM は、サードパーティのコンテキストでアクセスされる場合にのみ、プライバシー リスクのあるストレージ タイプを削除します。バグの修正が進行中です。
API の使用方法 BTM が有効化される Chrome バージョンはどれですか？10 秒が経過した後のリダイレクト/バウンス トラッキングは、BTM によるバウンス トラッキングと見なされるかどうか M116 では、3 PC がブロックされるユーザーの 100% に BTM がリリースされました。現在のところ、10 秒経過した後のリダイレクトは直帰とは見なされません。
ログインのユースケース ログイン状態を複数のドメイン間で自動的に同期/維持し、トラッキングのような動作で罰せられることはありませんか？ このリクエストについてはこちらでご説明しておりますが、エコシステムからのフィードバックもお待ちしております。
ユーザー ジャーニー 現在、BTM は複雑なユーザー ジャーニーを生み出しています。 こちらで、この件について議論しており、この件に関する Google の考えをお伝えしています。
Storage Access API Chromium の BTM は、Storage Access API（SAA）からの 3PC 権限付与に従います。 この問題については、TPAC 2023 のエコシステム参加者と話し合い、こちらから追加のフィードバックをお待ちしています。
広告レポートへの影響 バウンス トラッキング対策を導入すると、広告のユースケースを実施する際に、ARA などの他のプライバシー サンドボックス API を利用するエコシステム内の小規模な会社が増える可能性があります。 バウンス トラッキング対策は、3PCD の回避の防止を目的としています。ARA は、3PCD 後に利用可能なさまざまな測定ソリューションの 1 つですが、使用する必要はありません。

プライバシー バジェット

今四半期はフィードバックが提供されていません。

クロスサイト プライバシーの境界を強化する

フィードバックのテーマ まとめ Chrome レスポンス
（前の四半期でもレポートされています）

関連ウェブサイト セット（RWS）のドメイン数の上限		 関連ドメイン数の拡張リクエスト。 現時点では、上限を引き上げる予定はありません。この上限は、ユーザーのプライバシーに関する考慮事項、W3C のエコシステム関係者からのフィードバック、他のブラウザでの同等の実装の考慮事項に基づいて設定されました。詳しくは、ブログ投稿（1、 2）をご覧ください。

この数値上限を超えるクロスサイト Cookie アクセスを必要とするユースケースを検討し、ID のユースケース、認証済みの埋め込み、広告のユースケースに関する Google のガイダンスを活用することをおすすめします。
Cookie アクセスのスコープ RWS のすべてのドメインに、すべてのドメインのすべての Cookie の読み取りと書き込みを行うためのアクセス権が付与される懸念があります。 RWS のメンバーになっても、メンバーが互いの Cookie にアクセスすることはできません。代わりに、これによりメンバーは他の同じ RWS サイトに埋め込まれている場合に、（Storage Access API 呼び出し後に）自身の Cookie にアクセスできるようになります。
（前の四半期でも報告）

RWS + CHIPS 統合		 A/B テストなどのユースケースをサポートするための RWS + CHIPS インテグレーションのリクエスト 今後も、この機能のユースケースやご要望を こちらからお寄せください。現時点では、この機能の必要性をブラウザ間の相互運用性のリスクと比較検討しています。
API の使用方法 ユーザーがローカルで Chrome の設定からサイトを手動で削除した場合はどうなりますか？ 現在のところ、ユーザーがグループから手動でサイトを削除する方法はありません。代わりに、ユーザーは [サードパーティの Cookie をブロックする] の下にある切り替え、または新しいトラッキング保護設定パネルの [サードパーティの Cookie をすべてブロック] の切り替えを使用して、「関連サイト」機能を無効にすることもできます。
クロスドメイン通信 RWS でクロスドメイン通信が可能になりますか？ Google では現在、Storage Access API を介してパーティション分割されていない一部のタイプのストレージ（localStorage や Broadcast Channel など）へのアクセスを拡張するオリジン トライアルを実施しており、これによってこの通信が可能になります。この機能は、Storage Access API でサポートされているすべての構成、同じ RWS 全体、 RWS 以外のサイトで使用できます。詳しくは、こちらの ブログ投稿をご覧ください。
requestStorageAccessFor document.requestStorageAccessFor(origin) は、送信元のクロスサイト Cookie で解決される Promise を返すことができますか？ できません。呼び出しはトップレベルのオリジン（引数として渡されたオリジンとは異なる）から行われるため、これを行うと同一オリジン ポリシーに違反します。

Fenced Frames API

フィードバックのテーマ まとめ Chrome レスポンス
（前の四半期にも報告されています）

ネイティブ広告		 ネイティブ広告でフェンス付きフレームがサポートされるようになりました。 以前にお知らせしたとおり、プライバシー保護をさらに強化するために、一部のプライバシー サンドボックス テクノロジーが今後必須となる予定です。たとえば Protected Audience では、2026 年までに広告のレンダリングにフェンス付きフレームを使用し、イベントレベル レポートから移行する必要があります。これらの今後の各要件については、「最短」の日付を記載しており、業界は API の今後の予定を明確にしています。さらに時間の余裕をもって、引き続き業界と協力して、より幅広い重要なユースケースのサポートを設計、実装することができます。たとえば、Protected Audience API による動画広告とネイティブ広告のサポートを維持するため、2026 年以降の要件に先駆けてフェンス付きフレームを進化させる予定です。Google のコミットメントに基づき、CMA はこのような変更について協議し、これらの要件を「早期」に実装する前に、エコシステムからのフィードバックを引き続き活用していきます。
プラットフォームによるサイズの違い フェンス付きフレームに表示されるコンテンツのサイズがパソコンとスマートフォンで異なると報告されています。 現在、この問題を調査しております。こちらからフィードバックをお寄せください。
adComponent をレンダリングする フェンス付きフレームで adComponents をレンダリングする方法のサンプルコードはありますか？ フェンス付きフレーム内で navigator.adAuctionComponents(numComponents) を使用して、複数の要素で構成される広告を表示する方法に関するドキュメントの提供を予定しています。
API の改善 FencedFrame に提供するシグナルを増やす（ブランド保護などを改善）。 ご提案を歓迎し、ぜひこちらからフィードバックをお寄せください。

Shared Storage API

フィードバックのテーマ まとめ Chrome レスポンス
不正使用対策 / 不正防止のユースケース 共有ストレージを不正行為や異常検出に使用する可能性。 この可能性についてはこちらでご案内しており、追加のフィードバックをお待ちしています。
フリークエンシー キャップ クロスサイト フリークエンシー キャップを PA API の外部で設定できるようにします。 クロスサイト フリークエンシー キャップを PA API の外部で設定することは有益なユースケースであるというフィードバックをありがとうございます。現時点では、プライバシー サンドボックスは現行の 3PCD 向け API セットに重点を置いています。ただし、こちらから、このユースケースに関するエコシステムからのフィードバックをお待ちしています。

チップ

フィードバックのテーマ まとめ Chrome レスポンス
ポップアップ/リダイレクト ポップアップやリダイレクトを含む埋め込み認証のユースケースを CHIP はどのようにサポートしますか？ 先日、サードパーティによる段階的な廃止がログイン ワークフローに及ぼす影響の確認に関するガイダンスを共有いたしました。ぜひこちらからフィードバックをお寄せください。
パーティションの上限 サイトごとのパーティションごとの上限全体を 1 KiB に減らします。 Google ではこのリクエストを検討しております。こちらからフィードバックをお寄せください。Google は 3PCD のロールアウトを継続し、デベロッパーが CHIP を採用してフィードバックを提供する間、フィードバックのモニタリングを続けていきます。
Cookie の移行 ウェブアプリを移行する際に、進行中の Cookie やセッションが中断しないように分割された Cookie を発行するための推奨プロセス こちらの回答で、移行のスキームを提案しましたが、デベロッパーは自社の構成により適した 代替ソリューションを策定できました。
API の使用方法 ユーザーが Ad Privacy API 設定にオプトインしない場合、パーティション分割ストレージへのアクセスは無効になりますか？ パーティション化されたストレージとパーティション化された Cookie（CHIP）は、ユーザーが Ad Privacy API 設定にオプトインしていなくても、情報のクロスサイト転送を可能にしないため、有効になります。原則として、クロスサイト転送には制限、チェック、またはユーザーによるオプトインが適用されますが、現在のところ、これらは CHIPS には適用されません。
API の使用方法 ブラウザが「通知なく」パーティション分割するのではなく、最終的にパーティション分割されていない Cookie をブロックする理由は何ですか。 こちらで説明されているように、短期および中期的にはこれを行えません。

FedCM

フィードバックのテーマ まとめ Chrome レスポンス
API の使用方法 開発環境内の eTLD+1 の「well-known file」を提供できません。 こちらで説明されているとおり、Chrome Canary はよく知られた URL の取得をスキップするように更新されました。
API の使用方法 サードパーティのログイン権限をリクエストするため、または FedCM を使用するために定義された特定のユーザー操作要件はありますか？ こちらで説明されているように、特定のユーザー操作の要件はありません。
API の安全性 クライアントが FedCM を開始できるようにするフローを用意する計画はありますか？ただし、基本的にトークンは IdP から RP のバックエンド システムに転送されますか？ こちらでご説明いたしますので、ぜひフィードバックをお寄せください。
オプトイン IDP が RP のクライアント ID の受信をオプトインできるようにして、ユーザーは IDP を信頼できるかどうかを判断できるようにします。 こちらで、このリクエストについて検討しています。追加のフィードバックをお待ちしています。
API の使用方法 FedCM に関するドキュメントの追加リクエスト。 Google はこのフィードバックを認識し、この API の開発を続けながらドキュメントを改善してまいります。

スパムや不正行為に対処する

Private State Token API（とその他の API）

フィードバックのテーマ まとめ Chrome レスポンス
ドキュメント テストに役立つ、プライベート ステート トークンに関する詳細なデベロッパー ガイドをリクエストします。 2023 年第 4 四半期にプライベート ステート トークンのデベロッパー ガイドを公開しました。
年齢/性別確認 3PCD の後にオーディエンスの「年齢と性別」の検証を行うことは困難。 プライベート ステート トークンは現在、年齢と性別の確認を目的としたものではありません。Google は、ユースケースをより深く理解し、それをどのように実現しているかについて理解を深めたいと考えています。追加のフィードバックをお待ちしています。