GA4 和 Shopify Analytics 对不上，不一定说明谁错了。它们回答的问题不同：Shopify 更接近订单和交易后台，GA4 更适合分析用户行为和渠道路径，广告后台按自己的归因窗口给转化功劳。周复盘真正要解决的不是让所有数字完全相同，而是知道差异是否可解释、是否影响决策、谁负责修复。
如果团队每周都在争“到底哪个数是真的”，说明复盘口径还没有建立。正确做法是给每类决策指定主数据源：财务和履约看 Shopify，行为漏斗看 GA4，广告优化看平台但必须回到利润和订单质量校准。
这篇文章覆盖的搜索意图
这篇文章对应的是“GA4 Shopify discrepancy”“Shopify analytics vs GA4 revenue”“GA4 purchase not matching Shopify orders”“ecommerce revenue reconciliation”和“GA4 和 Shopify 对不上”这类搜索。读者真正需要的不是一句“两个系统口径不同”，而是一套周会里能执行的数据归属规则。
关键词会落到 attribution window、transaction_id、refund handling、time zone、purchase event、order status、UTM preservation、revenue reconciliation 和 weekly ecommerce review。中文会更强调“周复盘该信谁”，英文会更强调 discrepancy、source of truth、data reconciliation 和 purchase tracking debug。
先区分订单事实和行为分析
订单事实包括订单号、支付状态、退款、商品、金额、税费、运费和履约状态，通常以 Shopify 后台和支付记录为准。行为分析包括来源、会话、页面、事件、漏斗和路径，通常用 GA4 看趋势。把两者混成一个真相源，会让复盘变成争论。
GA4 的 purchase 事件仍然必须 QA。transaction_id、value、currency 和 items 如果缺失或重复，GA4 就不能用于收入判断。Shopify 也不是所有营销判断的答案，因为它未必能完整解释用户从哪里来、看了什么页面、在哪一步流失。
为什么数字会不同
差异来自多处：归因窗口不同、时区不同、退款处理不同、支付跳转断 session、Cookie 和 consent 状态不同、广告平台去重逻辑不同、GA4 事件延迟、订单取消或测试订单没有排除。完全一致不是目标，可解释才是目标。
周复盘要建立容忍区间。如果 GA4 purchase 数量和 Shopify 订单长期接近，差异稳定且原因清楚，就可以用于趋势分析。如果突然偏离，先查 tracking，再改预算。
给每类问题指定主数据源
财务问题看 Shopify、支付和利润表；流量质量看 GA4 source/medium、campaign、landing page 和 funnel；广告账户学习看平台转化，但必须和 Shopify 订单质量、退款和毛利对齐；商品表现看 Shopify item、GA4 item-scoped metrics、客服和退款原因一起判断。
主数据源不是唯一数据源。它只是第一判断来源。比如广告 ROAS 高但 Shopify 利润没有改善，就不能说广告一定有效；GA4 显示某渠道转化低，也要检查 UTM 和 purchase 是否正常。
每周先做数据健康检查
复盘开始的前 10 分钟只看数据是否可信：订单数、GA4 purchase、revenue、refund、UTM、广告转化、测试订单、异常订单、时区和 consent 变化。数据健康没过，不要直接改预算或页面。
如果发现异常，记录异常开始时间、影响范围、可能原因、负责人和修复后验证方法。数据问题也要有 owner，不然每周都会重复争论同一个差异。
用差异推动动作，而不是追求统一数字
当差异稳定，它是口径差异；当差异突然变化，它是排错信号；当差异只出现在某渠道、设备、市场或支付方式，它是诊断入口。复盘要把差异转成下一步检查，而不是把时间花在追求所有系统完全一样。
最终周报可以同时保留三列：Shopify 订单事实、GA4 行为漏斗、广告平台归因。每个动作都写清楚使用哪一列作为判断依据。
给周会指定三种数字的主人
为了避免每周重复争论，建议给三种数字指定负责人。订单事实由运营或财务负责人维护，包含 Shopify 订单、退款、取消和支付记录。行为漏斗由数据负责人维护，包含 GA4 事件、UTM、landing page 和设备/市场拆分。广告归因由投放负责人维护，但必须在会上说明它和 Shopify 订单质量、退款和利润的差异。
负责人不是为了互相甩锅，而是为了让差异有解释路径。只要某个数字异常，会议不需要全员猜原因，先由对应负责人给出证据、影响范围和下一步排查。
周复盘数据源分工表
| 问题 | 主数据源 | 辅助数据源 | 先查什么 |
|---|---|---|---|
| 收入和订单 | Shopify / 支付记录 | GA4 purchase | 测试订单、退款、取消订单 |
| 渠道表现 | GA4 | 广告后台、UTM 表 | source/medium、campaign、landing page |
| 广告优化 | 广告平台 | Shopify 利润、GA4 漏斗 | 归因窗口、转化价值、订单质量 |
| 商品问题 | Shopify 商品订单 | GA4 items、客服、退款 | 变体、库存、退货原因 |
周复盘不需要一个完美数字，需要一个稳定判断系统。只要团队知道每个数字回答什么问题、什么时候可信、什么时候要排错，GA4 和 Shopify 的差异就会从争论变成诊断工具。
下一步是把 purchase QA、UTM 命名和退款复盘固定到周会开头。先确认数据能读，再决定预算、页面和商品动作。
把诊断变成一条运营记录
读完这篇文章以后，不要只留下一个模糊印象。至少写一条短运营记录：日期、负责人、相关页面或广告、当前指标、预期变化、下次复查时间。记录不需要复杂，但要具体到另一个人能看懂你检查了什么、为什么选择这个动作。
这个习惯很重要，因为电商团队经常一次改很多东西：页面改了，预算动了，折扣加了，新素材也上线了。下一次数据变化时，没人知道是哪一个动作产生影响。小型决策日志能减少这种噪音，也会成为后续复盘的记忆：哪些假设是对的，哪些修复反复有效，哪些问题其实来自追踪而不是用户行为。
文中链接到的 Ecomwith 工具、教程或答案页应该作为下一步动作，而不是装饰链接。如果文章指向计算器，就输入当前数字并保存结果；如果指向教程，就用课程补齐流程；如果指向答案页，就先统一概念再讨论策略。当前文章先帮助你做第一层判断，后续页面再帮助你把动作变得可衡量。
下次复查前，把观察窗口也写清楚。结账修复可能需要二十到五十次 checkout start 才能初步判断；广告结构调整可能需要几个转化周期；内容和 SEO 调整需要等待索引和查询数据。先写预期证据，再上线改动，团队就不容易过早宣布成功，也不容易在信号出现前放弃修复。