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 サービスで入札からインタレスト グループを除外する
購入者がリアルタイムの信頼できる入札シグナル サーバーで、特定のインタレスト グループに入札すべきでないこと（キャンペーンが無効、一時停止、予算超過である、または特定のパブリッシャーに入札すべきでないことなど）を判断できる場合は、信頼できる入札シグナルの取得に対する priorityVector レスポンスでブラウザにその旨を通知できます。priorityVector と prioritySignals の計算結果が負の場合、ブラウザはこのインタレスト グループの generateBid() の呼び出しをスキップします。このメカニズムの詳細については、説明の「興味 / 関心グループのフィルタリングと優先順位付け」セクションをご覧ください。
JavaScript 実行環境を再利用する
ブラウザが generateBid() を実行する前に、新しい JavaScript 実行環境を初期化する必要があります。この処理には、最小限の generateBid() 自体の実行にかかる時間と同程度の時間がかかる場合があります。この時間を節約するには、送信元別グループ化または凍結コンテキストの実行モードを使用します。
group-by-origin モードでは、インタレスト グループが同じオリジンで結合されている場合に実行環境を再利用できます。また、入札スクリプトの変更は不要な可能性があります。詳細については、説明のgroup-by-origin の説明をご覧ください。フリーズされたコンテキスト モードでは、すべての実行環境を再利用できます。ただし、入札スクリプトの変更が必要になる場合があります。詳しくは、説明の frozen-context の説明をご覧ください。
入札スクリプトを再利用する
可能であれば、インタレスト グループに同じ入札スクリプトを使用します。これにより、ブラウザが複数のスクリプトをダウンロード、解析、コンパイルする必要がなくなります（これにより、余分なネットワーク リクエストが発生します）。ビッダーは、同じスクリプトを使用して、興味 / 関心グループの情報（name や userBiddingSignals など）に基づいて入札を差別化できます。
HTTP キャッシュ制御ヘッダーがないと、入札スクリプトはキャッシュに保存されません。スクリプトが不必要に取得されないように、適切なヘッダーを指定してください。ページ上で複数のオークションが同時に実行されている場合、同じビッダーの入札スクリプトがすでにメモリ内にある場合は、キャッシュ セマンティクスを無視して再利用されます。オークションが順番に実行される場合、ブラウザは HTTP キャッシュ メカニズムに準拠します。
ブラウザは、入札時（generateBid() の場合）とレポート時（reportWin() の場合）に入札スクリプトを読み込みます。キャッシュ制御ヘッダーが設定されていない場合、ブラウザは同じスクリプトを 2 回取得します（期間ごとに 1 回ずつ）。
そのため、すべてのスクリプトにキャッシュ制御ヘッダーを設定することをおすすめします。
trustedBiddingSignalsUrls を再利用する
ネットワーク レイテンシとリソース使用量は非常に大きくなる可能性があります。リアルタイムの信頼できる入札シグナルの取得回数を減らすと、このレイテンシを短縮できます。
trustedBiddingSignalsUrl が複数のインタレスト グループ間で再利用される場合、信頼できる入札シグナルの取得を組み合わせることができます。可能な限り、すべてのインタレスト グループに同じ trustedBiddingSignalsUrl を使用してください。
適切な HTTP キャッシュ コントロール ヘッダーを指定して、信頼できる入札シグナルの取得が特定のウェブページの広告スロット全体でキャッシュに保存されるようにします。trustedBiddingSignalsSlotSizeMode を slot-size に設定しないでください。設定すると、リクエストされた URL が異なるため、スロットのサイズが異なる場合に広告スロット間でキャッシュに保存できなくなります。
リアルタイムの信頼できる入札シグナルの取得量の削減
ネットワーク レイテンシは非常に大きくなる可能性があります。これは、リアルタイムの信頼できる入札シグナルの取得中に転送されるデータの量に直接影響します。
広告固有のデータやインタレスト グループ固有のデータを、リアルタイムの信頼できる入札シグナル サービスではなく、インタレスト グループに保存することをおすすめします。リアルタイムの信頼できる入札シグナル データは、キャンペーンの予算やキルスイッチなど、真にリアルタイムのシグナルにのみ予約します。
1 日またはそれ以上の頻度で更新できるシグナルは、インタレスト グループに保存し、毎日の更新を使用して更新する必要があります。
「Key-Value サービスで入札からインタレスト グループを除外する」セクションで説明されているように、除外されたインタレスト グループの信頼できる入札シグナルを返さないでください。
インタレスト グループの優先順位付け
販売者はタイムアウトを使用して、パブリッシャーのページでブラウザ リソースの使用方法を制限します。perBuyerCumulativeTimeouts を使用して、信頼できる入札シグナルの取得と入札スクリプトの実行に要する時間を制限する場合は、オークションで落札する可能性が高いインタレスト グループを優先して、まず実行するようにすることが重要です。たとえば、perBuyerCumulativeTimeouts が 100 ms に設定され、ビッダーの信頼できる入札シグナルの取得に 50 ms かかり、各 generateBid() 呼び出しに 10 ms かかり、デバイスに 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() の速度に依存しないため、perBuyerTimeouts や perBuyerGroupLimits を使用するよりも perBuyerCumulativeTimeouts を使用することをおすすめします（たとえば、入札が速いインタレスト グループが多数ある場合と、入札が遅いインタレスト グループが少数ある場合でも、両方ともタイムアウト前に完了できます）。
オークション構成の signal フィールドを使用してオークション全体のタイムアウトを実装することも、信頼できるスコアリング シグナルの取得と scoreAd() の実行に時間がかかりすぎる場合にオークションが長くなりすぎないようにする良い方法です。
次のステップ
誰もが利用できる API を構築するために、Google は皆様との対話を通じてしたいと考えています。
API についてディスカッションする
他のプライバシー サンドボックス API と同様に、この API はドキュメント化され、一般公開されているです。
API を試す
Protected Audience API に関する会話をテストして参加できます。