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

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

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

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

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

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

現在のレポート期間の終了後に受信したフィードバックには、Chrome の回答がまだ考慮されていない場合があります。

CHIPS
Cookies Having Independent Partitioned State
DSP
デマンドサイド プラットフォーム
FedCM
Federated Credential Management
FPS
ファーストパーティ セット
IAB
Interactive Advertising Bureau
IDP
ID プロバイダ
IETF
インターネット技術特別調査委員会
IP
インターネット プロトコル アドレス
openRTB
リアルタイム ビッダー
延長
オリジン トライアル
PatCG
プライベート広告テクノロジー コミュニティ グループ
RP
証明書利用者
SSP
サプライサイド プラットフォーム
TEE
高信頼実行環境
UA
ユーザー エージェント文字列
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
IP の故意の無視

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

フィードバック テーマ 概要 Chrome のレスポンス
テストとトライアル テストの開始までにプライバシー サンドボックス API が完了していない場合、CMA の評価に伝えるテストの関連性 プライバシー サンドボックス API の開発は急速に進んでいます。これらの機能はすでにオリジン トライアルでテストされており、今年の夏にはトラフィックの 100% に対して一般提供される予定です。

また、2026 年より前に影響を受けない特定の機能（FLEDGE イベントレベル レポート、iframe を使用した FLEDGE レンダリングなど）のタイムラインを明確にしました。

エコシステムの皆様には、API をテストし、サードパーティ Cookie の廃止後にテスターが期待する機能に基づいて CMA にフィードバックを提供することをおすすめします。これにより、サードパーティ Cookie のサポート終了が及ぼす可能性のある影響を評価できます。
ユーザー コントロール プライバシー サンドボックス API のユーザー コントロールの影響に関するエコシステムへの明確なガイダンス エコシステムで使用できるユーザー管理機能について、Google から法的な助言を行うことはできません。同時に、Chrome ではプライバシー サンドボックス技術の改善に継続的に取り組んでいる一環として、ごく一部のユーザーに対して更新されたプライバシー サンドボックス（「広告のプライバシー強化」）のユーザー コントロールを表示するテストを実施しています。更新内容には、より明確で有用な表現とレイアウトが含まれています。Chrome がこれらの改良を評価し、より多くのユーザーに拡大するかどうかを決定したら、エコシステムと詳細情報を共有できます。
データ漏洩 ブラウザが不正使用された場合、ファースト パーティ データが Google やその他の関係者に漏洩するリスク Google の FLEDGE の説明では、1 つの広告テクノロジーのデータを、その広告テクノロジー（ワークレットまたは信頼できるサーバー）とのみ共有するか、その広告テクノロジーによって明示的に共有されることが明記されています（購入者が表示する広告の URL を販売者に示すなど）。唯一の例外は、k-匿名性チェックがグローバルな一元化されたサーバーによって行われなければならないことです。これは、Google が引き続き多くのリソースを投入している分野です。Google のプライバシーに関する考え方の詳細については、K-匿名性の説明をご覧ください。

それ以外にも、k-匿名性サーバー設計で採用されている広告テクノロジー保護の仕組みについて、詳しく説明させていただきます。
その他のディスカッション フォーラム 技術者以外のエコシステム プレーヤーがフィードバックを共有するための追加フォーラムを W3C にリクエストする プライバシー サンドボックスのフィードバック フォームは、一般的なコメントや具体的なコメント、技術的なコメントや技術的でないコメントに適しています。
「ウェブ広告ビジネスの改善」グループは、毎週の電話会議と GitHub リポジトリを介してディスカッションを行うフォーラムです。
プライバシー サンドボックスのフィードバック ページでは、フィードバックの提供やディスカッションへの参加に関するその他のメカニズムについて説明しています。また、Chrome では、質問やコンテンツの共有を促進するために、公開のオフィスアワーなどのイベントも引き続き開催しています。また、Chrome は過去四半期に 10 件を超える業界イベントを主催または参加しました。
タイムラインの明確化 2023 年第 3 四半期の一般提供の正確な日付について PrivacySandbox.com に公開されているタイムラインによると、一般提供は Chrome バージョン 115 のリリースとともに開始される予定です。
reCAPTCHA reCATPCHA のスパム検出のユースケースにおけるサンドボックス API の影響 Google は、プライバシー サンドボックスの提案がウェブの安全性や不正行為に大きな影響を与えないように、reCAPTCHA から定期的にフィードバックを得ています。サードパーティ Cookie のサポート終了に備えて独自の計画を策定しているため、この質問はパートナーに直接お問い合わせいただくことをおすすめします。
Chrome 拡張機能 プライバシー サンドボックス技術（アンチ シークレット トラッキング（ACT）対策など）は Chrome 拡張機能に適用されますか？ ACT が Chrome 拡張機能に適用されるかどうかについては、まだ発表していません。ただし、技術によってユーザーに関する情報が秘密裏に収集される場合、これは Google のプライバシー原則に準拠していません。

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

トピック

フィードバック テーマ 概要 Chrome のレスポンス
TAG 設計レビュー TAG は、Topics の初期設計レビューを公開しました。 Google は引き続き Topics に取り組んでおり、最新情報ページとこの号で最新情報をお知らせしています。YouTube は TAG の審査に対して点ごとに回答し、より上位のビジョンをこちらで共有しました。Topics API は、2023 年に広告エコシステムでテストする必要がある API のコレクションの一部として引き続き残ります。Google は、この分野のクロスブラウザ標準化に向けた今後の取り組みに、テストに関するフィードバックと実装者の経験が有益な貢献となることを願っています。Google は、Topics API がクロスブラウザ互換性のある合意済みの標準となる可能性のある移行を容易にする方法について、エコシステムと引き続き連携していく予定です。
トピックへのアプローチ Chrome が Topics API の開発に採用しているオープンなアプローチのサポート ご意見ありがとうございます。Google は、業界グループと連携して、エコシステム全体に価値をもたらす Topics API を開発していく予定です。
（2022 年第 3 四半期にも報告）
トピック分類の粒度が十分でない		 広範なトピック分類には、地域固有のトピックなど、より詳細なトピックは含まれません。 第 1 四半期の更新:

分類の改善は継続的に行われており、第 2 四半期に Topics API の更新された分類を発表する予定です。この新しい分類を作成するために、Google はエコシステム全体の企業と緊密に連携しました。
Google は、エコシステムにとって最も有用な分類について、積極的にフィードバックを求めています。トピックの数を増やすか、より詳細なトピックを含めるかを評価する際には、1）プライバシーへの影響（トピックの数を増やすとフィンガープリント リスクが生じる可能性があります）と 2）過去に観測されたトピックを取得する能力（トピックの数を増やすと、広告テクノロジーが過去に選択したトピックを検出する可能性が低くなるなど）など、いくつかの点を考慮する必要があります。
（2022 年第 4 四半期にも報告）
ファーストパーティ シグナルへの影響		 トピック シグナルは非常に価値が高いため、他のファーストパーティのインタレスト ベースのシグナルの価値が低下する可能性があります。 Google は、インタレスト ベース広告はウェブの重要なユースケースであると考えています。Topics は、そのユースケースをサポートするように設計されています。一部の大手パブリッシャーは、Topics がファーストパーティ データ戦略に悪影響を及ぼすのではないかと懸念しています。エコシステム テストでは、トピックがパブリッシャーに与える影響に関する分析情報を得ることができます。
広告以外のトピックのユースケース インタレスト ベースの広告の表示以外の目的で Topics を使用する Topics は、自由でオープンなウェブにとって重要なユースケースであるインタレスト ベース広告のユースケースに対応するように設計されています。現在、他のユースケースに関するフィードバックを募集し、評価を行っています。
デフォルトのオプトイン ステータス トピックの同意のデフォルト設定に対する地域の法律の影響 Google は、法律上の見解についてコメントする立場にありません。
（2022 年第 3 四半期にも報告）
カテゴリが間違っているサイト		 特定のサイトのトピックが誤って分類されている場合の広告ターゲティング 第 1 四半期の更新:
第 2 四半期に、Topics API の分類システムの更新を発表する予定です。この更新について、エコシステムの皆様と連携できることを楽しみにしています。
現在のフィードバックに応じて、サイトは、最も人気のあるサイトを含む人間がキュレートしたオーバーライド リストと、デバイス上の ML モデルを組み合わせて分類されます。Chrome では、トピックの分類にサイトが貢献するためのオプションを継続的に評価しています。ユーティリティの改善は、プライバシーと不正使用のリスクと比較検討する必要があります。たとえば、サイトが自己ラベル付けを方法として使用し、さまざまな（機密性の高い）意味をトピックにエンコードする、サイトが金銭的な利益のためにトピックを偽装する、サイトがトピックを攻撃して他のユーザーにとっての有用性を損なう（たとえば、ユーザーのトピックに意味のないノイズをスパムする）などのリスクがあります。一般ユーザーは、chrome://topics-internals またはこのコラボで利用可能なツールを使用して、これらのコンポーネントを検査できます。テストを重ねることで、分類の精度は徐々に向上していくと見込まれます。誤って分類されている可能性があるサイトの例について、フィードバックをお寄せください。
トピック分類器 デバッグ目的で「トピックなし」が呼び出し元に返された場合の理由を示す追加情報を返すリクエスト Google は、デベロッパーが Topics API をシステムに統合する際に、デバッグツールが役立つことを理解しており、その重要性を認識しています。ただし、追加情報（Topics が返されなかった理由など）を公開すると、意図した範囲を超えて、当事者が詳細情報（ユーザーがシークレット モードになっている、API が無効になっているなど）を把握できる情報の共有が意図せず行われ、ユーザーのプライバシーが侵害される可能性があります。現時点では追加のデバッグツールを提供する予定はありませんが、有用なツールについてフィードバックをお寄せください。
個人情報取得（PIR） Topics API で個人情報取得を採用するようリクエスト Google は以前に PIR の使用を調査し、トレードオフを共有しました。
入札ストリーム 入札ストリームで、Topics は Seller Defined Audiences とは別に表されますか？ Topics API は Chrome によって開発されたプライバシー サンドボックスの提案であり、IAB Tech Lab のSeller-Defined Audiences の提案とは異なります。これらの 2 つは入札ストリーム内で明確に区別される必要があります。OpenRTB 入札リクエストでトピックがどのように表されるかを確認する。

Protected Audience API（旧 FLEDGE）

フィードバック テーマ 概要 Chrome のレスポンス
FLEDGE 機能の提供状況 フェンスド フレームの適用、K-匿名性などの FLEDGE 機能のテストと実装のタイムラインを明確化しました。 さまざまなスコープの FLEDGE 機能と、それらがサポートされる時期について、ステータスを共有しています。FLEDGE の開発を進めるにあたり、このお知らせに関する追加のフィードバックをお寄せいただければ幸いです。
商品のレンダリングに関する制限 FLEDGE フェンス付きフレームにおける複数の要素で構成される広告の制限を緩和するようリクエスト 2 月に発表したとおり、フェンスド フレームの使用は 2026 年まで任意のままであり、iframe の動作は urn-iframe によってサポートされます。このトピックについて、さらにご意見をお寄せください。
スケーラビリティの問題 使用量の増加に伴う FLEDGE のパフォーマンス フィードバックに積極的にフォローアップし、より多くのコンテキストを把握して、実用的な解決策を提案できるよう取り組んでいます。最初のステップとして、フィードバックを次の 2 つのカテゴリに分類しました。
  1. SSP 主導のフィルタリングにより、a）SSP と b）DSP の両方で秒間クエリ数（QPS）の負荷を最適化します。
  2. DSP の QPS 負荷を最適化するためのインタレスト グループの DailyUpdate ロジック。
（2022 年第 3 四半期にも報告）
入札ロジックの公開設定		 DSP 入札ロジックが JavaScript で公開されるという懸念 1 四半期の更新:

攻撃者がサーバーから探索的（強制ブラウジング）な方法でデータをリクエストする能力を制限する提案を共有しました。エコシステムのプレーヤーの皆様から、この提案に対するフィードバックやサポートをお寄せいただければ幸いです。
テストの難しさ 小規模な DSP が FLEDGE を適切にテストし、広告主様が大規模な DSP でのテストのみに関心を持つリスクを軽減する能力 Google は小規模な DSP との連携に取り組んでおり、FLEDGE が一般提供に移行するにつれて、あらゆる規模の DSP と広告主様によるテストの拡大を強く推奨しています。エコシステム内の他社と FLEDGE をテストする際に、Google がどのようにサポートできるかについて、広告主様からのご意見をお聞かせください。また、小規模な DSP でテストするよう広告主様を促すアイデアや業界の取り組みについても、ぜひお知らせください。
動的リマーケティング サードパーティ Cookie のサポート終了後も、FLEDGE で動的リマーケティングは引き続き利用できますか？ Google では、この質問への回答を検討しています。また、動的リマーケティングの使用方法について、エコシステム プレーヤーから追加の分析情報を共有していただければ幸いです。
不正行為/不正使用 エコシステムは、リスクを軽減し、不正な行為者や購入者が望ましいオーディエンスとしてポジショニングするのを防ぐにはどうすればよいでしょうか。 Google は、不正行為や不正使用についてエコシステムのプレーヤーとさらに連携し、この分野に関するフィードバックを歓迎します。
ユーザー設定 ユーザー設定を保存して広告選択に使用するプロセス 特定の広告については、表示されるクリエイティブやその選択方法を管理するうえで、関連する広告テクノロジーが最適な位置にあります。
定量テストの提案 定量テストを公正に行うには、サードパーティ Cookie を使用しないトラフィックでテストを行うべきか、FLEDGE のみを使用する SSP でテストを行うべきか。サードパーティ Cookie からのシグナルの混在を回避するにはどうすればよいですか？ いただいたフィードバックに感謝いたします。Google は CMA と協力して、サードパーティ Cookie のサポート終了とプライバシー サンドボックスの提案がエコシステムに与える影響を信頼できる形で把握できるテストを設計しています。CMA の定量テストに関する提案について、追加のフィードバックがある場合は、CMA に直接共有することをおすすめします。
より明確なドキュメント オークション構成に関する明確なドキュメントをリクエストする 今後数週間以内に、FLEDGE オークション レポートの概要を追加したブログ投稿を公開する予定です。
並列化 入札とオークション（B&A）サービスは並列処理をサポートしますか？ 入札 / オークション サーバーを使用する広告テクノロジーは、結果を並行して配信できる複数のサーバーを起動できます。
不正行為の軽減 プライベート ステート トークンを使用する FLEDGE k-匿名性サーバーでユーザーのプライバシーを確保できますか？ k-匿名化の目的は、マイクロターゲティングではなく、FLEDGE でイベントレベル レポートが許可される暫定的なフェーズ中にバックアップを確保することです。詳しくは、追加のフィードバックをお待ちしております。
ES モジュールの競合 ES モジュールと競合するため、generateBid をグローバル関数として削除するようリクエスト このリクエストについて現在検討中です。ご意見やご感想をお寄せください。
コンポーネント オークション オークション設計をパブリッシャーがより細かく管理できるようにするリクエスト デバイス上の Chrome と同様に、コンポーネント オークションをサポートする入札とオークションのプラン。
B&A タイムライン B&A サーバーのテストに関心をお持ちの広告テクノロジー企業向けのタイムラインの明確化 B&A の説明を更新し、タイムライン セクションを更新して、CMA に合わせて、Chrome の B&A テストの各フェーズにおけるタイムラインの明確な定義を追加しました。
タイムアウト制御スキーム FLEDGE で現在利用可能なタイムアウト制御スキームの強化 これは興味深い提案です。ご提案は、調査対象の提案のキューに追加され、進展状況が報告されます。
クリエイティブのビッドリーム クリエイティブに基づいて落札した入札単価を確認、フィルタできる これは興味深い提案です。ご提案は、調査対象の提案のキューに追加され、進展状況が報告されます。
reportWin reportWin 関数で、落札者以外の異なるインタレスト グループ所有者の最高スコアの入札について追加情報を提供する提案 これは興味深い提案です。集計レポートに追加のシグナルを追加することを検討いたします。追加のフィードバックをお待ちしております。
イベントタイプ FLEDGE と統合する場合の測定 API 全体でのイベントタイプの標準化 これは興味深い提案です。ご提案は、調査対象の提案のキューに追加され、進展状況が報告されます。FLEDGE 以外の他のプライバシー サンドボックス API にも影響するため、この分野における Google の幅広い取り組みとの調整が必要になります。フィードバックをお寄せください。
イベントレベルのレポートの長期的なソリューション サードパーティ Cookie のサポート終了後も highestScoringOtherBid などの特定のデータを維持したいという関心 2 月の投稿で説明したとおり、イベントレベルのオークション落札レポートは「2026 年まで」サポートされます。現時点では詳細をお伝えできませんが、サードパーティ Cookie のサポート終了後も特定のデータを保持することが重要な理由について、追加のフィードバックをお寄せください。
インタレスト グループの上限 オリジンが 1 つのブラウザを追加できるインタレスト グループの数の上限はいくつですか？ Chrome では、オーナーごとに最大 1,000 個の興味 / 関心グループ、最大 1,000 個の興味 / 関心グループ オーナーを設定できます。これらは、通常の運用でヒットされるのではなく、ガードレールとして使用することを目的としています。
イベントレベルのシグナル generateBid と reportWin のイベントレベルのシグナルを取得し、機械学習のトレーニングで使用できるようにするプロポーザルのサポート ブラウザで設計されたシグナルと広告テクノロジー定義のシグナルに関する決定について、こちらで共有しています。ご意見をお寄せいただければ幸いです。
入札スクリプト 入札スクリプトの URL にユーザー ID を含めます。 FLEDGE には、広告を表示するには、インタレスト グループのオーナー、入札スクリプトの URL、レンダリングされたクリエイティブの組が k-匿名化されている必要があるという追加要件があるため、これはできません。
k-匿名性の適用 （componentAd、size）ペアに k-匿名性が適用されますか？ はい、対象になります。turtledove/issues/312 を参照してください。
入札およびオークション サービスの要件 B&A サービスは、デバイス上の FLEDGE と統合する参加者と、B&A サービスと統合する参加者をどのようにサポートしますか？ デザインは現在も最終調整中です。追加のフィードバックをお待ちしております。
ポストビュー アトリビューション ポストビュー アトリビューションはサポートされますか？ 現在のところ、視認性の標準定義はなく、クリエイティブ自体に依存して視聴イベントをマークしています。turtledove/issues/452 を参照してください。
類似ターゲティング プライバシー サンドボックスは「類似ユーザー ターゲティング」をサポートできますか？ ユースケースについてはこちらで議論しています。ご意見をお寄せください。
リアルタイム モニタリング API FLEDGE のリアルタイム モニタリング アプローチの提案 提案について現在検討中です。追加の意見をお待ちしております。
FLEDGE レポート 過剰報告や過小報告を防ぐため、reportWin と reportResult はランダムな順序で作成する必要があります。 reportResult() の販売者シグナルを reportWin() に含めるには、reportResult() を販売者が実行してから、購入者が reportWin() を実行する必要があります。詳しくは、説明をご覧ください。
カスタム Key-Value（K/V）サーバー カスタム K/V サーバーは今後サポートされますか？ この質問についてはこちらで議論しています。追加の意見をお待ちしております。
トップレベル オークション 最上位のオークション メカニズムを実行するには、広告サーバーである必要がありますか？ FLEDGE API では、API を呼び出す必要があるパーティションが指定されていません。FLEDGE の設計には、その意味での要件はありません。FLEDGE オークション（複数販売者オークションを含む）は誰でも実施できます。2022 年第 4 四半期レポートで説明したように、FLEDGE では、各パブリッシャーがオークションの構造（最上位販売者とコンポーネント販売者の選択など）を選択できます。
API の範囲 FLEDGE はファーストパーティ データと連携する予定ですか？ 2023 年第 2 四半期に、ファーストパーティ データが FLEDGE で実際に使用可能であり、1）興味 / 関心グループのメンバーシップを決定するロジックとして使用できること、2）その後の入札ロジックの生成で使用するためにユーザー入札シグナルとしてフィードできることを明確にするコンテンツを公開します。
クロスドメイン インタレスト グループ クロスドメインのインタレスト グループを作成できる ブラウザをインタレスト グループに追加するときに利用可能な情報はすべて、そのオーディエンスに通知するために使用できます。サードパーティ Cookie が段階的に廃止されると、インタレスト グループの作成に役立つクロスサイト データの利用が制限されます。
クライアントサイド入札ロジック 既存のサーバーサイド入札ロジックをクライアントサイドに移植する 移行プロセスで困難な点や現在不足している点について、詳しくお聞かせください。追加のフィードバックや分析情報もお待ちしております。
K/V サーバー値 K/V サーバー値は文字列型である必要がありますか？ 値は文字列である必要がありますが、オブジェクトを JSON またはプロトコル バッファに保存し、文字列にシリアル化できます。
広告主のブロックリスト 広告主のブロックリストを購入者に提供するのに適したシグナルはどれですか。 適切な場所は auctionSignals または perBuyerSignals です。
入札単位 CPI や CPM などのさまざまな入札単位のサポート 現在の設計ではこれが必要な理由について詳しくお聞かせください。また、その他のフィードバックもお寄せください。
オークション ロジック オークションの落札者はブラウザと広告サーバーどちらが決定しますか？ 落札者の選択はすべてサンドボックス内で実行され、すべての決定は販売者のコードによって行われます。ブラウザは、購入者と販売者のコードが実行されるシーリングされたプライベート環境を提供します。
権限に関するポリシー オリジン トライアルの終了後も、現在の FLEDGE Permissions-Policy は引き続き適用されますか？ オリジン トライアルでは、両方の機能の現在のデフォルトの許可リストは一時的なもので、変更されます。広告テクノロジーが変更の適用を開始するまでに、どのくらいの期間を準備に充てる必要があるかについて、ご意見をお聞かせください。
シグナルサイズの制約 信頼できる入札シグナル リクエストは、同じ trustedBiddingSignalsUrl を持つ複数のインタレスト グループ間で統合されます。サイズの上限は 2 MB です。 この制約は、デバイス上の呼び出し元がデバイス上のリソースを圧倒しないようにするために存在します。B&A サーバーからの呼び出し元にはより緩和された制約が適用されます。
レポート シグナル インタレスト グループ オーナーごと、computeBid または reportWin / reportResult ごとのクライアントサイド エラー数を取得できるように、シグナル「script-errors」を追加します。 Google は、この提案に関連するプライバシーに関する懸念事項を検討しており、この提案が必要な理由について、エコシステムのプレーヤーから追加の分析情報を共有していただきたいと考えています。
k-匿名性のウィンドウサイズ K-Anon のウィンドウ サイズを現在の 7 日間の上限から引き上げます。 現在、この件については検討中であり、エコシステムからの追加の意見を待っています。
デバイス単位の掲載結果 ユーザーが多数のインタレスト グループに属している場合、FLEDGE はデバイスのパフォーマンスをどのように処理しますか？ FLEDGE では、SSP と DSP 全体で複数のタイムアウト、優先順位付け、上限オプションが提供されています。これにより、デバイスが多数のインタレスト グループに属している場合に、デバイスのパフォーマンスがオークションへの参加を制限する理由となる可能性がある状況で、広告テクノロジーをきめ細かく制御できます。
B&A サービスのテスト デバッグに使用できるログを増やすため、テストフェーズ中にエコシステム プレーヤーに独自のサーバーを使用するようリクエストする B&A を使用すると、承認済みのクラウド プロバイダからサーバーを起動してスケーリングできます。ユーザーのプライバシーを維持するため、実行は高信頼実行環境（TEE）内で行われます。まもなく B&A TEE のデバッグに関する説明を公開し、それをサポートする機能を開発する予定です。このトピックについて追加のフィードバックを求めています。
規制要件 FLEDGE は、各国のクラウド プロバイダと連携して、現地の規制要件への準拠をサポートしますか？ 他のクラウド プロバイダの提案は常に受け付けていますが、現時点では、サードパーティ Cookie のサポート終了が適用された場合に、少なくとも GCP と AWS をサポートする予定です。詳しくは、こちらの説明をご覧ください。

デジタル広告の測定

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

フィードバック テーマ 概要 Chrome のレスポンス
騒音の影響に関するデータ分析 ノイズの影響に関するデータ分析を行う方法に関するガイダンス ノイズに関する追加のドキュメントと、ノイズと設計上の決定に関するドキュメントを共有しました。これらのドキュメントは、ノイズが広告テクノロジー データに与える影響を変更するために使用できます。

詳細なガイドもご利用いただけます。
null レポート null レポートの実装に関する明確化 現在、null レポートの実装に関する提案に取り組んでおり、近日中に詳細をお知らせいたします。null レポートを実装することで、プライバシーを損なうことなくレポートの遅延を短縮できます。
騒音レベル アトリビューション ウィンドウの長さに基づくノイズレベルの調整 Google は、この提案を歓迎し、仕様に追加することを検討しています。追加のフィードバックはこちらからお寄せください。
トリガーデータのサイズ トリガーデータのサイズが 3 ビットに制限されているのはなぜですか？ サイズは 3 ビット、8 個の個別値に制限されており、ユーザーに関するクロスサイト/コンテキスト情報の量が制限されています。イベントレベル レポートの現在のパラメータ設定が妥当かどうかについて、エコシステムのプレーヤーの皆様からフィードバックを送信していただければ幸いです。
イベントレベルのレポートのトリガー 重複除去キー内での優先順位付けの許可 YouTube では現在、この問題の解決策を検討しており、皆様からの追加のフィードバックをお待ちしております。
デバッグのサポート サードパーティ Cookie のサポート終了後のデバッグに関する明確化 サードパーティ Cookie のサポート終了後もデバッグをサポートできるよう、現在検討を進めています。フィードバックやアイデアをお待ちしております。
クリックスルー コンバージョンの代替手段 クリックスルー コンバージョンの代替手段に関する詳細なガイダンスをリクエストする コンバージョン測定のユースケースに適した、持続可能なプライベート測定システムとして、Attribution Reporting API を使用することをエコシステムに推奨します。他にも代替手段が存在するため、広告テクノロジー プロバイダは、プライバシーとユーティリティのニーズに基づいて適切なソリューションを決定する必要があります。
課金のユースケース アトリビューション レポートでコンバージョン ベースの課金のユースケースがサポートされる範囲を明確化 Google は、お支払いに関する Attribution Reporting API のスコープを明確にするために、公開情報の作成に取り組んでいます。Attribution Reporting API は、当初、CPA 課金を直接サポートするようにスコープ設定されていませんでした。CPC と CPM の課金（広告テクノロジーのほとんどが使用する課金構造）をサポートしています。
これは、エコシステムからのフィードバックが追加された場合に、今後サポートされる可能性があります。
ユースケースのサポート Measurement API のユースケースのドキュメント Google は、すべてのプライバシー サンドボックス レポート サーフェスのドキュメントを明確にするよう取り組んでいます。
クリックの品質 広告の意図的なクリックと意図しないクリックを区別するシグナルを追加するようリクエスト リクエストについて現在協議中です。ご意見やご提案をお待ちしております。
測定ソリューション 複数の DSP にまたがる測定ソリューションのサポート Attribution Reporting API は、測定プロバイダが複数の DSP 間で重複を除去するために使用できます。また、attributionsrc で URL のリストをサポートすることを提案しています。これにより、DSP は測定プロバイダの Attribution Reporting API リクエストを簡単にサポートできるようになります。上記の提案について、ご意見やご感想をお寄せください。
イベントレベルのレポート レポートが直接送信されるまでの日数をリクエストする このリクエストは、現在利用可能な情報を使用して広告テクノロジーですでに計算できます。このリクエストについて、エコシステムから他のフィードバックは寄せられていませんが、フィードバックをお寄せいただければ幸いです。
source_registration_time イベントレベルのアトリビューション レポートに source_registration_time を追加。 YouTube ではこのリクエストを検討しており、エコシステムのプレーヤーにとってこの機能が有用かどうかについて、追加のフィードバックをお待ちしております。
シークレット モード ユーザーがシークレット モードでブラウジングしている場合、測定ソリューションは使用できますか？ いいえ。ユーザーがシークレット モードの場合、測定ソリューションは使用できません。シークレット モードでは、サードパーティ Cookie はデフォルトでオフになっています。
データ クリーンルーム Measurement API はクリーンルームで使用できますか？ 一般的なデータ クリーンルームは、さまざまなソースの個別の ID データをデータベースにアップロードし、その基盤となるデータを統合して分析を実行する環境です。プライバシー サンドボックス API の 2 つの測定フレームワークは、イベントレベル レポートと概要レポートです。イベントレベル レポートには、データ クリーンルームで使用できる広告テクノロジー提供のイベント ID が含まれていますが、関連付けられたコンバージョン側の情報は限定的でノイズが多いため、暗号化された集計可能レポートはクリーンルームで直接使用することはできませんが、集計サービスによって提供される概要結果は、実行する分析への入力として、または補足情報として使用できます。

集計サービス

フィードバック テーマ 概要 Chrome のレスポンス
（2022 年第 4 四半期にも報告あり）
レポートの遅延		 レポートの遅延はどのくらいですか？ 2023 年第 1 四半期の更新:

パートナーからのフィードバックに基づき、遅延を短縮 し、遅延の影響を軽減するための提案を共有しました。

どちらのプロポーザルも、WICG コールで広告テクノロジーがサポートしています。
重複なしルール 同じ共有 ID を持つ集計可能なレポートがすでに処理されている場合、「集計可能なレポートの遅延」をどのように処理しますか？ 集計 API に対する遅延損失の影響を部分的に解決するため、集計可能なレポートの共有情報に追加のレポート遅延を追加し、集計サービスの共有 ID を定義する提案を共有しました。この提案について、フィードバックをお寄せください。
データ処理 プライバシー バジェットを使用して、差分プライバシーを尊重しながら複数回のデータパスのサポートを有効にするためのリクエスト Google では、このユースケースを実現するために、プライバシー バジェットをより柔軟に使用できる方法の可能性を検討しています。フィードバックをお寄せください。
（2022 年第 2 四半期にも報告）クエリの使い勝手 キーの集計クエリを有効にする。 2023 年第 1 四半期の更新:

この機能リクエストは現在検討中ですが、現時点では提案できる内容はありません。
オリジン トライアルの制限事項 集計サービスのスコープを明確にします（現在、オリジン トライアルでは適用されていない「重複なしルール」など）。 一般提供版とオリジン トライアル版で利用できる機能について明確にするため、ドキュメントの更新を検討しています。

Private Aggregation API

フィードバック テーマ 概要 Chrome のレスポンス
Private Aggregation の予算に対する割合 L1 の拠出予算が制限的すぎる。 Private Aggregation API への呼び出しは、コントリビューションと呼ばれます。ユーザーのプライバシーを保護するため、個人から収集できる寄付の数が制限されています。
すべての集計キーのすべての集計可能な値を合計した値が、貢献度予算を下回っている必要があります。

現在の設計では、特定の報告元からの過去 24 時間（ローリング ウィンドウとして）の貢献度に上限が設定されています。これは、フィードバックに記載されている L1 拠出金の予算です。デベロッパーは、想定されるボリュームに基づいて貢献する値をスケーリングすることをおすすめします（値を 1 に設定するだけではありません）。そのため、予算を使い切らないように、一般的なイベントには小さい値を使用することをおすすめします。

現在、Private Aggregation API のコントリビューション バジェット（数値の上限とスコープの両方）についてフィードバックを募集しています。スコープをオリジンごとからサイトごとへの移行と、既存の上限を 10 分間のウィンドウに移行し、1 日あたりの上限を拡大することを検討しています。

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

User-Agent の情報量削減/User-Agent Client-Hints

フィードバック テーマ 概要 Chrome のレスポンス
UA-R の導入 英国のトップ 10,000 サイトのうち、プログラマティック広告を使用しているサイトの 1% のみが HTTP クライアント ヒントを送信しています。移行していない DSP は、不正行為防止機能に影響する可能性があります。 同じデータセットで分析を行った結果、HTML <meta> タグと JavaScript API を使用した UA-CH の使用状況を考慮すると、UA-CH を使用しているサイトの数は、フィードバックに記載されている 1% という数字よりもはるかに多いことがわかりました。この点と、エコシステムからのフィードバックなどのその他の事実に基づき、Google は CMA に通知しながら、公開されたタイムラインに沿って UA の段階的な廃止のフェーズ 6 を進めることを決定いたしました。なお、サイトには移行の準備期間として 2 年近くの猶予が設けられており、準備が整っていないサイトについては、非推奨化トライアルを引き続きご利用いただけます。
その他のフォーム ファクタに関するヒント UA-CH にテレビや VR などの追加のフォーム ファクタを提供するようリクエストする Google は、この提案を歓迎し、設計に組み込むことを検討しています。追加のフィードバックをお待ちしております。
自動テスト UAR フェーズ 6 のリリース前にヘッドレス Chrome の UA-CH バグを解決するようリクエスト 該当のバグは修正されました。
iOS での UA-CH のサポート 広告のユースケースで UA の詳細な情報に依存しているサイトでは、iOS 版 Chrome はサポートされていないことを明記しています。 Safari 以外の iOS ブラウザ（iOS 版 Chrome を含む）では、ネットワーク スタックを制御するため、UA-CH を有効にするには WebKit プロジェクトに UA-CH のサポートを追加する必要があります。

IP 保護（旧 Gnatcatcher）

フィードバック テーマ 概要 Chrome のレスポンス
（第 4 四半期にも報告）位置情報のユースケース IP 保護により、位置情報に基づくコンテンツのパーソナライズなど、正当な位置情報のユースケースが今後機能しなくなる可能性があります。 回答は 2022 年第 4 四半期から変わっていません。

「Google は、IP アドレスの正当なユースケースを Chrome で引き続きサポートできるよう、関係者と連携して取り組んでいます。IP 位置情報の粒度に関するエコシステムからのフィードバックをお待ちしております。」
規制コンプライアンス 地域の人口が 100 万人未満の場合、IP 保護の現在のしきい値である 100 万人では、ウェブサイトが規制遵守のために IP アドレスを使用できなくなります。 Google は、IP アドレスの正当なユースケースを Chrome で引き続きサポートできるよう、関係者と連携して取り組んでいます。Google は、知的財産保護に関する規制遵守について、エコシステムからのフィードバックを求めています。
不正行為の軽減 当事者は、マスクされていない IP アドレスを他のユーザーと共有することで、IP 保護を回避できます。 Google は、現在の IP 保護の提案では、技術的に、マスクされていない IP アドレスが他者と共有されなくなるわけではないというリスクを認識しています。Google は、この不正使用のリスクを回避する緩和策に取り組んでいます。

提案を繰り返す際には、フィードバックや議論をさらに深めていただくことをおすすめします。具体的には、マスクされていない IP アドレスを他のパーティと共有する必要があると考えられるユースケースを教えてください。
ネットワークのブロック 当事者は IP 保護プロキシを使用してネットワーク ブロックを回避できます。 このシナリオでは、ブロックを実行するエンティティが IP 保護を無効にする必要があります。問題への対応が完了しました。ご意見やご感想をお寄せください。
IP 保護プロポーザルの影響を受ける IP アドレスのブロックリスト 多くの広告テクノロジー企業は、TAG データセンターの IP リストなどの IP アドレスの基本的なブロックリストを使用して、不正行為（または少なくとも収益化できない）の可能性が高い広告枠に入札しないようにしています。広告テクノロジーがトラッカーでもあり、IP 保護に関する提案の対象となる場合、その企業は広告枠を購入する前に広告に関する基本的なチェックを行うことができなくなる可能性があります。 潜在的な問題と解決策について、IP 保護に関する提案についてフィードバックを送信して、議論に参加してください。1 つの方法は、以前にフラグが立てられた IP アドレスから送信されたクライアントをプロキシしないように、同様のリストを IP 保護に適用することです。

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

ファーストパーティ セット

フィードバック テーマ 概要 Chrome のレスポンス
（第 4 四半期にも報告）ドメインの上限 関連付けられたドメイン数の増加をリクエストする 回答は 2022 年第 4 四半期から変わっていません。

「Chrome は、ユーザーのプライバシー保護にも配慮した実用的なソリューションを提供することに取り組んでいることを、WICG のコールにおいて明確にしました。そのため、ドメイン数の上限の影響を受ける可能性がある特定のユースケースについて、コミュニティからフィードバックをお寄せいただければ幸いです。これにより、ユーザーのプライバシーを保護しながら、こうしたユースケースに対応する方法を検討できます。」
代替の FPS の送信 FPS のグローバル リストを送信する代替方法の提案 現在、Google は Chrome でファーストパーティ セット（FPS）をリリースする準備を進めており、セットの送信を受け付ける一元化された GitHub リポジトリを設定しています。サードパーティ Cookie のサポート終了に備えて、FPS が既存のウェブ プラットフォーム ソリューションのギャップを埋めることを期待しているため、サイト作成者が FPS をどのように活用しているかを学ぶことを期待しています。セットのリストが時間とともに増え、エコシステムがサードパーティ Cookie のない世界に適応するにつれて、提案されているような分散型スキームなどの代替スキームを検討できるレベルまでプロセスを成熟させることもできます。現在のプロセスでは、設定された有効期間を導入し、時間の経過とともに登録プロセスを進化させていく予定です。送信プロセスが成熟したら、このアイデアを再検討します。
リポジトリのモデレーション 不正使用を防ぐため、FPS 送信リポジトリのコミュニティ モデレーションを適用します。不正な行為者は、バーナーのオリジンを使用してセットを提案するプロセスを簡単に圧倒できます。また、膨大な数のリクエストが、本物のセット提案のオペレーションに影響する可能性があります。 YouTube は、技術的な検証チェックに基づいて、チェックをできるだけ客観的なものになるようにしています。これは、送信プロセスに対する最もスケーラブルなアプローチであると考えています。この目標に沿って、スパムやバーナーの送信に対してプロセスが耐障害性を持つようにすることも目指しています。
関連するサブセット FPS は、関連するサブセットを介してサードパーティ ベンダー/SaaS フロー ユースケースをサポートできますか？ サードパーティ ベンダー / SaaS フローは今のところ、ファースト パーティ セットの対象となるユースケースではありません。これらのユースケースでクロスサイト クッキーがどのように使用されているかについて、追加のフィードバックをお寄せください。
FPS + CHIPS の統合 A/B テストなどのユースケースをサポートするために FPS + CHIPS の統合をリクエストする Google ではこのユースケースについて検討しており、WICG の電話会議でさらに議論することも検討しています。追加の意見はこちらからお寄せください。
GDPR GDPR のコンセプトに基づいてモデル化される新しい FPS サブセットの提案 Google では、この提案について社内で議論し、Google がプライバシーに関する目標として掲げている内容や、Google がこれまでに受け取った他のフィードバックと照らし合わせて検討しました。その結果、現時点ではこの提案を進めない理由を説明する回答を用意しました。
メモリ FPS リストが組み込まれた場合のブラウザのメモリサイズの予想される変化 Disconnect Tracking Protection List など、メモリへの影響を最小限に抑えながらこのようなリストをブラウザが保存する前例があります。First-party Sets リストは各 Chrome クライアントにローカルでコピーされますが、Google はファイルサイズを継続的にモニタリングし、メモリ フットプリントを最適化できると確信しています。

Fenced Frames API

フィードバック テーマ 概要 Chrome のレスポンス
フェンス付きフレームの制限事項 Fenced Frames による制限事項を明確化 3 月に、フェンスド フレームに関する説明を更新し、その機能に関する情報を提供しました。追加のフィードバックをお待ちしております。
アクセス情報を展開する 隣接するフレームに関する情報へのアクセス権を拡張するリクエスト Google は、この要件がエコシステムにとって必要である理由をさらに理解したいと考えています。追加のフィードバックをお待ちしております。
フェンス付きフレームと iframe フェンスド フレームと iframe の機能の同等性に関する質問 利用可能なすべてのプライバシー サンドボックス API とレポートは、iframe と FencedFrames で同じように使用できます。
フェンス付きフレームのサイズ変更 フレームサイズの変更を制限すると、特定のユースケースに影響します。 制限の影響を受けるユースケースの種類について詳しくお聞かせください。追加のフィードバックをお待ちしております。

Shared Storage API

フィードバック テーマ 概要 Chrome のレスポンス
サードパーティのワークレット サードパーティは、オリジン別にパーティショニングされた共有ストレージに書き込むことができますか？または、第三者測定用の他のワークレットを呼び出すか？ コードが実行されているブラウジング コンテキストのオリジンによって、そのデータが書き込まれる共有ストレージが決まります。サードパーティ コードをページに追加する場合、サードパーティ コードは独自のブラウジング コンテキストを持つ iframe として埋め込むことができます。これにより、サードパーティ コードは独自のオリジンに書き込むことができます。サードパーティ コードは iframe ではなくスクリプトとして埋め込むこともできます。この場合、ブラウジング コンテキストは切り替わらず、サードパーティは埋め込み元の共有ストレージに書き込むことができます。共有ストレージから読み取ることができるのは、その共有ストレージのオーナーのみです。
重複除去 Chrome エコシステム外のインタラクションでは重複除去は行えません。 共有ストレージは、Chrome ブラウザベースの独自のリーチ出力を Chrome 内で提供することを目的としています。Google は、広告テクノロジーと連携して、これらの出力を幅広いリーチ モデルの一部としてどのように使用できるかを把握したいと考えています。出力自体がインタラクションの一部しか説明できない可能性があることを認識しており、広告テクノロジーと連携して、重ねて適用できる追加のモデリング手法を検討したいと考えています。
コンバージョンのルックバック ウィンドウ コンバージョン率のルックバック ウィンドウをリクエストして、コンバージョン数の推移を確認する これは、共有ストレージを使用してクライアントサイドでさまざまなコンバージョン パスを処理することで実装できます。これにより、分割されていない安全なブラウザ ストレージよりも高度な分析の柔軟性が向上します。
アイテムの有効期限 有効期限を 90 日に延長するリクエスト データ保持ポリシーは 2022 年 11 月に更新され、各キーは最後の書き込みから 30 日後に消去されることが明記されています。新しいポリシーがエコシステムに適しているかどうかを把握するため、追加のフィードバックをお待ちしております。
クリエイティブのローテーション クリエイティブのローテーションのユースケースは、オークション後の実際のアクションを反映していません。 クリエイティブのローテーションに関するドキュメントの正確性について、購入側の広告テクノロジー企業からのご意見をお待ちしております。

CHIPs

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

FedCM

フィードバック テーマ 概要 Chrome のレスポンス
ID アサーション エンドポイント ID アサーション エンドポイントへの任意のリクエストを明示的に許可します。 Google は、ユーザーに煩わしさを与えることなく、ウェブサイトがクロスオリジンの認証情報リクエストをサイレントで行う機能を制限するこのプルリクエストについて、Mozilla と連携してきました。今後も、他のフィードバックについても審査し、対応していきます。
ID の事前入力 FedCM を使用して、FedCM リストの ID プロバイダをログイン フォームに事前入力できますか？ このユースケースで懸念されるのは、ユーザーとやり取りしていないサイトが、ユーザーが最後に使用した IDP をクエリできる場合に、情報が漏洩する可能性があることです。この問題について現在協議中です。ご意見をお寄せください。
コンテキストに基づくアカウントの選択 アカウント選択 UI にコンテキスト シグナルを追加する提案 Google ではこの提案を検討しており、さらなる議論を歓迎しています。

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

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

フィードバック テーマ 概要 Chrome のレスポンス
機能収集アンケート さまざまな不正行為対策のユースケースに必要な機能に関するアンケート結果の収集を第 1 四半期の初めに完了し、一般公開しました（分、 結果） Google は、不正行為防止機能向けの専用でプライバシー保護 API の新しい提案とプロトタイプを開発する際に、このフィードバックを組み込む予定です。十分なニーズがあり、ユーザーのプライバシーを保護しながら、ウェブにこの機能を導入するために構築できる既存の技術がある場合は、開発を優先する予定です。たとえば、デバイスとブートの完全性は高い評価を受けており、多くのプラットフォームには、デバイスの完全性の評価を安全に共有する既存の API が存在するため、コミュニティ グループ内で調査を進めるのに適しています。
PST 発送通知のフィードバック リリースに向けて、古いバージョンのプライバシー パスを使用していることが懸念されています。また、仕様の一部のセクションが不明確であり、ブラウザの互換性を促進するために改善すべきであるというフィードバックも寄せられました。 一般提供にリリースする前に、提案された仕様の変更の多くと、いくつかの API の変更を実装する予定です。このフィードバックは第 1 四半期の終わりに寄せられたため、github の問題についてフォローアップし、具体的な詳細とリリース計画の最新情報をお知らせします（このフィードバック レポートの公開時点では進行中です）。

API の大きな変更については、検討の余地がありますが、一般提供に向けてリリースを進め、より多くのデベロッパーから実践的なフィードバックを得ることが最善の方法であると考えています。Google は、この議論を継続し、ブラウザの標準化を推進したいと考えています。新しい標準が登場した場合、Google はそれを慎重に移行するための計画を策定することを検討します。