Display & Video 360 API を使用するアプリケーションでは、割り当ての最適化が不可欠です。 割り当て使用量を最適化すると、API リクエストが合理化され、設定されたレート制限を超えた場合に返されるエラーを回避するため、パフォーマンスが向上します。
このページでは、一般的なおすすめの方法と、割り当て使用量の削減に役立つ Display & Video 360 API の補足機能について説明します。
さまざまな広告主に対して同時にリクエストを行う
Display & Video 360 API のほとんどのメソッドで、URL で広告主を指定します。同じ広告主を指定して呼び出しを行う場合は、プロジェクト全体の割り当てに加えて、より厳しい「広告主ごと、プロジェクトごと」のレート制限がこれらのメソッドに適用されます。
この割り当てを最適化するには、同時リクエストを別々の広告主を指定するリクエストだけに制限します。
filter パラメータと orderBy パラメータを使用する
複数のリソースを取得する場合は、get メソッドではなく list メソッドを使用します。ただし、ページサイズの制限により、list 呼び出しは依然として割り当てを大量に消費する可能性があります。完全なリスト レスポンスのサブセットのみを取得する必要がある場合は、オプションの filter パラメータと orderBy パラメータを利用して、割り当ての使用を最適化できます。
filter パラメータを使用すると、list 呼び出しで取得するリソースを、指定された式に従うプロパティを持つリソースに制限できます。このパラメータは、以下を取得しようとするときに便利です。
- ID は不明だがプロパティがわかっている特定のリソース。特定のリソースを検索する場合は、返されたリストを目的のリソースの既知のプロパティでフィルタできます。たとえば、既知の
displayNameで広告申込情報をフィルタしたり、想定されるcreativeTypeでクリエイティブをフィルタしたり、関連するexchangeで広告枠ソースをフィルタしたりできます。 - 関連リソース。多くの場合、ディスプレイ &ビデオ 360 のリソースは互いに関連付けられています。フィルタを使用すると、返されるリソースを、別のリソースと特定の関係を持つリソースに制限できます。たとえば、特定の
campaignIdの下にあるすべての広告掲載オーダーや、広告申込情報に割り当てられているすべてのクリエイティブを取得できます。 - 実行可能なプロパティを持つリソースのみ。API 機能を使用すると、リソースのステータスを簡単に確認してプログラムで対応できます。フィルタを使用すると、
list呼び出しを使用して、アクションが必要なリソースのみを取得できます。たとえば、特定の対応可能なlineItemWarningMessageを示すすべての広告申込情報、特定の日時以降に更新されたすべての広告掲載オーダー、失敗したapprovalStatusすべてのクリエイティブの取得などが考えられます。
orderBy パラメータを使用すると、取得したリソースを特定のプロパティで昇順または降順で並べ替えることができます。orderBy は、特に filter と併用する場合は、特定のリソースを見つける前に走査する必要があるページ数を制限するために使用できます。また、リソースリストの上限と下限も簡単に取得できます。たとえば、updateTime で並べ替えると、広告主の最新の広告申込情報や広告掲載オーダーをすばやく見つけることができます。
一括関数とリソース全体関数を使用する
Display & Video 360 API には、1 つのリクエストで多数のアクションを実行する一括関数やリソース全体を対象とする関数が多数用意されています。このような関数の例を以下に示します。
- 1 つのチャネルに属するサイトの一括編集チャネルには数千のサイトを割り当てることができます。個別の
createリクエストまたはdeleteリクエストでチャネルのサイトリストを管理する代わりに、1 つのbulkEditリクエストまたはreplaceリクエストを使用して、多数のサイトの追加と削除、チャネルのコンテンツ全体の置き換えをそれぞれ行うことができます。 - 広告主のターゲティング スイート全体を管理する。リソースのターゲティング スイートは、複数のターゲティング タイプに割り当てられます。リソースレベルのターゲティング関数（
advertisersサービスのlistAssignedTargetingOptionsやeditAssignedTargetingOptionsなど）を使用すると、1 つのリクエストで複数のターゲティング タイプにわたるターゲティングを取得、作成、削除できます。これにより、広告主のターゲティング スイートを 1 つのリクエストに設定するクォータ費用を削減できます。 - 複数の広告申込情報に同じターゲティング制限を設定する。複数の広告申込情報に同じターゲティングの変更を一度に行う必要がある場合は、1 つの
advertisers.lineItems.bulkEditAssignedTargetingOptionsリクエストを使って変更できます。 - 複数の広告申込情報を有効化または一時停止する広告申込情報は作成後に配信を
開始する必要があります複数の広告申込情報を連続して作成する場合は、1 回の
advertisers.lineItems.bulkUpdateリクエストですべての広告申込情報を有効にできます。同じ方法で、複数の広告申込情報を一時停止して配信を停止することもできます。
定期的に使用する ID をキャッシュに保存して確認する
Display & Video 360 API の多くのオペレーションでは、API 自体を通じて取得されるリソース ID（ターゲティング オプション ID、Google オーディエンス ID など）を使用する必要があります。使用するたびに API から ID を取得しなくても済むように、これらの ID をローカルに保存することをおすすめします。
ただし、一部のリソースは非推奨となったり、削除されたり、使用できなくなったりすることがあります。これらのリソースに ID を使用しようとすると、エラーが返されることがあります。したがって、適切な get またはフィルタリングされた list メソッドを使用して、キャッシュに保存されたすべての ID を週に 1 回チェックして、ID がまだ取得可能で、想定されたステータスになっていることを確認することをおすすめします。
長時間実行オペレーションに指数バックオフを実装する
SDF のダウンロード タスクなどの長時間実行オペレーションが完了したかどうかを確認するポーリング中は、指数バックオフ戦略を使用して、送信されるリクエストの頻度と合計数を減らします。
指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理戦略で、クライアントは時間をかけてリクエストを定期的に再試行します。指数バックオフを適切に使用すると、帯域幅の使用効率が向上し、正常なレスポンスの取得に必要なリクエストの数が減り、同時実行環境でのリクエストのスループットが最大化されます。
クライアント ライブラリで実装された指数バックオフ戦略については、SDF のダウンロード コードサンプルをご覧ください。単純な指数バックオフを実装する詳細なフローは次のとおりです。
- API に
sdfdownloadtasks.operations.getリクエストを行います。 - オペレーション オブジェクトを取得します。
doneフィールドが true でない場合は、リクエストを再試行する必要があることを示します。- 5 秒 + 乱数のミリ秒間待機してから、リクエストを再試行します。
- オペレーション オブジェクトを取得します。
doneフィールドが true でない場合は、リクエストを再試行する必要があることを示します。- 10 秒 + ミリ秒のランダムな待機時間を待機してから、リクエストを再試行します。
- オペレーション オブジェクトを取得します。
doneフィールドが true でない場合は、リクエストを再試行する必要があることを示します。- 20 秒 + ミリ秒のランダムな待機時間を待機してから、リクエストを再試行します。
- オペレーション オブジェクトを取得します。
doneフィールドが true でない場合は、リクエストを再試行する必要があることを示します。- 40 秒 + ミリ秒のランダムな待機時間を待機してから、リクエストを再試行します。
- オペレーション オブジェクトを取得します。
doneフィールドが true でない場合は、リクエストを再試行する必要があることを示します。- 80 秒 + ミリ秒のランダムな待機時間を待機してから、リクエストを再試行します。
- クエリ オブジェクトが更新されるか、最大経過時間に達するまで、このパターンを続行します。