这是给网站交付需求使用的合成教学例，不是客户成果、真实账号测试或认证。
先定义计数单位，再谈转化
新商城的确认页刷新，可能再次发送purchase事件；另一个事件的订单编号，也可能在所填付款导出中找不到。不能把每条分析记录都叫成交。验收营收看板前，应约定交易编号、币种、金额与观察窗口。
| 所填记录 | 金额 | 能确认什么 |
|---|---|---|
| T1首条purchase | AUD120 | 存在一条分析事件 |
| T1重复purchase | AUD120 | 本次导出交易编号重复 |
| T2 purchase | AUD90 | 没有所提供的已付款匹配 |
| 后台已付款T1 | AUD120 | 所提供的已付款交易为一笔 |
运行填好的例子
下载有限规则Node检查器和已填写输入。使用Node 24或更新版本，不需要账号或API，也不联网。
node checks.mjs ga4-purchase-reconciliation ga4-purchase-reconciliation.json预期输出为原始事件3条、所填唯一交易2个、所填已付交易1个，重复编号DEMO-T1、未匹配编号DEMO-T2。本例不声称GA4实际接收、去重或归因了什么，也不直接把事件金额相加当营收。
商家可以委托的验收步骤
索取授权测试订单与脱敏事件负载，核对分析事件、后台订单和付款结果是否使用同一交易编号。在测试环境刷新确认页、重复投递，再检查同编号下金额或币种是否冲突；冲突应调查，不能悄悄“保留第一条”。
退款、取消、同意状态、导出延迟和付款状态变化应另外约定。必须使用完整可比窗口；未匹配只表示这份数据里缺少，不等于真实账号一定未付款。分析事件也不是已确认的人数、有效询盘或外部付费订阅。
这个离线对照不读取GA4或支付系统，也不测量归因。它是采购证据合同，不替代会计判断或生产事件实现。
官方依据与边界
Google Analytics电商指南：说明purchase事件的transaction_id、value、currency与items等字段。
来源于2026年10月15日核验。输入与验收规则为原创教学设计；正式实施前还要核对当前平台版本及实际交付合同。