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

多くの Google 広告アプリケーションの中核となる機能は、データ分析、顧客へのクエリ、ポリシーの遵守状況チェックなどのユースケースで使用するアカウントデータの取得です。データの取得中は、Google サーバーに過負荷状態にならないように、またはレート制限が発生しないように使用量を最適化する必要があります。詳細については、レート制限と最新の連絡先メールアドレスの維持に関するガイドをご覧ください。

レポートに関する Google のリソース利用ポリシーについて

Google Ads API では、サーバーの安定性を確保するために、API リソースを大量に消費する GoogleAdsService.Search クエリパターンと GoogleAdsService.SearchStream クエリパターンをスロットリングしています。特定のクエリパターンがスロットリングされても、他のサービス、メソッド、クエリパターンは影響を受けません。スロットリングされたリクエストでは、次のエラーがスローされます。

API バージョン	エラーコード
v16 以下	`QuotaError.RESOURCE_EXHAUSTED`
v17 以降	`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 では、コストの高いクエリを追跡できるように、サーバー上で確認されたさまざまなクエリパターンのリソース消費量に関して集計された最初の統計情報を公開しています。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	3,000
長期（24 時間）。	26	150	14000

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

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

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

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

レポートの作成頻度を最適化する

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

アカウントを定期的に更新する必要がある場合は、少数の 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 Ads API サーバーに過負荷がかかり、レート制限やスロットリングが発生する可能性があります。

この場合は、単一のレポートを実行してローカルで処理することをおすすめします。メモリ内マップを使用したそのようなアプローチの一例を示します。

  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 つの方法です。詳しくは、ラベルガイドをご覧ください。

取得するデータを最適化する

レポートを実行するときは、クエリに含める列に注意してください。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 時間ごとに取得するのは非常に非効率的です。これらの値をローカルデータベースに保存し、変更イベントレポートまたは変更ステータスレポートを実行して、1 日に 1 ～ 2 回変更をダウンロードすることができます。

場合によっては、適切なフィルタを適用することで、ダウンロードする行の数を減らすことができます。

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

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

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

Monitoring

レート制限