📍 WDQWDWQD987AAAAA:216.73.216.36
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4bca89cc808c.html
📄

推广服务商：甲乙双方指标不同如何建立可对照的交付表

当甲方考核曝光、线索和转化，乙方只按发布量、收录量或素材数量结算时，交付表不能强行统一成一张指标表，而要建立“双方各自指标 + 共同核对项”的对照结构。可行做法是：先确认两套指标能否通过同一份原始记录回溯，再决定用一张对照表还是两张表加一张映射表。

先判断两套指标是否同源

建立可对照交付表的第一步不是列字段，而是确认甲乙双方的指标是否来自同一批可追溯的原始记录。同源时，一张主表加两列口径说明就能对齐；不同源时，强行合并只会让双方在验收时各说各话。

可以区分两种情况：

• 同源可对照：甲方的“有效线索”与乙方的“表单提交量”都来自同一表单后台或同一统计工具，只是筛选条件不同。此时差异是口径差异，可以通过字段映射解决。
• 不同源不可直接对照：甲方看的是 CRM 里的成交阶段，乙方看的是内容平台的发布记录，两者之间没有共同的唯一标识。此时对照表只能做到时间、批次、数量级的粗略对齐，不能承诺逐条对应。

判断依据是：能否用同一个编号或同一份导出文件把两边记录串起来。能串起来，就继续做字段映射；串不起来，就要在交付表里明确写“仅作批次级对照”，避免验收时把两套数当成一套数。

同源条件下：一张主表加口径列

如果双方指标同源，建议用一张主表，把甲方指标、乙方指标、共同核对项放在同一行，并增加“口径说明”和“差异原因”两列。这样做的目的是让每次验收都能看到同一批数据在两个口径下的表现，而不是分别看两份报表。

具体动作可以这样设计：

1. 确定一个共同主键，例如批次号、内容编号或日期区间。
2. 每一行同时填入甲方指标值和乙方指标值。
3. 增加一列记录差异原因，例如“甲方剔除重复提交”“乙方按原始提交计数”。
4. 验收时先核对主键是否齐全，再核对差异原因是否与约定一致。

假设一个批次中乙方记录 100 条提交，甲方按去重和有效性筛选后记录 72 条。如果差异原因列写明“去重 18 条、无效号码 10 条”，双方就能对着同一行确认，而不是各自拿一份总数争论。这个例子的数字只用于说明对照方法，实际差异需要按各自后台记录逐项核对。

这个动作的结果会影响下一步：如果差异原因能逐项对应，下一批次可以继续沿用这张表；如果差异原因无法解释，说明口径还没有真正对齐，需要先回到原始记录层面重新约定，而不是急着扩大交付量。

不同源条件下：两张表加一张映射表

当双方指标来自不同系统、无法逐条对应时，不要硬做一张主表。更稳妥的做法是保留两张各自独立的指标表，再增加一张映射表，只对齐时间、批次和总量级。映射表的作用是让双方知道“这两个数不是同一件事”，而不是制造一个看似统一的合计数。

映射表至少应包含：

• 时间区间或批次编号，作为两边都能接受的对照轴。
• 甲方指标名称与数值，保留甲方原始口径。
• 乙方指标名称与数值，保留乙方原始口径。
• 对照级别，写明是“批次级”“日级”还是“仅总量参考”。
• 不可对照说明，写清哪些结论不能从这张表直接推出。

例如甲方按周统计线索量，乙方按内容条目统计发布量，两者之间没有一对一关系。映射表可以显示“本周发布 20 条，甲方记录线索 15 条”，但不能据此判断哪一条内容带来了哪一条线索。这个边界必须写进交付表，否则规模化后一旦出现例外，双方会默认存在并不存在的对应关系。

实施这个动作后，验收流程会发生变化：先确认映射表的对照级别是否被双方接受，再分别验收两张原始表。如果某一周甲方线索量下降而乙方发布量正常，映射表只能提示“两边趋势不一致”，不能直接归因，下一步应是检查各自系统内的记录，而不是直接调整结算。

规模化后出现例外时怎么处理

个别样本下成立的对照关系，在批量执行后经常出现例外。常见原因是：样本阶段人工核对了每一条记录，规模化后改为自动汇总，两边系统的去重规则、时间归属规则或状态更新延迟开始产生差异。这不是某一方故意做错，而是对照表没有预留例外处理位置。

可以在交付表中增加一个“例外登记”区域，记录无法按常规规则对照的批次或记录，并写明处理状态。处理状态至少区分：待双方确认、已按约定归入某一方口径、暂不纳入本期对照。这样做的结果是，例外不会被悄悄混入正常数据，也不会因为一条异常记录导致整张表被推翻。

需要说明适用条件：如果双方指标差异本身就是业务常态，例如甲方考核成交、乙方只负责内容发布，那么对照表的目标应限定为“过程可核对”，而不是“结果可换算”。把不可换算的关系写成可换算，会在规模化后制造更多争议。

交付表落地前要确认的三件事

在正式使用对照表之前，建议双方确认以下三点，避免表格建好之后仍然无法验收：

• 主键是否唯一且稳定：批次号或内容编号在两边系统中是否都能查到，是否会重复或变更。
• 更新时点是否一致：甲方数据是实时更新还是按日汇总，乙方是发布即记录还是审核后记录。时点不同，同一批次在两边看到的数值本来就可能不同。
• 争议由谁裁定：当两边数值无法对照时，以哪一方的原始记录为准，或者是否需要回到第三方可查的记录。这个规则要提前写进交付表，而不是等到争议发生后再补。

完成这三项确认后，再决定用一张主表还是两张表加映射表。判断标准很简单：如果双方能接受同一主键下的差异原因，就用一张主表；如果只能接受批次级对照，就用两张表加映射表，并把不可对照的结论明确排除在验收依据之外。这样建立的交付表，才能在样本之外仍然经得起核对。