此页面由 Cloud Translation API 翻译。

高效管理数据

许多 Google Ads 应用的一项核心功能是检索账号数据，以用于数据分析、客户查询和政策合规性检查等用例。提取数据时，您应优化使用情况，以免 Google 服务器过载或冒限速的风险。如需了解详情，请参阅有关速率限制和维护最新的联系电子邮件地址的指南。

了解 Google 针对报告的资源使用政策

为确保服务器的稳定性，Google Ads API 会限制占用过多 API 资源的 GoogleAdsService.Search 和 GoogleAdsService.SearchStream 查询模式。如果特定查询模式被节流，其他服务、方法和查询模式将继续正常运行，不受影响。系统会针对被节流的请求抛出以下错误：

API 版本	错误代码
<= v17	`QuotaError.RESOURCE_EXHAUSTED`
>= v18	`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 账号中下载的数据。

监控

速率限制