おすすめのレポート方法

まず管理画面で新しいレポートを作成する

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

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

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

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

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

ReportType 関連するフィルタと指標
INVENTORY_AVAILABILITY
  • 接頭辞 FILTER_TRUEVIEW_IAR のフィルタ。
YOUTUBE
  • 接頭辞 FILTER_TRUEVIEW が付いたフィルタ（接頭辞 FILTER_TRUEVIEW_IAR の付いたフィルタを除く）。
  • 接頭辞 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 から、生成されたレポート ファイルを取得できます。