このページは Cloud Translation API によって翻訳されました。

データを効率的に管理する

多くの Google 広告アプリケーションのコア機能は、データ分析、お客様からのお問い合わせ、ポリシー遵守チェックなどのユースケースで使用するためにアカウントデータを取得することです。データを取得する際は、Google サーバーが過負荷にならないように、またはレート制限を受けるリスクがないように、使用量を最適化する必要があります。詳しくは、レート制限と最新の連絡先メールアドレスの維持に関するガイドをご覧ください。

レポートのリソース使用量に関する Google のポリシーを理解する

Google Ads API は、サーバーの安定性を確保するため、過剰な量の API リソースを使用する GoogleAdsService.Search クエリパターンと GoogleAdsService.SearchStream クエリパターンをスロットリングします。特定のクエリパターンがスロットリングされても、他のサービス、メソッド、クエリパターンは影響を受けずに動作します。スロットリングされたリクエストに対して、次のエラーがスローされます。

API バージョン	エラーコード
<= v17	`QuotaError.RESOURCE_EXHAUSTED`
>= v18	リソース使用率が高い時間に応じて、`QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION` または `QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION`。

費用の高いレポートを特定してモニタリングできるように、個々のレポートの費用指標も返されます。

メソッド	費用フィールド
`GoogleAdsService.Search`	`SearchGoogleAdsResponse.query_resource_consumption`
`GoogleAdsService.SearchStream`	`SearchGoogleAdsStreamResponse.query_resource_consumption`

これらのフィールドから返される費用指標は、次のようなさまざまな要因によって異なります。

アカウントのサイズ
レポートでフェッチするビューと列
Google Ads API サーバーへの負荷。

費用のかかるクエリを追跡できるように、Google は、サーバー上で発生するさまざまなクエリパターンのリソース使用量に関する最初の集計統計情報を公開します。クエリの微調整に役立つよう、更新された数値が定期的に公開されます。

期間	平均（p50）。	P70（中程度）	P95（非常に高い）
短期（5 分）	6000	30000	1800000
長期（24 時間）。	16000	90000	8400000

たとえば、次のようなクエリパターンを実行しているとします。このクエリパターンは、レポートごとに 600 ユニットのリソースを消費します。

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = "YYYY-MM-DD"

このクエリを複数の顧客アカウントに対して複数の個別の日付で実行するには、クエリを変更して segments.date フィルタに異なる値を代入します。次の表に、リソース使用量がさまざまなリソース使用量バケットに収まるように、特定の時間枠で実行できるレポートの数を示します。

期間	平均	やや高い	非常に高い
短期（5 分）	10	50	3000
長期（24 時間）。	26	150	14000

このクエリパターンを 5 分間に 10 回実行した場合は平均使用量と見なされますが、5 分間に 3, 000 件のレポートを実行した場合は非常に高い使用量と見なされます。

レポートのリソース使用量を最適化する方法はいくつかあります。このガイドの残りの部分では、これらの戦略の一部について説明します。

データをキャッシュに保存する

データが必要になるたびにサーバーを呼び出すのではなく、API サーバーから取得したエンティティの詳細をローカルデータベースにキャッシュに保存する必要があります。特に、アクセス頻度が高いエンティティや、変更頻度が低いエンティティの場合は、この方法がおすすめです。可能であれば、change-event と change-status を使用して、結果を最後に同期してから変更されたオブジェクトを検出します。

レポートの実行頻度を最適化する

Google 広告では、データの更新頻度と更新頻度に関するガイドラインを公開しています。このガイダンスに基づいて、レポートの取得頻度を決定する必要があります。

アカウントを定期的に更新する必要がある場合は、そのようなアカウントの数を少数のセットに制限することをおすすめします（たとえば、上位 20 個の Google 広告アカウントのみなど）。残りは、1 日に 1 ～ 2 回など、より低い頻度で更新できます。

レポートのサイズを最適化する

アプリケーションは、多数の小さなレポートを実行するのではなく、大量のバッチデータを取得する必要があります。この選択に影響する要因として、アカウントの上限があります。

たとえば、特定の広告グループの統計情報を取得し、統計データベーステーブルを更新する次のコードについて考えてみましょう。

  List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  foreach (long adGroupId in adGroupIds)
  {
    string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
        "metrics.cost_micros, metrics.impressions, segments.date FROM " +
        "ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
        "ad_group.id = ${adGroupId}";
    List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

このコードは、小規模なテストアカウントで適切に機能します。ただし、Google 広告では、キャンペーンごとに最大 20,000 個の広告グループ、アカウントごとに最大 10,000 個のキャンペーンをサポートしています。そのため、このコードを大規模な Google 広告アカウントに対して実行すると、Google 広告 API サーバーが過負荷状態になり、レート制限とスロットリングが発生する可能性があります。

1 つのレポートを実行してローカルで処理するほうが適切です。インメモリマップを使用するこのようなアプローチの例を示します。

  Hashset<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
      "metrics.cost_micros, metrics.impressions, segments.date FROM " +
      "ad_group WHERE segments.date DURING LAST_7_DAYS";
  List<GoogleAdsRow> rows = RunGoogleAdsReport(customer_id, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  for each (GoogleAdsRow row in rows)
  {
    var adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (long adGroupId in memoryMap.Keys())
  {
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

これにより、実行されるレポートの数が減るため、Google Ads API サーバーの負荷が軽減されます。

レポートが大きすぎてメモリに収まらない場合は、次のように LIMIT 句を追加してクエリを小さなグループに分割することもできます。

SELECT
  ad_group.id,
  ad_group.name,
  metrics.clicks,
  metrics.cost_micros,
  metrics.impressions,
  segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
  AND ad_group.id IN (id1, id2, ...)
LIMIT 100000

エンティティをグループ化してレポートクエリの数を減らす方法として、ラベルもあります。詳しくは、ラベルガイドをご覧ください。

フェッチする内容を最適化する

レポートを実行する際は、クエリに含める列に注意する必要があります。1 時間ごとに実行される次の例について考えてみましょう。

SELECT
  customer.id,
  customer.currency_code,
  campaign.id,
  campaign.name,
  ad_group.id,
  ad_group.name,
  ad_group_criterion.keyword.match_type,
  ad_group_criterion.keyword.text,
  ad_group_criterion.criterion_id,
  ad_group_criterion.quality_info.creative_quality_score,
  ad_group_criterion.system_serving_status,
  ad_group_criterion.negative,
  ad_group_criterion.quality_info.quality_score,
  ad_group_criterion.quality_info.search_predicted_ctr,
  ad_group_criterion.quality_info.post_click_quality_score,
  metrics.historical_landing_page_quality_score,
  metrics.search_click_share,
  metrics.historical_creative_quality_score,
  metrics.clicks,
  metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS

1 時間ごとに変更される可能性が高い列は metrics.clicks と metrics.impressions のみです。他のすべての列は頻繁に更新されないか、まったく更新されないため、1 時間ごとに取得するのは非常に非効率的です。これらの値をローカルデータベースに保存し、change-event レポートまたは change-status レポートを実行して、1 日に 1 ～ 2 回変更をダウンロードできます。

適切なフィルタを適用することで、ダウンロードする行数を減らすことができます。

使用していないアカウントをクリーンアップする

アプリケーションがサードパーティの顧客アカウントを管理する場合は、顧客の解約を念頭に置いてアプリケーションを開発する必要があります。プロセスとデータストアを定期的にクリーンアップして、アプリケーションを使わなくなったお客様のアカウントを削除する必要があります。使用していない Google 広告アカウントを削除する際は、次のガイダンスにご留意ください。

お客様がアカウントの管理のためにアプリに付与した承認を取り消します。
お客様の Google 広告アカウントへの API 呼び出しを停止します。これは、ユーザーの介入なしで実行するように設計された cron ジョブやデータパイプラインなどのオフラインジョブに特に当てはまります。
お客様が承認を取り消した場合、アプリケーションは状況を適切に処理し、Google の API サーバーに無効な API 呼び出しを送信しないようにする必要があります。
お客様が Google 広告アカウントを解約した場合は、そのことを検出し、Google の API サーバーに無効な API 呼び出しを送信しないようにする必要があります。
適切な期間が経過したら、お客様の Google 広告アカウントからダウンロードしたデータをローカルデータベースから削除します。

Monitoring

レート制限