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

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

2022 年第 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、Fledge、Attribution Reporting API に関する質問とフィードバックが寄せられました。

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

頭字語の用語集

チップ: 独立したパーティション状態を持つ Cookie
DSP: デマンドサイドプラットフォーム
FedCM: Federated Credential Management
FPS: ファーストパーティセット
IAB: Interactive Advertising Bureau
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 レスポンス
（第 3 四半期にも報告）さまざまなタイプの関係者にとっての有用性	プライバシーサンドボックステクノロジーは大規模なデベロッパーに好まれ、ニッチな（小規模な）サイトが一般的な（大規模な）サイトよりも貢献するのではないかという懸念	第 3 四半期の回答に変更はありません。「Google は、自社のビジネスを自己評価することで競争をゆがめない方法でプライバシーサンドボックスの提案を設計、実装し、規模に関係なく、デジタル広告やパブリッシャーや広告主への影響を考慮に入れて、プライバシーサンドボックスの提案を設計、実装することを CMA に約束しました。Google は引き続き CMA と緊密に連携し、Google の取り組みがこれらのコミットメントを遵守するようにしています。プライバシーサンドボックスのテストが進むにつれ、さまざまな関係者に対して新しいテクノロジーがどのように機能するかという重要な課題を評価することになります。この点においてフィードバックは非常に重要です。特に、技術設計のさらなる改善に役立つ具体的かつ実用的なフィードバックは重要です。 Google は CMA と協力して定量テストのアプローチを開発してきました。市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供するため、CMA によるテスト設計に関する注記の発表を支援しています。」
（第 3 四半期にも報告）ドキュメントのリクエスト	テスト、分析、実装の管理方法を詳しく説明したリソースのリクエスト	第 4 四半期の更新: Google Play が現在提供しているマテリアルがユーザーの参考になれば幸いです。新しいテクノロジーがどのように役立つかをデベロッパーが理解できるように、今後もより多くのマテリアルを提供できるよう、引き続き取り組んでまいります。前四半期に privacysandbox.com に「ニュースと最新情報」セクションを追加し、プライバシーサンドボックスが今後の広告の関連性の向上にどのように役立つかについて広範なレビューを公開しました。また、ベストプラクティスやデモを共有する公開デベロッパーオフィスアワーセッションや、プロダクト/エンジニアリングリードとの Q&A セッションを実施し、ライブディスカッションや質問のためのセッションを開催しました。
Core Web Vitals	プライバシーサンドボックス API のレイテンシはウェブに関する主な指標にどのように影響しますか？	レイテンシを最小限に抑えることは、プライバシーサンドボックス API の主な設計目標です。API の大部分はウェブサイトの最初のレンダリング後に呼び出されるため、現時点では API のレイテンシがサイトの Core Web Vitals に及ぼす影響は最小限になるものと予想されています。Google は各 API のレイテンシをさらに低減するためにモニタリングと改善を続けており、継続的なテストとフィードバックを推奨しています。リアルタイムビッダープロセスでのレイテンシについては、「FLEDGE オークションのパフォーマンス」の FLEDGE のセクションをご覧ください。
相互運用性	他のソリューション候補との相互運用性に関する懸念	プライバシーサンドボックスの目標は、ウェブエコシステムのニーズに応えつつ、クロスサイトトラッキングからユーザーを保護することです。Google では、このようなクロスサイトトラッキングを可能にする従来のブラウザテクノロジー（サードパーティ Cookie など）から脱却し、特定のユースケースをサポートすることを目的とした新しいテクノロジーを代わりに提供することで、この目標を達成したいと考えています。プライバシーサンドボックスの提案は、ユーザーのデバイスから送信されるデータを制限することでプライバシーを強化します。この提案では、ウェブサイトから収集されたデータを共有または処理するウェブサイトの機能に技術的な制限は課しません。そのため、このテクノロジーによって、企業が「データスチュワードシップ」契約またはその他の類似の契約関係を結ぶことを妨げることはありません。同様に、ユーザーが他の手段でのデータの共有に同意する制限も制限されていません。なお、Google では、Google のプロダクトやサービスを含むすべてのウェブサイトに同じようにプライバシーサンドボックス技術を適用することを約束しています。Chrome でサードパーティ Cookie のサポートが終了した後は、Google がデジタル広告のターゲティングや測定を目的としてその他の個人データ（ユーザーの同期済みの Chrome 閲覧履歴など）を使用してユーザーをトラッキングしないことも明言されています。

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

トピック

フィードバックテーマ	まとめ	Chrome レスポンス
Google 検索のランキングへの影響	ウェブサイトの Topics API サポートが Google 検索の検索結果ランキングに影響する可能性があるかどうかについてのお問い合わせ	一部のウェブサイトでは、Topics API をオプトアウトする場合があります。検索組織に対して、プライバシーサンドボックスチームは、ウェブサイトの Topics API 導入のインセンティブとしてページランキングを使用することを、調整や要求はしていません。Google は CMA に対し、Topics API をオプトアウトするサイトの決定を Google 検索がランキングシグナルとして使用しないことを確認しています。
Topics 分類器	ホスト名の他に、URL やページコンテンツを追加してウェブページのトピックを判断し、さまざまな関係者にとっての有用性を高めます。	現在、ユーザーの閲覧履歴はウェブサイトのホスト名によって分類されています。Chrome では、トピック分類でページ単位のメタデータ（ページの URL やコンテンツのすべてまたは一部のコンポーネントなど）を考慮するためのオプションを引き続き評価しています。ユーティリティを改善する場合は、プライバシーや不正使用のリスクを比較検討する必要があります。特にメタデータに関しては、次のようなリスクがあります。 - さまざまな（そして機密情報になり得る）意味をトピックにエンコードするために、ページレベルのメタデータを変更するサイト - 金銭的利益を得るために、ページレベルのメタデータを偽装してトピックを偽装するサイト - クロスサイトトラッキングの手段としてページレベルのメタデータを動的に変更するサイト
（第 3 四半期にもレポートされます）自社シグナルへの影響	Topics シグナルは価値が高い場合があり、その結果、他のファーストパーティのインタレストベースシグナルの価値が下がります。	第 3 四半期の回答に変更はありません。「インタレストベース広告はウェブにとって重要なユースケースであり、Topics はそのユースケースをサポートするよう設計されています。[第 3 四半期のレポート] で述べたとおり、他のエコシステムの関係者からは、Topics が価値を提供するのに十分役に立たないという懸念が寄せられています。いずれの場合も、分類法の改善は継続的な取り組みであり、エコシステムのテストとインプットとともに、分類法も進化することが期待されています。」
分類の更新	分類リストはどのように更新されますか？	エコシステムにとって最も有益な分類について、フィードバックをお待ちしています。最初の Topics API 提案に含まれる分類は、機能テストを可能にするように設計されています。Chrome では、分類を更新するための複数のアプローチを積極的に検討しています。たとえば、Chrome では、今後のイテレーションに含めるカテゴリを決定するために、トピックごとに商業的価値の概念を利用する場合があります。
Topics 地域分類器のパフォーマンス	地域のドメインでの Topics 分類器のパフォーマンスが低い	分類器の改善は継続的な取り組みを行っております。寄せられたフィードバックに基づき、検討中の 1 つの可能性として、Topics のオーバーライドリストを拡大することが検討されています。これにより、Google の分析によると、グローバルカバレッジと精度が向上することがわかっています。 Topics API の分類には、関連する 2 つのコンポーネントがあります。（1）上位 1 万のサイトとそのトピックを含むオーバーライドリストと、（2）ホスト名をトピックに分類するデバイス上の ML モデルです。オーバーライドリスト（1）を展開すると、分類器のパフォーマンスが低い可能性のある地域の分類のパフォーマンスを向上させることができます。
1 週間のエポック	ユーザーが短期間の意思決定を行うためには、1 週間のエポックは長すぎます。	Google は、適切なエポックの長さについて積極的に検討しています。エコシステムにとってより良いエポックについては、さらなるフィードバックをお待ちしています。
HTTP ヘッダーの取得	トピックの HTTP ヘッダーの取得に関する十分な情報がない懸念	ヘッダーと fetch() は現在進行中です。詳細については、こちらをご覧ください。また、説明に SkipObservation の情報を追加しました。
Topics は広告主様を支援することのみを目的としており、ユーザーを支援するものではありません	トピック/プライバシーサンドボックスは、業界に特化したアプローチのようです。ユーザーにとってのメリットは、業界にとってのメリットよりも明確ではありません。	Google では、Topics が自由でオープンなウェブを維持するインタレストベース広告に対応していることに加え、サードパーティ Cookie と比べてプライバシーが大幅に向上していることが Topics のメリットであると考えています。有効な代替手段がない状態でサードパーティ Cookie を削除すると、パブリッシャーに悪影響を及ぼし、プライバシー、透明性、ユーザーが実際にリセットまたはコントロールできない手法に悪影響を及ぼしかねません。多くの企業が Topics API と Sandbox API を積極的にテストしており、Google はプライバシー保護の強化とウェブの支援のためのツールの提供に取り組んでいます。先ごろ、W3C Technical Architecture Group から Topics API に関する初期ビューが公開され、これに回答する予定です。現段階では、この審査の内容が Topics API の開発とリリースにとって意味する可能性がある内容について、エコシステムから質問が寄せられているため、今年は Chrome Stable でリリースする計画を再確認いたします。Google は、W3C Technical Architecture Group からのご意見を高く評価していますが、CMA およびエコシステムと協議しながら Topics の開発とテストを続ける取り組みがきわめて重要であると考えています。
データ漏洩	Topics が許可なく他のサイトに漏洩することへの懸念	Topics API の設計上、1 社のパブリッシャー（さらに少数のパブリッシャーのグループであっても）のデータは、いかなる方法でも漏洩する可能性はほぼありません。パブリッシャー様のウェブサイトも Topics API を完全に制御でき、権限ポリシーを介してこの API へのアクセスを禁止できます。
テスト用の広告主がいない	パブリッシャー様は、現状では広告主に Topics の価値を実証できないことを懸念しています。	2023 年後半には、広告関連のすべての API を統合テストに利用できるようにし、広告主にとっての Topics の価値のエコシステム分析を可能にする予定です。結果のテストと公開は、データ、分析、手法をレビューする CMA が監督します。エコシステムは Google および CMA とフィードバックを共有することが推奨されています。
Topics と FLEDGE	FLEDGE の入札ロジック内で Topics を使用する方法に関するリクエスト	Topics は FLEDGE の入札ロジック内で使用可能です。統合ガイドも作成中であり、実装に関する追加情報を記載する予定です。
トピックの呼び出し元のカスタムランキング	呼び出し元によってランキングを調整できるようにする	広告テクノロジーごとのカスタムトピックランキングや値に関する課題は、これが、返されるトピック、つまりフィンガープリントベクトルに影響を与える可能性があるメカニズムになる可能性があることです。
トピックの発信者優先度リスト	呼び出し元が、Topics API が適格性に基づいて返すトピックの優先順位リストを提供できるようにします。	現在、このアイデアについてさらに検討しており、追加のご意見をお待ちしています。

FLEDGE

フィードバックテーマ	まとめ	Chrome レスポンス
Google アドマネージャー	Google アドマネージャーが FLEDGE オークションの最終決定者となり、Google パブリッシャータグと Google アドマネージャーを優先することへの懸念。	FLEDGE では、各パブリッシャーがトップレベルの販売者とコンポーネント販売者の選択を含む、オークションの構造を選択できます。コンポーネントオークションの各購入者と販売者は、トップレベルの販売者が誰であるかを把握し、入札するかどうかを選択できます。
FLEDGE のテスト参加者が不足しています	より多くの企業に FLEDGE のテストを促すようリクエストする（API の機能を改善し、プライバシーを侵害するフィンガープリントのような代替手段を使わないようにするなど）	プライバシーサンドボックスは、CMA と ICO のガイダンスと緊密に連携しながら段階的に進めており、FLEDGE の機能テストにより、必要な安定性と機能が実証されています。Google はエコシステムに対するサンドボックス API のテストを引き続き奨励しており、最近「Maximize Ad Relevance」ドキュメントを公開し、サードパーティ Cookie の廃止後の広告業界の重要なユースケースにおいて FLEDGE とその他の API がどのように役立つかを紹介しました。プライバシーサンドボックスの他の部分では、トラッキングをカバーする緩和策（UA-CH、IP 保護、バウンストラッキング対策を参照）をすでにサポートしており、今後も改善が続けられます。Google の目標は、FLEDGE を唯一の有効なターゲティングソリューションにすることではありません。業界や規制機関と協力して、Chrome ブラウザにおけるプライバシー保護に最適な広告技術の開発に取り組んでいきます。
機械学習のユースケース	機械学習のユースケースでオークション入札アルゴリズムをトレーニングする方法に関する詳細なガイダンスが FLEDGE と Attribution Reporting でサポートされるようになります	Google は、テスターがプライバシーサンドボックス技術を最も効果的に適用する方法を見つけられるよう支援する必要性を認識しています。機械学習へのインプットとしてのプライバシーサンドボックス API のさまざまな要素の使用に特化したガイダンスの公開を開始しました。最新の記事「Maximize Ad Relevance」では、広告業界がこれらのシグナルを機械学習に活用する方法について解説しており、Google は今後もそうしたガイダンスを公開していく予定です。
FLEDGE Key-Value（K/V）サーバーのクエリ	K/V サーバーが一般公開クエリ可能なのはなぜですか？	K/V サーバーは、FLEDGE オークションにリアルタイムのシグナルを提供することを目的としています。そのため、K/V サーバーは、FLEDGE オークションが実行される場所からアクセス可能である必要があります。つまり、ユーザーのデバイス上であり、一般公開されている必要があります。K/V サーバーに保存されている値は、すでにキーを持っている当事者のみが取得できます。そのため、広告テクノロジーがインタレストグループ内のブラウザにキーのみを与え、ランダムに推測できるキーを使用しない場合は、オークションを実施するために値を必要とするブラウザのみがキーを取得できます。
日時ターゲティングを行うにはどうすればよいですか？	入札ロジック関数で日付オブジェクトに対応しました。	これを行う方法は複数あり、購入者は販売者に現在の日時を尋ねることができます。また、販売者がすべての購入者に簡単に提供できるようにする必要があります。購入者は、リアルタイムの Key-Value レスポンスで日時を指定することもできます。最後に、購入者は購入者ごとのシグナルのコンテキストに基づくレスポンスの一部として日付と時刻を指定できます。販売者はこれを購入者の generateBid スクリプトに渡すことができます。
ユーザーの好み	FLEDGE または代替ソリューションで配信される場合、広告主ごとにクリエイティブをブロックできる機能をユーザーが選択できる。	ユーザーは Chrome で Ads API をオプトアウトできます。特定の広告の場合、関連する広告テクノロジーが、表示するクリエイティブやその選択方法を管理できる最適な当事者です。
明確なタイムライン	フェンス付きフレームの必要性など、FLEDGE でのプライバシー保護の利用可能性に関する詳細情報のリクエスト。	より詳細なタイムラインは第 1 四半期に発表する予定です。
混乱の報告	FLEDGE レポートが、Fenced Frames や Private Aggregation API などの他の API とどのように連携するかについて、より明確な説明を求めます。	今後数週間以内に、Private Aggregation API、FLEDGE、Fenced Frames の相互作用に関する説明を公開する予定です。
リアルタイムビッダーと FLEDGE	FLEDGE を標準のリアルタイムビッダーと統合する方法に関するガイダンス。	アドテックのリアルタイムビッダーの機能を複雑にしている主な理由は、イベントレベルのデータへのアクセスと、ARA への統合の容易さです。第 1 四半期には、この両方に関する最新情報と説明を送信する予定です。
FLEDGE オークションのパフォーマンス	FLEDGE オークションでレイテンシが長いというテスターからの報告	テスト結果とユースケースを共有してくださったテスターからの報告に感謝するとともに、FLEDGE のパフォーマンスを改善する方法に関するご提案を共有しています。また、オークションを遅らせている原因をデベロッパーがより的確に診断できるようにするためのツールをブラウザに追加し、確認されたレイテンシの主な原因に体系的に対処しています。最近の改善点には、遅いオークションのタイムアウト、高速ビッダーフィルタリング技術、FLEDGE ワークレットを再利用して起動費用の発生を回避する方法、コンテキスト広告リクエストを FLEDGE の起動時間およびネットワークフェッチと並行して実行するための継続的な取り組みなどがあります。実際に API を使用した経験に基づいて、Chrome デベロッパーと FLEDGE テスターの間で、レイテンシの最適化が継続的な議論の中で行われることを期待しています。
インタレストグループのサイズメモリ上限	1 つのインタレストグループの上限を 50 KB から引き上げるリクエスト。	Google ではこのリクエストを積極的に検討しており、どのような制限値が機能するのかについてフィードバックを求めています。
FLEDGE 配信データとファーストパーティの Cookie を組み合わせる	FLEDGE は広告主の自社データとの統合をサポートしていますか？	FLEDGE は、広告主様がすでに保有している自社データを使用して広告をサポートするように構築されています。ただし FLEDGE は、広告主自身のサイト以外のウェブサイトでのユーザーの閲覧行動を学習する広告主をサポートすることは想定していません。オフサイト閲覧行動を自社データに付加することは、プライバシーサンドボックスの目的に反します。今後数週間のうちに、FLEDGE で自社データとの統合がどのようにサポートされるかについて、詳しい統合ガイドをご案内する予定です。
k-匿名性の値	「K」から「k-匿名」の値はどのように決定され、公開されますか？	「K」の値はまだ確定中です。今後の計画の進展に伴い、詳細をお知らせいたします。未知の k 値が FLEDGE の準備と ML モデルのトレーニングのスコープ設定にどのように影響するかについて詳しく知りたいと思います。このトピックに関する追加のフィードバックをぜひお寄せください。
複数の SSP のサポート	FLEDGE で複数の SSP はどのようにサポートされますか？	FLEDGE は、この提案に記載されているように、複数の販売者によるオークションをサポートしています。
入札ロジックの可視性	DSP 入札ロジックが JavaScript で公開されるのに対する懸念	現在の設計上の入札ロジックでは、JavaScript に他のユーザーもアクセス可能ですが、これが DSP にとって懸念される理由について、フィードバックをお待ちしています。
prebid.js	FLEDGE で prebid.js をサポートするスケジュールを教えてください。	FLEDGE モジュールをサポートしているのは、バージョン 7.14 以降の Prebid.js のみです。テストに関心をお持ちの場合は、FLEDGE モジュールを追加し、Prebid インスタンスをアップグレードする必要があります。
FLEDGE のユーザー定義関数	ユーザー定義関数（UDF）は FLEDGE でどのようにサポートされますか？エンドユーザーがプログラムして API の機能を拡張できる関数です。	解説はこちらでご覧いただけます。この調整はまだ開発中ですので、ユースケースに関する追加のフィードバックをお待ちしています。
インタレストグループのリソースに対する同一オリジンの制約の緩和	特定の広告テクノロジーのユースケースを可能にするために、インタレストグループリソースに対する同一オリジンの制約を緩和するリクエスト	FLEDGE の現在の実装では、`biddingLogicUrl`、`biddingWasmHelperUrl`、`dailyUpdateUrl`、`trustedBiddingSignalsUrl` のオリジンはインタレストグループのオーナーと同じである必要があります。この制約は、こちらで説明しているとおり、攻撃者による特定の悪用を防ぐために存在します。
インタレストグループのオーナー権限	広告テクノロジーが、サイトをまたいで同じインタレストグループに対して joinInterestGroup を使用できるかどうかを制限するリクエスト	YouTube はオーディエンスをどのように作成するかではなく、どのように利用するかを重視しています。考えられるアプローチについてはこちらでご説明しており、追加のご意見をお待ちしています。
Key-Value サーバーキーの有効期限	対応するインタレストグループの有効期限が切れた後のサーバーキーの削除について	Google は鍵の有効期限を処理する方法を検討しており、こちらからフィードバックをお待ちしています。

デジタル広告の測定

Attribution Reporting（とその他の API）

フィードバックテーマ	まとめ	Chrome レスポンス
オリジントライアルのトラフィック	現在のオリジントライアルのトラフィックでは、ユーティリティテストを行うには十分ではありません。	現在のオリジントライアルは、エコシステムのプレーヤーが機能テストを実施して、API が意図したとおりに動作していることを確認することを目的としています。Google は、さまざまなプライバシーサンドボックス API の開発が成熟すると、ユーティリティテストのために大量のトラフィックが必要になることを理解しています。現在のテストのタイムラインでは、2023 年第 3 四半期に一般提供（このユースケース向けのテクノロジーがリリースされ、すべての Chrome トラフィックでご利用いただけるようになる時期）までに導入される予定です（privacysandbox.com の最新のタイムラインをご覧ください）。追加のトラフィックを必要とするユースケースのテストについて、追加のフィードバックがあればお寄せください。
異なるプライバシーサンドボックス測定 API の機能の重複	プライバシーサンドボックスを通じて複数の測定方法が重複するという懸念は、Attribution Reporting API や Private Aggregation API など、複雑さが増す。	Google では、API のさまざまなユースケースを明確にするためにドキュメントの改善に取り組んでいます。説明が不足している領域については、追加のフィードバックをお寄せください。たとえば、Attribution Reporting API がコンバージョン測定のサポートに特化したものであるのに対し、Private Aggregation API と Shared Storage API はより幅広いクロスサイト測定のユースケースをサポートする汎用 API です。
失敗したレポートリクエストを再試行する	レポートリクエストが失敗した場合の試行回数の明確化。	これに関するガイダンスを公開しました。要約すると、レポートはブラウザが実行中またはオンラインのときにのみ送信されます。最初に送信に失敗した後、レポートは 5 分後に再試行されます。2 回目の失敗の後、15 分後に報告が再試行されます。それ以降、レポートは送信されません。
レポートの遅延	レポートの遅延はどのくらいが予想されますか？	レポートの遅延についてデータを収集し、これらを並行して詳しく評価するにあたり、エコシステムからのフィードバックをお待ちしています。
ページの事前レンダリング	ARA アトリビューションは事前レンダリングページで機能しますか？	アトリビューション登録は、有効化（実際のクリックまたはビューが発生する）まで事前レンダリングページで延期されます。つまり、「attributionsrc」リクエスト ping が延期されます。
コンバージョンリフト測定	同じドメインの A/B テストでコンバージョンリフトを測定する方法	アトリビューションレポートを通じて、同じドメインの A/B テストでコンバージョンリフトを測定できる。デベロッパーは、Aggregate API を使用して A/B パラメータをキーとしてエンコードし、それらのキーバケットごとのコンバージョン値の概要レポートを受け取ることができます。
（第 3 四半期にもレポート）クロスドメインコンバージョン	リンク先が 2 つ以上あるなど、クロスドメインのコンバージョンをトラッキングする方法	第 4 四半期の更新: Google は、ドメインをまたいだ会話をトラッキングできるようにするランディングページのリンク先制限を削除する提案を公開しました。この提案は実装されました。
（第 3 四半期にもレポートされます）コンバージョンレポートの有効期限の設定	レポートフィルタ / 有効期限（24 時間未満）のサポートリクエスト	第 4 四半期の更新: 今回お知らせしたプルリクエストでは、レポートの有効期限とレポート期間を切り離し、レポートの遅延とコンバージョンの有効期限のトレードオフを軽減します。これは M110 でリリースされました。
不正行為や不正使用	広告主やマーケティング担当者から、広告が配信されるパブリッシャーのサイトに基づいてデータをスライスして集計できるようにすることを求めるリクエスト。これにより、不正な広告行為の可能性についてより多くの分析情報が得られます	このフィードバックについては、こちらで活発に議論を続けており、追加のご意見もお待ちしております。
（第 3 四半期にもレポート）イベント単位のレポートの遅延	ユースケースによっては、イベント単位のレポートで 2 ～ 30 日という遅れが長すぎることもあります。	イベント単位のレポートのデフォルトのレポート期間は、2 日間、7 日間、30 日間です。「expiry」パラメータを使用してこれを変更できます。広告テクノロジーでは、可能性のあるレポートが 2 日以内に取得されるように、期限（最短 1 日）を設定できます。より詳細なレポートを送信するとタイミング攻撃につながるおそれがあるため、プライバシー保護のため、有効期限の粒度は 1 日に制限しています。また、イベントレベルレポートと集計レポートに対して、独立した「expiry」パラメータを設定できます。こちらをご覧ください。また、他の広告テクノロジーが Attribution Reporting API で取得できない特別なレポート期間は Google 広告には反映されません。
同じレポート元の要件	ソース登録元をコンバージョン登録元と同じにするという要件を削除するリクエスト	このユースケースを解決するために、HTTP リダイレクトを使用して登録を委任することを提案します。新しいガイダンスについて、その他のフィードバックがあればお寄せください。
コンバージョントラッキング	コンバージョンの発生が、広告主様が設定した特定の時間の前か後かを区別する必要がある	Attribution Reporting API では、ソースアトリビューションの有効期限と優先度を設定できます。両方を使用することで、技術的には、X 日間に発生したコンバージョンを、X より後に発生したコンバージョンとは別にアトリビューションできます。
ノイズシミュレーション	コンバージョン数の少ない広告主への影響を把握するために、バケットごとにさまざまなコンバージョン数をシミュレートできるようにするためのリクエスト	ノイズラボの今後のバージョンでは、これをシミュレートする方法を追加する予定です。その他のフィードバックがございましたら、ぜひお寄せください。
モバイルでのレポート	モバイル版の Chrome がバックグラウンドで動作しているときにも、レポートは送信されますか？	現時点では、モバイルでも、Chrome がバックグラウンドで実行されているときはレポートは送信されません。API が Android のプライバシーサンドボックスと統合されると、この状況が変わる可能性があります。こちらをご覧ください。Android 向けプライバシーサンドボックスは、CMA が承認するコミットメントには含まれていません。
データの可用性	Privacy Sandbox API を介して Google がデータへの追加アクセス権を得られることが懸念される	第一に、Google 広告には、Attribution Reporting API またはその他のプライバシーサンドボックス API からのデータへの優先的なアクセス権はありません。この問題は、「相互運用性」の「一般的なフィードバック」セクションにも記載されています。このセクションには、Google のコミットメントの詳細が記載されています。次に Google は、大規模なサイトと小規模なサイトの違いから、ノイズベースのプライバシー保護は小規模なデータスライスに大きな影響を与える可能性があることを認識しています。ただし、いくつかの緩和策があります。たとえば、長期間にわたって集計するなどの方法によってこの問題を解決できます。とはいえ、非常に小さなデータスライス（1、2 回の購入など）に基づく結論が広告主にとってまったく意味のあるものかどうかはまだ不明確です。Google は、オリジントライアル中、この問題に関してより具体的なフィードバックを提供できるように、さまざまなプライバシーパラメータとノイズパラメータをテストする機能を活用することをテスターに推奨しています。

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

User-Agent の情報量削減

フィードバックテーマ	まとめ	Chrome レスポンス
ウェブエコシステムの準備が整うまでユーザーエージェントの情報量削減を遅らせる	今後予定されているユーザーエージェントの情報量削減の変更に対応する時間がありません。	このフィードバックについては、「Google と CMA とのやりとり」セクションの「Stakeholder Concerns」のレポート全文で取り上げています。
ウェブエコシステムの準備が整うまでユーザーエージェントの情報量削減を遅らせる	構造化ユーザーエージェント（SUA）がデプロイされるまでユーザーエージェント情報量削減のロールアウトを延期するリクエスト	Google 広告チームは、2021 年 10 月に OpenRTB への構造化されたユーザーエージェントの追加（仕様を参照）を提案し、2022 年 4 月にリリースされた 2.6 の仕様更新に組み込まれています。 UA-CH と WURFL API を使用して SUA を作成する方法をScientia Mobile のブログ投稿で示しているように、SUA がデプロイされ、現在利用可能であるという証拠があります。

###

User-Agent Client Hints API

フィードバックテーマ	まとめ	Chrome レスポンス
その他の隠しトラッキング手法を使用して UA-CH をテストする	提案されたすべてのプライバシーサンドボックス API とフィンガープリント手法を包括的なアプローチでテストする方法に関するガイダンス	Google のテスト計画は、サンドボックスの提案の他の部分とは対照的に、フィンガープリント防止対策の一部を開発するための非同期のタイムラインを反映することを目的としています。サードパーティ Cookie が廃止された後にのみ、フィンガープリント対策の一部の対策（プライバシーバジェット、IP 保護、バウンストラッキング対策など）が完全に開発され、一般提供を開始できるという現実に対処するものです。こうした指紋防止対策は定量テストには含まれませんが、停止時に入手可能な事実に基づく定性評価の対象となります。
（第 2 四半期にもレポートされます）パフォーマンス	Critical-CH 経由でのヒント取得のレイテンシ（最初のページの読み込み時）に関する懸念	以下の UA-CH 専用セクションをご覧ください
フィードバックが不十分	UA-CH の変更に関するエコシステムからのフィードバックだけでは不十分で、エコシステムでの認知度の欠如が懸念されます。	Google では、サービスの中断を最小限に抑えるよう、慎重に計画を周知してまいりました。 User-Agent Reduction と UA-CH API の計画は、2022 年 3 月 18 日に W3C Anti-Fraud Community Group に、2022 年 1 月 20 日に Web Payments Working Group と Web Payments Security Interest Group に対してそれぞれ発表されました。プレゼンテーション中またはプレゼンテーション後に、大きな懸念は示されませんでした。 Google では、事前に 100 人以上のサイト事業者にフィードバックをお願いしています。さらに、Google は Blink-Dev チャネルを利用して、エコシステムの関係者からのフィードバックに基づいてユーザーエージェント削減のロールアウトを公表しています。
タイミング	ロールアウトのタイミングと業界への準備に関する懸念	以下の UA-CH 専用セクションをご覧ください
Chrome プラットフォームのステータス	UA-CH の Chromestatus ページを更新するようリクエストしました	chromestatus エントリは 12 月 19 日に「混合シグナル」に更新されました。

IP 保護（旧 Gnatcatcher）

フィードバックテーマ	まとめ	Chrome レスポンス
オプトインまたはオプトアウト	IP アドレスのプライバシーはオプトインですか、オプトアウトですか？	Google は、すべてのユーザーに IP 保護を提供することを目指しています。この目標を踏まえ、Google は現在、IP 保護のユーザー選択オプションを評価しています。
自社データの IP アドレスのユースケース	IP アドレスを使用して、IP 保護を導入した後の自社ドメインのユーザージャーニーをつなぎ合わせることはできますか？	以前公開されたとおり、IP 保護はまずサードパーティのコンテキストでのトラッキングに重点を置いています。つまり、ファーストパーティドメインへの影響はありません。
広告テクノロジーのユースケース	企業はどのようにして IP 保護で不正行為対策を設定できますか？	Google は、現在のウェブにおける不正行為対策のシグナルとして IP アドレスの重要性を認識しています。CMA とのコミットメント（第 20 項）の一部として、Google は、スパム対策および不正対策の取り組みを実行するウェブサイトの能力をサポートする合理的な努力を払うことなく、IP 保護を導入することはないと述べています。Google の最優先事項の一つは、IP 保護が不正防止のユースケースと検出機能に与える影響を理解することです。これにより、企業のウェブの安全性を維持できるプライバシー保護技術に、さらに投資することができます。時間の経過とともにシグナルが変化する中でも、セキュリティチームと不正防止企業のニーズに対応することを目的として、フィードバックと新しい提案に対するインプットを奨励しています。
不正行為や不正使用	IP 保護にサービス拒否攻撃（DoS）対策は含まれていますか？	Google はウェブの安全性を確保しながらプライバシーの向上に取り組んでおり、サービス拒否攻撃からの保護は、設計における重要な不正使用対策ユースケースの一つです。Google では、IP 保護自体の設計と新しい不正使用対策ソリューションを通じて、DoS 攻撃防御への影響を最小限に抑えることを目指しています。IP 保護は当初、サードパーティの組み込みサービスに重点を置いていたため、自社サイトの DoS 対策への影響は限定的であるとの関係者も指摘しています。ただし、DoS ユースケース、特にサードパーティの組み込みサービスに対するリスクを評価するため、引き続き一般公開のフィードバックをお願いしています。また、スパム行為のあるユーザーを特定せずにサイトやサービスがブロックできる、不正行為に関するフィードバックとクライアントブロックのメカニズムの検討も行っています。
コンテンツのフィルタリング	IP 保護を使用したコンテンツフィルタリング	コンテンツのフィルタリングやユーザーエクスペリエンスのカスタマイズに対するニーズは、企業によって異なります。現在、このようなユースケースの多くは IP アドレスに依存していないため、IP 保護の影響を受けることはありません。たとえば、コンテンツをカスタマイズしてエンゲージメントを促進したいと考えているパブリッシャー様は、ユーザーの興味 / 関心やパブリッシャーとの過去のインタラクションを把握するために、ファーストパーティ Cookie またはサードパーティ Cookie（CHIP）を使用することがあります。また、適切なユーザーに適切な広告を配信することに注力している広告テクノロジーパートナーは、FLEDGE と Topics を組み込むことで、たとえばサードパーティ Cookie やその他のクロスサイトトラッキング技術を使用して、現在と同様の広告成果を提供できます。また、既存のメカニズムでは不十分なコンテンツフィルタリングをサポートするために、IP 保護に新しいプライバシー保護機能（おおまかな位置情報など）を組み込むことも検討しています。IP 保護の影響を受ける可能性のあるコンテンツフィルタリングのユースケースについて、ぜひフィードバックをお寄せください。
（第 3 四半期にもレポートされています）位置情報のユースケース	IP 保護を使用すると、位置情報に基づくコンテンツのパーソナライズなど、位置情報に基づく正当なユースケースが今後機能しなくなる可能性があります。	第 4 四半期の更新: Google は、Chrome が IP アドレスの正当なユースケースを引き続きサポートできるよう、関係者と連携しています。Google は、こちらから IP の位置情報の粒度に関するエコシステムのフィードバックを求めています。

プライバシーバジェット

フィードバックテーマ	まとめ	Chrome レスポンス
ドキュメントの明確化	多くの例を挙げて、プライバシーバジェットが導入された後にどのような制限があるかを関係者が予測できるようにする	プライバシーバジェットの提案は現在も活発に議論されているため、どのブラウザでも実装されていません。調整可能な最も早い日付は、プライバシーバジェットを適用できる最も早い日付を表します。これは、2024 年にサードパーティ Cookie が削除されるまでは起こりません。現時点では、お伝えできる追加ドキュメントはありません。この提案については、詳細が決まり次第、あらためてお知らせいたします。それまでの間に、提案の作成に役立つフィードバックをお寄せください。

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

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

フィードバックテーマ	まとめ	Chrome レスポンス
（第 3 四半期にもレポート）ドメインの上限	関連ドメイン数の増加のリクエスト	第 4 四半期の更新: GitHub のモックセット提出プロセスや、rSA と rSAFor をローカルでテストするフラグなど、ローカルテスト用の FPS をリリースしました。また、FPS に関するデベロッパー向けのオープンミーティングを 2 回開催し、関連する一部のユースケースに関する質問に引き続き対応しています。デベロッパーには、FPS 機能をテストして、関連するサブセットのドメイン上限がユースケースでの FPS のユーザビリティにどう影響するかに関するフィードバックを提供することをおすすめします。 Chrome がユーザーのプライバシーに関する利益にも配慮した実用的なソリューションの提供に取り組んでいることを、WICG の電話で明確にしました。ドメイン制限の影響を受ける特定のユースケースについてコミュニティからのフィードバックをお待ちしております。これにより、チームはユーザーのプライバシーを保護しながらこれらのユースケースに対処する方法を検討できます。
不正行為の緩和策に関する詳細情報のリクエスト	同意していないドメインにドメインが追加されるとどうなりますか？	2022 年 12 月 2 日、ファーストパーティセットの送信ガイドラインをこちらに公開しました。送信ガイドラインに記載のとおり、すべてのチェンジマネジメントは、所有権の検証を含む GitHub の検証プロセスに従ったうえで遵守します。これにより、このリスクを軽減できます。
不正行為の軽減	ファーストパーティセットの構成が悪用される恐れがある	現在、サブセットの種類に対するテクニカルチェックを拡張する方法を検討しており、こちらのコミュニティで追加の情報入力を積極的に求めています。
広告のユースケース	広告ターゲティングをサポートするためにファーストパーティセットを使用する必要があるかどうかに関する質問	Google はファーストパーティセット向けの広告ターゲティングのユースケースをサポートしません。そのため、利用可能な Ads API を使用することをおすすめします。
（第 3 四半期にも報告）ポリシー	GDPR ではセット内のサイト数に制限が課されていないことから、FPS は「適用されるデータ保護法」に関する CMA のコミットメントと整合していないという懸念があるのに対し、FPS では 3 つとされている	Google の回答は第 3 四半期から変更されていません。 Google は今後も CMA に対し、Google 独自のビジネスを主体とすることで競争を歪めない方法でプライバシーサンドボックスの提案を設計、実装し、デジタル広告、パブリッシャー、データ保護におけるコンプライアンス、データ保護、広告主への影響を考慮に入れて、引き続き CMA に取り組んでまいります。お客様の懸念事項では、GDPR との互換性がない旨が開示されていません。Google は引き続き CMA と緊密に連携し、私たちの仕事がこれらのコミットメントを遵守するようにしています。」
代替案	GDPR 検証済みセット	「GDPR 検証済みセット」の導入提案についてエコシステムから寄せられたフィードバックに加え、Chrome には、この代替案に次のような制限に関する懸念があります。「GDPR 検証済みセット」は、GDPR に「準拠している」と主張しています（ただし、その意味は明確ではありません）。一方、Google の取り組みでは、「プライバシー関連の成果に対する影響」をより一般的に考慮することを求めています。コミットメントを受け入れる決定において、CMA は、これが「適用されるデータ保護法に定められたデータ保護原則の遵守」を考慮する Google の義務とは別であることを指摘します。この義務は、CMA が説明するように、Google は該当するデータ保護法に拘束されるという事実を反映し、コミットメントに適用される場合とより一般的な場合があります。ドメインを複数のセットで表示できるようにする提案には、プライバシーに関する懸念があります。ファーストパーティセットは、広範なクロスサイトトラッキングを有効にすることなく、現時点でサードパーティ Cookie に依存している特定のユースケースをサポートすることを目的としています。複数のセットへのドメイン参加を許可すると、ファーストパーティセットの提案に組み込まれている主要なプライバシー保護が適用されません。その他の有意義な制限を受けることはありません。 GDPR 検証済みセットは、「共通の使用ポリシーを共有するデータ管理者およびデータ処理者のグループとしてセットを定義する」ことも提案しています。これは、最初のファーストパーティセット提案で、セット内のすべての関係者が共通のプライバシーポリシーを共有する必要があるという要件に似ています。その後、プライバシーポリシーに基づく要件に関する懸念を提起したエコシステムからの強いフィードバックに基づき、この要件を削除しました。例えば、W3C コミュニティのメンバーによって提起されたその他の課題の中でも、製品や地理的なばらつきのために、共通のプライバシーポリシーを維持するのは不可能だという意見がサイトパブリッシャーから寄せられました（1、 2、3）。この提案にも同様の課題が当てはまると思われます。この代替案の提起を受け、Chrome ではファーストパーティセットの提案を更新し、新しいセットの作成に関する送信ガイドラインを公開しました。

Fenced Frames API

フィードバックテーマ	まとめ	Chrome レスポンス
OT 中のフェンス付きフレームの制限	オリジントライアル期間中のフェンス付きフレームに関する現在の制限事項は？	制限事項と実装状況に関するドキュメントの作成を進めており、2023 年第 1 四半期に発表する予定です。
1 つのフェンス付きフレーム内の複数の広告	1 つのオークションで複数の広告主を 1 つのフェンス付きフレームに表示するリクエスト	現在、このリクエストは積極的には行われていませんが、エコシステムのプレーヤーがこの機能を重視していると思われる場合は、追加のフィードバックをお寄せください。
ウェブバンドル	フェンス付きフレームを使用したウェブバンドルについて、どのような要件とサポートが予定されていますか？	現時点では、今後これが要件になるかどうかについての最新情報は決まっていません。変更内容は事前に通知され、サードパーティ Cookie が廃止される前に適用されることはありません。現在のステータスについては、こちらの説明をご覧ください。

Shared Storage API

フィードバックテーマ	まとめ	Chrome レスポンス
広告テクノロジー用の共有ストレージ	広告テクノロジーのユースケースにおける共有ストレージの使用に関する不確実性	共有ストレージと Private Aggregation API は、クロスサイトストレージ測定を必要とするさまざまな測定目的で使用できます。例については、こちらをご覧ください。 Google は、DSP および測定ソリューションプロバイダが広告ユースケースのメインインテグレータになると予測しています。

チップ

フィードバックテーマ	まとめ	Chrome レスポンス
（第 3 四半期にもレポート）分割要件	ファーストパーティの Cookie の「分割」属性に明示的な動作要件を追加しました。	第 4 四半期の更新: GitHub と PrivacyCG 呼び出しに関する議論の結果、ファーストパーティの Cookie に設定されたパーティション化された Cookie は、（A、A）のパーティションキー（A はトップレベルサイト）を使用するという動作が一致しました。この動作を説明と仕様に記載します。
Cookie の管理	ファーストパーティまたはサードパーティの Cookie を管理、統制するためのツールはありますか？	サードパーティの Cookie のブロックが有効になっているサイトをテストするには、Chrome DevTools と NetLog を使用します。どちらのツールも、ユーザー設定によって Cookie がブロックされた場合に報告します。監査ウェブサイトについて、どのような追加監査をお考えかについて、フィードバックをお寄せください。

FedCM

フィードバックテーマ	まとめ	Chrome レスポンス
IdP にセッションを許可するには RP の知識が必要	ユーザーが 2 つの異なる RP から Feide IdP にログインしようとした場合の問題	この問題の解決策については、こちらをご覧ください。
相互運用性	FedCM を使用してユーザーがログインするウェブサイトとユーザーの関係に FedCM が及ぼす影響、およびウェブサイト間の「相互運用性」に関する懸念	FedCM は、Chrome からサードパーティ Cookie が削除された後も、現在サードパーティ Cookie に依存しているフェデレーション ID サービスを引き続きサポートすることを目指しています。Google は、FedCM はこのようなサービスで利用できるオプションの 1 つにすぎないと私たちは考えています。ID プロバイダ（IdP）と証明書利用者（RP）は、ニーズにより適した他のテクノロジーを自由に使用できます。ユーザーと RP の関係と「相互運用性」に関する懸念は、FedCM の提案が誤解されていることによるものと思われます。ユーザーが RP のサイトへのログインを選択したら、FedCM は IdP に任せて、RP と共有する情報とどのような形式で共有するかを決定します。FedCM では、IdP は「ユーザーが認証する [RP] ごとに一意の仮名化された ID を作成する」必要はありません。代わりに FedCM は、ユーザーの実際の識別子、その識別子のサイトごとのバージョン、またはこの情報の他のバージョンを共有するかどうかを選択するために、各 IdP に対して開かれています。（FedCM の仕様では、クロスサイト相関は API に関連するプライバシーリスクとして特定されており、考えられる緩和策として有向（サイト単位）識別子について説明しています。ただし、有向識別子を使用するかどうかは、ブラウザではなく IdP が決定します）。 FedCM はすでに、ID に関するユーザーの選択も提供しています。たとえば、ユーザーが同じ IdP で複数の ID（仕事用プロファイルと個人用プロファイルなど）を使用している場合、FedCM ではユーザーが RP のサイトへのログインに使用する ID を選択できます。さらに、各 RP がサイトでサポートする IdP を独自に決定します。その決定の側面の一つは、IdP が依存するメカニズムを FedCM であれ別のテクノロジーであれ、考慮することです。前述のように、ブラウザは RP や IdP に関するこれらの選択を指示しません。

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

Private State Token API

フィードバックテーマ	まとめ	Chrome レスポンス
bot の処理	プライベートステートトークンが bot に発行されていることをカード発行会社が発見した場合はどうなりますか？	bot に発行されたトークンがエコシステムに長期間残らないようにするには、カード発行会社はトークンへの署名に使用する鍵を定期的にローテーションする必要があります。これにより、破損している可能性のある発行ロジックの下で発行された古いトークンが期限切れになり、サイトで最新の発行ロジックで新しいトークンが引き換えられるようにする必要があります。
同一サイトフォームの送信	fetch/XMLHttpRequest API からのリクエストではなく、フルページナビゲーション（Content-Type: application/x-www-form-urlencoded）を含む同一サイトフォームの送信に、プライベートステートトークンを使用できますか？	これは現在、プライベートステートトークンの最初のバージョンではサポートされていません。このユースケースに対して強い需要がある場合は、エコシステムからのフィードバックを歓迎します。
サーバーサイド認証	プライベートステートトークンをサーバーサイドで確認できるかどうかに関する質問	トークンがカード発行会社に対して引き換えられ、カード発行会社はクーポン記録を作成します。この記録には、トークン自体またはトークンから派生した署名付き値を含めることができます。サーバーはそのクーポン記録を使用してトークンの真正性を検証します。カード発行会社のエコシステムによって、クーポン利用記録の解釈方法にはさまざまな基準があります。

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