有效管理資料

許多 Google Ads 應用程式的核心功能是擷取帳戶資料，以用於資料分析、客戶查詢和政策遵循檢查等用途。擷取資料時，請盡量減少用量，以免 Google 伺服器負載過重，或面臨頻率限制。詳情請參閱頻率限制和維護最新聯絡電子郵件地址指南。

瞭解報表的使用政策

為確保伺服器穩定，Google Ads API 會限制消耗過多 API 資源的 GoogleAdsService.Search 和 GoogleAdsService.SearchStream 查詢模式。如果特定查詢模式受到節流，其他服務、方法和查詢模式仍會繼續運作，不受影響。系統會針對遭節流的要求擲回下列錯誤：

錯誤代碼
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION 或 QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION 視資源使用率偏高的時間長度而定。

如果遇到這些錯誤，請等待 5 分鐘，再重試因 QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION 而失敗的要求；如果要求因 QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION 而失敗，請等待 30 分鐘。

為協助您找出及監控高成本報表，我們也會傳回個別報表的費用指標：

方法 費用欄位
GoogleAdsService.Search SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream SearchGoogleAdsStreamResponse.query_resource_consumption

這些欄位傳回的費用指標取決於多項因素，例如：

  • 帳戶大小
  • 報表中擷取的檢視畫面和資料欄
  • Google Ads API 伺服器的負載

下表列出 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下表顯示在指定時間範圍內可執行的報表數量，讓資源用量符合各種資源用量 bucket。

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

在 5 分鐘內執行 10 次這類查詢模式，會計為平均用量；在 5 分鐘內執行 3000 份報表，則會計為極高用量。

您可以採取幾種策略，最佳化報表的資源消耗。本指南其餘部分將介紹其中幾項策略。

快取資料

您應在本地資料庫中快取從 API 伺服器擷取的實體詳細資料，而不是每次需要資料時都呼叫伺服器，尤其是經常存取或不常變更的實體。請盡可能使用 change-event 和 change-status，偵測自上次同步處理結果以來，有哪些物件發生變更。

調整報表執行頻率

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(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

由於執行的報表數量減少，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

每小時可能變更的資料欄只有 metrics.clicks 和 metrics.impressions。其他所有資料欄的更新頻率都很低，甚至完全不更新，因此每小時擷取一次的效率極低。您可以將這些值儲存在本機資料庫中，並執行變更事件或變更狀態報表，每天下載一或兩次變更。

在某些情況下，您可以套用適當的篩選條件，減少下載的資料列數量。

清理未使用的帳戶

如果您的應用程式管理第三方客戶帳戶，則在開發應用程式時，必須考量客戶流失的情況。您應定期清理程序和資料存放區，移除不再使用應用程式的客戶帳戶。清理未使用的 Google Ads 帳戶時，請注意下列指引：

  • 撤銷客戶授予應用程式管理帳戶的授權。
  • 停止對客戶的 Google Ads 帳戶發出 API 呼叫。這項規定特別適用於離線工作，例如 Cron 工作和資料管道，這些工作設計為不需使用者介入即可執行。
  • 如果顧客撤銷授權，應用程式應妥善處理這種情況，避免向 Google 的 API 伺服器傳送無效的 API 呼叫。
  • 如果客戶已取消 Google Ads 帳戶，請偵測已取消的帳戶，避免向 Google 的 API 伺服器傳送無效的 API 呼叫。
  • 在適當時間後，從本機資料庫刪除從客戶 Google Ads 帳戶下載的資料。
上一頁
監控
下一頁
頻率限制