プライバシー サンドボックスの関連性と測定に関する API に関するよくある質問への回答。
Topics と販売者定義のオーディエンス（SDA）の違い
Topics と SDA は補完的なタイプの情報を提供し、パブリッシャーが管理します。これらは競合しているとは 考えていません購入機会を最大化するために、両方が同時に、または異なる状況で機能します。購入者は、プログラムでインプレッションを評価する際にさまざまなシグナルを考慮し、使用します。Topics もその一つです。販売者はこれまで公開マーケットプレイス オークションにオーディエンス セグメントを含めていないため、Topics が使用される可能性があります。代わりに、販売者は、広告主、代理店、DSP との取引でオーディエンスをプログラマティック購入に利用できるようにしています。この場合、販売者と購入者は、意図的に SDA を使用して取引を行います。このような場合に Topics を使用する場合は、次の 1 つ以上に該当する可能性があります。
- Topics を使用してオーディエンスの定義を強化する営業担当者
- トピックを入札単価のシグナルとして使用する購入者
- 購入者が Topics を使用して SDA が正確かどうかを検証する
Protected Audience では、Google がオーディエンスの作成を管理することになりますか？
いいえ。サイトはプライバシー サンドボックスの内外で、引き続き独自のオーディエンスを作成できます。サイトがプライバシー サンドボックス内でオーディエンスを作成する際、サイト所有者または選択したプロキシが、オーディエンスを作成できるユーザー、オーディエンスの内容、オーディエンスの更新方法、オーディエンスの入札方法、オーディエンスからユーザーを削除するかどうかを決定します。
Protected Audience はパブリッシャーが作成したインタレスト グループに対応していますか？
はい。パブリッシャーの皆様が、データ漏洩を恐れて、OpenRTB ベースのオークションにオーディエンスを参加させることに慎重な姿勢があることは理解しています。パブリッシャーは、個々のパブリッシャー ユーザーのクロスサイト ビューをビッダーに提供しないオーディエンスを Protected Audience で今すぐ作成できます。Google は、Protected Audience のデータ漏洩の少ない環境をパブリッシャーが活用できる方法を引き続き模索してまいります。
Protected Audience のオークションで、広告品質ルールはどのように適用されますか？
Protected Audience オークションでは、さまざまな方法で広告品質ルールが適用されます。いずれも、現在の SSP で広告品質ルールが適用される仕組みに似ています。1 つは、不明なクリエイティブを含むオークションで、そのクリエイティブをスキャンのキューに入れるようにする方法です。SSP はこのユースケースをより適切にサポートしてほしいというフィードバックをいただいています。現在、SSP が帯域外で監査できる renderUrls のフィードを作成して、Key-Value サーバーに情報を保存できるメカニズムを設計しています。また、広告の事前登録を必須にすることもできます。前のケースと同様に、クリエイティブをスキャンした後、結果を Key-Value サーバーに関連付けることができます。その後、購入者がそのクリエイティブで入札すると（OpenRTB と同じフォーマットに従う可能性のあるクリエイティブ ID によって示されます）、販売者のスコアリング ロジックで Key-Value サーバーが検索され、それに応じたスコア付け方法が決まります。
Protected Audience は動画広告をサポートしていますか？
はい。VAST URL は Protected Audience との間で受け渡しできます。VAST URL が返されると、セルサイドのテクノロジーは、プレーヤーに送信する前に、購入者の VAST URL のラップ方法を調整できます。フェンス付きフレームへの移行（2026 年以降）とユーザーのプライバシー保護のさらなる強化が求められる前に、Google は、エコシステムが必ず動画を含むデザインに関する議論に参加することを期待しています。
Protected Audience はネイティブ広告をサポートしていますか？
はい。JSON URL は Protected Audience との間で受け渡しできます。JSON URL が生成されると、セルサイドの技術は、最終的な JSON がレンダリング コードに渡される前に、必要なイベントを追加する方法を調整できます。ユーザーのプライバシー保護をさらに強化するためにフェンス付きフレームへの移行（2026 年以降）に先立ち、Google は、エコシステムがネイティブなどのデザインに関する議論に参加することを期待しています。
Protected Audience の広告レンダリングはイノベーションを妨げますか？
いいえ。広告レンダリングは常にブラウザ技術に依存しています。それは変わりませんこの問題は、将来的に Protected Audience とともにフェンス付きフレームの使用が必要になる計画に固有のものです。これらの計画が「将来」である理由の 1 つは、広告のレンダリングに関して、フェンス付きフレーム技術でエコシステムのイノベーションと差別化をサポートしたいからです。ご興味をお持ちのデベロッパーや企業は、ネイティブ広告のアプローチをサポートする方法など、フェンス付きフレームの方向性について検討する必要があります。
Protected Audience では、従来のオークションで現在使用されている高度なペースと入札単価の評価手法を使用できますか？
Protected Audience は、購入者がキャンペーンのペースと予算を把握するためのリアルタイムのオプションを提供します。広告枠の観点からは、販売者はページのコンテキストなどに関するオークション シグナルを購入者に提供できます。販売者がコンテキスト入札リクエストの送信を選択した場合、購入者はそのメカニズムを通じて広告枠についても学習し、Protected Audience の入札生成に使用できるコンテキスト シグナルを（perBuyerSignals を介して）提供できます。先行ユーザーはすでに ML システムを Protected Audience に接続しています。Protected Audience 環境でこれらのシステムの入札を調整するには時間がかかることは理解していますが、調整は可能で、すでに行われています。
OpenRTB 標準は Protected Audience で機能しますか？
はい。この作業は IAB Tech Lab で、代表的な DSP と SSP の十分な数の常連のグループを通じて進行中です。今後は、Protected Audience オークション内で通信標準として OpenRTB プロトコルの一部が使用される予定であり、すでにその仕組みを構築しているアーリー アドプターもいます。
Protected Audience では、広告配信のために 2 つの異なるアーキテクチャを維持する必要がありますか？
いいえ。Protected Audience では、2 つのアーキテクチャを個別に維持する必要はありません。アーキテクチャの選択はお客様自身が行います。オンライン広告の発展が進むにつれ、それを支えるシステムが複雑になってきました。インターネットの機密性を高めると、複雑さが増し、作業が必要になります。広告テクノロジー企業は、2 つの異なるアーキテクチャを維持するか、Protected Audience を従来のオークションと統合したアーキテクチャに構築できます。
Protected Audience をサポートする広告テクノロジー企業が増えると、従来のオークションはどうなりますか？
コンテキスト オークションは、取引、非自社オーディエンス ターゲティング キャンペーン、その他の多くのコンテキスト シナリオなど、さまざまな理由から引き続き重要になると考えられます。また、インタレスト グループが存在しない場合や、Protected Audience の入札単価が最小価格に届かない場合や、広告品質のルールを順守していない場合にも、価値は変わらず有用です。
Protected Audience のオークションは、広告主とパブリッシャーの間の仲介者の総数や特定の広告機会の重複を削減するエコシステムのサプライパス最適化（SPO）の取り組みに反しますか？
いいえ。Protected Audience で落札された広告は、最大 2 つの販売者エンティティ（たとえば、サプライサイド プラットフォーム（SSP）とパブリッシャーの広告サーバー）を通過します。購入者がパブリッシャーとの直接統合を構築した場合は、ほとんど通過しません。
複数の仲介を使用して同じリクエストを複製するかどうかは、パブリッシャーが自由に選択できます。Protected Audience は、このいずれかの方法で影響を受けないようにする必要があります。
Protected Audience オークションは、クロスサイト ユーザーデータの漏洩を防ぐため、現在のサーバー間リアルタイム システムの外部で行われます。広告リクエストが重複していると言う人もいます技術的に実証可能なプライバシーを実現するには トレードオフが伴いますただし長期的には、エコシステムが従来のサーバーサイド オークションなしで Protected Audience を使用する場合もあります。これを選択すると、サプライパスをさらに最適化できる可能性があります。
Protected Audience は、既存のトラフィック シェーピング インフラストラクチャの価値を低下させますか？
1 秒あたりのクエリ数に関する変更点は、多くの SSP が、DSP にリクエストを送信するかどうかを判断する機能としてクロスサイト ID を使用していることです。したがって、クロスサイト ID の削減は、既存のトラフィック パターンの手法に影響します。これは、パブリッシャーが Protected Audience オークションの実施を希望するかどうかに関係なく当てはまります。
多くの SSP でトラフィック パターンを調査し、キャッシュ保存やコンテキスト ベースのフィルタリングなどのソリューションを見つけました。今後、デベロッパーはプライベート アグリゲーションを利用して、DSP 入札の設定をより深く理解し、それに応じてフィルタリングできるようになる見込みです。
最終的には、クロスサイト識別子を中心に構築された一部のレガシー インフラストラクチャは使用できなくなります。
Protected Audience オークションによる新しいリクエストは SSP の処理能力に負担をかけることになりますか？
一部の SSP からは、容量は問題ではなく、統合の観点から SSP の価値提案の重要な要素ではないというご意見をいただいています。オークション プロセスでの新しい呼び出しについて懸念している SSP については、容量に関する懸念を抱えている SSP をすでにサポートしており、それらのサービスを拡張して Protected Audience をサポートしたいと考えています。これらの会社への連絡をご希望の場合は、Google までご連絡ください。
ブラウザ内に競合するリソースがある場合、Protected Audience では優先度にどのように対処しますか？
Protected Audience は一般的に、販売者が使用できる時間とリソースを決定できる制御機能と、購入者が利用できるリソースの最適な使用方法を決定できるツールを構築するという標準的なパラダイムに従っています。これらのコントロールとツールは現在利用可能ですが、そのすべてのメリットは、購入者と販売者が導入した後に実現されます。また、Chrome では、オークションを高速化するためのさまざまなインフラストラクチャ改善にも引き続き取り組んでいます（crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev32/1197 など）。
Protected Audience はレイテンシの懸念にどのように対処しますか？
Protected Audience が登場する前は、サーバーで行われるリアルタイム ビッダーでは、販売者がレイテンシを抑えるために購入者のレスポンスに厳密なタイムアウトを指定していました。レイテンシを抑制するという同じ目的を達成するために、よく似た販売者指定のタイムアウト制御（perBuyerCumulativeTimeouts、perBuyerTimeouts、sellerTimeout のドキュメントを参照）を Protected Audience に追加しました。また、これらのコントロールにより、オークション参加者はロジックを最適化し、リソースが最も効率的に使用され、広告テクノロジー エコシステムと高品質のユーザー エクスペリエンスをサポートすることが奨励されます。
Chrome では、オークションを高速化するためのさまざまなインフラストラクチャの改善にも引き続き取り組んでいます（例: crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev.com/119733）。このレイテンシに関する取り組みについて、購入者と販売者に役立つ追加ツールと、Chrome のエンジニアが調査すべきボトルネックの報告の両方について、フィードバックをお待ちしています。
入札やオークション サービス（B&A）が存在する場合、デバイス上の Protected Audience 向けの開発は無駄な作業になりますか？
いいえ。広告テクノロジーのユースケースにはオンデバイスで十分です。入札とオークション サービスは、広告テクノロジーがブラウザが許容するよりも多くの入札計算リソースに投資する必要がある場合、オプションの水平方向規模のソリューションです。デベロッパーが後で入札やオークション サービス環境に参加することに決めたとしても、ほとんどの作業は再利用できるため、オンデバイス開発は有効な投資です。構築されたパイプとインフラストラクチャの大部分は、引き続き同様に機能します。
Protected Audience に対するクラウドベースの高信頼実行環境（TEE）要件は、企業に Google Cloud の使用を促すものですか？
プライバシー サンドボックスは、堅牢なプライバシーとセキュリティを提供するように API を設計しており、Google Cloud にメリットをもたらすような設計上の決定は行っていません。クラウド プロバイダのサポートは AWS から始まりました。これは、多くの広告テクノロジー プロバイダが Amazon を選択しているためです。将来的には、AWS と Google Cloud だけでなく、他のクラウド プロバイダもサポートする予定です。また、他のクラウド プロバイダについても積極的に提案しています。レイテンシが懸念される場合、クラウドでは、他のクラウド プロバイダとの距離を短縮するロケーションを選択できます。
プライバシー サンドボックスによって、高信頼実行環境（TEE）を非パブリック クラウド データセンターで実行できるようになりますか？
監査可能な高信頼実行環境（TEE）は、Google のプライバシーとセキュリティ モデルの一部です。まず パブリッククラウドプロバイダが提供する TEE から始めました明確にするために記すと、近い将来に高信頼実行環境を使用する必要がある API は、Attribution Reporting API と Private Aggregation API のみです。どちらもオークション設定でリアルタイムで TEE を呼び出す必要はありません。Google は、パブリック クラウドベース ソリューション以外のオプションのサポートを引き続き模索しています。
信頼できる実行環境をパブリック クラウドで実行する方が、オンプレミスの広告テクノロジー データセンターよりも費用がかかるのではないでしょうか？
Google の現在の TEE プライバシー モデルは、パブリック クラウド実装のセキュリティ対策によるメリットがあるため、信頼できる実行環境をオンプレミスで運用する方が安価であるという仮定については疑問視しています。これらの手法における費用に関する考慮事項は次のとおりです。
パブリック クラウド プロバイダは、セキュリティに関して厳しい基準を課す必要があります。たとえば、AWS はセキュリティ対策が確立されている定評あるクラウド プロバイダです。特に AWS Nitro には、Nitro Enclave がエンクレーブで処理されるデータにオペレーターがアクセスできないようにするためのセキュリティ モデルが文書化されています。また、保護されたリソース（復号鍵など）は、エンクレーブで実行されている承認済みコードでのみ使用できます。物理的なアクセスも検討しますAWS は、Amazon 社員による物理的なアクセスリスクの軽減策を設計し、実装しています。既存のハードウェア ベースの TEE は、パブリック クラウドが行うように設計されているすべての物理的攻撃を防御できるわけではありません。また、Amazon は最近、独立調査会社である NCC Group に、社内の従業員によるアクセスに関連するセキュリティ主張に焦点を当てた Nitro 設計のレビューを依頼しました。公開レポートは、AWS の設計が主張を満たしていることを示しています。
こうした取り組みの実施、支援、改善には費用がかかります。グローバルに分散され、広く利用可能なパブリック クラウドでは、これらの費用が幅広い顧客層に分散されます。
プライバシー サンドボックスによってお支払い情報は変わりますか？
いいえ。広告テクノロジー企業やその他の API 呼び出し元は、ページに何かがレンダリングされているかどうかと、その料金を引き続き確認できます。
プライバシー サンドボックスでフリークエンシー キャップを設定することはできますか？
Protected Audience では、prevWinsMs オブジェクトを使用して、同じインタレスト グループ内のクロスサイトのフリークエンシー キャップをサポートしています。Protected Audience オークションでの購入者の generateBid() 関数により、同じブラウザでの以前の広告表示の結果に基づいて入札戦略に情報を提供できるロジックを作成できます。
Protected Audience の外部でフリークエンシー キャップに使用できるソリューションはいくつかありますが、広告テクノロジーがサードパーティ Cookie で使用するクロスサイト手法に完全に対応することはできません。
- ファーストパーティ Cookie: 広告テクノロジーは、独自のファーストパーティ データを使用して、自社のサイト全体にフリークエンシー キャップを設定できます。
- CHIP: 広告テクノロジーはパーティション化された Cookie を使用して、サイトごとのフリークエンシー キャップを管理できます。
- 共有ストレージ
SelectURL(): 広告テクノロジーがオークションで落札した後、クリエイティブを表示する前に、共有ストレージを呼び出してクロスサイト データにアクセスし、URL の選択出力ゲートで頻度に基づいて適切なクリエイティブを選択できます。
広告テクノロジーに有意義な有用性を提供する、プライバシー最優先の Protected Audience フリークエンシー キャップ ソリューションは、次の理由により困難です。
- 現時点では、広告テクノロジーのフィードバックから、周波数信号がノイズを許容できるかどうかは不明です。
- 広告テクノロジーから、オークション時にクロスサイト周波数シグナルを利用できるようにする必要があるため、広告オークションで使用するためにノイズのないクロスサイト シグナルを使用する必要があるというフィードバックが寄せられています。これにより、サイト全体でのユーザー アクティビティに関する大量の情報が漏えいし、プライバシー サンドボックスのプライバシー目標を損なう可能性があります。
- Google はレイテンシの発生に敏感です。このシグナルを提供するデバイス上のソリューションは、レイテンシを引き起こし、オークション環境を混乱させる可能性があります。
- 多くの場合、解決策として新しい API を使用し、W3C プロポーザル プロセスを経る必要があります。
そのため、Protected Audience 以外でフリークエンシー キャップ ソリューションを構築することは当面のロードマップには含まれていませんが、このユースケースを解決するための考えられる方法に関するフィードバックは歓迎しています。
プライバシー サンドボックスが適用されないユースケースについてはどうなりますか？
プライバシー サンドボックス API は、プライバシー保護広告の主な構成要素を提供します。デベロッパーは、これらの API をどのように組み合わせるかを柔軟に決定できます。ビルディング ブロック アプローチにより、企業は顧客に価値を提供するソリューションを革新し、開発できます。プライバシー サンドボックスは、すべてのユースケースに対応するエンドツーエンド ソリューションとして考えているわけではありません。これは悪い結果になると 考えていますその代わりに、デベロッパーや企業は、ソリューションに統合するプライバシー サンドボックス API など、さまざまなテクノロジーを通じてアイデアを実現し続けるでしょう。