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