以下限制和配额适用于 Data API。
配额类别
Data API 提供了三种请求配额类别:核心、实时和漏斗。向核心方法发出的 API 请求会消耗核心配额。向实时方法发出的 API 请求会消耗实时配额。每个请求只会消耗一种配额。
配额类别 | API 方法 |
---|---|
核心 | runReport、runPivotReport、batchRunReports、batchRunPivotReports、runAccessReport、getMetadata、checkCompatibility、createAudienceExports |
实时 | runRealtimeReport |
漏斗图 | runFunnelReport |
Google Analytics 媒体资源配额
所有请求都会消耗媒体资源配额。
配额名称 | 标准版媒体资源的数量上限 | Analytics 360 版媒体资源数量上限 |
---|---|---|
每项媒体资源每天的核心令牌数 | 200000 | 200 万 |
每项媒体资源每小时的核心令牌数 | 40000 | 400000 |
每个项目每项媒体资源每小时的核心令牌数 | 14,000 | 140,000 |
每项媒体资源的核心并发请求数 | 10 | 50 |
每个项目每项媒体资源每小时的核心服务器错误数 | 10 | 50 |
每项媒体资源每天的实时令牌数 | 200000 | 200 万 |
每项媒体资源每小时的实时令牌数 | 40000 | 400000 |
每个项目每项媒体资源每小时的实时令牌数 | 14,000 | 140,000 |
每项媒体资源的实时并发请求数 | 10 | 50 |
每个项目每项媒体资源每小时的实时服务器错误数 | 10 | 50 |
每项媒体资源每天的漏斗令牌数 | 200000 | 200 万 |
每项媒体资源每小时的漏斗令牌数 | 40000 | 400000 |
每个项目每项媒体资源每小时的漏斗令牌数 | 14,000 | 140,000 |
每项媒体资源的漏斗并发请求数 | 10 | 50 |
每个项目每项媒体资源每小时的漏斗服务器错误数 | 10 | 50 |
- 并发请求是指同时执行的请求数量。为了减少请求并发量,请等待之前的请求完成,然后再发送其他请求。
- 服务器错误代码为 500 和 503。只有当请求导致服务器错误时,系统才会扣减服务器错误配额。当项目和媒体资源对的服务器错误配额耗尽时,系统会阻止该项目对该媒体资源的所有请求。
- 每个请求都会消耗“每项媒体资源每小时的令牌数”配额和“每个项目每项媒体资源每小时的令牌数”配额。也就是说,必须有超过 3 个项目访问某项媒体资源,“每项媒体资源每小时的令牌数”配额才会在“每个项目每项媒体资源每小时的令牌数”配额之前耗尽。
媒体资源每小时可以发出 120 个可能受阈值限制的请求。维度 userAgeBracket
、userGender
、brandingInterest
、audienceId
和 audienceName
可能会设置阈值。我们之所以应用限额,是为了防止查看报告的人通过其中的数据推断出用户的受众特征或兴趣。
媒体资源令牌配额
系统会根据请求的复杂程度,为每个请求计算令牌。大多数请求的费用将不超过 10 个令牌。如果请求消耗了大量配额令牌,通常是以下因素造成的:
- 行数较多
- 列数量较多
- 复杂的过滤条件
- 长日期范围
对于每个 API 请求,您都可以在请求正文中指定 "returnPropertyQuota": true
,以返回当前媒体资源配额令牌状态。此状态包含此请求消耗的数量以及每个配额组的剩余数量。例如,考虑在 RunReportRequest
中指定此参数。