收到响应和脚本完成不能证明已获取全部行。限制与延迟取决于具体API。
核查提取结果
检查时期、时区、过滤、字段、分页和响应元数据。GA4 Data API的rowCount表示查询结果的总行数，不只是单页行数；这不证明覆盖全部真实活动。遵守配额并标明部分提取。
区分四个时间
同日、同一时区的虚构示例：观测08:00，可用08:10，提取08:15，展示08:20。虽然提取仅过去5分钟，数据自观测已过20分钟。Data Studio等工具仍受来源延迟和缓存影响。
| 项目 | 时间 |
|---|---|
| 观测 | 08:00 |
| 可用 | 08:10 |
| 提取 | 08:15 |
| 展示 | 08:20 |
来源与核查
利用完整性证据自动提取数据。
即使生成的报告没有技术错误，也可能遗漏结果页面或使用不同的筛选条件。应保留时间窗口、架构和分页规则，然后检查总数和重复项。准备周期重放，同时确保不会静默丢失变更历史记录。
- 版本筛选条件、维度、单位、时区和分页。
- 将提取的样本与同一周期的源进行比较。
- 重放中断的提取过程，并检查是否存在丢失和重复项。
一手资料：Google SRE — Data Processing Pipelines. 相关方法：阅读实用指南.
时区与迟到事件
报告期间由事件时间和结算规则决定。
- 分别记录事件时间、接收时间和业务时区。虚构例中，23:30 UTC在固定偏移UTC+02:00下是次日01:30。PostgreSQL带时区的时间戳不会保留原始时区名称。
- 采用包含起点、不包含终点的区间。先在业务时区确定边界，再转换为UTC。测试夏令时切换、月末和没有时间的日期；本地一天不能总按24小时替代。
- 规定允许的延迟和报表截止时间。重放同一标识，区分新事件与重复记录。保留已发布版本并记录修订影响；水位线是到达时间的估计，不是数据完整性的保证。
可复现的验收案例
虚构示例：数据不代表客户或实际观察结果。
查看案例输入
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}预期判断
在指定时区中，该事件属于10月9日。也保留UTC时刻。
验证步骤
- 定义报告时区及参考时刻。
- 重现午夜附近的事件。
- 保留UTC、本地日期及截点规则。 加入时钟调整时存在歧义的本地时间，保留偏移量和时区，而不是推断具体时刻。
能把接收日期当作事件日期吗？
只有报表定义明确要求时才可以。保存两种时间，并解释迟到事件如何处理。
一手资料：PostgreSQL — Date/time types. 相关方法：阅读实用指南.