GA4 电商埋点 playbook
你店里每个转化决策都站在这套管道上。相当多的店跑着一条重复计数、丢步骤、错归因的漏斗——还在垃圾上自信地做决定。
GA4 的电商模型是一串事件——view_item、add_to_cart、begin_checkout、add_shipping_info、add_payment_info、purchase——各自携带 items 数组与金额参数。做对了，下游所有分析都成立；错得微妙，下游一切都在礼貌地撒谎。这份 playbook 实现模型、对照事实校验、装上随店铺变化保持诚实的检查。
阶段一：完整实现事件模型
不完整的实现是常态也是问题：有 purchase 没 begin_checkout 等于没有漏斗；事件缺 items 数组等于没有商品级分析；缺 value 和 currency 等于对不上账的收入报表。完整实现整条序列与参数，能用平台原生集成就用，但即便如此也要审计——原生集成会漂移。
从 view_item 到 purchase 的完整事件序列
每个商务事件带完整 items 数组：id、name、category、price、quantity
每个带钱的事件带 value 和 currency
与订单系统严格一致的 transaction ID——去重全靠它
阶段二：对照事实校验
检验就是对账：同一窗口的 GA4 购买收入对实际订单。同意模式和拦截器会留一个小缺口；超出的部分要查。然后以顾客身份在桌面和移动端走一遍漏斗，在 DebugView 里看事件触发——每一步、各一次、参数正确。重复触发的 purchase 和幽灵结账步骤会在这里现形。
阶段三：保持可信
埋点和一切一样会衰退：主题更新弄掉标签、新模板不带事件上线、应用注入重复。按计划重新对账、每次重大主题或结账变更后重走漏斗、把验证过的状态记录在案——漂移因此可检测，而不是在对数字信心崩塌时才被发现。
运行方式
完整实现模型
每个事件、完整参数、匹配的 transaction ID——走平台集成，加审计。
对账并走查
收入对到订单，漏斗在 DebugView 里、两类设备上走一遍。
排上复查
按节奏对账，每次结构性店铺变更后重新验证。
你会得到什么
每一步都真实、只触发一次的漏斗
能和订单系统对上账的收入报表
真正有数据可用的商品级分析
按计划抓住的漂移，而不是靠危机
由这些 Agent 负责
可配合使用
常见问题
平台有原生 GA4 集成，我是不是就完事了？
更接近开了个头。原生集成完整度参差——结账步骤和 items 数组质量是常见缺口——而且随平台更新漂移。信之前先审计实际触发的东西。
GA4 收入该和订单对到多准？
在你流量结构下同意模式与拦截器能解释的缺口内——通常低报 5% 到 15%。稳定且被理解的缺口没事；不稳定或扩大的缺口是缺陷。
服务端埋点值得上吗？
它收窄拦截器缺口、提升数据持久性，代价是实打实的搭建成本。先修基础——一条忠实传输坏事件的服务端管道，是昂贵的垃圾。
哪些 Agent 跑这个？
Analyst 负责审计、对账与计划性重验，对坏掉的部分产出精确修复方案——它在报告之前必先校验，因为在坏数据上报告比不报告更糟。