おすすめのレポート方法

まず UI で新しいレポートを作成する

レポートには、レポートの種類、フィルタ、ディメンション、指標に関連する多くの制限と要件が適用されます。これらの制限は API で適用され、HTTP 400 エラーが返されます。レポートの作成時にエラーが発生しないように、まずディスプレイ＆ビデオ 360 の管理画面で新しいレポートを作成することをおすすめします。

レポートを作成したら、リファレンス ドキュメント ページの [この API を試す] 機能をクリックして、Query リソースの queries.get を実行します。返された JSON を使用して、今後のレポートを作成できます。

レポートタイプに固有の指標とフィルタを使用する

一部の指標とフィルタの値は、特定のレポート タイプに固有です。まず UI でレポートを作成するだけでなく、特定の ReportType 値に属する指標とフィルタを、Bid Manager API の値で特定することもできます。

関連する Bid Manager API のフィルタと指標の値を特定する方法はいくつかあります。この表は、これらのタイプのレポートで使用できるフィルタと指標を網羅したものではありません。すべての値を 1 つのレポートで一緒に使用できるわけではありません。

ReportType 関連するフィルタと指標
YOUTUBE
  • 接頭辞が FILTER_TRUEVIEW のフィルタ。
  • 接頭辞が METRIC_TRUEVIEW の指標。
GRP
  • 接頭辞が METRIC_GRP の指標。
YOUTUBE_PROGRAMMATIC_GUARANTEED
  • 接頭辞が FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED のフィルタ。
  • 接頭辞が METRIC_PROGRAMMATIC_GUARANTEED の指標。
REACH
  • 接頭辞が METRIC_UNIQUE_REACH の指標。
UNIQUE_REACH_AUDIENCE
  • 接頭辞が METRIC_UNIQUE_REACH の指標。

レポートを保存、再利用する

同じレポートを何度も挿入したり削除したりするとリソースが浪費されるため、定期的に実行するクエリのレポートを作成して保存しておくことをおすすめします。dataRange フィールドに設定された Range 値（PREVIOUS_DAY や LAST_7_DAYS など）を使用すると、レポートの再利用が容易になります。

レポートのスケジュール設定

アドホック レポートや 1 回限りのレポートは個別に実行され、不完全なデータセットに対しても実行される可能性があるため、リソースを浪費するおそれがあります。スケジュールに基づくレポートは一括して実行され、前日分のデータ処理が完了するまで実行されないことが保証されているため、レポート リソースが最大限に活用されます。詳細については、使用できるスケジュールのフィールドをご覧ください。

類似のレポートを統合する

異なる広告主またはパートナーに対して、同じ指標と期間のレポートを定期的に生成する場合は、レポートを統合してレポートの量を最適化することをおすすめします。

類似のレポートを組み合わせるには、すべてのレポートのフィルタを追加し、すべてのフィルタタイプをディメンションとして追加します。生成後、生成されたレポートの行を元のフィルタ値で分割して、元のレポートを生成できます。

レポートの割り当てを検討する

ディスプレイ＆ビデオ 360 のレポート機能を責任ある形で利用していただくため、サービス全体で次の使用量割り当てが適用されます。

1 日あたりのアドホック レポートの実行数

ユーザーが 24 時間以内に実行できるアドホック レポートの数を制限します。この割り当てを超えないようにするには、次のようにします。

有効なスケジュール設定レポート

一定期間にユーザーがアクティブにスケジュール設定できるレポートの数を制限します。この割り当てを超えないようにするには、次のようにします。

同時実行レポート

ユーザーが同時に実行できるレポートの数を制限します。この割り当てを超えないようにするには、次のようにします。

  • 定期的に実行されるレポートをスケジュール設定します。
  • 不要な API スクリプトを無効にします。
  • 指数バックオフ ロジックを使用してポーリングし、レポートの完了時間を追跡します。

レポートの実装を最適化しているにもかかわらず、特定の割り当てを超えている場合は、お問い合わせフォームからディスプレイ＆ビデオ 360 サポートまでお問い合わせください。

レポートのステータスをポーリングする際に指数バックオフを使用する

レポートの実行にかかる時間を予測することはできません。時間の長さは、期間や処理されるデータの量など多くの要因によって、数秒から数時間まで変動します。レポートの実行時間とレポートに含まれる行数との間にも相関関係はありません。したがって、queries.reports.get メソッドを使用してレポート リソースを定期的に取得し、リソースの metadata.status.state フィールドが DONE または FAILED に更新されているかどうかを確認して、実行が完了したかどうかを判断する必要があります。このプロセスを「ポーリング」と呼びます。

ポーリングは必要なものではありますが、実行に長時間を要するレポートに遭遇した場合、実装効率が悪いと割り当てられたリソースをすぐに使い切ってしまう可能性があります。したがって、指数バックオフを使用して再試行回数を制限し、割り当てリソースを節約することをおすすめします。

指数バックオフ

指数バックオフはネットワーク アプリケーションで使用される標準的なエラー処理戦略で、失敗したリクエストをクライアントが再試行する際に、失敗するたびに次の再試行までの待機時間を増やしていく方法です。指数バックオフを適切に使用すると、帯域幅の使用効率が高くなり、より少ないリクエスト数で正常なレスポンスを受け取ることができ、同時実行環境でのリクエストのスループットが最大化します。

単純な指数バックオフを実装するフローを次に示します。

  1. API に queries.reports.get リクエストを送信します。
  2. レポート オブジェクトを取得します。metadata.status.state フィールドが DONE または FAILED でない場合、レポートの実行が完了していないことを示します。この場合は、ポーリングを続行する必要があります。
  3. 5 秒 + ランダムなミリ秒間待機してから、リクエストを再試行します。
  4. レポート オブジェクトを取得します。metadata.status.state フィールドが DONE または FAILED でない場合、レポートの実行が完了していないことを示します。この場合は、ポーリングを続行する必要があります。
  5. 10 秒 + ランダムなミリ秒間待機してから、リクエストを再試行します。
  6. レポート オブジェクトを取得します。metadata.status.state フィールドが DONE または FAILED でない場合、レポートの実行が完了していないことを示します。この場合は、ポーリングを続行する必要があります。
  7. 20 秒 + ランダムなミリ秒間待機してから、リクエストを再試行します。
  8. レポート オブジェクトを取得します。metadata.status.state フィールドが DONE または FAILED でない場合、レポートの実行が完了していないことを示します。この場合は、ポーリングを続行する必要があります。
  9. 40 秒 + ランダムなミリ秒間待機してから、リクエストを再試行します。
  10. レポート オブジェクトを取得します。metadata.status.state フィールドが DONE または FAILED でない場合、レポートの実行が完了していないことを示します。この場合は、ポーリングを続行する必要があります。
  11. 80 秒 + ランダムなミリ秒間待機してから、リクエストを再試行します。
  12. レポート オブジェクトが更新されるか、経過時間が最大時間に達するまで、このパターンを続けます。

レポートの実行が完了し、DONE 状態になった場合は、metadata.googleCloudStoragePath フィールドで指定されたパスの Google Cloud Storage から生成されたレポート ファイルを取得できます。