高效管理数据

许多 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 服务器上各种查询句式的资源消耗汇总统计信息，可帮助您跟踪和微调高开销查询：

时间窗口 平均值 (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(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 账号下载的数据。
上一页
监控
下一页
速率限制