首次用户获取来源、会话来源和关键事件的贡献分配是不同视角。有效报告应在比较渠道前明确这些作用域。
确定共同基准
定义时间段、时区、币种、转化和归因窗口。对购买，应将事件与订单核对，检查重复并说明退款处理方式。归因收入既不是利润率，也不是增量利润。
按作用域阅读GA4维度
表格区分流量来源的三个作用域。更改报告归因模型不会改写用户和会话维度。忽略该差异可能造成表面矛盾。
| 作用域 | 问题 | 模型选择的影响 |
|---|---|---|
| 用户 | 首次获客来源 | 该作用域的维度不变 |
| 会话 | 每次会话的来源 | 该作用域的维度不变 |
| 事件 | 关键事件的贡献分配 | 取决于所选报告归因模型 |
行动前记录差异
注明标记、同意、覆盖范围和转化延迟的变化。将定义与提取日期随报告保留。平台间的差异需要核对测量范围，不应自动触发预算重分配。
来源与核验
- Google Analytics — Scopes of traffic-source dimensions
- Google Analytics — Minimize duplicate key events with transaction IDs
- Google Analytics — Get started with attribution
多渠道报告需要权威的统计数据。
多个渠道可能对同一用户旅程做出贡献。在每个报告中定义功劳分配，并统计唯一结果的来源。检查窗口期、中断跟踪以及未指定广告系列参数的回访访客；直接访问并不一定意味着之前没有贡献。
- 记录归因模型和窗口期。
- 将唯一结果与渠道功劳进行核对。
- 披露未跟踪用户旅程的限制。
平台归因的销售额是否应该相加？
不应作为唯一订单的计数。每个报告都可能对同一笔销售进行功劳分配；呈现协调和重叠情况。
一手资料：Google Analytics — Campaign URL data. 相关方法：阅读实用指南.
时区与迟到事件
报告期间由事件时间和结算规则决定。
- 分别记录事件时间、接收时间和业务时区。虚构例中，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. 相关方法：阅读实用指南.