Tracking knowledge / 01
Shopify GA4 / GTMTracking Plan
先定义事件为什么发生、参数从哪里来、谁负责发送，再打开 GTM。
这份计划用于 Shopify 真实实施与验收，不是标签安装清单。它把 Shopify 的标准客户事件、GA4 推荐电商事件、GTM 映射、purchase 去重与报表解释放进同一份可交付契约。
Direct answer
可靠的 Shopify GA4 追踪，不等于“装好 GA4 和 GTM”。
可靠追踪需要一份事件契约：Shopify 发生什么业务事实、映射成哪个 GA4 事件、参数从哪个对象读取、由哪一条链路发送、如何证明只发送一次。
最小闭环是 view_item → add_to_cart → begin_checkout → purchase。其中 purchase 必须带稳定且非空的 transaction_id；value 与 items[] 的计算口径必须事先固定。
验收也不能只看 DebugView 出现事件。必须同时验证 Shopify 源事件、GTM 映射、GA4 请求、重复行为和次日报表，最后再解释 Shopify 与 GA4 为什么不会天然完全一致。
Architecture / 01
从业务事实到可解释报表
把 Shopify、像素层、GTM 和 GA4 分层，出现问题时才能知道应该检查哪一层。
01
Shopify
标准客户事件与订单事实
02
Pixel layer
权限、同意状态与沙箱
03
dataLayer
统一事件与参数契约
04
GTM
变量、触发器、标签
05
GA4
DebugView 与报表
关键原则：GA4 事件名不是源事件。比如 Shopify 的 checkout_completed 是业务事实，再映射为 GA4 的 purchase。把两者混成一个名字，会让排错失去边界。
Event contract / 04
四个核心电商事件，逐个定义触发与验收
Google 建议使用标准电商事件与 items 数组；这张表增加了 Shopify 的源事件和实施验收条件。
| GA4 事件 | Shopify 源事件 | 触发定义 | 核心参数 | 验收重点 |
|---|---|---|---|---|
| view_item | product_viewed | 商品详情被实际查看；不要用所有页面浏览代替 | currency · value · items[] | item_id、variant、price 与当前商品一致 |
| add_to_cart | product_added_to_cart | Shopify 确认商品已加入购物车 | currency · value · items[] · quantity | 一次加购只发一次，数量与行项目一致 |
| begin_checkout | checkout_started | 结账真正开始，而不是点击任何 Checkout 文案 | currency · value · items[] · coupon | 从购物车、Buy Now 等入口进入都能覆盖 |
| purchase | checkout_completed | 订单完成且能取得稳定订单标识 | transaction_id · currency · value · items[] | 刷新感谢页、像素并存时不重复计数 |
Google 的推荐事件参考明确说明：发送 value 时应同时发送 currency；purchase 的 value 应是 items 中 price × quantity 的总和，不含 shipping 与 tax。不要用 Shopify Total Sales 直接填 GA4 purchase value，再期待两边收入完全相同。
Parameter plan / 08
参数表先定“来源”，再定“名字”
同一个字段如果在主题、Pixel 和服务端有不同来源，事件看似完整，实际无法稳定对账。
transaction_idShopify 订单 ID / 订单号的稳定映射
每笔订单唯一、非空；全链路使用同一格式
purchase / refund
item_idVariant SKU；无 SKU 时使用稳定 Variant ID
不能在同一属性中一会儿用 SKU、一会儿用 Product ID
全部商品事件
item_name事件发生时的商品标题
用于阅读，不作为唯一关联键
全部商品事件
item_variant变体标题或可读规格
与 item_id 指向同一变体
全部商品事件
price / quantityShopify 行项目金额与数量
price 为单价；value 由 price × quantity 汇总
全部商品事件
currencyShopify 事件当时的展示/结算币种
ISO 4217 三位代码；只要发送 value 就必须同步发送
全部价值事件
value商品行价值总和
GA4 purchase value 不含 shipping 与 tax，二者单独传
全部价值事件
coupon订单级或行项目优惠码
先定义订单级和商品级的归属，避免混用
checkout / purchase
Implementation decisions / 04
GTM 不是默认答案，而是受约束的实现选择
先判断官方集成、App Pixel、Custom Pixel、主题 dataLayer 与服务端各自负责什么。
优先使用 Shopify 官方集成或 App Pixel
适用：标准 Google 渠道需求、事件覆盖足够、团队更重视稳定维护
依据：Shopify 将 Web Pixels API 作为受支持的像素集成方式；应用像素运行在受控沙箱中。
风险：自定义参数、跨平台命名和高级去重能力可能受集成边界限制。
Custom Pixel + GTM
适用：需要明确掌控 Shopify 标准事件到 GA4 / Ads 的映射
依据：可以订阅 product_viewed、product_added_to_cart、checkout_started、checkout_completed，再推入像素沙箱内的数据层。
风险：不是把传统主题里的 GTM 代码原样搬进去；DOM 抓取、主窗口对象和部分第三方脚本在沙箱中受限。
主题 dataLayer 仅负责店面事件
适用：需要追踪主题自定义交互，且事件发生在 storefront DOM
依据：适合搜索、筛选、表单或自定义组件信号，不应单独承担 checkout_completed。
风险：主题事件与 Pixel / App 同时发送同名电商事件，会产生重复链路。
服务端追踪作为独立项目
适用：浏览器缺失率、广告回传或数据治理要求足以支撑额外复杂度
依据：需要单独设计 event_id、transaction_id、同意状态、身份字段与客户端去重。
风险：服务端不是自动更准确；没有源事件契约时，它只会把错误更稳定地发送两次。
Risk model / 02
重复事件与收入差异，要分开诊断
一个是采集链路问题，另一个常常是指标口径、隐私和处理逻辑的差异。
purchase 重复的五个入口
- 1. Shopify Google 集成和 GTM 同时发送。
- 2. App Pixel 与 Custom Pixel 同时映射 checkout_completed。
- 3. 主题感谢页脚本仍存在，刷新页面再次发送。
- 4. 客户端和服务端都发送，但没有统一去重契约。
- 5. transaction_id 为空、格式变化或不同订单复用同一值。
Google 的 transaction_id 说明指出 Web 数据流会使用相同 ID 去重，但这不是保留重复发送链路的理由；空字符串甚至可能导致购买被错误合并。
Shopify 与 GA4 收入不一致
- • Shopify Total Sales 包含税、运费、关税、费用与销售冲销；GA4 purchase value 的推荐口径不含 tax 与 shipping。
- • 用户拒绝同意、拦截脚本或禁用 JavaScript，GA4 可能无法观察到购买。
- • 时区、币种换算、订单编辑、退款和测试订单处理时间不同。
- • GA4 报表处理与归因不是 Shopify 订单数据库的实时镜像。
对账前先根据 Shopify 销售指标定义确定比较的是订单数、purchase 事件数、Gross sales、Net sales 还是 Total sales，以及两边是否使用同一日期、时区、币种与订单集合。
QA protocol / 08
上线验收清单与调试顺序
不要在四个工具之间随机跳转。先验证源事件，再沿映射链路向下排查。
- 确认生产 GA4 Measurement ID、GTM Container ID 与目标属性，不用测试属性替代生产验收。
- 从无缓存的新会话依次完成商品浏览、加购、开始结账和测试购买，记录时间与订单号。
- 在 Shopify Pixel Helper 检查标准事件名称、次数与 payload；再看 GTM Preview 的触发器和变量。
- 在 GA4 DebugView 对照事件顺序、参数和值；DebugView 不出现时先检查 consent 与 debug_mode。
- 检查 items[] 每一项的 item_id、item_name、variant、price、quantity，而不只看事件名变绿。
- 刷新商品页、快速重复点击加购、返回结账、刷新感谢页，专门测试重复触发。
- 对 purchase 核对 transaction_id、currency、value、tax、shipping 和优惠，不用总额肉眼相似代替字段核对。
- 发布后隔天在 GA4 标准报告复核，因为 DebugView 实时可见不代表标准报表维度一定正确。
Google 建议通过 Tag Assistant / Preview 开启 DebugView；如果客户端隐私控制或 Consent Mode 未允许 Analytics cookies，调试事件也可能不可见。
先确认源事件
Shopify Pixel Helper 中没有对应标准事件，就不要先改 GA4 标签。
再确认映射
检查 Shopify payload → dataLayer → GTM Variable 的字段路径和类型。
检查触发次数
同一次行为是否被 App、Custom Pixel、主题脚本或服务端重复发送。
检查 GA4 请求
确认事件进入正确 Measurement ID，参数没有被变量返回 undefined 或字符串化。
最后解释报表
区分采集错误、处理延迟、归因差异和指标口径差异，不把所有不一致都归咎于代码。
Delivery evidence
这份计划的 Information Gain 在哪里
普通教程告诉你复制代码；可引用的实施文档需要说明数据契约、冲突条件和如何证明结果。
WhaleLeap 的真实实施经验
在 Shopify 追踪项目里，最容易被低估的工作不是创建标签，而是确认同一业务动作是否被多个集成重复观察。我们会先列出现有 App、Customer Events、主题脚本和广告渠道，再决定保留哪一条主链路。
验收记录会保存测试路径、时间、商品/变体、测试订单号、源事件、GTM 触发次数和 GA4 参数，而不是只交付一张“事件已出现”的截图。这样数据异常发生后，团队能回到具体一层，而不是重新安装所有代码。
我们不承诺 Shopify、GA4 与广告平台数字完全一致。交付目标是让差异可分类、可复测、可解释，并把无法由浏览器端追踪解决的限制写入交接。
明确限制
- • 本文不是特定店铺的即插即用代码。
- • Custom Pixel 兼容性取决于第三方脚本与 Shopify 沙箱。
- • 隐私同意和浏览器拦截会造成不可恢复的客户端缺失。
- • 服务端追踪、CAPI、Consent Mode 与 BigQuery 需要独立范围。
- • 平台更新后应重新验证事件 payload 和限制。
官方依据
关键实现判断优先链接 Google Analytics 与 Shopify 官方资料；访问日期：2026-09-07。
From guide to implementation
需要把这份计划变成你店铺里的可验证追踪链路？
先查看 Tracking Service 的实施范围；如果你不确定问题在 Shopify、GTM 还是 GA4，提交免费诊断，我们先判断链路。