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

プライバシー サンドボックスの提案と Chrome の対応について、エコシステムから寄せられたフィードバックをまとめた 2024 年第 4 四半期の四半期レポート。

Google は CMA との約束の一環として、プライバシー サンドボックスの提案に関するステークホルダーとのエンゲージメント プロセスについて、四半期ごとに公開レポートを提供することに同意しています（約束の第 12 項と第 17 項（c）（ii）を参照）。これらのプライバシー サンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソースから Chrome が受け取ったフィードバックを集計して生成されます。GitHub の問題、privacysandbox.com で公開されているフィードバック フォーム、業界関係者とのミーティング、ウェブ標準フォーラムなどが含まれますが、これらに限定されません。Chrome は、エコシステムから寄せられたフィードバックを歓迎し、学んだことを設計上の意思決定に積極的に反映する方法を模索しています。

フィードバック テーマは、API ごとの発生頻度でランク付けされます。これは、特定のテーマについて Chrome チームが受け取ったフィードバックの量を集計し、量の降順で整理することで行われます。一般公開のミーティング（W3C、PatCG、IETF）、直接のフィードバック、GitHub、Google の社内チームと公開フォームから寄せられたよくある質問のトピックを審査することで、一般的なフィードバック テーマを特定しました。

具体的には、ウェブ標準団体の会議の議事録が確認され、直接的なフィードバックについては、Google のステークホルダーとの 1 対 1 の会議の記録、個々のエンジニアが受け取ったメール、API メーリング リスト、公開フィードバック フォームが検討されました。その後、Google はこれらのさまざまなアウトリーチ アクティビティに関与するチーム間で調整を行い、各 API に関連して浮上したテーマの相対的な普及度を判断しました。

Chrome のフィードバックへの対応に関する説明は、公開されているよくある質問、関係者から寄せられた問題に対する実際の回答、およびこの公開レポートの目的のために特別に決定された立場に基づいて作成されています。現在の開発とテストの重点を反映して、特に Topics、PA API、Attribution Reporting API とテクノロジーに関する質問とフィードバックが寄せられました。

最近いただいたフィードバックについては、Chrome の回答がまだ検討されていない場合があります。

頭字語の用語集

ARA
Attribution Reporting API
CHIPS
Cookies Having Independent Partitioned State
DSP
デマンドサイド プラットフォーム
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
ID プロバイダ
IETF
インターネット技術特別調査委員会
IP
インターネット プロトコル アドレス
openRTB
リアルタイム ビッダー
延長
オリジン トライアル
PA API
Protected Audience API（旧 FLEDGE）
PatCG
プライベート広告テクノロジー コミュニティ グループ
RP
証明書利用者
RWS
関連ウェブサイト セット（旧称: ファーストパーティ セット）
SSP
サプライサイド プラットフォーム
UA
ユーザー エージェント文字列
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
IP の故意の非公開化

一般的なフィードバック、特定の API/テクノロジーなし

フィードバック テーマ 概要 Chrome の対応
コミットメント コミットメントの G セクションは、プライバシー サンドボックスの実現に不可欠です。Google 独自の広告ビジネスがサンドボックス テクノロジーのみで運営されるという保証がないため、Google がこのテクノロジーを撤退する可能性とともに、その有用性が低下するリスクも高まります。このような機能の分離や削減は、オープンウェブにおけるプライバシー重視のアドレスビリティにとって、存続の脅威となります。 このコミットメントは、Google の広告ビジネスがプライバシー サンドボックス テクノロジーのみ で運営されることを保証するものではありません。Google は、サードパーティが使用できるプライバシー サンドボックス技術を含む、アドレスビリティに対するポートフォリオ アプローチを採用する予定です。Google は、広告エコシステム全体でポートフォリオ アプローチが一般的であることを理解しています。

Google は、デベロッパーがプライバシー保護ツールとテクノロジーを利用することが引き続き重要であると考えています。Google は、プライバシーと実用性をさらに向上させるため、プライバシー サンドボックス API の提供と投資を継続していきます。
ガバナンス 提案されているガバナンス モデルには、正式なコンサルトや再審査請求プロセスにおける説明責任のための具体的なメカニズムが含まれていません。 不正解です。（i）意思決定システムと関連する公開情報と、（ii）再審査請求プロセスの両方で、説明責任のための具体的なメカニズムが提供されています。さらに、監視受託者は、その機能について詳細に監督します。
ガバナンス モデルに、クロス プラットフォーム標準の作成と維持に関する規定が含まれていないというフィードバック。 どのガバナンス モデルでも、他のプレーヤー（この場合はブラウザ）に標準の採用を強制することはできません。そのため、クロスプラットフォームで標準を採用することを要求するモデルは提案していません。Google は、提案の作成と提案の実装に関する経験の共有が標準化プロセスの一般的な活動である標準化フォーラムに引き続き参加します。
ガバナンス 相談期間は 2 か月以上に延長することをおすすめします。提案されているガバナンス モデルでは、提案されている変更の影響を分析するのに十分な時間がエコシステムに与えられません。 3 週間は、特定の変更に対するフィードバック期間の全体ではありません。既存のフィードバック サイクル（はるかに長い）は継続されます。コンサルト プロセスでは、戦略的な意思決定のための既存のプロセス内に、新しい正式なフィードバック ウィンドウが設けられます。そのため、第三者は機能の開発中に、さまざまなフォーラム（GitHub、W3C、IAB Tech Lab などの広告標準団体など）を通じて引き続きフィードバックを提供できます。このようにフィードバック サイクルを構成することで、開発プロセスに大きな遅延を発生させることなく、提案された変更についてエコシステムが分析し、意見を共有できるようになります。
ガバナンス 今後のガバナンス計画に関する詳細情報の提供をリクエストする。 提案されているガバナンス モデルの概要は、CMA の 2024 年第 2 四半期/第 3 四半期レポート（こちらの 3 ～ 5 ページ）に記載されています。
例外リクエスト 同意を得たユーザーに対してサードパーティ Cookie（3PC）にアクセスするための例外をリクエストします。 特定のデータ処理目的でデバイスへのアクセスと保存に同意したとしても、ユーザーが Chrome で 3PC の設定をオーバーライドすることを希望しているとは限りません。ユーザーの 3PC 設定をサイトレベルでオーバーライドできるようにすると、不正使用の可能性が大幅に高まります。また、例外をリクエストする可能性のあるすべてのサイトの動作を Chrome が監査することは現実的ではありません。
プライバシー サンドボックス プライバシー サンドボックス API のオプトイン率のリクエスト。 Google は、この情報をエコシステムと共有する予定はありません。デベロッパーは、現在コードをデプロイしている場所で API を呼び出して、プライバシー サンドボックス API の可用性を推定できます。
オリジン トライアル オリジン トライアルを延長する予定はありますか？ オリジン トライアルは 2025 年 4 月 14 日まで延長されました。
プライバシー サンドボックス プライバシー サンドボックスのビジネス価値を強調し、経営陣の賛同を得られる、技術的な説明を簡潔にまとめた資料をリクエストします。 先日、privacysandbox.com にビジネス向けリソースのセクションを追加しました。こちらで、この情報をご確認いただけます。
モード B ブラウザが「モード B」の場合、現在の Cookie ジャー（1PC、3PC、ローカル ストレージ）は保持されますか？それともワイプされますか？ 現在の Cookie ジャーは削除されません。サードパーティ Cookie は、ファーストパーティ コンテキストで引き続きアクセスできます。
Chrome での 3PC へのアプローチの更新 今後、Chrome から 3PC が完全に削除される予定はありますか？ Google は、ユーザーの選択肢を拡大する新しいアプローチを提案しています。こちらに記載のとおり、サードパーティ Cookie のサポートを終了するのではなく、Chrome に新しい機能を導入します。この機能により、ユーザーはウェブブラウジング全体に適用される、十分な情報に基づく選択を行うことができます。また、この選択はいつでも調整することができます。Google は、この新しい方法について規制機関と協議しており、リリースに際しては業界とも連携していきます。
Chrome テスト Chrome 主導のテストラベルの継続的な提供をリクエストします。 プライバシー サンドボックス チームは、企業がCookie のサポート終了ラベルを引き続き使用したいと考えていることを理解しています。ラベルの提供を延長するプロセスは、オリジン トライアルの延長と同様です。このプロセスの一環として、試験運用版は一度に 3 つの Chrome マイルストーンにのみ延長できます。たとえば、Cookie のサポート終了ラベルに関する Chrome の最新の延長テスト（I2EE）は、Chrome M130 ～ M132 に延長されました。これにより、2 月上旬の M133 安定版リリースまでラベルがサポートされます。その他の拡張機能も同じプロセスで審査されるため、最新情報については blink-dev メール グループをフォローすることをおすすめします。

登録と構成証明

今四半期にフィードバックはありませんでした。

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

トピック

フィードバック テーマ 概要 Chrome の対応
仕様 分類モデルは Android（アプリ名）と Chrome（ホスト名）の間で共有されますか？ いいえ。分類が異なるため、別々のモデルです。
トピック分類の粒度 トピックは一般的な内容であるため、ファーストパーティ情報と組み合わせて使用しても有用ではありません。 Topics 分類は、有用性とプライバシーのバランスを重視しています。Google は、トピックをより具体的にするためのメカニズムを検討しましたが、セキュリティやプライバシーに関する懸念などから、最終的にはそうしないことにしました。

広告テクノロジーは、コンテキスト データ、クリエイティブ データ、ファーストパーティ データに加えて、機械学習や、プライバシー保護に関する API からのプライバシーに配慮したシグナルなど、利用可能なすべてのツールを組み合わせることで最善の結果を得ることができます。詳しくは、こちらをご覧ください。
API 使用量 Topics API のサポート範囲は狭いです。 カバレッジが低い主な理由は次のとおりです。
- ユーザーによる管理/オプトアウト
- パブリッシャーによる管理/オプトアウト
- サイトの適格性（次のサイトはトピックとの照合が承認されていません: 安全でないサイト、WebView、iOS 版 Chrome、シークレット モード）
- ユーザーの制限（18 歳未満の Chrome ユーザーやシークレット モードを使用しているユーザーは、コールバックによる観察とトピックの割り当てを受けることができません）
- 販売者の観察要件（コールバックによる観察を拡大するには、約 4 週間の準備期間が必要です）
- 実装の時期（コールバックによる観察を拡大するには、約 4 週間の準備期間が必要です）
API 使用量 Topics API の使用に関する情報の提供をリクエストします。[Networking] タブには、呼び出しが送信されてキャッチされたことが示されているようですが、chrome://topics-internals/ にはオブザーバーが記録されていません。 HTTP ヘッダー メカニズムを使用して Topics API を操作する場合、トピックは Sec-Browsing-Topics リクエスト ヘッダーで送信されますが、サーバーが Observe-Browsing-Topics: ?1 レスポンス ヘッダーで応答した場合にのみ確認されます。詳しくは、こちらをご覧ください。
Chromium の関与 パソコン版 Chrome は、Chromium をベースとする他のブラウザと、同じ観察とランキングのコンテキストを共有しますか？

モバイルの場合、Android Chrome は Chromium / アプリ内 Chromium をベースとする他の Android ブラウザと、同じ観察とランキングのコンテキストを共有しますか？		 Chrome は、デバイス上の他のブラウザとトピックデータを共有しません。
仕様 ユーザーによるページビューが「トピック履歴エントリ」と見なされるかどうかを Topics API が判断する仕組み 週ごとのトピックの計算の対象となるには、ページ訪問に「observe」呼び出し（任意の呼び出し元からのもの）が含まれている必要があります。「observe」呼び出しがないと、そのアクセスはトピック履歴に含まれません。
セキュリティ Topics API では、ある呼び出し元が他の呼び出し元のトピックを取得できないようにするにはどうすればよいですか？ 詳しくは、こちらをご覧ください。
分類 Topics API 内のツリー構造分類は、各エポックの観測でどのように使用されますか？ 上位 5 つのトピックの計算では、分類システムによって提供された元のトピックのみが考慮され、ランキングは（i）ページ訪問頻度と（ii）優先度スコアによって決定されます（仕様をご覧ください）。

上位 5 つのトピックの呼び出し元による検出数を計算する際、主なトピックまたはその子トピックを検出した呼び出し元が含まれます。
仕様 レスポンスの 5% のランダムなノイズに関する追加情報の提供をリクエストします。 エポックごとに常に 5 つの上位トピックがあります。閲覧履歴に 5 つのトピックがない場合、5 つになるまでトピックがランダムに選択されます。これをパディング トピックと呼びます。呼び出し元が、過去数週間にそのトピックを含むサイト上でユーザーを観測（API を呼び出している）していない限り、ランダムにパディングされたトピックは呼び出し元に返されません。

API が呼び出されると、ユーザーごと、サイトごと、エポックごとのハッシュが計算されます。そのハッシュがノイズが追加されたトピックを返す確率よりも小さい場合、ユーザーごと、サイトごと、エポックごとにランダムにトピックが選択されて返されます。ただし、ノイズが追加されたトピックが返されるのは、呼び出し元がそのユーザー/サイト/エポックに対応するノイズが追加されていないトピックを観測した場合のみです（説明を参照）。このフィルタリングにより、特定の呼び出し元に対して、観測能力に関係なく、ノイズが追加されたトピックが 5% の確率で返されます。
仕様 週をまたいで重複するトピックはどのように扱われますか？API は週ごとに個別に選択してから統合していますか？ 各週（エポック）のトピックは個別に計算されます。各エポックから返されるトピックは、呼び出し元がアクセスしているサイトによって異なります。

特定の呼び出し元でトピックがエポック間で繰り返される可能性は考慮されていません（そのため、別のトピックの選択を検討する必要があります）。この問題について、こちらからフィードバックを送信してください。

Protected Audience API

フィードバック テーマ 概要 Chrome の対応
A/B テスト こちらで説明されている共有ストレージ ソリューションはレイテンシが増加し、障害率が高くなります（つまり、トラフィックの大部分が人口 ID なしで終了します）。エントロピーの低い ID（3 ビット）でも、プライバシーに大きな影響を与えることなく効果的な A/B テストを行うことができます。 Google は、共有ストレージ ソリューションが引き続き有効なアプローチであると考えていますが、このリクエストを検討しており、この機能が優先度が高い場合は、エコシステムから追加のフィードバックをお寄せください。
レポート reportWin() のビット数の増加をリクエストします。特に、PA API の新しいクリックとディスプレイ レポートで 6 ～ 8 ビットが使用されるため、他の PA API レポートで使用できる残りのビットが実質的に減ることになります。 プライバシーに関する懸念があるため、Google は modelingSignals ビットを現在の 12 ビットを超えて増やすことを検討していません。

Google は、プライベート モデル トレーニングの提案について、エコシステムからフィードバックを募集しています。この提案は、プライバシー サンドボックスで課せられるビット数の上限なしで、安全な環境で ML トレーニングのニーズをサポートすることを目的としています。
インタレスト グループ インタレスト グループ（IG）のライフサイクルを 30 日間から 90 日間に延長するようリクエストする。 ブログ投稿でお知らせしたとおり、Instagram の有効期間を 90 日に延長する予定です。詳しくは、こちらをご覧ください。

現在、実装に取り組んでおり、利用可能になり次第、リリース スケジュールをお知らせします。
インタレスト グループ IG 委任の動的更新をリクエストする。 Google は、複数の関係者から寄せられたこのリクエストを認識しており、解決策を調査しています。

開発が進むにつれて GitHub で最新情報を共有し、エコシステムからのフィードバックをお待ちしております。
デバイス上 オンデバイス PA API ソリューションへの投資を継続することで、エコシステムにさらなる価値をもたらします。 プライバシー サンドボックス チームは、PA API などのプライバシー保護技術（PET）ベースの API の開発を継続し、デベロッパーがブラウザでより多くのプライバシー保護オプションを利用できるようにしています。これらの技術は、現在、Chrome ブラウザ全体で広範囲に一般提供されています（一部のデベロッパーが誤解しているように 1% だけではありません）。多くの企業がブラウザ外で他の PET ベースのソリューションを採用しているように、ユーザーが 3PC を有効にするかどうかにかかわらず、開発者は PET ベースのソリューションをプロダクトに組み込むことができます。多くのデベロッパーは、オンデバイス PA API ソリューションに投資することで、確定的なファーストパーティ オーディエンス シグナルを拡張し、サイト全体のリーチを拡大しています。一部のデベロッパーは、より多くのサードパーティ Cookie が無効になった場合にのみ、プライバシー サンドボックス API やその他の PET ベースのソリューションを使用することを選択し、サードパーティ Cookie を保持するブラウザの数を推測できる情報を待機しているようです。Google は、そうしたデベロッパーが、必要な情報を見つかるまで待ってからプロダクトに関する決定を下すことを認識しています。
インタレスト グループ SSP が IG の作成とそれに関連するロールを担うことを許可します。SSP はこれを付加価値の重要な部分と見ており、SSP を通じてパブリッシャーが IG を販売できるようにしたいと考えています。 複数のステークホルダーから、より高度な IG 委任をサポートするようリクエストを受けており、このプロセスに SSP が貢献する付加価値があると考えています。

Google は、さまざまな関係者がオーディエンス拡張プロセスに参加できるようにする最適なソリューションを見つけるために調査を行っています。開発が進むにつれて GitHub で最新情報をお知らせします。エコシステムからのフィードバックもお待ちしております。
レポート forDebuggingOnly と Private Aggregation API の間で「ゼロ以外の入札単価」のレポート数が異なる。 差異が生じる理由は 2 つあります。

まず、Private Aggregation API のデバッグモードは、デバイス上で 3PC が許可されている場合にのみ使用できますが、forDebuggingOnly API は常に非サンプリングで使用できます（この最後の動作は、こちらで詳しく説明するように、最終的には変更されます）。

次に、Private Aggregation API には貢献の上限がありますが、forDebuggingOnly には上限がありません。

ただし、このフィードバックから、予期しない差異の原因が他にもある可能性があることがわかりました。Google は、この問題の解決に向けてサードパーティ ステークホルダーと連携しています。
クリック感 クリック関連シグナルの更新案で説明したように、ビューとクリックは、「対象となる」attributionsrc 属性によって開始されたリクエストに新しい HTTP レスポンス ヘッダーを返すことで登録されます。このレスポンス ヘッダーには、これらのビューとクリックを集計数に含めることができる他のパーティを示すために使用できるオリジンのリストが含まれます。広告テクノロジーがオリジンを任意に設定できるということですか？ クリック率に関する説明では、集計されたビュー数とクリック数にビューまたはクリック イベントを提供する広告テクノロジー（「提供元」）は、レスポンス ヘッダーにオプションのパラメータを指定して、「Protected Audience オークションの generateBid() 呼び出しに提供される計算されたビュー数とクリック数にこのイベントを含めることができる IG 所有者のオリジン」（「対象となるオリジン」）を指定できることが明記されています。

ただし、これらの視聴回数とクリック数は、視聴回数とクリック数のカウントには自動的に含まれません。各広告テクノロジーは、IG で、視聴イベントとクリック イベントを含める「提供元」のセットを指定する必要があります。これらの提供元のデータのみが、その広告テクノロジーの generateBid() 呼び出しに表示される視聴回数とクリック数に貢献します。

このメカニズムには双方の合意が必要です。これにより、悪意のあるプレーヤーが他のアドテックの視聴回数とクリック数に影響を与えるのを防ぐことができます。また、これは、「提供元」の広告テクノロジーが「対象となるオリジン」を恣意的に設定しても、対象となるオリジンがその提供元を明示的に意図的に IG に含めない限り、対象となるオリジンの視聴回数とクリック数に影響しないことを意味します。
プライベート モデル トレーニング DP-SGD（差分プライバシー - 確率的勾配降下法）では、バックプロパゲーション中に計算された勾配のスパース性が破壊されるため、トレーニング プロセスが大幅に遅くなる場合があります。この問題に対処するために検討されている手法や、この懸念に関する考えはありますか？ Google は、DP-SGD でスパース性を維持するいくつかの手法（こちらなど）を認識しており、非公開モデル トレーニング インフラストラクチャでこうした手法のサポートを検討しています。

状況が進展しましたら、最新情報をお知らせいたします。こちらからフィードバックをお送りいただけます。
ターゲット除外 こちらで説明されている IG のネガティブ フィルタ機能のリリースに関する最新情報をリクエストします。 こちらの回答に記載のとおり、PA API 入札でネガティブ IG をサポートする予定です。

リリース タイムラインが決まりましたらお知らせいたします。こちらからフィードバックをお寄せください。
単価設定 入札時に複数の IG を組み合わせることはできますか？ 現在、PA API ではこの操作はできません。PA API は、IG が単一のサイトがユーザーについて把握している情報に関連するという設計に基づいています。これは、エコシステム全体との議論の中心となっています。このアプローチにより、広告テクノロジーは、広告主がウェブ全体でファーストパーティ オーディエンスを拡大するのに役立つさまざまなソリューションを構築できます。

Microsoft の Ads Selection API の提案では、オーディエンスがサイト間の情報に基づくという異なる設計が提案されていることを認識しています。

Google は引き続き Microsoft のアプローチをモニタリングしますが、Chrome で同様の変更を検討する前に、プライバシー コミュニティを含むエコシステムからさらに多くの議論を期待しています。
ネイティブ広告 PA API がネイティブ広告のさまざまなフォーマットとレンダリング要件を適切にサポートできるかどうか、PA API が効果的なネイティブ広告に必要なクリエイティブの柔軟性と最適化を可能にするかどうかに関する懸念。 Google は、ネイティブ広告のさらなるサポートについて積極的に調査しており、エコシステムからのフィードバックをお待ちしております。
レポート 入札スクリプトとリソースを競合し、実行中のオークション フレームから移動されたときに失われる可能性があるレポート スクリプトの堅牢性を改善するようリクエストしました。 近いうちに GitHub に回答を投稿する予定ですが、これらの懸念が実際に有効な報告に大きな影響を与えることはないと考えています。
マクロの置換 オークション構成で渡されたマクロ置換が、一部のサードパーティ構成で機能しない。 根本原因は、Mode A/B とラベル付けされたすべてのトラフィックでこの機能が有効になっていなかったことです。Google は最近、この機能（および同じ状況にある他の機能）を、モード A/B とラベル付けされたすべてのトラフィックに有効にすることを決定しました。この変更は 2025 年第 1 四半期中に実施する予定です。
追加のフィードバックはこちらからお寄せください。
ドキュメント generateBid() 内の browserSignals オブジェクトの直近の値の測定単位について、ドキュメントに不一致があるようです。明確にしていただきたいので、ご連絡いたします。 詳しくは、こちらで回答しています。また、ドキュメントも更新しました。正解は、測定単位がミリ秒であることです。
レポート サードパーティ レポートのリクエスト: DSP と SSP は Chrome からインプレッション通知を受信しますが、ミドルレイヤ テクニカル プロバイダはデフォルトで受信しません。 現在、この機能リクエストについてこちらで議論しており、皆様からのフィードバックをお待ちしております。
インタレスト グループ パラレル IG オークション ワークフローを使用する際に、interestGroupBuyers を動的に除外する方法に関するガイダンスをリクエストします。 詳しくは、こちらのガイダンスをご覧ください。
ネイティブ広告 特定のページ読み込みに対する独立した PA API オークションでは、同じページの広告のフィルタリングが行われません。 ネイティブ広告のさらなるサポート（「ネイティブ」と呼ばれるおすすめウィジェットや、1 つのユニットに複数の広告を含むものなど）は現在研究中です。現在の設計では、同じページの広告のフィルタリングがサポートされていない可能性があります。また、フェンスド フレームなどのその他の保護機能によって、この機能がさらに制限される可能性もあります。
ネイティブ広告 URL ベースのシグナルに依存する既存の PA API 機能（クリエイティブ スキャン、レポートなど）は、ネイティブ広告クリエイティブで使用される JSON オブジェクトを処理するように調整する必要があります。 ネイティブ広告のサポートの拡充は現在調査中であり、ネイティブ広告のレンダリングを支援するために PA API を適応させる可能性を評価しています。
広告の検証 PA API のサードパーティのブランド保護は、perBuyerSignals のレイテンシとキャッシュの制限の影響を受けます。これは動的コンテンツで問題になります。 Google は、SSP と DSP が、キャッシュに保存されたデータがブランド保護に関連性を保つように、トラフィック シェーピングの目標とブランド保護の最大 TTL のバランスを取りながら、キャッシュに保存する最適な TTL を決定する必要があることを認識しています。Google はこの問題を調査しており、進展がありましたらお知らせいたします。
広告の検証 入札後のブランド保護測定を行うには、SSP による FullpageURL マクロの置換が必要です。 現在の SSP 向けの推奨事項では、このシグナルを deprecatedReplaceInURN で提供しています。
広告の検証 SSP が入札後検証に使用するマクロ形式が標準化されていないと、データ処理と分析の不整合やエラーが発生する可能性があります。 SSP と広告検証ツールは、マクロの使用に関する明確なガイドラインと仕様を定義するために直接連携し、SSP 全体でマクロ形式の標準化を推進して、一貫性を確保し、データ処理と分析のエラーを防ぐ必要があります。これは、IAB Tech Lab などの広告標準化団体に適した活動です。
広告の検証 広告主と広告検証ツールは、デバッグとトラブルシューティングのために、同じパブリッシャーのコンテキストで入札前チェックと入札後チェックをリンクするメカニズムが必要です。 入札後の検証方法の 1 つとして、オークション ベースとキャンペーン ベースのシグナルをイベントレベル レポートに組み込む方法があります。これにより、入札前決定ログとの結合が可能になる場合があります。Google は、この目標を達成するための可能なパターンを模索しており、進展状況に応じて最新情報をお知らせします。
広告の検証 プリビッダー向けの信頼できる Key-Value（TKV）サーバー ソリューション（DSP 所有と広告検証ツール所有）の調査と、ポストビッダーのフェンスド フレームの制限への対応をリクエスト。 Google は現在、このリクエストを評価しています。また、こちらからエコシステムの皆様からのフィードバックをお待ちしております。Google は、入札前のブランド セーフティをサポートし、関係者間の調整要件を緩和できるソリューションを見つけられるよう取り組んでいます。
ネイティブ広告 ネイティブ広告のセルサイドの入札後レンダリング監査のリクエスト。 ネイティブ広告のサポートについては現在調査中です。Google では、ネイティブ広告のレンダリングを支援するために、この機能などの既存の機能を適応させることを検討しています。

Protected Auction（B&A サービス）

フィードバック テーマ 概要 Chrome の対応
レイテンシ 遅延を軽減するための適切な対策が講じられていません。B&A サービスは長期的にはこの問題を軽減できる可能性がありますが、Google は Chrome の 3PC の変更前に、このサービスの幅広い提供を約束していません。 Google は過去数四半期にわたり、デバイス上のレイテンシの改善に取り組んできました。また、必要に応じて B&A サービスを構築してスケーリングしています。これらの機能を活用する方法について詳しくは、最近更新されたレイテンシのベスト プラクティス ガイドをご覧ください。また、新しいレイテンシ改善の開発も継続しており、その一部はこちらでご覧いただけます。
（前四半期にも報告）

オークションのセキュリティ		 オンデバイス オークションの改ざんを防止または軽減する方法について、さらに明確にするようリクエストする（Google がこれを重大なリスクと見なしているかどうかなど）。 回答は前四半期から変わっていません。

「PA API 広告のレポート メカニズムでは、現在、人間と bot のトラフィックを区別するために使用される情報が保持されます。さらに、ドメインの追加または除外に関する現在のドメインベースの手法は、PA API で使用できます。詳しくは、IAB Tech Lab のプライバシー サンドボックスに関するレポートに対する Google の回答をご覧ください。」
オンプレミス ソリューション プライベート クラウドのサポートが不足しているため、最大手のサプライヤーがプライバシー サンドボックスや B&A を採用しない可能性があること、およびプライベート クラウドのサポートに向けたロードマップが長く不明確であることに関する懸念。 Google は、プライバシー サンドボックス サービスが動作するインフラストラクチャの拡大に取り組んでいます。最近、Azure クラウドのサポートを発表しました。また、プライベート クラウドでも同様のプライバシーとセキュリティの保護を提供するソリューションの調査を継続しています。

10 月のコミュニケーション以降、オンプレミスの信頼実行環境（TEE）で Chrome ユーザーのプライバシーを保護するための潜在的なアプローチの研究を継続し、進展がありました。調査の段階は、エコシステムのステークホルダーとさまざまなアプローチを検証する段階に移行しており、第 1 四半期に意見の収集を開始する予定です。エコシステムからのフィードバックとコラボレーションにより、考えられる解決策を絞り込むことができます。
テスト PA API レポート ソリューション（リアルタイム レポートとプライベート集計）をテストするために TEE を作成できますか？ 集計サービスのテストでは、広告テクノロジーはテストデータとローカルテストツールを使用して、機能テストのサマリー レポートを生成できます。ローカルテストの Codelab はこちらをご覧ください。

TEE で集計をテストするには、上記の Codelab の前提条件に記載されているように、広告テクノロジーが登録プロセスを完了する必要があります。

このリクエストについてご意見がございましたら、 こちらからお寄せください。
取引の K/V 統合 ビジネス上のユースケースで KV から取引ベースの情報を取得する機能をリクエストします。 この機能リクエストは現在審査中です。GitHub で最新情報をお知らせいたします。
勝ちなしの
取引測定		 SSP が落札しなかったときとその理由を把握するためのシグナルまたは機能の要求。 現在、このリクエストを評価しており、GitHub で最新情報をお知らせします。
機能のリクエスト 広告のグループをそれぞれの取引 ID セットに照合するのに役立つ辞書構造をプライバシー サンドボックスに提供するようリクエストします。 Google では、このリクエストと、取引 ID の保存に関連する IG サイズを削減するその他の方法を検討しています。最新情報は GitHub でお知らせします。
パフォーマンス 入札スクリプトのサイズが原因で広告オークションの機会を逃した可能性を測定するソリューション。 現在、このリクエストを検討中です。こちらからフィードバックをお寄せください。
仕様 現在、B&A は、仕様で prevWins に代わる最新のフィールド prevWinMs ではなく、prevWins フィールドのみを読み取ります。 B&A が prevWins のミリ秒単位の所要時間を generatebid() に渡さないのは正解です。Chrome はペイロードのオーバーヘッドを抑えるために、時間の値を秒単位で送信します。この問題を解決するには、B&A で秒単位をミリ秒単位に変換します。B&A は、オンデバイス オークションとの互換性を確保するため、browserSignals で prevWins と prevWinsMs の両方を提供します。

注: ウェブのオンデバイス オークションの場合でも、prevWins と prevWinsMs は同じ値に対応し、prevWinsMs = prevWins * 1,000 です。

現在、修正を優先して対応しております。
ドキュメント ドキュメントには、販売者向けフロントエンド（SFE）のテスト方法が明記されていません。デプロイの完了直後に追加のテストガイダンスと、ビルドに Bazel を使用する方法があると便利です。 この Codelab は、広範なエコシステムが SFE を簡単にテストできるようにするためのガイドとして公開されています。
デプロイ B&A 用にビルド済みバイナリを提供する予定はありますか？ B&A 用にビルド済みバイナリを提供することを検討しておりますが、具体的なスケジュールは未定です。それまでは、広告テクノロジーは独自にバイナリをビルドし、提供されたハッシュを使用して検証できます。
デプロイ すべてのオーケストレーション タイプ（サーバー、クライアント、混在）をサポートする必要がありますか？それとも、他のタイプよりも優先すべきタイプはありますか？ 広告テクノロジーで実装するモードについて、具体的な推奨事項はありません。選択はさまざまな要因によって異なりますが、最終的にはお客様にとって最善の方法を選択してください。
テスト B&A ビルド中に失敗したテストについて、明確化を求めています。 これは、不安定なテストが原因である可能性があります。広告テクノロジーに、すべての build_and_test_all_in_docker ビルドコマンドに --no-tests フラグを使用してテストの実行をスキップするよう伝えました。
ログ GCP のログ エクスプローラのログが、テストモードでは SFE を実行している VM インスタンスにタグ付けされているが、本番環境モードでは VM インスタンスにタグ付けされていない理由を明確にします。 正確に何が確認されたかによって異なるため、一般化は難しいですが、一般に次のように考えることができます。

- non_prod のログは、クラウド プロバイダ（この場合は GCP）によってリダイレクトされた stderr ログであり、GCP によってタグが追加された可能性があります。

- VM によって生成されたログには通常、VM インスタンスのタグが付けられますが、バイナリによって生成されたログには GCP によってタグが付けられません。

- 本番環境のログは TEE の Open Telemetry によってエクスポートされ、タグが異なります。

こちらに、non_prod と prod で利用可能な機能の詳細を示します。
B&A OTEL ロギングが無効になっているときにシークレットが見つからない場合に 403 エラーが発生する。 この問題は 4.1 アップデートで修正され、ドキュメントもそれに応じて編集されました。
B&A GCP Terraform 構成の outputs.tf ファイルがないとエラーが発生する。 この問題は解決しました。
テスト テストモードで秘密鍵を取得する際にエラーが発生する。 このような場合は、サーバーが TEST_MODE=true で実行されていることを確認してください。

詳しくは、こちらをご覧ください。
ロードマップ getInterestGroupAdAuctionData で複数の販売者オリジンを受け入れて、販売者オリジンと B&A ペイロードの暗号テキストのマップを返す予定はありますか？ はい。navigator.getInterestGroupAdAuctionData() で複数の販売者を受け入れられるようにするサポートの追加が予定されています。
KV の仕様 KV URL（trustedScoringSignalsURL）を Promise として配信することはできますか？ 詳しくは、こちらをご覧ください。
B&A プライベート オークションの実施にクライアント（ブラウザ）に必要な機能を B&A 販売側に示すための新しいプラットフォーム ヘッダーの作成をリクエストしています。 現在、この機能リクエストについてこちらで議論しており、皆様からのフィードバックをお待ちしております。
トラフィック シェーピング 特に DSP 向けに、B&A サーバーのホスティングによる追加費用を削減するための提案。 現在、この提案についてこちらで議論しており、皆様からのフィードバックをお待ちしております。
Bring-Your-
Own-Binary		 すべてのバイナリがサポートされていることを明示的に説明するように、説明を更新することを検討してください。 このポリシーは更新されました。詳しくは、こちらをご覧ください。
KV 呼び出し generateBid() は、すべての Key-Value（KV）ストア呼び出しが完了するまで待機しますか？それとも、独立して実行されますか？KV バッチ処理はタイミングにどのように影響しますか？ 詳しくは、こちらをご覧ください。
パフォーマンス 入札スクリプトの再利用と、スクリプトにキャッシュ制御ヘッダーを設定する推奨事項に関する追加のドキュメントの提供をリクエスト。 ドキュメントはこちらに追加されています。
パフォーマンス デバイス上のオークションのレイテンシを短縮するために、リソース（入札スクリプトなど）を非同期で読み込む機能を検討して調査することをリクエストします。 現在、この機能リクエストについてこちらで議論しており、皆様からのフィードバックをお待ちしております。
同意のロギング CONSENTED_DEBUG_TOKEN を設定して同意ログを使用する際に発生するエラーについて、明確化が必要。 このような場合は、SECRET_MANAGER に CONSENTED_DEBUG_TOKEN が存在し、ENABLE_OTEL_BASED_LOGGING が true に設定され、TELEMETRY_CONFIG が mode: PROD に設定されていることを確認します。

こちらの説明を参照してください。ソースは こちらです。
ログ forDebuggingOnly イベントは B&A で使用できますか？ B&A の forDebuggingOnly は、2024 年 4 月より単一販売者のオークションで利用可能になりました。まもなく、複数販売者のオークションでこの機能を有効にする予定です。
ワークレット ログ ワークレットのロギングを ChromeDriver と互換性のあるものにするリクエスト。 現在、このリクエストを検討中です。こちらからフィードバックをお寄せください。

デジタル広告の測定

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

フィードバック テーマ 概要 Chrome の対応
デバッグ レポート Chrome のサードパーティ Cookie に関するアプローチの更新後、広告テクノロジーが ARA デバッグ レポートを利用するにはどうすればよいですか？

サードパーティ Cookie を保持し、プライバシー サンドボックス API を有効にしているユーザーの ARA デバッグ レポートに、広告テクノロジーが引き続きアクセスできる必要がありますか？		 広告テクノロジーは、サードパーティ Cookie と ARA の両方が有効になっているユーザーに対して、Cookie ベースと Cookie を使用しないデバッグ ソリューションにアクセスできます。Cookie をオフにすると、集計デバッグ ソリューションにのみアクセスできるようになります。

デバッグ ソリューションの詳細については、こちらとこちらをご覧ください。
特徴検出 サーバーサイドで ARA の特徴検出を行う方法に関するガイダンスのリクエスト。 現在、ARA 機能のサポートは、ユーザー エージェント文字列に表示される Chrome のバージョンに基づいて識別できます。

この件について、エコシステムからのフィードバックをお待ちしています。
機能のリクエスト ARA 集計の shared_info で使用される source_registration_time の精度を高め（1 日ではなく 1 時間または 1 分に切り捨て）、タイムゾーンを考慮して構成できるようにする（現在は UTC のみ）リクエスト。 source_registration_time フィールドを 1 日に切り捨てることは、広告テクノロジーが特定のユーザーを特定のソース登録に関連付ける能力を軽減するために使用されるプライバシー メカニズムです。現在、source_registration_time は UTC に基づいています。広告テクノロジーは、このことを考慮して広告レポートを調整できます。

このリクエストについてエコシステムからご意見がございましたら、こちらからお寄せください。
仕様 「trigger_data」と「priority」の仕様を明確にするようリクエストします。特に、配列値で使用する場合。 これらのフィールドは配列値を受け入れません。説明の角かっこは配列を表すのではなく、テキストが値の例ではなく、説明付きのプレースホルダであることを示します。

角かっこ内のテキストが示すように、

- trigger_data は int-64 です
- priority は符号付き int-64 です

どちらのフィールドも配列値を受け入れません。また、ドキュメントがわかりにくい場合は、ARA のヘッダー検証ツールを使用してさまざまな値を試し、エラーが発生するかどうかを確認することも検討してください。
Accelerated Mobile Pages（AMP）広告のサポート ARA は AMP 広告に対応していますか？ AMP をサポートする方法に関する Google の提案はこちらでご覧いただけます。ご意見やご感想をお寄せください。
仕様 ARA のマルチレイヤ埋め込み広告の「参照サイト」としてどの URL が使用されますか？ 最上位サイトの URL。
（前四半期にも報告）

機能リクエスト		 event_report_window の最小値を 3,600 秒（1 時間）から 1,800 秒（30 分）に引き下げるリクエスト。 最小レポート期間を決定するには、有用性とプライバシーの考慮事項のバランスを取る必要があります。

イベントレベル レポートの最小レポート期間は 1 時間です。これは、プライバシーを維持し、特定の種類の履歴再構成攻撃を軽減するために不可欠です。

このリクエストについてご意見がございましたら、こちらからお寄せください。
ノイズ ARA イベントレベル レポートでノイズがどのように実装されているかを詳しく把握し、データの正確な解釈と活用を実現する。 詳しくは、こちらとこちらをご覧ください。
レポート 集計レポートの shared_info に、デフォルトで source_registration_time が含まれなくなりました。 これは API の変更によるものです。詳しくは、こちらをご覧ください。
レポート chrome://attribution-internals/ UI の [集計可能なレポート] タブに filtering_id が表示されない。 現在、filtering_id は [トリガー登録] タブの詳細で、行をクリックすると表示されます。これにより、有効性を確認できます。[集計可能なレポート] タブに表示することの有用性を認識しており、こちらで対応しています。
アトリビューション ソース アトリビューション ソースの仕組みについて明確な説明を求めるリクエスト。 詳しくは、こちらをご覧ください。
アプリからウェブへのアトリビューション ソースが OS とウェブのどちらになるか不明な場合の実装に関するガイダンスの依頼。 ガイダンスについては、こちらをご覧ください。

集計サービス

フィードバック テーマ 概要 Chrome の対応
機能のリクエスト AgS の構成可能なタイムアウト、または長期実行のジョブ ステータスの可視性の向上をリクエストします。 長時間実行ジョブのモニタリングをサポートする機能を検討しています。

この件について、エコシステムからのフィードバックをお待ちしています。
Terraform service_account_token_creator_list が設定されていない場合でも、Terraform がアカウントの IAM ポリシーの変更を試行する。 デベロッパーは、ローカルの modules/adtech_setup/main.tf ファイルに追加した権限を追加できます。
ドキュメントのリクエスト 集計サービスのヘルスをモニタリングする方法に関するドキュメントまたは Codelab をリクエストする。 サービスとジョブの健全性をモニタリングするために使用できる既存のアラームの説明については、coordinator-services-and-shared-libraries リポジトリの関連オペレータ Terraform ファイル（alarms.tf と monitoring.tf）をご覧ください。

集計サービス ジョブのモニタリング方法に関するドキュメントとガイダンスを追加で公開する予定です。
スケーリング スケーリングの問題をモニタリングする方法 集計サービスの大規模化に関するこちらのガイダンスの更新版を公開しました。

現在、マシンがジョブのスケールをサポートできないために障害が発生したことを示す直接的なシグナルはありません。間接的なシグナルには、失敗前にメモリ使用量が 90% に達する、ジョブが繰り返し失敗するなどがあります。このようなシグナルの必要性について、エコシステムから追加のフィードバックをお寄せください。
仕様 AgS レポート バッチの一般的な実行時間はどのくらいですか？ こちらのガイダンスを参照してください。

Private Aggregation API

フィードバック テーマ 概要 Chrome の対応
機能のリクエスト 2^16 の精度で contributeToHistogramOnEvent に浮動小数点値（負の値を含む）の貢献を許可するリクエスト 現在、この提案についてこちらで議論しており、皆様からのフィードバックをお待ちしております。

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

ユーザー エージェント文字列削減/ユーザー エージェント クライアントのヒント

今四半期にフィードバックはありませんでした。

IP 保護（旧 Gnatcatcher）

フィードバック テーマ 概要 Chrome の対応
位置情報 IP 保護の地理位置情報ファイルのリクエスト。 IP 保護のために IP を大まかなロケーションにマッピングするファイルは、こちらから入手できます。このファイルは定期的に更新されます。

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

フィードバック テーマ 概要 Chrome の対応
許可リスト 更新されたポリシーでは、Google の意思決定プロセスとは独立した許可リストや同様のメカニズムには対応していません。 Google は、バウンス トラッキング対策（BTM）に許可リストを関連付ける予定はありません。保護はすべてのドメインに均一に適用されます。
コンプライアンス ICO は、プライバシー関連のコンプライアンスに関する権限を持っている必要があります。 コンプライアンス ステータスは BTM の適用とは関係ありません。また、Google は BTM の実装におけるコンプライアンスに関する決定を下しません。
競合 Google は、BTM（またはその他の手段）を使用して PET の競合他社を締め出し、その後、競合他社を市場に復帰させるかどうかを裁量で判断できる可能性があります。現在の再審査請求プロセスでは、PET の競合他社が BTM などの手段を一時的に使用できなくなる可能性があります。 現在の BTM の提案は、技術として離脱トラッキングを対象としています。Google は、同様の手法が関与する特定のユースケースを損なうことを避けることを目的としていますが、BTM から個別に免除を提供する予定はありません。したがって、Google が競合他社の存在について裁量権を行使するという問題は生じません。

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

フィードバック テーマ 概要 Chrome の対応
（前四半期にも報告）

関連ウェブサイト セット（RWS）のドメイン数の上限		 現在の関連付け可能なドメインの上限は 5 つですが、クロスサイト測定のユースケースを実現するには十分ではありません。 回答は前四半期と同様です。

現時点では、数値の上限を引き上げる予定はありません。この上限は、ユーザーのプライバシーに関する考慮事項、W3C のエコシステム ステークホルダーからのフィードバック、他のブラウザの類似実装の検討に基づいて設定されました。
詳しくは、ブログ投稿（1、2）をご覧ください。

数値の上限を超えるクロスサイト Cookie アクセスを必要とするユースケースを検討し、ID のユースケース、認証済み埋め込み、広告のユースケースに関する Google のガイダンスを活用することをおすすめします。

この問題についてご意見がございましたら、こちらからお寄せください。

Fenced Frames API

フィードバック テーマ 概要 Chrome の対応
ネイティブ広告 フェンス付きフレームでのネイティブ広告のレンダリングは、iframe とパブリッシャーのページ間の通信に制限があるため、パブリッシャーのスタイルを継承することが制限されるという課題があります。 フェンスド フレームの適用後のサポートなど、ネイティブ広告のさらなるサポートについては、現在調査中です。

この問題についてご意見がございましたら、こちらからお寄せください。

Shared Storage API

フィードバック テーマ 概要 Chrome の対応
API 使用量 他のプライバシー サンドボックス API が機能している場合でも、一部のデバイスでは Shared Storage API を使用できません。 この動作は、共有ストレージのホールドバック テストの対象となる少数のユーザー（約 1%）に発生することが想定されます。この試験運用の設定は、さまざまなシナリオでの API のパフォーマンスと採用状況を評価するために使用されます。
API 使用量 共有ストレージへの書き込みは、パブリッシャーのオリジンで行われますか？それとも入札スクリプトのオリジンで行われますか？最初のテストでは、パブリッシャーのオリジンがスクリプトのオリジンと異なる場合、書き込みは行われませんでした。 この問題は解決済みです。デベロッパー ツールのバグが疑われる場合にのみ、引き続きオープンになります。詳しくは、こちらをご覧ください。

共有ストレージは、generateBid 呼び出しの入札コンテキストで購入者のオリジンに書き込みます。書き込みは、パブリッシャーのページが別のドメインにある場合でも、パブリッシャーのオリジンに関連付けられません。
API 使用量 不正な行為者が Shared Storage レポートを読み取れないための安全対策はありますか？ 共有ストレージはオリジンを呼び出してパーティショニングされるため、不正な行為者や広告テクノロジーが別の広告テクノロジーから共有ストレージ データを読み取ることはできません。非公開集計レポートは TLS 経由で同じオリジンに直接送信されるため、インターセプトされることはありません。

CHIPS

フィードバック テーマ 概要 Chrome の対応
パーティション化された Cookie Chrome と Firefox では、特に Partitioned 属性を使用している場合、異なる localhost ポート間で Cookie の処理が不一致になる。 Firefox では、異なるポートの localhost は別々のパーティション キーとして扱われます。この動作はセキュリティ原則に沿っていますが、仕様と Chrome のアプローチから外れています。

この件については、HTML 仕様の議論で他のブラウザと協議する予定です。CHIPS パーティション キーが変更された場合は、エコシステムに通知します。この問題についてご意見がございましたら、こちらからお知らせください。
パーティション化された Cookie Clear-Site-Data のドラフトでは、送信元サイトのパーティションを超えてデータを削除できると誤って規定されており、こちらで参照されている以前の議論と矛盾しています。 これは標準仕様ドキュメントのバグであり、まもなく修正する予定です。正しい動作は、説明のこのセクションで指定されています。また、ストレージ パーティショニングの説明リポジトリで他のブラウザと一致する動作になっています。Chrome の実装はすでに正しく動作しています。

FedCM

今四半期にフィードバックはありませんでした。

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

Private State Tokens API（および他の API）

今四半期にフィードバックはありませんでした。