Protected Audience API を効率的に運用することは、すべての人の利益になります。
- ウェブを閲覧するユーザーは、サイトをすばやく読み込めるようにしたいと考えています。つまりデベロッパーは、サイトや埋め込み広告の読み込みに必要な限られたデバイス リソース（コンピューティング リソースやネットワーク リソースなど）を過剰に使用しないように、Protected Audience API を効率的に使用する必要があります。
- パブリッシャーは、サイトの読み込みが速く、効率的でレスポンシブなエクスペリエンスを提供したいと考えています。パブリッシャーも、収益を最大化するために効果的な広告を求めています。
- 広告主と広告テクノロジーは、最大限の利便性を提供するために、広告をすばやく表示したいと考えています。
このドキュメントでは、サイトを最大限の効率で運用するための Protected Audience API の実装に関するベスト プラクティスの概要を説明します。
購入者（入札者）のベスト プラクティス
Protected Audience API オークションの効率を最適化するには、次のベスト プラクティスに従ってください。
インタレスト グループのオーナー数が減少
Protected Audience API の入札者を保護するため、ブラウザはサイト分離を使用してウェブ上のさまざまなオリジンを保護するのと同様に、高コストなリソース（オペレーティング システムのプロセスなど）を使用して、個々のインタレスト グループのオーナーを保護します。
このような非常に高コストなリソースの支出を最小限に抑えるには、インタレスト グループのオーナー数を最小限にすることが重要です。異なるサブドメインがそれぞれ異なるインタレスト グループを所有することは避けてください。たとえば、adtech.example に cats.adtech.example と dogs.adtech.example が所有するインタレスト グループがある場合、ブラウザは 2 つの異なるプロセスを使用して入札スクリプトを実行する可能性があります。
インタレスト グループの入札数が少ない
ブラウザでは、購入者の generateBid() スクリプトを呼び出す前に、新しいクリーンな JavaScript 実行環境の設定、generateBid() コードの解析と読み込みなど、重要な設定と準備を行う必要があります。
- 有効な広告キャンペーンの現在のターゲットではないユーザーを表すインタレスト グループには、空の広告クリエイティブ リストが必要です。これにより、Protected Audience API は、関連性のある広告のないインタレスト グループに対して
generateBid()を実行できなくなります。 - 類似のインタレスト グループを組み合わせると、
generateBid()を実行する必要がある回数が少なくなります。インタレスト グループのuserBiddingSignalsプロパティを使用すると、ユーザーに関する追加のメタデータを保存できます。これにより、インタレスト グループが少なくなってもターゲティングの効果が低下する可能性があります。 - Protected Audience API では、販売者が定めるインタレスト グループ数の上限と、購入者がインタレスト グループの相対的な優先度を指定するための API がサポートされています。この制限を使用すると、実行する入札スクリプトの数を大幅に減らすことができます。
Key-Value サービスの入札からインタレスト グループを除外します
購入者は、特定のインタレスト グループが入札すべきでない（キャンペーンが無効化されている、一時停止されている、予算不足である、特定のパブリッシャーに入札すべきではないなど）を、リアルタイム Trusted Bidding シグナル サーバーで判断できる場合、信頼できる入札シグナルの取得に対する priorityVector レスポンスでブラウザにその旨を通知できます。priorityVector と prioritySignals のスパース ドット積が負の場合、ブラウザはこのインタレスト グループに対する generateBid() の呼び出しをスキップします。このメカニズムの詳細については、説明の「インタレスト グループのフィルタリングと優先順位付け」セクションをご覧ください。
JavaScript 実行環境を再利用する
ブラウザで generateBid() を実行する前に、新しい JavaScript 実行環境を初期化する必要があります。これには、最小限の generateBid() 自体の実行にかかる時間と同じくらい、かなりの時間がかかることがあります。この時間は、オリジン別グループまたはフリーズ コンテキストの実行モードを使用することで短縮できます。
group-by-origin モードでは、インタレスト グループが同じオリジンで結合されている場合、実行環境を再利用できます。また、入札スクリプトに変更を加える必要はほとんどありません。詳しくは、説明の group-by-origin の説明をご覧ください。固定コンテキスト モードでは、潜在的にすべての実行環境を再利用できますが、入札スクリプトの変更が必要になる場合があります。詳しくは、説明の frozen-context の説明をご覧ください。
入札スクリプトを再利用する
可能な場合は、インタレスト グループに同じ入札スクリプトを使用します。これにより、ブラウザは複数のスクリプトをダウンロード、解析、コンパイルする必要がなくなります（これにより、追加のネットワーク リクエストが発生します）。ビッダーは、同じスクリプトを使用しながら、インタレスト グループの情報（name や userBiddingSignals など）に基づいて入札の差別化を図ることができます。
trustedBiddingSignalsUrls を再利用
ネットワーク レイテンシとリソース使用量は、非常に大きくなる可能性があります。リアルタイムの信頼できる入札シグナルの取得回数を減らすと、このレイテンシを短縮できます。
trustedBiddingSignalsUrl が複数のインタレスト グループ間で再利用される場合、信頼できる入札シグナルの取得を組み合わせることができます。可能な限り、すべてのインタレスト グループに同じ trustedBiddingSignalsUrl を使用します。
適切な HTTP キャッシュ コントロール ヘッダーを指定して、信頼できる入札シグナルの取得が特定のウェブページの広告スロット間でキャッシュされるようにします。trustedBiddingSignalsSlotSizeMode を slot-size に設定することは避けてください。そうすると、リクエストされた URL が異なるためにスロットのサイズが異なる場合に、広告スロットをまたいでキャッシュ保存されなくなります。
より小規模なリアルタイムの信頼できる入札シグナルを取得する
ネットワーク レイテンシは非常に大きくなる可能性があり、リアルタイムの信頼できる入札シグナルの取得中に転送されるデータの量に直接影響します。
広告固有またはインタレスト グループ固有のデータを、リアルタイムの信頼できる入札シグナル サービスではなく、インタレスト グループに保存することをおすすめします。信頼できるリアルタイムの入札シグナルデータは、キャンペーンの予算設定や強制切り替えなど、真にリアルタイムのシグナルに対してのみ予約してください。
毎日またはそれ以上の頻度で更新できるシグナルは、インタレスト グループに保存し、毎日の更新を使用して更新する必要があります。
「Key-Value サービスの入札からインタレスト グループを除外する」セクションの説明に沿って除外されたインタレスト グループに対しては、信頼できる入札シグナルを返さないでください。
インタレスト グループの優先順位付け
販売者はタイムアウトを使用して、パブリッシャーのページでブラウザ リソースが使用される方法を制限します。perBuyerCumulativeTimeouts を使用して、購入者が信頼できる入札シグナルを取得して入札スクリプトを実行する必要がある時間を制限する場合、購入者はインタレスト グループに優先順位を付け、オークションで勝つ可能性が高いユーザーが最初に実行されるようにすることが重要です。たとえば、perBuyerCumulativeTimeouts が 100 ミリ秒に設定され、ビッダーの信頼できる入札シグナルの取得に 50 ミリ秒かかり、generateBid() が 1 回呼び出されるのに 10 ミリ秒かかり、デバイスに 10 のインタレスト グループがある場合、インタレスト グループの半数だけが入札単価を計算できます。この例の購入者は、収益の可能性が最も高い順にインタレスト グループを優先順位付けする必要があります。
インタレスト グループには、priority フィールドで定義した静的な優先度を含めることができます。インタレスト グループでは、信頼できる入札シグナルサービスで計算され、信頼できる入札シグナルの取得に対する priorityVector レスポンスでブラウザに返される動的な優先度を使用することもできます。
ブラウザがインタレスト グループを優先度の高いものから順に実行すると、結合オリジンが異なるインタレスト グループが混在するため、group-by-origin による最適化が機能しなくなる可能性があります。
販売者向けベスト プラクティス
Protected Audience API オークションの効率をモニタリングして最適化していることを確認します。
オークションを並列化
最新のネットワーク接続とマルチコア プロセッサは、複数のアクティビティを同時に実行する優れた機能を備えています。ブラウザは、他のアクティビティと並行して Protected Audience オークションを実行できます。そのためには、できるだけ早く runAdAuction() を呼び出すことをおすすめします。runAdAuction() への一部の入力（コンテキストに基づくレスポンスでブラウザに送り返されるものなど）は、早い段階で利用できない可能性があることを認識した場合、ブラウザは、利用できるようになる前に runAdAution() を呼び出し、JavaScript Promise を使用してこれらの入力を後で提供できるようにします。オークションのレイテンシを可能な限り低く抑えるには、interestGroupBuyers 入力がわかっているときに runAdAuction() を呼び出す必要があります。これにより、ビッダーのリアルタイム ビッダー シグナルの取得など、オークションの多くの部分をすぐに開始できます。
オークションをモニタリングする
オークションに関する指標を収集します。ブラウザから販売者に per-buyer の遅延指標を報告して、販売者のオークションにかけられた時間について多くの分析情報を得ることができます。販売者はこれらの指標を基に、最も効果的にタイムアウトを設定する方法など、オークションを最適化する方法を見つけることができます。販売者は特定の購入者のレイテンシ指標を購入者と共有し、さらなる最適化に役立てることができます。
ビッダーは、自分のインタレスト グループの入札パフォーマンスに関する分析情報を持っている場合がありますが、その分析情報を他のビッダーと比較することはできません。さまざまなビッダーの相対的な落札率と入札拒否率を比較すると、インタレスト グループが有効な入札を行えなかったことや、未承認のクリエイティブで入札が過剰であったことが原因で入札のコンピューティング リソースが浪費されたケースを特定できます。
遅い入札スクリプトを防ぐ
入札スクリプトに時間がかかりすぎると、Protected Audience API オークションにかかわるすべての関係者にとって速度が低下する可能性があります。タイムアウトを使用すると、遅いオークションを防ぐと同時に、停滞しているオークションの収益を取り戻すことができます。
販売者は perBuyerCumulativeTimeouts を使用して、オークションが遅くなってタイムアウトになるのを防ぎ、またオークションが遅くてタイムアウトになった場合でも入札を受け入れるようにする必要があります。perBuyerCumulativeTimeouts は、インタレスト グループの数や generateBid() の速度に左右されないため、perBuyerCumulativeTimeouts の使用が推奨されます（perBuyerTimeouts と perBuyerGroupLimits の使用）。
オークション構成の signal フィールドを使用してオークション全体のタイムアウトを実装することも、信頼できるスコアリング シグナルの取得と scoreAd() の実行に時間がかかりすぎる場合に、過度に長いオークションが発生しないようにすることをおすすめします。
次のステップ
誰もが利用できる API を構築するために、Google は皆様との対話を通じてしたいと考えています。
API についてディスカッションする
他のプライバシー サンドボックス API と同様に、この API はドキュメント化され、一般公開されているです。
API を試す
Protected Audience API に関する会話をテストして参加できます。