您的 GA4 属性报告上个月有 4,180 笔交易。而您的订单表显示为 4,690 笔。如果问哪个数据正确，诚实的答案是两者都不正确，除非您能解释缺失的 510 笔订单去了哪里。这不是数据整理的问题。您生成的每一个实验结果和每一个优先级评分都是基于一个存在未知误差且方向不明的数字计算得出的。
谷歌将大量未测量的数据视为正常数据：只有在房产记录出现后，才会启用行为建模以进行用户同意模式的验证。 每天至少发生1,000起事件 analytics_storage='denied' 至少7天再往下，缺失数据仍然缺失。
这适用于电商团队中负责分析或转化率优化（CRO）的人员。最终，您将获得一份核对表，一份将差距分解为具体原因并针对每个原因进行测试的清单，以及一个您可以据此进行解释的容差值。
采购对账实际衡量的是什么
数据核对并非“让数字匹配”。它们永远不可能完全匹配，强行匹配的团队通常比放任差距不管更糟糕。数据核对旨在解答三个问题：差距有多大？哪些机制造成了差距？以及可以弥补多少差距，需要付出多大代价？我们会在任何实验性工作之前进行数据核对，因为一项基于转化事件的测试，如果悄无声息地导致一部分订单流失，那就不能称之为实验。
步骤 1：提取两个可以根据订单 ID 连接的表
对于同一日历范围的每个订单，您需要从两个系统中各提取一行，并且键在两个系统中都存在。
- 后端： 订单 ID、在物业报告时区创建的时间戳、在 GA4 中配置的相同税费和运费基础上的订单价值、付款方式、设备、国家/地区、状态。
- GA4： 是 BigQuery 导出，不是用户界面。查询
purchase事件ecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue设备类别和流量来源。
特意使用 BigQuery。来自用户同意模式的建模数据出现在 GA4 标准报告和一些探索性报告中，但 Google 表示并非如此。 不会 在 BigQuery 导出中，您可以查看受众群体、用户探索、用户群组或留存率探索，以及预测指标。将用户界面与您的订单表进行比较，实际上是在比较估算值和事实值。
然后基于订单 ID 进行全外连接。现在您有三个存储桶：同时包含两者、仅包含后端数据、仅包含 GA4 数据。第三个存储桶较小，但最具诊断意义。
步骤二：用三种方式表达差距，而不是一种。
单一的月度百分比掩盖了所有信息。请计算所有三个百分比：
- 订单数量差距： （后端订单减去匹配的 GA4 购买记录）/ 后端订单。这样可以找出跟踪丢失的原因。
- 收入缺口： 对价值也进行同样的计算。如果数量差距为 3%，收入差距为 11%，那么你遇到的不是跟踪问题，而是价值定义问题（税收、运费、折扣、货币、礼品卡）。
- 每日缺口波动： 绘制每日订单数量差距图。平坦的曲线表示结构性原因，例如用户许可或障碍。峰值则表示部署、营销活动爆发或支付服务商故障。
步骤 3：将差距分解为已命名的原因
请按此表操作。每一种病因都有相应的检测方法，可以在一小时内确诊或排除。
| 原因 | 如何测试 | 数据中的签名 |
|---|---|---|
| 拒绝授权，标签不会触发。 | 将您 CMP 的同意状态日志与同一时期的 GA4 会话进行比较。 | 日均占比稳定；主要集中在欧盟和土耳其的流量。 |
| 广告和追踪器拦截器 | 统计确认 URL 的服务器日志请求次数，并与该 URL 上的 GA4 购买事件进行比较。 | 桌面版、Firefox 和隐私浏览器存在偏差；长期稳定 |
| 确认页面始终无法加载。 | 统计服务器日志中从未请求过确认 URL 的仅后端订单数量 | 专注于银行转账和3DS支付方式 |
| 重复购买事件 | 统计 GA4 购买事件 transaction_id | GA4 有时会导致后端性能下降；页面刷新和后退按钮使用频繁。 |
| 跨域链接已断开 | 检查是否 _gl 经受住了支付提供商的返程考验 | 购买行为会进入归因于支付域的新会话，作为推荐。 |
| Cookie 生命周期重置 | 按浏览器细分新用户率 | Safari 和 iOS 上的新用户和直接流量虚高 |
| 模型与原始数据 | 将 GA4 UI 总计与 BigQuery 中相同日期范围内的数据进行比较。 | 在你打开订单表格之前，这两个谷歌数字就存在差异。 |
| 价值定义 | 重新计算包含和不包含税费、运费和折扣的后端收入 | 计数相符，但收入不符 |
| 时区边界 | 重新汇总为整周数据 | 按周粒度计算，差距逐渐缩小至零。 |
两人需要特别关照。 transaction_id 去重功能仅适用于网页数据流，不适用于应用数据流。谷歌警告称，发送空字符串会导致 Analytics（分析）去重失败。 每周 购买活动携带 transaction_id=''一个漏洞就可能让你一天的大部分时间白白浪费。另外，每个数据流中不需要的推荐链接列表最多只能包含 50 个域名，如果你使用多个收单机构、钱包和银行页面，这会造成很大的不便。
【需要内部数据：在Switas的和解工作中观察到的这九个原因的分布情况，以便读者了解哪些原因通常占主导地位。】
第四步：设定你能捍卫的容忍度
谷歌并未公布可接受的偏差范围，而广为流传的“5%可以接受”的说法也未出现在我们查阅过的任何谷歌文档中。建议您根据分解结果而非单纯的数值来设定此偏差范围。
| 月度订单数量差距 | 阅读 | 操作 |
|---|---|---|
| 截至2％ | 时区边缘和正常去重 | 记录原因，每季度复查一次 |
| 2％5％ | 只有当每个点都归因于明确的原因时，这种做法才可接受。 | 先记录，然后进行实验。 |
| 5％10％ | 至少有一个结构性问题尚未解决。 | 在信任绝对转换率数字之前，请先进行修正。 |
| 高于10％ | 不适合用于实验 | 在问题解决之前，请停止使用 GA4 购买量作为主要实验指标。 |
这些是我们设定的运营阈值，并非行业标准。关键在于：无法解释的3%比已解释的8%更糟糕。
步骤 5：按每小时工作恢复订单数量最多的顺序进行调整
- 值定义和时区。 配置，而非工程，通常需要一个下午的时间。
- 重复和空的交易 ID。 一个数据层修复。
- 跨域和不必要的引用。 配置好两者后，请重新测试正式支付退款路径，而不是测试环境。
- 服务器端购买事件。 使用测量协议，通过您的订单系统发送采购订单。
client_id您的网页代码已生成。Google 要求这些事件必须在原始客户端事件时间戳后的 48 小时内提交，否则归因处理可能无法按预期进行。这可以恢复因拦截器或从未渲染的确认页面而丢失的订单。 - 同意架构。 最慢且最具政治性的部分。将剩余部分视为已知、有规模且有据可查的差距。
在土耳其或欧盟销售产品会有什么变化？
两个地区性因素影响了数据。
在土耳其，用户也需要选择加入才能获得同意，但没有谷歌的安全保障。 土耳其数据保护局于2022年12月23日作出第2022/1358号决定，对一家网站运营商处以30万土耳其里拉的罚款，原因是其在没有法律依据的情况下运行广告和营销cookies，并要求用户主动选择加入非必要cookies。许多土耳其网站对此的回应是直接屏蔽谷歌标签，而不是发送同意信号。这种区别代价高昂：建模需要 analytics_storage='denied' 事件必须存在。如果横幅广告不触发任何内容，谷歌就无法建立模型，因此数据会丢失而不是被估算出来。
土耳其的 3DS 流程通过邮寄方式将买家退回。 使用 iyzico，商家会渲染一个解码后的 3DS 页面，并在 OTP 验证后，iyzico 会将用户重定向到商家的网站。 callbackUrl - status, paymentId 和 mdStatusPOST 请求驱动的返回正是 Google 所说的破坏跨域测量的结果，因为重定向可能会移除数据。 _gl 在目的地加载之前。如果您发现刷卡支付的差额接近于零，而货到付款的差额接近于零，原因就在这里。
两项被广泛流传的说法，我们无法核实。
“Safari 将第一方 Cookie 的有效期限制为 7 天。” 不准确。WebKit 的文档指出，ITP 会在 7 天后删除 JavaScript cookie 和其他脚本可写存储。 无需用户交互此外，当用户通过分类域名的链接装饰访问着陆页时，JavaScript cookie 的有效期会被单独限制在 24 小时。Simo Ahava 的测试发现，有效期是根据浏览器使用天数而非日历天数计算的，因此回头客的标识符可能会保留超过一周。
“5%的误差是可以接受的。” 我们在谷歌上找不到任何与此数据相关的来源。该数据在供应商博客和论坛问答中流传。请将其视为坊间传闻，而非确凿证据。
这种方法失效的地方
它不涵盖应用流，而应用流则不涵盖应用流。 transaction_id 去重功能不适用，也不适用于订阅和部分发货模式，因为在这些模式下，“一个订单”并非指单一事件。它无法恢复被拒绝授权用户的身份，只能估算订单量。它也无法解决渠道归因问题，这是一个更复杂、更棘手的问题。此外，它还假设您的订单表是干净的：如果取消订单和被阻止欺诈的订单在双方的统计方式不一致，您将徒劳地追查一个仅存在于您的查询中的数据缺失。
常见问题
我们应该多久运行一次这个程序？ 先进行一次完整的分解，然后生成每日差距图。每次结账、CMP、支付提供商或标签管理器发生更改后，都要重新运行完整的分解。
为什么不使用 GA4 界面而要使用 BigQuery 呢？ 界面可以包含导出数据中未包含的建模用户和会话，因此谷歌给出的两个数据彼此不一致。与估算值进行比对，使得这种差异无法分解。
服务器端标记能否彻底消除这种差距？ 不。它只能恢复因拦截器或确认页面未加载而丢失的订单，无法恢复已拒绝授权的用户订单。
GA4 的版本高于我们的后端版本。这可能吗？ 是的。通常是由于页面刷新导致的重复购买事件，或者是空的或重复使用的购买事件。 transaction_id或者，将订单分发到生产场所。
同意模式能否解决土耳其式的同意差距？ 部分如此。被拒绝的信号使得建模成为可能，但需遵守谷歌的流量阈值。它不能替代土耳其法律规定的合法横幅广告。
怎样的差距才算合理？ 每一个百分点都有名称。有据可查的8%胜过无法解释的3%。
修复此问题后，我们是否需要重新发布历史报告？ 不。请标注固定日期，并将各个期间视为单独的序列。重复跟踪的转换会破坏审计跟踪。
当差距超过 10% 时，我们还能进行 A/B 测试吗？ 使用测试工具内部测量的相对指标运行它们，但在差距分解之前，不要报告 GA4 的绝对收入影响。
本月请在您自己的店铺运行此项对账，或者 让我们的分析团队和你一起运行它 并将分解结果、容差和修正顺序交给你。
来源
- [GA4] Google Analytics 帮助中心关于同意模式的行为建模
- [GA4] 使用交易 ID 最大程度减少重复的关键事件，Google Analytics 帮助
- [GA4] 不必要的引荐，Google Analytics 帮助
- [GA4] 跨域测量，Google Analytics 帮助
- 将测量协议事件发送到 Google Analytics 和 Google for Developers。
- 同意模式参数，Google Tag Platform 文档
- WebKit 中的跟踪预防
- Simo Ahava 报道：WebKit 浏览器中 JavaScript Cookie 的过期时间限制已被移除。
- KVKK 库鲁卡拉里 2022/1358, 2022 年 12 月 23 日
- 3DS 实现，iyzico 开发人员文档
