改善报表性能

如今，越来越多的企业用户正在使用我们的报表API生成同步报表。有时用户调用API的方式会导致频繁超时，进而影响了报表产品的整体性能。为确保所有用户能够顺利集成，我们现在对以下四个场景进行了改善。

场景1

如果您的API请求满足以下条件之一，那么我们将拦截相应请求。 - 您的查询维度包括behavior_id，并且查询的ID数量超过200个。

注意
我们已优化了通过/report/integrated/get/（不带有order_field和enable_total_metrics参数）获取的、具有behavior_id维度的受众报告的报告性能。此优化将增加查询的ID数量至2000。请注意，第一个请求可能需要很长时间才能获取返回。但是，查询参数相同但页数不同的后续请求可以快速返回。
此优化目前为白名单功能。如需使用此功能，请联系您的TikTok销售代表。一旦您进入白名单，就无需添加新的请求参数，我们将在下游自动启用参数。

• 您的查询维度包括interest_category/interest_category_tier2/interest_category_tier3/interest_category_tier4，并且查询的ID数量超过了下表列出的数量限制。

场景2

如果您的开发者应用频繁超时，我们将动态降低您的QPS限制，具体调整如下： - 如果在10秒内有10个超时请求，那么QPS限制将暂时降低至5 QPS，持续5分钟。 - 如果在10秒内有20个超时请求，那么QPS限制将被临时降低至1 QPS，持续5分钟。 - 如果在10秒内有30个超时请求，那么QPS限制将被临时降低至0 QPS，持续5分钟。

场景3

如果您重试同一个请求，并且在10分钟内该请求超时3次及以上，那么我们将在您的开发者应用中暂时拦截该重试请求，持续10分钟。

场景4

如果您在某场景下的每日超时率大于80%（例如，当您查询30天内受众的年龄和性别分布，并且返回ID数量超过20,000个），那么我们将在您的开发者应用中拦截该请求。

如果您的每日超时率在某些情况下超过80%，那么在这些情况下，我们将拦截您开发者应用的请求。

示例：当您查询30天内受众的年龄和性别分布，并且返回ID数量超过20,000个，那么我们将会拦截该请求。

为了避免超时，我们建议：

• 当您查询3天内受众的年龄/性别/地区分布时，返回的ID数量应该不超过5,000个。
• 当您查询7天内受众的年龄/性别/地区分布时，返回的ID数量应该不超过2,000个。