Google 広告のサービスに関するご意見やご提案は、Google 広告と測定のコミュニティサーバーの公式 Google 広告 Discord チャンネルにご参加ください。

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

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

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

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

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

エラーコード
`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 回など、低い頻度で更新できます。

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

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

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

  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 サーバーに過負荷がかかり、レート制限とスロットリングが発生する可能性があります。

より良い方法は、単一のレポートを実行してローカルで処理することです。インメモリマップを使用するアプローチの 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 ジョブやデータパイプラインなどのオフラインジョブに特に当てはまります。
お客様が承認を取り消した場合は、アプリケーションが状況を適切に処理し、無効な API 呼び出しを Google の API サーバーに送信しないようにする必要があります。
お客様が Google 広告アカウントを解約している場合は、それを検出し、無効な API 呼び出しを Google の API サーバーに送信しないようにする必要があります。
お客様の Google 広告アカウントからダウンロードしたデータは、適切な期間が経過したらローカルデータベースから削除します。

Monitoring

レート制限