許多 Google Ads 應用程式的核心功能,在於擷取帳戶資料,以便用於資料分析、客戶查詢和政策合規檢查等用途。擷取資料時,建議您最佳化用量,以免 Google 伺服器超載,或受到頻率限制。詳情請參閱有關頻率限制的指南,以及維護最新的聯絡電子郵件地址。
瞭解 Google 的報表資源使用政策
為確保伺服器的穩定性,Google Ads API 會限制 GoogleAdsService.Search
和 GoogleAdsService.SearchStream
查詢模式耗用過多 API 資源。如果特定查詢模式受到節流限制,其他服務、方法和查詢模式仍會繼續運作。受限的要求系統會擲回下列錯誤:
API 版本 | 錯誤代碼 |
---|---|
<= 第 16 版 | QuotaError.RESOURCE_EXHAUSTED |
>= 第 17 版 | 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
篩選器的不同值,為多個個別日期執行這項查詢。下表顯示了在特定時間範圍內可以執行的報表數量,讓資源用量適合各種資源用量值區。
時間範圍 | 平均值 | 適中 | 非常高 |
---|---|---|---|
短期 (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(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
唯一每小時可能變更的資料欄為 metrics.clicks
和 metrics.impressions
。所有其他資料欄很少更新或完全不更新,因此每小時擷取這些資料欄的效率很低。您可以將這些值儲存在本機資料庫中,並執行變更事件或變更狀態報表,以每天一或兩次下載變更。
在某些情況下,您可以套用適當的篩選器來減少下載的資料列數。
清除未使用的帳戶
如果您的應用程式會管理第三方廣告客戶帳戶,您就必須在開發應用程式時考量客戶流失。您應定期清除程序和資料儲存庫,以便為不再使用您應用程式的客戶移除帳戶。清理未使用的 Google Ads 帳戶時,請記住下列原則:
- 撤銷客戶授予應用程式管理其帳戶的授權。
- 停止對客戶的 Google Ads 帳戶發出 API 呼叫,這尤其適用於離線工作,例如 Cron 工作和資料管道,這些工作是設計用來在無需使用者介入的情況下執行。
- 如果客戶撤銷授權,您的應用程式應妥善處理這個情況,避免向 Google 的 API 伺服器傳送無效的 API 呼叫。
- 如果客戶已取消 Google Ads 帳戶,您應偵測帳戶,避免將無效的 API 呼叫傳送至 Google 的 API 伺服器。
- 經過適當時間範圍後,請將您從客戶的 Google Ads 帳戶下載的資料從本機資料庫中刪除。