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

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

多くの 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 のサーバーで確認されたさまざまなクエリパターンのリソース消費量について、最初の集計統計を公開しています。クエリを微調整できるように、更新された数値を定期的に公開します。

期間	平均（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 回実行すると平均使用量としてカウントされますが、3, 000 件のレポートを 5 分間で実行すると使用量が非常に多くなります。

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

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

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

1 つのレポートを実行してローカルで処理する方が良いアプローチです。ここでは、メモリ内マップを使用するアプローチの 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 時間ごとに取得するのは非効率です。これらの値をローカルデータベースに保存し、変更イベントレポートまたは変更ステータスレポートを実行して、1 日に 1 回または 2 回、変更をダウンロードすることができます。

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

使用していないアカウントの削除

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

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

Monitoring

レート制限