对账订单与分析数据
本任务交付一份能复算的批量对账记录：范围说明、订单与分析明细的匹配表、数量和金额差异、原因证据及后续动作。它服务于日常经营读数复核；单笔测试购买与 Pixel 实施验收另见购买事件与金额核对。
先读指标口径与数据质量。准备有权限查看的订单、付款与退款资料，以及所选分析来源的交易明细。只有汇总报表时可先做汇总比较，但不能声称完成逐笔匹配；调试时看到的少量事件也不能代替整批数据。
1. 固定范围和时间边界
写明店铺、渠道、订单状态、测试标记、业务日期、时区和币种。订单创建、付款成功、履约完成与退款分别记录，不用一个“完成”状态代替全部事实。原始购买与后续编辑也要区分版本。
时间至少分成业务窗口、后续观察截止和实际提取时间。区间采用含起点不含终点，避免相邻两日重复；发生时间用于归属，接收时间用于判断迟到。退款若追踪同一批订单，应按原订单关联，不把期间内其他批次的退款混进来。
不要把“等了 72 小时”当作所有数据已完整的保证。Google 数据新鲜度说明提示处理期间数字可能变化，典型处理时间也不是承诺。记录当次可见状态与计划复查时间，后续快照有变化时保留差异。
2. 整理业务与分析两侧明细
| 一侧 | 最小字段 |
|---|---|
| 业务 | 店铺与订单 ID、渠道、测试标记、付款及取消状态、各动作时间、币种、商品原额、折扣、税、运费、退款及原订单关联 |
| 分析 | 来源与提取时间、事件类型、transaction_id、发生与接收时间、currency、value、税与运费、可用的去重和采集资格证据 |
| 对账映射 | 业务键与交易 ID 的对应、字段计算规则、缺失与空值、筛选与调整记录 |
先核对提取是否完整、是否有行数限制或筛选遗漏。用稳定业务键匹配，不靠姓名或金额猜配；多店订单号可能重名，须保留店铺命名空间。无法匹配的记录独立保留，不做强行连接。
GA4 的交易 ID 文档要求每单唯一，避免空字符串，并限定交易去重适用于网页数据流。原始接收日志、去重后交易明细与最终报表须分开标识；重复发送不自动等于最终报表重复计数。退款属于另一事件类型，多次部分退款还需各自的记录标识，不能按一个 transaction_id 把购买和退款全部合并成一行。
金额先逐项映射。按 Google 的 purchase 参考，value 是各项 price × quantity 之和，不含税与运费；有商品折扣时 price 使用折后单价，提供 value 时须提供 currency。核对实际载荷是否符合定义，不能拿含税运费的订单总额直接比。退款则需检查对应 refund 记录与 transaction_id，不能假设后台退款自然出现在分析工具中。电商测量说明
3. 用一批虚构订单复算
以下全部为原创练习数据，币种 USD、时区 Asia/Shanghai。业务范围是 2026-10-01 00:00 至 10-04 00:00 首次付款成功的网页订单；排除一笔未付款取消单 70 和一笔测试单 30。保留已付款后部分退款的订单。金额基准是自定义的折后商品金额，不含税运费，不能当作 Shopify 某张报表的默认字段。
| 订单 / 交易 ID | 付款时间 | 商品原额 − 折扣 | 税 / 运费 | 截至 10-08 12:00 的业务变化 |
|---|---|---|---|---|
| A / T-A | 10-01 10:00 | 120 − 20 = 100 | 0 / 0 | 10-05 10:00 商品退款 20，无税运费退款 |
| B / T-B | 10-02 11:00 | 80 − 0 = 80 | 0 / 0 | 无后续变化 |
| C / T-C | 10-02 14:00 | 60 − 0 = 60 | 0 / 0 | 无后续变化 |
| D / T-D | 10-03 16:00 | 50 − 0 = 50 | 5 / 5 | 无后续变化 |
| E / T-E | 10-03 23:58 | 40 − 0 = 40 | 0 / 0 | 无后续变化 |
本例分析侧使用未经去重的采集层原始接收日志，不是 GA4 界面报表。假定 A、B、D、E 均符合本次采集条件；C 有记录证明当时未授予该采集所需同意，按本例配置未发送购买事件。
| 交易 ID | 原始购买日志 | 证据与处理 |
|---|---|---|
| T-A | value 100 一条 | 正常；另有 10-05 的 refund 20，与购买分别保留 |
| T-B | value 80 两条 | 已确认同一购买重复发送；对账视图保留一笔 |
| T-C | 无 | 采集资格缺口，保留在业务总体，不补发 |
| T-D | value 60 一条 | 已确认错误包含税 5 与运费 5；调整视图减 10，原始错误保留并交开发处理 |
| T-E | value 40 一条，10-05 08:00 才接收 | 发生于业务窗口内；属于迟到，不能按到达日移成新订单 |
10-04 12:00 首次提取时，T-E 尚未到达：原始购买日志为 4 条、合计 320；T-A 的退款也尚未发生。10-08 12:00 再提取时，T-E 已到达，原始购买日志为 5 条、合计 360，另有 refund 20。下面只使用第二次快照：
| 比较层次 | 复算 | 结果 |
|---|---|---|
| 业务购买基准 | 100 + 80 + 60 + 50 + 40 | 5 笔，330 |
| 原始购买日志 | 100 + 80 + 80 + 60 + 40 | 5 条，360 |
| 剔除已确认重复 | 360 − 80 | 4 笔，280 |
| 调整误含税运费 | 280 − 5 − 5 | 4 笔，270 |
| 购买差异 | 330 − 270 | 1 笔，60 |
| 业务批次扣商品退款 | 330 − 20 | 310 |
| 观测批次扣相同退款 | 270 − 20 | 250 |
| 退款后差异 | 310 − 250 | 60 |
原始日志“5 条”与业务“5 笔”数量相同，却不是同一个集合。购买金额原始差异为 360 − 330 = 30，可分解为重复增加 80、误含税运费增加 10、未采集减少 60。它们互相抵消，汇总接近不能证明质量良好。
本例匹配了业务总体的 4 ÷ 5 = 80%，但在已确认符合采集条件的 4 笔中匹配了 4 笔。这只描述本例覆盖与连接结果，不证明全站分析覆盖率，更不能据此给全部渠道业绩乘以 1.25。
4. 给每个差异写证据，不按猜测分摊
先看只在业务侧、只在分析侧、两侧都有但不一致的集合；再按状态、时间、币种与金额分项解释。一个订单可以有多个问题，分别登记，汇总差异时则注明每项调整发生在哪一步，防止重复扣除。
同意状态未知时写未知，不能反推“没事件就是拒绝”。已确认不应采集的缺口不进入补发清单；建模也不能补成逐单证据。Google 的行为建模说明明确建模受资格条件限制，且 BigQuery 等导出不包含这类行为建模数据。比较前须注明数据是否含估计，不能把不同数据层当作同一来源。
多币种先分币种对账。确需换算时保留原币金额、汇率来源、换算日期与舍入规则；没有这些依据，不把汇率差异归为漏报。Shopify 字段与同一购买链的金额排查分别转到报表说明和金额排查方法。
5. 交付可使用范围与下一次复核
差异表每项写明已解释、需修复或待查，附证据、负责人和复核日期。依数据质量判断哪些读数可用、哪些有限可用、哪些决定应暂停；不要只给整批一个“通过”。修复后需要新的观测证据，调整视图正确不代表采集已经修好。
完成前检查：
- 两侧范围、时区、币种、状态与金额映射可复现，原始快照和提取时间可追溯。
- 购买次数、唯一交易数与业务订单数分开，空 ID、碰撞和无法匹配记录单列。
- 重复、迟到、税运费、折扣及退款调整能逐项复算，购买与退款不相互去重。
- 业务总体、采集资格和实际观测分别报告；未知原因没有被强行解释。
- 未解释差异及未完成观察窗口明确保留，并有使用限制、责任人与下次复核安排。