GA4 系列 / 第 3 课
先别看报表，先把事件参数 QA 表做出来
purchase 少了，可能是用户没买，也可能是事件没发、金额没带、transaction_id 重复、items 缺字段。本课把这些可能性放进一张可验收的事件 QA 表。
本课产出
GA4 事件参数 QA 表
核心动作
先验事件链，再读漏斗
下一课
Consent Mode 与隐私测量
第一屏 QA 工作台
event name
行为叫什么
trigger timing
什么时候触发
required params
必须带哪些参数
QA method
用什么证据验收
安装通过，不等于事件定义通过
上一课已经选定唯一安装路径，并把 Property、数据流、Measurement ID、时区、负责人和测试订单写进验收记录。它证明当前路径能把一笔订单送到正确位置，却没有证明每个事件都在正确的业务动作后触发。
继续用同一笔 20oz 保温杯、Shopify 订单 #1008、支付 $48 的案例。GA4 事件是一条动作记录，session 是访问过程，user 是观察到的用户标识，Shopify order 才是订单事实；transaction_id 负责把 purchase 与订单对上，不能替代前三步事件的触发和参数验收。
本课把 view_item、add_to_cart、begin_checkout 和 purchase 逐项写成事件验收图：事件名、触发时机、event-scoped 与 item-scoped 参数、后台证据、负责人和失败动作都要齐。测试和次日报表使用同一 Property 时区与完整日期范围；事件含义或参数没验清，就暂停漏斗、受众、关键事件和广告导入。
事件合同主干
事件不是技术日志，而是一份业务动作合同
同一个事件名必须在同一个真实动作后触发，并携带后续分析所需的上下文。先把合同、完整订单和验收顺序写成正文，互动才只是练习，不是答案本身。
先确认这篇课解决什么
读者已经在上一课证明生产 Property、Web stream 和唯一发送路径能收到一次购买，但还不能据此建立漏斗。安装验收回答“数据有没有送到正确位置”，事件验收回答“送来的动作到底是什么意思”。本篇的新术语包括事件合同、触发时机、event-scoped parameter、item-scoped parameter、去重键和反证样本。
本篇决策是：这组事件能否被下游漏斗、受众、key event 和广告导入复用。结束时，你要能拿一笔订单解释每个事件为什么触发、参数从哪里来、在哪个后台核对、什么算通过、失败时停止什么，并交付一张已填写事件参数 QA 表。
固定案例：同一笔订单，四个事件各有自己的合同
教学店仍然面向美国市场销售 20oz 防漏保温杯，Property 时区为 America/New_York。Shopify 显示订单 #1008，GA4 transaction_id 为 TMB-1048，商品 ID 为 TMB-20-OZ，数量 1，支付金额 48 美元，币种 USD。测试使用同一设备、同一 consent state 和同一发布版本。
买家在 10:41:20 看到商品，10:42:05 加购，10:44:10 进入结账，10:47:32 支付成功。时间只是教学证据，用来证明触发顺序；它不代表所有真实买家必须按同样速度完成购买。事件链通过时，四个动作只各触发一次，商品对象在各步保持同一个 item_id，purchase 再用 transaction_id 回到 Shopify 订单事实。
| 真实动作 | 事件合同 | 事件层参数 | 商品层参数 | 证据与通过 | 失败动作 |
|---|---|---|---|---|---|
| 商品详情实际可见 | view_item | currency=USD, value=48 | item_id=TMB-20-OZ, item_name, price=48, quantity=1 | DebugView 在商品可见后一次；商品与页面相符 | 若首屏未见商品就触发，修触发条件 |
| 买家确认加入购物车 | add_to_cart | currency=USD, value=48 | 同一 item_id、price、quantity | 购物车状态改变后一次；items 与购物车一致 | 若按钮失败仍触发，先修成功状态监听 |
| 买家进入结账流程 | begin_checkout | currency=USD, value=48, coupon（如有） | 同一 item_id、price、quantity | 结账真正开始后一次；金额口径可解释 | 若只打开购物车就触发，收紧边界 |
| 支付成功并生成订单 | purchase | transaction_id=TMB-1048, value=48, currency=USD | 同一 item_id、price、quantity | DebugView 一次且与 Shopify #1008 对账 | 缺 ID/金额/items 或双发就禁止激活 |
通过样本
purchase 只出现一次；transaction_id=TMB-1048；value=48；currency=USD；items 中包含 TMB-20-OZ、price 48、quantity 1；Shopify #1008 已支付。次日标准报表在同一属性时区找到对应记录。
反证样本
如果 purchase 在支付前触发、transaction_id 为空、value 为 0、currency 缺失、items 为空，或同一订单出现两次，就算 Realtime 有事件也不通过。先修对应 trigger、mapping 或 duplicate sender，重跑同一订单，不用报表过滤掩盖错误。
对象和证明边界不能省略
event 是一次动作记录，session 是一段访问，user 是 GA4 在设备、浏览器、身份与同意边界下观察到的分析对象，Shopify order 才是支付与退款事实。一位用户可以有多个 session，一个 session 可以有多个 event，一笔订单通常只应有一个可去重的 purchase。把这些对象混在一起，会让转化率的分子与分母失去意义。
transaction_id 只能帮助 purchase 去重和订单对账，不能证明 view_item、add_to_cart 或 begin_checkout 的触发正确，也不能证明广告带来增量或订单有利润。本课通过后仍只允许进入事件语义之后的分析；若任何合同缺证据，就停止漏斗、受众、key event 和 Ads 导入，并把失败路由写进记录。
四步事件链
先把真实买家动作，翻译成 GA4 事件
event taxonomy 不是背一串英文事件名。先看一笔 20oz 保温杯订单：买家看商品、加购物车、进入结账、付款成单。每一步都对应一个 GA4 事件，也都有自己的验收证据和误读风险。下面这块可以点，先选你现在最想验收的一步。
四步必须按真实状态变化定义，不能按按钮名称定义。买家点了“加入购物车”但请求失败，不应产生 add_to_cart；买家打开购物车抽屉，也不等于 begin_checkout。先写业务成功条件，再检查 tag 是否在那个条件之后触发。
默认选中 view_item。点击前先说出它的通过证据：20oz 商品内容实际可见，items 里的 TMB-20-OZ、price 48、quantity 1 与页面一致，事件只出现一次。其他步骤沿用同样的“动作—触发—参数—证据”顺序。
默认静态结论：view_item 在商品实际可见后触发一次，item_id=TMB-20-OZ，price=48，quantity=1；它证明商品浏览被记录，不证明用户形成购买意图，更不证明后续订单。失败时先修可见性或商品映射，不改漏斗分母。
切换到 add_to_cart、begin_checkout 或 purchase 时，必须同时更换成功条件和证据。purchase 的 transaction_id 不能倒过来替前三步背书；每一步都要独立通过。
主表
事件参数 QA 表要把语义、触发、参数和证据写在一起
事件名回答「发生了什么」，参数回答「这次动作的上下文是什么」，QA 方法回答「我们怎么证明它能上线」。
经营词边界
先补两个会被误用的经营词：ROAS 和 attribution
事件 QA 不是广告课，但它会直接影响广告判断。purchase、value、currency、items 和 transaction_id 没验清前，不要急着解释 ROAS 或争渠道功劳。
ROAS
广告收入回报，通常是广告带来的收入除以广告花费。
你会在哪里看到：Google Ads、Meta Ads、GA4 探索和周经营复盘表。
purchase 双发、value 口径不清或 currency 缺失时，ROAS 会被抬高或压低，预算判断会偏。
Attribution
把一次 purchase 记到哪个渠道、广告、关键词或触点名下的规则。
你会在哪里看到：GA4 attribution reports、Google Ads conversion columns、Shopify 营销报表。
事件链坏了，归因差异就还不是策略问题，而是证据不干净。先修事件，再争渠道功劳。
Key event
GA4 里被标记为业务重要的 event。event 先被收集，验收通过后才考虑标成 key event。
你会在哪里看到：GA4 Admin 的 Events / Key events、Advertising 报表、Google Ads conversion 创建流程。
如果 purchase 参数没验清就进入 key event 或 Ads conversion，出价、归因和转化数都会继承脏数据。
事件边界
能用推荐事件，就不要自造事件名
GA4 事件不是一类东西。先分清自动收集、增强型衡量、推荐事件和自定义事件，才能控制命名增长。
事件类型决定的是命名来源与责任，不决定数据天然可靠。自动收集仍可能进入错 Property，增强型衡量不能代替电商事件，推荐事件仍需正确参数，自定义事件则必须证明现有推荐语义无法表达。
默认选中推荐事件，因为 view_item、add_to_cart、begin_checkout 和 purchase 已有共同语义。先读推荐定义和参数，再决定是否存在真正缺口；不要因为团队内部叫法不同就复制一套同义自定义事件。
当前边界
推荐事件
适合用来做什么
view_item_list、select_item、view_item、add_to_cart、view_cart、begin_checkout、purchase、refund。
常见误用
能用推荐事件和 prescribed parameters 时，不要自造 product_view 或 buy_success。
默认静态结果是使用 GA4 推荐电商事件，并在事件字典中记录官方语义、真实触发、必填参数、owner 和测试订单证据。通过条件不是名字拼对，而是动作与 payload 合同都通过。
若确需自定义事件，先写无法用推荐事件表达的业务动作、命名规则、参数合同与下游读者；否则保持推荐事件，减少分裂的漏斗与受众定义。
事件字典
事件字典不是命名表，是上线验收记录
每个事件都要写清业务含义、触发时机、必填参数、证据和负责人。否则 DebugView 里有事件，也没人知道它能不能进入漏斗、受众或广告导入。
事件名
使用推荐事件和官方 prescribed parameters 优先；只有推荐事件无法表达时才新增自定义事件。
view_item, add_to_cart, begin_checkout, purchase
key event / Ads 边界
写清这个事件是否已经通过 QA，能否标成 key event，以及能否创建或导入 Google Ads conversion。
purchase: key event only after value/currency/items pass
业务含义
用白话写清这个事件代表的真实买家动作。
Shopper successfully adds one item to cart
触发时机
写清是在按钮点击、购物车更新、进入 checkout，还是订单生成后触发。
After cart updates, not on click only
必填参数
列出这个事件必须带上的参数和商品数组字段。
items, value, currency, transaction_id
验收证据
写明用 DebugView、Realtime、测试订单、次日报表中的哪一层证明。
DebugView event record + Shopify order #1008
负责人
写清谁修事件、谁验收、谁决定是否可以进入报表和广告导入。
data lead, developer, media lead
事件验收图
先把四个字段层级验清楚，再让 purchase 进入报表
点击你最容易出错的一层。详情面板会显示后台证据、坏掉后的影响、写回复制笔记总结的句子，以及下一步应该继续还是暂停。
四层合同按依赖顺序验收：event_name 先回答发生什么，event-scoped 参数描述整次动作，item-scoped 参数描述商品明细，transaction_id 最后把 purchase 与订单事实连接。前一层含糊，后一层再完整也不能修复语义。
默认从 event_name 开始。点击前先用 #1008 说出它的后台证据、坏掉后影响和停止动作；动态面板只校验结构，不替代已填写合同。
event_name
事件名称层
这层是什么
event_name 先声明买家到底做了什么动作，例如 view_item、add_to_cart 或 purchase。它不是随手起名，而是所有报表、漏斗和受众理解动作的入口。
后台证据
GA4 DebugView 事件名、Events 表、测试设备记录和事件字典里的业务动作必须一致。
坏掉后影响
如果同一动作被拆成 product_view、view_product、pdp_view，后续漏斗和受众会被切碎。
复制笔记总结写回句
event_name 已验：本次 purchase 使用推荐事件名，不新造 buy_success；DebugView 和 Events 表一致。
下一步路线 / 禁止动作
事件名未统一前，不进入漏斗分析、受众复用或广告导入。
默认静态结果：event_name=purchase 只在支付成功并生成 Shopify #1008 后出现一次。若感谢页加载、按钮点击或订单状态刷新都会触发，就停止激活并修正触发边界；不能用 transaction_id 去重来掩盖错误触发。
切换其他层时，默认结论仍保留：event 参数要解释 $48 USD，items 要解释 TMB-20-OZ × 1，transaction_id 要回到 #1008。四层全部通过才进入次日报表和 Ads 放行。
参数验收
参数设计比事件数量更重要
一个 purchase 没有 transaction_id、value、currency 和 items，后面的收入、商品、漏斗和广告分析都会变弱。
items
商品数组。它把 item-scoped parameters 放进同一个事件，例如商品 ID、名称、分类、变体、数量和价格。
一笔 20oz 保温杯订单里，items 应该能看到杯子的 item_id、item_name、quantity、price 和 item_category。
商品层报表、商品受众和商品漏斗都会变弱。
value
这次事件的价值，常用于购买收入或转化价值；发送 value 时要同时明确 currency。
purchase 的 value 可以是订单收入口径，但要写清是否含税费、运费和折扣，并确认 currency。
收入、ROAS 和广告导入价值会失去基础。
currency
货币。只要使用 value，就要明确币种；这是标准报表和广告导入解释金额的基础。
USD、EUR、GBP 不应混成一个没有币种的收入数字。
跨币种收入和转化价值解释会混乱。
transaction_id
订单去重字段。它告诉 GA4 这是不是同一笔订单。
Shopify 订单 #1008 对应 purchase 的 transaction_id。
刷新感谢页或重复安装时，purchase 可能重复计数。
Payload 检查器
purchase 参数错一项，后面的报表都会偏
不要只问 purchase 有没有触发。把一笔测试订单的 payload 拆开，看 transaction_id、value、currency、items 和发送路径各自会让什么业务判断变形。
payload 检查的起点是已知正确订单，不是报表总额。先把 Shopify #1008 的 transaction_id、支付金额、币种和商品行写在左侧，再逐字段比较 GA4。这样才能知道缺口来自 ID、金额口径、商品映射还是重复发送。
默认错误样例聚焦 transaction_id。点击前先预测会坏什么：同一订单无法可靠去重和对账，收入与订单数可能重复；第一修复应回到订单 ID 映射，而不是在报表里删除一行。
当前错误样例
缺 transaction_id
event_name: purchase
transaction_id: ""
value: 50.00
currency: USD
items: [{ item_id: "tumbler-20oz", quantity: 1 }]
会坏什么
刷新感谢页、重复 tag 或多路径发送时，订单数和收入可能被重复计算，后续对账也没有抓手。
第一修复
把 Shopify order id / order name 映射进 transaction_id，并用同一笔测试订单确认 DebugView、Tag Assistant / GTM preview 和次日报表都只出现一次。
通过标准
DebugView、Shopify 订单和次日报表都能看到同一个订单引用。
不要先做
不要把 purchase 导入 Google Ads，也不要用它解释 ROAS。
默认静态修复是让 purchase 带稳定且非空的 transaction_id=TMB-1048，并在 DebugView、次日报表与 Shopify #1008 三处只看到同一订单一次。修复前暂停 key event、Ads import、revenue 和商品表现判断。
切换 value、currency、items 或重复发送案例时，仍使用同一订单做对照。一次只修一个 payload 层并重跑，不同时更换商品、设备、consent state 和发布版本。
30 分钟事件 QA meeting
用五段会议路径决定事件能否放行
这条 QA meeting 是事件合同、证据链和放行状态的互补路径；下面原有的四步测试订单流程仍负责把一笔测试订单实际跑完，两者不能互相改名或替代。
0-5 分钟
会议焦点先选一条要验收的链：电商核心事件、新 custom event、server-side，或 Measurement Protocol；不要把四条路径混成一个“通过”。
证据写下 Property、data stream、发送方、测试设备、页面/订单范围和发布版本，确认本次会只覆盖这一条链。
动作 / 输出输出本次 QA 的链路边界和 owner；其他发送路径标成未覆盖，不用一条路径的读数替代另一条路径的验收。
5-10 分钟
会议焦点确认事件名和语义：推荐电商事件优先，custom event 只有在推荐事件无法表达时保留；把删除、内部事件和映射关系写清。
证据对照事件字典、实际 payload 的 event_name、触发页面和业务动作，检查 view_item、add_to_cart、begin_checkout、purchase 是否被另一个名字冒充。
动作 / 输出输出保留/改名/删除/仅内部使用的名单；命名未决时先不标 key event，也不进入 Ads import。
10-18 分钟
会议焦点逐字段验 items、value、currency、transaction_id、item identity、quantity、discount 和触发时机；参数不一致先归为 parameter issue。
证据用同一笔 Shopify 测试订单对照 DebugView payload、订单明细、发送路径和事件时间，记录缺失、重复、空值或口径差异。
动作 / 输出输出字段级修复清单和重测条件；在参数合同未通过前，不把收入、商品表现或需求变化写成业务结论。
18-24 分钟
会议焦点跑完整证据链：DebugView、Realtime、测试订单和次日报表；Realtime 能看到事件不等于事件已经可用于报告。
证据保存测试设备事件顺序、Realtime Property、Shopify order ID / transaction_id、次日 purchase / revenue 读数和处理延迟。
动作 / 输出输出通过、先修触发/参数/去重/延迟，或只能做方向判断；缺 DebugView、订单或次日报表时不写“已验收”。
24-30 分钟
会议焦点给这条事件一个上线判断：可以放行、必须修复后再报表、只做方向判断，还是阻止 Ads import，并指定负责人和下次检查日期。
证据复核 event_name、参数、订单唯一性、consent/filter、证据链、key event / Ads 边界和变更记录；每个结论都要有直接证据。
动作 / 输出把状态、负责人、修复动作和下一次日期写入事件字典/QA 记录；既不把测试订单流程改名，也不以 QA 会议替代下面的四步测试订单流程。
Payload 合同实验室
先把一笔订单的字段讲清，再交给漏斗或广告
已有的检查器告诉你哪些 purchase 字段会坏。这个实验室把正确 JSON、错误对照、商品作用域、部分退款、订阅边界、重复 transaction_id 和可复查 QA 记录放进同一次练习。所有内容都是课堂或授权测试引用，不会向 GA4、Shopify、广告平台或支付系统写入数据。
本地字段 QA 记录
有效 JSON 只是待验证的字段合同，不是生产验收
选择、勾选、填写、保存和导出只保留当前浏览器中的课堂记录。它们不发送事件、不创建订单、不做退款、不改订阅、不改 tag、不改 Google Ads 或 Consent。
事件链沙盘
沿着一次真实买家旅程选择一个事件，再读它必须保留的字段、它能回到的订单事实，以及它不能证明的业务结论。
Payload 要保留什么
读稳定且非空的 transaction_id、value、currency、items、coupon、shipping、tax 与发送来源，再与同一 Shopify 订单对照。
可回到的事实
只有订单引用、支付状态、金额定义和商品行都能读回时，才可以讨论这条 purchase 是否可用于后续验收。
它不能证明什么
一次可见 purchase 不能单独证明净销售、无退款、广告增量、利润或 Google Ads 转化已可用。
JSON 对照合同
一次可对账的 purchase
20oz 保温杯 49 USD，优惠 5 USD，运费 6 USD，订单总值按团队已声明的公式为 50 USD。示例只练字段关系，不表示真实订单已收款或收入已确认。
可读的有效 payload
{
"event": "purchase",
"transaction_id": "TMB-1048",
"currency": "USD",
"value": 50.00,
"coupon": "WELCOME5",
"shipping": 6.00,
"tax": 0.00,
"items": [{ "item_id": "tumbler-20oz", "item_name": "20oz Tumbler", "item_variant": "sage", "price": 49.00, "quantity": 1, "discount": 5.00 }]
}错误对照 payload
{
"event": "purchase",
"transaction_id": "",
"value": 50.00,
"items": [{ "item_name": "20oz Tumbler", "quantity": 1 }]
}字段映射
把 item_id 和 item_variant 回到 Shopify 商品和变体，把 transaction_id 回到同一订单引用，再把 value 公式和 coupon、shipping、tax 的处理写清楚。
QA 读回
检查 DebugView 或测试工具中的字段、发送来源、同一 Shopify 订单和次日报表。任何一层未读回时都写未知。
不能越过的边界
有效 JSON 形状不等于真实支付、净销售、退款、广告价值或利润结论。
Payload 字段 QA 关卡
勾选代表这项已经写进课堂记录，不代表真实 schema、像素、Shopify 订单、退款、订阅或广告设置已经被修改。
Payload 找错题
同一订单的 GA4 purchase 缺少 item_id，value 又与 Shopify 订单不同，团队还不确定重复发送方。哪一种下一步既保留事实，也不制造新的生产改动？
可填写 Payload QA 记录
只记录课堂别名或已获授权的测试引用。真实客户、支付、地址、后台截图和访问凭证只应留在获授权的工作环境。
Payload 官方边界
官方页面检查日期：2026-07-26。它们说明当前电商事件、退款、去重和验证边界，不替代这个店铺的事件、订单、退款、订阅、同意或广告读回。
验收轨道
验收不是只看 Realtime，要留下证据链
DebugView、Realtime、测试订单和次日复核各自证明不同的事。缺一层，就不要急着把数据交给漏斗、受众或广告优化。
DebugView
通过 Google tag、Tag Assistant、GTM 预览或 debug_mode 隔离测试设备，并记录事件顺序和参数。
测试设备清晰、事件顺序合理、必填参数存在。
Realtime
确认真实测试流量进入正确 Property。
数据流和测试设备不混到其他属性。
测试订单
保存订单号、金额、币种、商品、purchase 事件时间和事件参数记录。
purchase 只记一次并能对上订单后台。
次日复核
标准报表、探索和收入口径能解释测试单。
处理延迟后，报表和 DebugView 不互相矛盾。
跨平台放行检查
先让 GA4 事件通过，再谈 Google Ads 和 Meta
事件能触发，只代表采集开始了。要进入 key event、Google Ads conversion 或 Meta 对照，你还要留下后台记录、字段和暂停条件。
GA4 event
后台记录 / 字段
DebugView event record、Events 表、测试设备和事件时间。
event_name, event_time, debug_device, items, value, currency, transaction_id
放行规则
先证明事件名、触发时机和参数正确；没有通过前只能用于修采集，不能用于经营判断。
暂停条件
事件能看到但参数缺失、触发时机不对、测试设备不清楚或订单对不上。
GA4 key event
后台记录 / 字段
GA4 Admin > Events / Key events 状态、标记时间、负责人和变更记录。
event_name, release_status, responsible_lead, change_log, report_scope
放行规则
只有通过事件 QA 的业务动作才标成 key event；标记后仍要写清它能用于哪些报表，不能自动等于 Ads conversion。
暂停条件
purchase 还在重复、value 口径未验清、items 为空或 consent/filter 状态未解释。
Google Ads conversion
后台记录 / 字段
Google Ads conversion action、GA4 link、import 状态、value 设置和最近一次测试订单。
conversion_action, source, value_setting, attribution_setting, import_time
放行规则
Ads conversion 只能接收已验收的 key event 或明确创建的转化动作；先保留旧转化作为对照，再切换优化目标。
暂停条件
GA4 purchase 还没和 Shopify 对账，或 value / currency / items 会把广告系统喂脏。
Meta event 对照
后台记录 / 字段
Meta Events Manager Test Events、event_name、event_id、content_ids、value、currency 和同一笔 Shopify 订单。
event_name, event_id, content_ids, value, currency, order_id
放行规则
Meta 不需要完全复制 GA4 命名，但同一笔购买的订单号、商品身份和金额口径要能解释差异。
暂停条件
GA4 item_id、Shopify variant、Meta content_ids 或 Catalog item id 互相对不上。
官方来源边界
官方文档能证明规则，不能替你证明 Shopify 订单已经通过
把官方来源当成边界表使用：它告诉你推荐命名、参数规范和 DebugView 能做什么，但触发时机、订单对账和广告放行仍要用自己的测试订单验收。
最小激活检查
这些条件没过，就只做方向判断，不进入广告优化
purchase 能触发只是开始。进入 key event、Google Ads conversion 或 Meta 对照前，至少要把订单唯一性、金额口径、商品身份、证据链和负责人写清。
purchase 只触发一次
一笔 Shopify 测试订单在 DebugView、Tag Assistant / GTM preview 和次日报表里只产生一次 purchase。
transaction_id 唯一且能对上 Shopify 订单
transaction_id 与 Shopify order ID / order name 一一对应，刷新感谢页不会新增订单。
value、currency、discount、shipping 口径清楚
同一笔 20oz 保温杯订单的收入、折扣、运费、税费公式已经写进事件字典。
items 包含商品 ID、名称、价格、数量
items 不为空，并且 item_id、item_name、price、quantity 能解释 Shopify 商品和变体。
GA4 item ID 能对上 Meta content_ids / catalog key
同一款商品能在 GA4 items、Shopify variant、Meta content_ids 和 Catalog item id 之间解释差异。
四层证据都保留
DebugView、Realtime、Shopify 订单和次日报表都能解释同一笔测试订单。
key event、Ads conversion、Meta event 状态分开记录
GA4 key event、Google Ads conversion、Meta event 对照各有放行状态和暂停条件。
负责人、卡住动作、复查日期已写入记录
事件字典写清谁修、谁验、暂时不能做什么、什么时候重新检查。
测试订单演练
用一笔 20oz 保温杯测试订单验收三套系统
真正的通过标准不是 Realtime 有事件，而是一笔测试订单能解释 GA4、Shopify 和广告导入之间的差异。
准备测试商品、折扣、运费、币种和预期订单金额。
一张测试订单预期表。
从商品列表走到商品页、加购、购物车、checkout 和 purchase。
DebugView 事件顺序记录。
核对 purchase 的 transaction_id、value、currency 和 items。
GA4 purchase 与 Shopify 订单号对上。
确认 purchase 只出现一次，没有 GTM、Shopify app 或 Customer events 重复发送。
一条主发送路径和重复路径处理记录。
检查标准报表、Explorations 和收入读数是否能解释测试单。
通过 / 先修事件 / 只做方向判断三选一结论。
失败路由
先分清是哪一层坏了，再下业务结论
同一个异常可能来自真实业务、触发时机、参数、去重、隐私或处理延迟。先路由，再行动。
失败路由从症状开始，不从猜测开始。写清哪一个事件、哪一个设备/页面、哪个完整日期窗口、Shopify 订单是否稳定，再选择最像的层。没有这些限定，“purchase 下降”既可能是业务，也可能是测量。
默认症状先检查真实订单与 GA4 purchase 是否同向。点击前写出最便宜的反证和被禁止动作；右侧结果只决定下一项检查，不能宣判最终根因。
GA4 purchase 比 Shopify 少很多
先查
DebugView 是否出现 purchase；checkout / thank-you path 是否变了；consent 是否阻断。
可能层级
可能是触发时机、结账边界、隐私状态或重复过滤问题。
安全动作
先跑测试订单并保存事件证据，再判断业务下滑。
不要先做
不要先降广告预算。
默认静态路线是先锁 Shopify 已支付订单，再核 purchase 数量和 transaction_id；若订单稳定而 GA4 缺失，检查 trigger、payload、duplicate sender、consent 与处理延迟。证据未解释前，不把缺口写成需求下降。
通过条件是一个具体层能解释差异，并由另一证据面验证；失败时缩小设备、页面或发布版本继续取证。任何路由都不能单独证明 attribution、incrementality 或 profit。
复制笔记总结
把事件 QA 结论写成下一课能继续用的笔记
不要只在聊天里说 tag 能触发。选择事件边界和失败路由后，把当前压力、第一证据、本周动作、暂停动作和复盘窗口复制出去。
复制按钮会把当前选择拼成笔记，但验收记录先要有固定事实：Property 时区、测试设备、发布版本、#1008/TMB-1048、$48 USD、四个事件的触发与参数、次日报表、owner 和停止线。动态选择不能覆盖这些事实。
“已复制”只是界面反馈。复制后要把记录放进任务系统，补证据链接并让另一位执行者能重走同一订单；无法复现时仍是未验收。
当前可复制版本
这份笔记会跟随你选择的事件边界和失败症状变化。复制后可以放进任务、复盘或下一课 Consent Mode 分析。
尚未复制：复制反馈不等于事件验收。
当前压力：GA4 purchase 比 Shopify 少很多
第一证据：用 20oz 保温杯测试订单、DebugView 事件记录、Shopify 订单号和次日报表证明事件链。
四步链路：看商品；view_item 已验：20oz 保温杯商品页打开后触发一次，items 商品身份和 Shopify 商品后台一致。
当前事件边界：推荐事件；view_item_list、select_item、view_item、add_to_cart、view_cart、begin_checkout、purchase、refund。
验收层级：事件名称层；写回：event_name 已验：本次 purchase 使用推荐事件名，不新造 buy_success；DebugView 和 Events 表一致。
Payload 检查：缺 transaction_id；修复：把 Shopify order id / order name 映射进 transaction_id，并用同一笔测试订单确认 DebugView、Tag Assistant / GTM preview 和次日报表都只出现一次。
Payload 实验：一次可对账的 purchase；purchase：读稳定且非空的 transaction_id、value、currency、items、coupon、shipping、tax 与发送来源，再与同一 Shopify 订单对照。
Payload QA 记录：0/8。先完成字段关卡和找错题，不把有效 JSON 当成生产验收。
key event / Ads 边界：事件通过 QA 后再决定是否标为 key event 或进入 Google Ads conversion。
Meta 对照：同一笔购买要能解释 GA4 item_id、Shopify variant、Meta content_ids 和订单金额差异。
ROAS / 归因边界：purchase、value、currency、items、transaction_id 未验清前，先不要解释 ROAS 或争渠道功劳。
下一篇激活前必读：consent state 与 privacy measurement boundary。
本周动作：先跑测试订单并保存事件证据，再判断业务下滑。
暂停动作：不要先降广告预算。
复盘窗口：次日报表、7 天稳定期、下一课 Consent Mode 与隐私测量。
静态交付句：“美国市场 20oz 保温杯测试订单 #1008 / TMB-1048，$48 USD；view_item、add_to_cart、begin_checkout、purchase 按真实状态顺序各一次。purchase 带 transaction_id、value、currency、items，商品为 TMB-20-OZ × 1；DebugView、Shopify 与次日报表可对账。”
暂停句：“任一事件过早/重复，或 purchase 缺 ID、金额、币种、items 时，不建立漏斗、不创建受众、不标记 key event、不导入 Ads；修复一个合同层后用同一订单重跑。”下一课只接收这份已验收事件字典，并继续讨论 consent 可见性。
本课完成判定
能用一笔测试订单完整解释 GA4、Shopify、Google Ads 和 Meta 之间的差异，purchase 只记一次，value / currency / items 能解释，DebugView 事件记录或日志已保存，事件字典进入变更记录，才算完成。
继续到隐私测量