许多 Google Ads 应用的核心功能是检索帐号数据,以用于数据分析、客户查询和政策合规性检查等用例。在提取数据时,您应该优化使用情况,以免 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 服务器的负载。
为了帮助您跟踪费用高昂的查询,我们针对在我们的服务器上发现的各种查询模式,发布了关于资源消耗量的初始汇总统计信息。我们会定期发布更新后的数据,以帮助您微调查询。
时间窗口 | 平均值 (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 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
列可能会每小时变化。所有其他列的更新频率较低或根本不更新,因此,如果按小时提取这些列,效率会非常低下。您可以将这些值存储在本地数据库中,并运行 change-event 或 change-status 报告,以便每天下载一到两次更改。
在某些情况下,您可以通过应用适当的过滤条件来减少下载的行数。
清理未使用的账号
如果您的应用管理第三方广告主帐号,则您在开发应用时需要考虑到客户流失情况。您应该定期清理流程和数据存储区,以便为不再使用您的应用的客户移除帐号。清理未使用的 Google Ads 账号时,请牢记以下指南:
- 撤消客户向您的应用授予的管理其账号的授权。
- 停止对客户的 Google Ads 帐号进行 API 调用。这尤其适用于在无需用户干预的情况下运行的离线作业,例如 Cron 作业和数据流水线。
- 如果客户撤消了授权,您的应用应妥善处理这种情况,并避免向 Google 的 API 服务器发送无效的 API 调用。
- 如果客户已取消其 Google Ads 帐号,则您应该检测出来,并避免向 Google 的 API 服务器发送无效的 API 调用。
- 适当一段时间后,从本地数据库中删除您从客户的 Google Ads 账号中下载的数据。