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 または frozen-context 実行モードを使用することで節約できます。
group-by-origin モードでは、インタレスト グループが同じオリジンで結合されている場合に実行環境を再利用できるため、入札スクリプトの変更は必要ない可能性があります。詳しくは、説明記事の group-by-origin の説明をご覧ください。フリーズ コンテキスト モードでは、すべての実行環境を再利用できますが、入札スクリプトの変更が必要になる場合があります。詳しくは、説明の frozen-context の説明をご覧ください。
入札スクリプトを再利用する
可能であれば、インタレスト グループに同じ入札スクリプトを使用します。これにより、ブラウザが複数のスクリプトをダウンロード、解析、コンパイルする必要がなくなり（ネットワーク リクエストの追加が発生しなくなります）、入札者は、同じスクリプトを使用しながら、インタレスト グループ情報（name や userBiddingSignals など）に基づいて入札を区別できます。
HTTP キャッシュ制御ヘッダーがない場合、入札スクリプトはキャッシュに保存されません。適切なヘッダーを指定して、スクリプトが不必要に取得されないようにします。ページで複数のオークションが並行して実行されている場合、同じ入札者の入札スクリプトがすでにメモリ内にある場合は、キャッシュ保存のセマンティクスを無視して再利用されます。オークションが順番に実行される場合、ブラウザは HTTP キャッシュ メカニズムに準拠します。
ブラウザは、入札時（generateBid() の場合）とレポート時（reportWin() の場合）に入札スクリプトを読み込みます。キャッシュ制御ヘッダーが設定されていない場合、ブラウザは同じスクリプトを 2 回（各期間に 1 回）取得します。
そのため、すべてのスクリプトにキャッシュ制御ヘッダーを設定することをおすすめします。
再利用 trustedBiddingSignalsUrls
ネットワーク レイテンシとリソース使用量が非常に大きくなる可能性があります。リアルタイムの信頼できる入札シグナルの取得回数を減らすと、このレイテンシを短縮できます。
複数のインタレスト グループ間で trustedBiddingSignalsUrl が再利用される場合、信頼できる入札シグナルの取得を組み合わせることができます。可能な場合は、すべてのインタレスト グループに同じ trustedBiddingSignalsUrl を使用します。
適切な HTTP キャッシュ制御ヘッダーを指定して、特定のウェブページの広告スロット間で信頼できる入札シグナルの取得がキャッシュに保存されるようにします。trustedBiddingSignalsSlotSizeMode を slot-size に設定しないでください。スロットのサイズが異なる場合、リクエストされる URL が異なるため、広告スロット間でキャッシュ保存が行われなくなります。
リアルタイムの信頼できる入札シグナルの取得を削減
ネットワーク レイテンシは非常に大きくなる可能性があり、リアルタイムの信頼できる入札シグナルの取得中に転送されるデータ量に直接影響します。
広告固有のデータまたはインタレスト グループ固有のデータは、リアルタイムの信頼できる入札シグナル サービスではなく、インタレスト グループに保存することが推奨されます。キャンペーンの予算設定やキルスイッチなど、真にリアルタイムのシグナルのみにリアルタイムの信頼できる入札シグナル データを予約します。
毎日またはそれ以上の頻度で更新できるシグナルは、インタレスト グループに保存し、毎日の更新を使用して更新する必要があります。
「Key/Value サービスで入札からインタレスト グループを除外する」セクションで説明されているように、フィルタで除外されたインタレスト グループの信頼できる入札シグナルを返さないでください。
インタレスト グループの優先順位付け
販売者はタイムアウトを使用して、パブリッシャー ページでのブラウザ リソースの使用を制限します。perBuyerCumulativeTimeouts を使用して、バイヤーが信頼できる入札シグナルを取得して入札スクリプトを実行する時間を制限する場合、バイヤーは、オークションで落札する可能性が最も高いインタレスト グループが最初に実行されるように、インタレスト グループの優先順位を必ず設定する必要があります。たとえば、perBuyerCumulativeTimeouts が 100 ミリ秒に設定されていて、入札者の信頼できる入札シグナルの取得に 50 ミリ秒かかり、各 generateBid() 呼び出しに 10 ミリ秒かかり、デバイスに 10 個のインタレスト グループが存在する場合、インタレスト グループの半分だけが入札を計算する機会を得ます。この例の購入者は、落札の可能性が高い順にインタレスト グループの優先度を設定する必要があります。
インタレスト グループには、priority フィールドで定義された静的優先度を含めることができます。インタレスト グループは、信頼できる入札シグナル サービスで計算され、信頼できる入札シグナル取得に対する priorityVector レスポンスとともにブラウザに返される動的優先度を使用することもできます。
ブラウザが優先度の高い順にインタレスト グループを実行すると、異なる参加元からのインタレスト グループが混在し、group-by-origin の最適化が妨げられる可能性があります。
販売者向けベスト プラクティス
Protected Audience API オークションの効率性をモニタリングし、最適化していることを確認します。
オークションを並列化する
最新のネットワーク接続とマルチコア プロセッサは、複数のアクティビティを同時に実行するのに優れています。ブラウザは、他のアクティビティと並行して Protected Audience オークションを実行できます。この処理は、できるだけ早く runAdAuction() を呼び出すことで最適化できます。runAdAuction() への入力の一部（コンテキスト応答でブラウザに返されるものなど）は、初期段階では利用できない可能性があることを認識して、ブラウザでは、それらが利用可能になる前に runAdAution() を呼び出し、JavaScript Promises を使用して後でこれらの入力を行うことが許可されています。オークションのレイテンシを可能な限り低減するには、interestGroupBuyers 入力がわかった時点で runAdAuction() を呼び出す必要があります。これにより、入札者のリアルタイム ビッダー シグナルの取得など、オークションの多くの部分をすぐに開始できます。
オークションをモニタリングする
オークションに関する指標を収集します。ブラウザは、販売者のオークションでの時間の使い方に関する多くの分析情報を提供する販売者に、per-buyer レイテンシ指標をレポートできます。販売者はこれらの指標を使用して、オークションを最適化する方法を検討できます。たとえば、タイムアウトを最も効果的に設定する方法を把握できます。販売者は、特定の購入者のレイテンシ指標を購入者と共有して、購入者がさらに最適化できるようにすることができます。
入札者は自社のインタレスト グループの入札パフォーマンスに関する分析情報を取得できますが、他の入札者と比較することはできません。さまざまなビッダーの相対的な落札率と入札拒否率を比較すると、インタレスト グループが有効な入札を生成しなかったり、承認されていないクリエイティブで過剰な入札が行われたりしたために、入札コンピューティング リソースが無駄になったケースを特定できます。
入札スクリプトの遅延を防ぐ
時間がかかりすぎる入札スクリプトは、Protected Audience API のオークションを遅くする可能性があります。タイムアウトを使用すると、オークションが遅延した場合でも収益を回復しながら、オークションの遅延を防ぐことができます。
営業担当者は、perBuyerCumulativeTimeouts を使用して、オークションの遅延を防ぎ、オークションが遅延してタイムアウトに達した場合でも入札を受け付ける必要があります。perBuyerCumulativeTimeouts はインタレスト グループの数や generateBid() の速度について意見を持たないため、perBuyerTimeouts や perBuyerGroupLimits よりも perBuyerCumulativeTimeouts を使用する方が望ましいです（たとえば、入札が速いインタレスト グループが多数あり、入札が遅いインタレスト グループが少数ある場合でも、両方ともタイムアウト前に完了できます）。
オークション構成の signal フィールドを使用してオークションの全体的なタイムアウトを実装することも、信頼できるスコアリング シグナルの取得と scoreAd() の実行に時間がかかりすぎる場合に、オークションが長くなりすぎるのを防ぐための良い方法です。
次のステップ
誰もが利用できる API を構築するために、Google は皆様との対話を通じてしたいと考えています。
API についてディスカッションする
他のプライバシー サンドボックス API と同様に、この API はドキュメント化され、一般公開されているです。
API を試す
Protected Audience API に関する会話をテストして参加できます。