Protected Audience API オークションのレイテンシを改善する
Protected Audience API オークションのレイテンシを改善するための一連のベストプラクティスを確認します。
FLEDGE の名前が Protected Audience API に変更されました。名前の変更の詳細については、ブログ記事をご覧ください。
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 をサポートしています。これらの制限を使用すると、実行する入札スクリプトの数を大幅に減らすことができます。
オークションに参加するインタレスト グループをフィルタリングする方法については、現在もディスカッションが続いています。この分野でアイデアがある場合は、GitHub のイシューを提出するか、Issue 305 に貢献してください。
オークション間で JavaScript 実行環境を再利用する方法についてのディスカッションが進行中です。環境を再利用すると、ブラウザが環境の初期化に費やす時間が短縮されます。以下をご覧ください。
- Issue 304
- Issue 310
- または、GitHub に新しいイシューを提出してください。
入札スクリプトを再利用する
個別のインタレスト グループで使用する共有の入札スクリプトをセットアップします。これにより、ブラウザが複数のスクリプトをダウンロード、解析、およびコンパイルして余分なネットワーク リクエストを発生させる必要がなくなります。
trustedBiddingSignalsUrls
を再利用する
ネットワークのレイテンシーとリソースの使用量が、非常に重要な場合があります。リアルタイムの信頼できる入札シグナルのフェッチ回数を減らすと、このレイテンシーを短縮できます。
trustedBiddingSignalsUrl
が複数のインタレスト グループ間で再利用される場合、信頼できる入札シグナルのフェッチを組み合わせることができます。可能な場合には、インタレスト グループ間で同じ trustedBiddingSignalsUrl
を使用します。
リアルタイムの信頼できる入札シグナルのフェッチ量を小さくする
ネットワークのレイテンシーが非常に大きくなる場合があり、これはリアルタイムの信頼できる入札シグナルのフェッチ中に転送されるデータの量から直接的な影響を受けます。
リアルタイムの信頼できる入札シグナル サービスではなく、広告固有またはインタレスト グループ固有のデータをインタレスト グループに保存することをお勧めします。キャンペーンの予算編成やキルスイッチなど、真にリアルタイムのシグナルのみのために、リアルタイムの信頼できる入札シグナル データを予約します。
毎日またはそれ以上の頻度で更新できるシグナルは、インタレスト グループに保存し、毎日の更新で更新する必要があります。
売り手のベストプラクティス
Protected Audience API オークションの効率を監視し、最適化していることを確認します。
オークションを監視する
オークションの指標を収集します。インタレスト グループのオーナーとインタレスト グループの入札の数は、オークションのパフォーマンスに大きな影響を与えるため、監視する必要があります。指標は scoreAd()
で表示できます。
scoreAd()
は、入札者が入札の計算にかかった時間を示す biddingDurationMsec
を受け取ります。マルチコア プロセッサは複数の入札スクリプトを同時に実行できますが、それでもパフォーマンスに大きな影響を与えるため、監視する価値があります。
入札者は、自身のインタレスト グループの入札パフォーマンスについて洞察を得ることができますが、これを他の入札者と比較することはできない場合があります。さまざまな入札者の相対的な落札率と入札拒否率を比較すると、インタレスト グループが実行可能な入札を行わなかったり、承認されていないクリエイティブで過剰な入札を行ったりしたために入札の計算リソースが浪費されたケースを特定するのに役立つ場合があります。
遅い入札スクリプトから保護する
入札スクリプトの実行に過度に時間がかかると、関係者全員の Protected Audience API オークションを遅らせる可能性があります。
- タイムアウトを使用します。Protected Audience API には入札スクリプトのデフォルトのタイムアウトが含まれていますが、
perBuyerTimeouts
を調整して、オークションに参加する入札者が過度に計算時間を使用しないようにすることができます。- Issue 293 で説明されているように、将来のタイムアウトと制限のディスカッションに参加することを検討してください。
- 制限を使用します。入札スクリプトのタイムアウトを設定すると、1 つのスクリプトの実行に時間がかかり過ぎてしまうのを防ぐことができますが、買い手は自由にユーザーを重複する可能性のある多数のインタレスト グループに追加できるため、各インタレスト グループは入札の機会と個別のタイムアウトを得ることができます。
perBuyerGroupLimits
を使用してインタレスト グループの数に制限を設定することで、個々の買い手が過度にオークション時間を消費するのを防ぐことができます。- 買い手と協力して、インタレスト グループの優先順位を確実に設定してください。そうすることで、最も重要なインタレスト グループが各オークションに確実に含まれるようになります。
今後の予定
すべての人にとって機能する API を確実に構築できるように、皆さんとの対話を持ちたいと考えています。
この API に関するディスカッション
他のプライバシーサンドボックス提案と同様に、この API は文書化され、公に議論されています。
API の実験
Protected Audience API を試して会話に参加できます。