本頁面由 Cloud Translation API 翻譯而成。

有效管理資料

許多 Google Ads 應用程式的核心功能，就是擷取要使用的帳戶資料例如資料分析、客戶查詢和政策遵循檢查擷取資料時，您應最佳化用量，以免超載或受到頻率受限的風險。詳情請參閱頻率限制及維護最新的聯絡電子郵件地址。

瞭解 Google 的報表資源使用政策

為了確保伺服器的穩定性，Google Ads API 會調節 GoogleAdsService.Search 和 GoogleAdsService.SearchStream 耗用過多的查詢模式大量 API 資源若特定查詢模式受到限制服務、方法和查詢模式將繼續運作，完全不受影響。受限的要求擲回下列錯誤：

API 版本	錯誤代碼
<= 第 17 版	`QuotaError.RESOURCE_EXHAUSTED`
>= 第 18 版	`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 伺服器的負載。

為了協助您追蹤費用較高的查詢，我們會發布初始匯總結果針對我們在其中所見之各種查詢模式的資源使用情形伺服器我們會定期發布更新的數字，協助您微調您的查詢。

時間範圍	平均 (第 50 個百分位數)。	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 的值篩選。下表顯示您可以在指定時間內執行的報表數量讓資源用量配合各種資源用量 Cloud Storage 也提供目錄同步處理功能方便您同步處理 VM 目錄與值區

時間範圍	平均值	適中	非常高
短期 (5 分鐘)	10	50	3000
長期 (24 小時)	26	150	14000

如果以這個查詢模式在 5 分鐘內執行 10 次，將計為平均值而以 5 分鐘為單位執行 3000 份報表，資料用量會非常高。

您可以透過下列幾種策略報表。本指南的其餘部分介紹了其中幾項策略。

快取資料

請將您從 API 伺服器擷取的實體詳細資料快取至本機讓您不必在每次需要資料時呼叫伺服器尤其是針對經常存取的實體，或是已變更這並非易事其中使用變更事件和變更狀態，能夠偵測從上次同步結果後有哪些物件變更。

最佳化執行報表的頻率

Google Ads 發布了有關資料更新間隔和做法的相關規範資料經常更新請根據這份指南以便擷取報表

如果您需要定期更新帳戶，建議您限制也就是一小部分的 Google Ads 帳戶數量 (例如只有前 20 名的 Google Ads 帳戶) 帳戶。其餘的更新頻率比較低，例如僅更新一次或一天兩次

最佳化報表大小

您的應用程式應擷取大量資料，而非執行大型小型報表的數量決定廣告狀態的其中一項因素是上限。

舉例來說，以下程式碼可用來擷取特定廣告的統計資料來更新統計資料資料庫的資料表：

  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 Ads 支援多達每個廣告活動最多 20,000 個廣告群組，每個帳戶最多 10,000 個廣告活動。如果這個程式碼適用於大型 Google Ads 帳戶，可能導致 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

標籤是將實體分組及減少報表數量的另一種方式舉個簡單的例子，您可以定義情境並指示 AI 如何回應服務中心查詢詳情請參閱標籤指南。

最佳化擷取內容

執行報表時，請留意您的查詢。假設以下範例排定為每次執行小時：

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

唯一每小時可能變動的資料欄為 metrics.clicks 和 metrics.impressions。所有其他欄很少更新因此，每小時擷取這些字串的效率很低您可以儲存並執行變更事件 (或變更狀態報表，每天下載一或兩次變更。

在某些情況下，您可以套用適當篩選器

清除未使用的帳戶

如果您的應用程式會管理第三方廣告客戶帳戶，您就必須開發應用程式時，請將客戶流失納入考量。建議您定期清理您的程序和資料儲存庫，為沒有相關客戶的客戶移除帳戶能夠減少使用者的需求清理未使用的 Google Ads 帳戶時，請保留請牢記下列原則：

撤銷客戶授予應用程式管理權限的授權他們的帳戶。
停止對客戶的 Google Ads 帳戶發出 API 呼叫，這尤其是 Cron 工作和資料管道這個 API 設計不需要使用者介入
如果客戶撤銷授權，您的應用程式妥善因應情況，避免將無效的 API 呼叫傳送至 Google 的 API 伺服器
如果客戶已經取消 Google Ads 帳戶，您應該偵測，避免將無效的 API 呼叫傳送至 Google 的 API 伺服器。
從客戶的 Google Ads 帳戶中刪除您從並對本機資料庫進行控管

監控

頻率限制