高效管理数据

许多 Google Ads 应用的一个核心功能是检索账号数据以供使用 数据分析、客户查询和政策合规检查等案例。 在提取数据时，您应该优化使用情况以免过载 Google 服务器，否则可能会受到速率限制。有关详情，请参阅 限制和维护 最新的联系电子邮件地址。

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

为了确保其服务器的稳定性，Google Ads API 限制了 GoogleAdsService.Search和 GoogleAdsService.SearchStream 占用过多资源的查询句式 API 资源数量如果特定查询句式受限，则其他查询句式 服务、方法和查询模式将继续正常运行，不受影响。通过 会抛出以下错误：

API 版本 错误代码
版本 17 以下 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 服务器上的负载。

为帮助您跟踪费用高昂的查询，我们将发布 有关我们在 Google Cloud 上发现的 我们的服务器我们会定期发布更新后的数据，以帮助您进行微调 您的查询。

时间窗口 平均值 (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 分钟内生成 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。所有其他列不经常更新或不经常更新 所以每小时获取一次它们的效率非常低您可以将这些 值并运行 change-event 或 change-status 报告，用于每天下载一次或两次更改。

在某些情况下，您可以应用 适当的过滤器

清理未使用的账号

如果您的应用管理第三方广告客户账号，则需要执行以下操作： 在开发应用时考虑到客户流失率。您应该定期 清理流程和数据存储区，为没有 使用您的应用清理未使用的 Google Ads 账号时， 以下指南：

  • 撤消客户向您的应用授予的管理权限 其账号。
  • 停止对客户的 Google Ads 账号进行 API 调用。这一点适用于 Cron 作业和数据流水线等离线作业 无需用户干预即可运行。
  • 如果客户撤消了授权，则您的应用 妥善处理这种情况，避免将无效的 API 调用发送到 Google 的 API 服务器
  • 如果客户撤销了其 Google Ads 账号，您应检测 并避免向 Google 的 API 服务器发送无效的 API 调用。
  • 从客户的 Google Ads 账号中删除您下载的数据， 一段时间之后，本地数据库的数据
上一页
监控
下一页
速率限制