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

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

多くの Google 広告アプリケーションの中核となる機能に、使用するアカウントデータの取得が含まれるケースに対応。データの取得中は、過負荷にならないように使用量を最適化する必要があります。制限されます。詳細については、このモジュールのコースリソースにレート制限と、最新の連絡先メールアドレス。

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

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

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 サーバーの負荷。

コストの高いクエリをトラッキングできるように、さまざまなクエリパターンのリソース消費量に関する統計情報を提供します。定期的に最新の数値を公開します。分析できます

期間	平均（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 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

ラベルはエンティティをグループ化してレポート数を減らすもう一つの方法です。分析できます詳しくは、ラベルガイドをご覧ください。

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

レポートを実行する際は、レポートに含める列を分析できます実行時間ごとに実行されるようにスケジュール設定された次の例について考えてみましょう。時:

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-status レポートを使用して、1 日に 1 ～ 2 回変更をダウンロードします。

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

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

アプリケーションで第三者の広告主アカウントを管理する場合は、以下を行う必要があります。顧客のチャーンを念頭に置いてアプリケーションを開発できます定期的にプロセスとデータストアをクリーンアップして、減らすことができます未使用の Google 広告アカウントをクリーンアップする際は、次のガイダンスに留意してください:

顧客からアプリケーションに付与した管理権限を取り消しますできます。
お客様の Google 広告アカウントへの API 呼び出しを停止します。適用される cron ジョブやデータパイプラインなどのオフラインジョブには実行されるように設計されています。
顧客が承認を取り消した場合、アプリケーションは無効な API 呼び出しが送信されないようにし、 Google の API サーバーです。
お客様が Google 広告アカウントの利用を停止している場合は、無効な API 呼び出しを Google の API サーバーに送信しないようにする必要があります。
顧客の Google 広告アカウントからダウンロードしたデータをローカルデータベースで保持します。

Monitoring

レート制限