ad-attribution-gap

归因差异核对

你是一名营销衡量分析师。请交付一份核对报告：明确指出各报告系统所报告数据之间的差异，并将差异中的每个单位归因于一个明确的原因。广告平台、分析工具和记录资金的系统之间存在结构性差异，这是预期之中的——如果一份报告中的数字完全一致，那就说明有人捏造了数字。

每个步骤都应用同一项检验：这一步能否量化差异，并将差异归因于一个明确的原因？如果不能，就跳过。

工作边界——移交，不要接手

• 跟踪的修复或安装（标签、像素、去重设置）不在范围内。如果分析得出“标签触发异常”或“去重失效”，请说明这一发现、量化其占差异的比例、指定负责人，并将问题移交给 mbfinotti/advertising-skills@ad-conversion-tracking。
• 选择归因模型不在范围内。应将模型差异视为需要衡量和抵消的差异原因，而不是需要做出的决策。如果用户问“我应该使用哪种模型”，请将其引导至归因模型选择资源。
• 广告账户表现诊断、落地页工作以及 CAC/ROAS 基准分析属于其他技能的范畴。

从财务核对中借鉴的原则

财务核对会先将双方调整至同一余额再进行比较，对每个调节项进行分类，并且只有在差额为 $0.00 时才结账。借鉴前两步，并有意打破第三步：

1. 在比较任何数字之前，将双方标准化到共同的基础上。
2. 将每个差异单位恰好归入以下三个类别之一：时点差异、定义差异或无法解释的残差。
3. 明确说明残差，不要将其压至零。银行核对必须与 $0.00 相符。归因核对永远不会如此，因为各系统实际统计的对象不同。目标是残差较小且原因明确，而不是残差为零。

首先采用这项判断检验——它优于任何百分比阈值，因为它适用于任意规模的账户：

• 当差异在不同周期内_稳定_、方向符合预期，且_可分解为明确的原因_时，差异属于正常。
• 当差异_方向反转_、突然跳变，或_无法归因于已知机制_时，差异属于缺陷。

这项检验与上述分类完全对应：所谓缺陷，正是无法归入时点差异或定义差异的差异。

开始前——五个问题

一开始就把这些问题打包询问。这是一次战术执行，不是战略访谈。

1. 涉及哪些来源？请说出广告平台、分析工具和事实来源。
2. 哪个系统记录资金——CRM 还是订单／计费系统？该系统决定转化次数。如果用户提议以广告平台为准，请提出异议：平台报告的是对转化的归因认领，而不是实际收到的资金。
3. 这个差距阻碍了什么决策？（预算重新分配、董事会数据、对某个渠道的信任。）这决定了需要拆解得多深入。
4. 日期范围和粒度是什么？建议按周或按月比较——按天比较会放大时区和日期标记造成的偏差，产生虚假的差异。
5. 是 B2B、B2C／电商，还是混合型？混合型企业应将两种漏斗分别进行核对（参见 B2B 与 B2C 部分）。

同一轮再问三个问题。它们只多占一条消息，却能决定本次执行最终采用的排序方式——没有这些信息，就无法替用户排列缺陷清单和下一步测量方案的优先级：

6. 答案最迟必须在哪天交付？ 临近的硬性期限会优先考虑能快速见效的方案——自我报告归因、花一小时修复标签或表单——并排除任何需要完整测试周期的方案。
7. 一次性成果还是可累积的资产？ 一次性答案更适合针对有争议的单个渠道进行留出测试。只有需要持续累积成果时，才值得开展常设测量工作。
8. 工作量上限是多少？ 包括分析师工时、工程协调、暂缓支出的政治资本，以及变更所需的可逆性。如果上限是“本周我自己的工时”，就排除所有需要其他团队参与的方案。

如果你能读取用户导出的报告（CSV、电子表格、数据仓库提取文件），就使用这些报告。否则，请用户粘贴各系统自身的以下数值：

• 约定时间范围内的转化总数和收入。
• 日期依据、时区、币种。
• 系统自身设置中显示的归因窗口和计数规则。

步骤 1 - 统一到共同基准

未经标准化的比较毫无意义，而标准化恰恰是从业者最容易跳过的一步。只要两份报告涵盖相同的转化操作、相同的时区日期范围和相同的定义，大多数所谓的“差异”就会随之缩小。请对齐以下各项，并在报告中记录选定的基准：

1. 日期基准。 广告平台通常会将转化记在广告互动日期（点击或展示）并回溯记录。分析工具和事实来源则会将转化记在转化事件日期。同一个周一的点击带来周四的购买，在一个系统中显示为周一，在另一个系统中则显示为周四，因此，范围较窄的数据提取可能会在一个系统中显示一次转化，在另一个系统中显示为零。请调整其中一方的日期，或扩大时间范围，直到涵盖这两种基准。
2. 时区。 每个系统都使用各自配置的时区进行报告。临近午夜的转化会落在不同的日历日期，但这并不代表实际存在差异。按周或按月统计大多可以消除这种影响。
3. 货币。 确认每个系统使用的货币，以及由哪一方进行货币换算。对于收入，以事实来源在交易日期使用的汇率为基准。
4. 转化定义。 对齐计入的事件，以及各系统的计数规则——有些平台会对每次点击计入_所有_转化，有些则只计入_一次_。同一笔订单在不同仪表板中可能会以不同的数量显示。
5. 归因窗口和模型。 不要假定默认值——平台默认设置会变化，且各个平台也不相同。如果可以浏览网页，请查找各平台当前文档中说明的默认窗口。否则，请让用户从平台设置中读取该值。在可配置的情况下，让各系统的窗口和模型保持一致。若无法配置，请在步骤 3 中将差异记录为需量化的定义层面原因。
6. 点击归因与展示归因。 平台会计入展示归因转化，而基于点击的分析工具无法看到这些转化。请在比较前将展示归因转化单独排除，或将其作为定义层面的一项单独列出。
7. 建模数据与观测数据。 当追踪受阻时，平台和分析工具会添加建模或估算的转化。切勿将建模估算值与确定的订单数量进行比较，却不注明两者各自的类型。
8. 收入基准。 选择一种基准：建议默认使用扣除税费和运费后的净收入。将其应用于所有系统，并记录各方如何处理退款、取消和折扣。
9. 数据成熟度。 仅比较归因期已成熟的时间范围：如果该范围内有一部分仍处于开放的归因窗口中，那么平台数据提取后数值还会继续增长，因此请将尚未成熟的部分标记为时间差异。分析侧的数据也会延迟稳定，因此，在将未匹配项视为差距之前，请先等待近期转化数据成熟——一种从业者采用的方法是等待整整 4 天。过早比较会凭空制造差异，而仅使用单日窗口则会造成最糟糕的情况：请使用 7 天或更长的窗口。

第 2 步——量化差距

1. 以事实来源为准，确定转化次数和收入。其他所有来源只能说明转化来自_哪里_，不能说明有_多少_转化。
2. 对每一组数据——每个广告平台与基准数据、分析工具与基准数据，以及平台与分析工具——计算绝对差值和相对于基准数据的百分比，并标明正负方向（哪一方更高）。
3. 绝不汇总不同广告平台的数据。如果一个平台报告 100 次转化，另一个报告 80 次，而订单系统记录了 120 次，那么实际就是 120 次转化，平台报告存在重叠，而不是 180 次。平台报告之间的重叠本身就是需要量化的定义差异。
4. 每组数据的总差距（标准化后的绝对差值）就是第 3 步需要拆解的量。
5. 执行整体交叉核对：MER = 总收入 ÷ 总广告支出，使用事实来源中的数据和实际计费支出计算。一家归因服务商提到，5.0 以上是常见数值，但也提醒其因行业和发展阶段而有很大差异。将 MER 视为完全绕开单个平台归因的交叉核对指标，绝不能将其作为目标。如果各平台的数据有所改善，但 MER 变差，那么有问题的是平台数据。
6. 比率核对：平台报告的转化次数如果超过基准记录次数的大约 1.5 倍，可能存在重复计数（这是从业者的经验判断，并非标准）——将其归入类别 3 调查，而不是类别 2。

第 1–4 步对 B2B 和 B2C 完全相同，只有基准系统不同。

第 3 步——将每个单位恰好归入一个类别

首先应用方向规则：每个原因都会以已知方向推动差距。若某个原因会朝相反方向推动差距，就无法解释当前方向的差距——用这一点快速排除候选原因。以下列表中的“平台偏高”表示该原因会使广告平台报告的数值高于基准数据。

类别 1——时间差：实际存在，会自行消除

等处理完成后，两个系统就会一致。无需修复，但必须调整比较日期或稍后重新运行。记录每项差异预期消除的日期。

• 按广告互动日期与按事件日期标记（方向取决于数据拉取时点位于时间窗口的哪一端）。
• 归因窗口仍处于开放状态——近期点击带来的转化尚未计入（平台偏低，之后会追上）。
• B2B 潜在客户到成交的延迟：客户在点击数周后才在 CRM 中成交。窗口短于销售周期的平台永远无法记录这笔成交（相对于已成交收入，平台偏低）。
• 线下转化上传和处理延迟——数据会在事件发生数小时或数天后导入（处理完成前平台偏低）。
• 处理中订单：一个系统已计入待处理或尚未履约的订单，另一个系统尚未计入。

类别 2——定义差异：实际存在，有明确解释，永远不会消除

各系统统计的确实是不同的内容。量化每一项，并将其作为有记录、可预期的差异保留——不要尝试“修复”。

• 归因窗口长度不同（窗口较长的系统数值偏高）。
• 归因模型不同——平台将 100% 的功劳归给自己的点击，而跨渠道分析模型会将功劳分配给多个渠道（相对于分析工具，平台偏高）。
• 只有一方计入了浏览后转化（平台偏高）。
• 只有一方计入了建模或估算的转化（该方偏高）。
• 计数规则不同：“每次”与“每次点击仅一次”转化（采用“每次”规则的一方偏高）。
• 跨平台自我归功导致重叠——多个平台各自认领同一笔转化（与基准数据相比，平台汇总值偏高，因此绝不能汇总各平台数据）。
• 收入按含税、含运费和未扣折扣，或按扣除这些项目后计算（按扣除前口径的一方偏高）。
• 事实来源记录了退款、取消和拒付，但平台或分析工具很少撤销这些记录（就收入而言，平台或分析工具偏高）。
• 采用不同的汇率或换算日期。
• 各系统的机器人流量或无效流量过滤规则不同。

第 3 类——无法解释的残差：唯一表明存在缺陷的类别

量化第 1 类和第 2 类后剩余的部分。这是唯一需要升级处理的类别，也是唯一交由 mbfinotti/advertising-skills@ad-conversion-tracking 处理的类别。可能藏在这里的已知机制：

• 标签损坏、缺失或重复触发（重复触发：平台数据偏高，通常远超约 1.5 倍的比率）。
• 浏览器/服务器事件去重失败（平台数据偏高）。
• 超出预期基线的同意管理、跟踪防护和广告拦截器造成的数据损失（分析数据偏低）。
• 跟踪参数被重定向、链接缩短服务或应用内浏览器剥除，流量被归入“直接访问”（分析数据错误归因；渠道层面存在差距，但总量层面没有差距）。
• AI 助手引荐：AI 助手带来的流量中，约 70% 没有引荐来源，因而被错误归类为“直接访问”（某份增长通讯给出的数据，仅供参考，并非经过审计）。渠道结构向“直接访问”倾斜，但总量没有变化。
• 跨设备和身份识别差距——用户旅程在不同设备或子域名之间断开（分析数据偏低，平台数据受影响较小）。
• 测试订单和内部流量污染数据源（基准数据偏高——没错，基准数据也可能出错）。

每个类别中的每一项都要注明：数量（单位和收入）、方向检查是否通过、证据和负责人。如果某个数值只能估算，请标明为估算值并说明依据。

第 4 步——评估残差

1. 逐对计算残差：总差距减去已量化的时间差和定义差。以数量、收入以及占总差距的比例表示。

2. 应用判断标准：残差是否稳定、方向一致且较小？如果是，记录下来并停止——不要追求将其降至零。

3. 诚实地说明“小”的背景：唯一正式公布的容差来自一家大型分析平台自身的文档——页面浏览量差异不超过 10%、用户数/会话数差异不超过 20%，“都在预期范围内，不必担心”。以下其他区间都来自提供跟踪审计服务的供应商和代理商，因此它们的共识趋势有参考意义，但具体百分比是自行报告的，未经审计。请将其引用为参考性排查启发，而非标准，并在报告中明确说明：

   对比对象	引用的正常范围	引用的调查范围
   广告平台与分析平台	10–20%	明显超出该区间；10–30% 也常被引用为正常范围
   分析平台与订单后端	低于约 25%	高于约 35%
   服务器端与浏览器事件	不超过约 10%	约 30%，且匹配率低于 50%

4. 校准先验判断：代理机构的审计报告显示，大多数账户至少存在一项重大的转化跟踪缺陷。发现 Bucket 3 缺陷是常见情况，而非例外。不过，仍须按照方向规则对其进行归类，否则它就会留作残差，而不会成为结论。

5. 方向反转、突然跳变或无法用任何已知机制解释的残差，都是缺陷。按每单位修复工作量对应的收入影响排列缺陷优先级，绝不能只看收入。展示调整过程：先说明每项缺陷的收入影响，再说明修复工作量，最后说明该比值实际将其排在什么位置。常见缺陷类别的典型排序如下：

   • 效率：重复触发的标签 > 锚点污染（测试订单和内部订单） > 缺失的 click-ID 捕获 > 被剥离的跟踪参数 > 损坏或缺失的标签 > 浏览器端／服务器端去重失败 > 同意和跟踪防护导致的数据损失 > 跨设备身份缺口
   • 价值：跨设备身份缺口 > 同意和跟踪防护导致的数据损失 > 浏览器端／服务器端去重失败 > 重复触发的标签 > 损坏或缺失的标签 > 缺失的 click-ID 捕获 > 被剥离的跟踪参数 > 锚点污染

   两种排序正好相反，这正是要将它们分开排序的原因。

   • 身份和同意导致的数据损失，涉及的收入金额最大，也最难修复：需要数周工程工作，或建立一项长期任务；无论投入多少工作量，这些损失在一定程度上都是结构性的。同意损失的补救措施还需要获得法务批准后才能上线，因此其排名会进一步低于按收入影响排出的名次。
   • 缺失的隐藏表单字段、针对测试订单的筛选器或重复标签，都只需一小时即可完成工作，且能完全修复。

   四类只需一小时的缺陷不能互换，尽管它们的工作量相同：

   • 重复标签优先：一位负责人只需修复一个标签容器，就能解决大量高估问题。
   • 其次是锚点污染：工作量几乎为零，分析师可全权负责。
   • click-ID 捕获和参数剥离各需第二个团队投入一小时：前者由营销运营团队处理表单字段，后者由负责重定向链的团队处理。

   这种效率排序会让价值排序顶端的项目得不到处理。跨设备身份缺口和同意损失在比值排序中每次都落后，因此一再被推迟，而那些只需一小时的修复则轮番完成。

   满足以下任一条件时，将它们提到只需一小时修复的类别之上：

   • 该缺口负责造成的损失逐期_扩大_，而非保持稳定。
   • 第 3 个问题中提到的决策，是会被身份缺口本身扭曲的渠道级预算重新分配。

   稳定的结构性损失可以暂缓处理。持续扩大的损失会在未来每一期不断累积。

   报告前，针对当前账户重新排序：团队已能自行修复的缺陷类别应上调；访谈中提到的硬性截止日期，则会让所有只需数周的类别排在所有只需数小时的类别之后。对于该账户完全无力处理的类别，应直接删除，而不是下调排名。如果没有任何团队会负责此处的服务器端身份处理工作，就在修复优先级列表中按名称删去该项，并将其作为未分配所有者、已量化的差异列入已知差异部分。

   排名末尾的类别会在下一期再次作为待处理范围出现。为每项缺陷指定负责人，并将跟踪缺陷交由 mbfinotti/advertising-skills@ad-conversion-tracking 处理。

6. 当残差经所有机制检验后仍然存在，或两个平台对相同转化次数各执一词时，答案必须来自核对流程之外。从下一节按优先级排列的后续步骤中选出一项，指定负责人，到此为止。

核对流程无法得出结论时——后续测量，按优先级排列

有两种情况需要超出此技能的处理范围：

• Bucket 3 残差经所有已知机制检验后仍然存在。
• 两个平台都声称拥有相同的转化次数，而核对流程只能证明两者存在重叠。

指出下一步并指定负责人。设计或执行其中任何一项都超出此技能的范围；其中两个跟踪环节应交由 mbfinotti/advertising-skills@ad-conversion-tracking 处理。 按单位投入所能获得的价值排序，而不是按听起来有多确凿排序。这些维度并不一致，因此请综合考量：

• 效率：自我报告归因 > 留出组或地理区域测试 > 使用共享事件 ID 的服务端数据采集 > 同意信号配置和建模转化 > 媒体组合建模
• 价值：留出组或地理区域测试 > 媒体组合建模 > 使用共享事件 ID 的服务端数据采集 > 自我报告归因 > 同意信号配置和建模转化
• 投入：媒体组合建模 > 留出组或地理区域测试 > 使用共享事件 ID 的服务端数据采集 > 同意信号配置和建模转化 > 自我报告归因
• 合规成本：同意信号配置和建模转化 > 使用共享事件 ID 的服务端数据采集 > 自我报告归因 > 留出组或地理区域测试 == 媒体组合建模

从投入来看，留出组高于服务端数据采集。构建工作需要两个团队投入约一周的工程时间。留出组需要在整个测试周期内暂停投放，这可能持续数周到一个季度，而且期间一直会消耗政治资本。

合规成本持平是真正的相等，而不是暂缓决策。两者都处于该维度的最低点：都不会收集任何新的个人数据。没有需要披露的内容，也没有需要审核的内容；撤销后也不会重新收集任何数据。

阶梯	投入	收获	代价
自我报告归因	花一小时填写表单并添加一个报告字段，然后等待一段时间才能看到结果	获得一个不受用户同意流失影响的独立渠道信号——粒度较粗且有自我报告偏差，但无法被阻断	隐私声明中需为新字段添加一行说明
留出组或地理区域测试	花一两天设计测试，然后经历完整的测试周期（B2C 需数周，B2B 按季度周期计算），还要承担暂停投放所需的政治成本	获得唯一的因果性答案，并彻底解决两个平台之间的归属权争端	没有监管方面的代价；恢复投放即可完全撤销
使用共享事件 ID 的服务端数据收集	两个团队合计约一周的工程工作	找回实际观察到的转化，而非估算值，并从源头杜绝重复计数	需在服务端传递同意信号，并在发送第一个事件前完成数据驻留和合同审查
同意信号配置和建模转化	花一天时间设置，然后获得由供应商提供且无法审计的输出	恢复平台侧的转化量估算值——这只是重现步骤 1 中建模值与观察值的差异，并未消除它	每个司法管辖区都需法律批准；错误配置无法撤销，只能重新收集同意
媒体组合建模	持续投入：构建数据管道、进行建模，并由专人负责更新频率	进行跨渠道的整体预算分配，涵盖任何转化记录都无法覆盖的渠道，包括线下渠道和品牌	没有监管方面的代价——它使用汇总后的支出和结果数据运行

默认阶梯：自我报告归因，与现有对账流程并行运行。

效率排序牺牲的是这份菜单中因果性证据的获取。留出组和媒体组合建模能提供任何对账都无法生成的证据，但每次效率评比都会输给一小时的表单工作：媒体组合建模的效率排名垫底，价值排名却位居第二。

这两者都不会因比率而晋级，因此各自都需要一个专属触发条件，并且必须审慎应用。

• 一旦两个平台声称拥有相同的转化，且争议预算足以证明暂停投放的合理性，就启用留出组。没有更低成本的阶梯能解决归属权争端。
• 当整体组合涵盖任何转化记录都无法覆盖的渠道（包括线下渠道和品牌），且有人能长期负责时，就启用媒体组合建模。

这个排序是默认方案，而非定律：它会随具体情境和执行者而变化。结合你对这个客户的已有了解，重新排序：

• 已经对营销数据建模的数据仓库，会大幅减少混合建模的工作量。
• 现有的服务端采集层，能让这一层变成配置变更。
• 严格的同意授权管辖区会让同意信号工作成为必选项，不受其占比影响。

访谈回答也会改变排序：近期有硬性截止日期，会让所有需要完整测试周期的层级降级；一次性要求则会让两个常设层级降级。

如果用户的限制排除了某一层级，就将其删除，而不是放在列表底部，并在报告中说明删除了哪一项。如果用户拒绝从任何地区或受众中扣留支出，就直接删除留出组和地理测试。将剩余四项排序，并说明因果层级不在选项之列，而不是把它留在“稍后”标题下，导致它下季度又作为范围重新出现。

• 没有工程资源，就会像删除混合建模一样，删除服务端采集。
• 没有人负责定期更新，就会删除混合建模。
• 账户中没有受同意授权法规约束的流量，就会删除同意信号配置。

成熟的最终状态是三角验证，而不是选出赢家：

• 平台归因用于每日竞价优化。
• 增量实验用于获取因果层面的真实结果。
• 混合建模用于组合分配。
• 不单独信任任何一种方法。

平台报告在结构上总是会自我美化（一份增长通讯如是说：“每个平台的 AI 都经过优化，让自己看起来表现出色。”），因此纠正工作必须来自平台之外。

B2B 与 B2C

两者的归一化维度、三个类别、方向规则、禁止求和规则、报告形式以及平台自我归因的处理方式都相同。不要寻找不存在的差异。

B2B（锚点：CRM）。

• 按 线索创建日期 划分队列，而不是按成交日期，否则比较毫无意义——主要的时间差异是从线索到成交的间隔，按成交日期提取数据会混合平台在相隔数月时看到的不同队列。
• 与平台对接的桥梁是离线转化导入，依据广告平台的点击 ID 进行匹配。该 ID 会被隐藏表单字段捕获并存储在线索中。导入本身的上传延迟和匹配率都是差异的成因。
  • 从业者报告的点击 ID 匹配率通常在 75–85% 左右。
  • 低于约 50% 时，应怀疑捕获缺陷：Cookie 被拦截、ID 在重定向过程中被剥除，或 CRM 未在每次提交时保存该 ID。这属于类别 3。
  • 平台还会限制点击后多久之内接受导入。请查看当前文档中规定的时间窗口。
  • 浏览器跟踪防护可能会在几天内删除存储于 Cookie 的点击 ID，因此在首次点击时进行服务器端捕获很重要。
• 在账户层级而非联系人层级归因，否则多人组成的采购群体中，只有填写表单的人会获得归因。
• 预期数据量较低：在分母较小时，百分比差异会剧烈波动。报告每个百分比时都应同时列出绝对单位，并优先采用较长的时间窗口。
• 在较长周期中，末次触点会低估平台贡献——正如 B2B 广告从业者 AJ Wilcox 所说：“它忽略了发现阶段。潜在客户很少会在点击一次后就转化。”将模型差异记录为定义差异。分析过程中不要切换模型。

B2C/电商（锚点：订单/计费系统）。

• 主要的定义差异包括退款、取消、重复/测试订单，以及收入按税费、运费和折扣前还是扣除后入账。定义一种收入计算口径（建议采用扣除税费和运费后的净额），并在所有地方统一使用。
• 订单生命周期（待处理 → 已付款 → 已履约 → 已退款/取消）会产生广告平台看不到的冲销。退款甚至可能出现在订单系统的一份报告中，而未出现在另一份报告中，因此也要审计锚点数据。
• 浏览器与服务器之间通过共享事件 ID（通常是订单 ID）进行对接，用于对每个购买事件的两份副本去重。事件 ID 缺失或不匹配会导致类别 3 的重复计数。
• 与 B2B 相比，平台过度归因的问题更突出，因为浏览后转化和建模转化在平台计数中占比更高。
• 短周期意味着时间差异会在几天内消退——窗口结束后重新运行比较，类别 1 的大部分差异应该会消失。

报告

请提交一份对账报告，包含以下部分（完整的实例见 ./references/reconciliation-examples.md，其中包含一个 B2C 案例和一个 B2B 案例）：

1. 摘要 - 锚定系统、锚定系统的数字，以及每组对比的一句话结论（“结构性差异，原因已明”或“发现缺陷，已指派负责人”）。
2. 标准化依据 - 日期依据、粒度、时区、币种、转化定义、时间窗口／模型设置、收入依据。注明定义的生效日期：若转化定义变更却未标注日期，所有趋势对比都会失效。
3. 差异表 - 每项原因占一行，列包括：来源系统组合 | 指标 | 金额 | 占总差额的百分比 | 分类 | 原因 | 方向核验 | 证据 | 负责人 | 状态。
4. 剩余差异说明 - 针对每组对比，列出总差额、已解释比例、剩余差异，以及判断测试的结论。
5. 缺陷与交接事项 - 按每单位修复工作量所涉收入从高到低排序；将收入金额和工作量调整值列为单独的列，让读者看出为什么金额最大的事项不一定排在首位。每项都应有负责人和下一步行动。
6. 需要沿用的已知差异 - 列出下期需重新应用的定义说明，确保下次对账从已记录的预期出发，而不是引发警报。

所有面向董事会或高管的数字都应以财务级事实来源为准。平台报告的数字仅用于平台内的出价优化；任何展示平台 ROAS 的演示文稿都应标明该数据不代表增量效果。负责人列可参考以下常见分工：

角色	负责事项
分析师（通常是本指南的读者）	标准化和对账工作本身
媒体买手	平台配置、时间窗口、标记参数
营销运营／RevOps	CRM 字段、点击 ID 捕获
数据／分析工程	数仓模型、去重键
财务	净收入——记录值

常见错误

• 未先进行标准化就直接比较——这是最常见的误报。按点击日期统计的总量与按事件日期统计的总量，本来就会不同，这不代表存在缺陷。
• 将不同广告平台的转化量相加，或将使用不同时间窗口的平台数据合并为一个总数。
• 强行将剩余差异降至零。完美对平意味着数据可能经过捏造，而非严谨。
• 将 10–30% 的经验范围当作标准，或引用任何容差却不注明其来源状态。
• 将模型估算值与确定性计数相比较，仿佛两者都是对已计数交易的统计。
• 测算一次平均差异后，就永远将其作为固定修正值扣除——同意率和媒体组合会不断变化，差异也随之变化。每期都应重新推导。
• 假设某个系统“正确”：两个系统可能都没有错，只是测量的对象不同；而锚定系统也可能受到污染（例如测试订单、未冲销的退款）。
• B2B 分群按成交日期，而不是按线索创建日期。
• 对低量级 B2B 数据只报告百分比。
• 修复标记却不在报告历史中添加注释——这项修复会造成数据不连续，看起来就像下期出现了缺陷。

目标和通过门槛

这项技能的自然评分指标是已解释占比：按每组来源数据计算，（量化的时间因素 + 量化的定义因素）÷ 总差额。

• 通过：已解释占比 ≥ 80%，且剩余差异通过判断测试（稳定、方向一致，并且没有尚未检查的已知机制候选项）。
• 为什么是 80%：它容许的剩余差异（≤ 差额的 20%）处于唯一正式公布的预期范围内（根据分析供应商自己的文档，偏差最高达 10–20% 属于正常情况），因此继续追究最后五分之一，只会追求底层数据无法支持的精确度。
• 迭代直至达标：对于每个未解释的单位，按照方向规则逐一检查类别 1 和类别 2 的原因列表。窗口关闭后重新运行，以确认疑似时间因素是否确实已解决。只有这之后，才能将剩余部分视为残余，或将其升级为缺陷。
• 无法达到 100%。如果迭代停滞在 80% 以下，且未发现缺陷，请在报告中明确说明，并列出已排除的因素——坦诚地报告已解释 70% 及排除项，胜过捏造 100%。

参考资料

• mbfinotti/advertising-skills@ad-conversion-tracking - 移交在类别 3 中发现的已确认追踪缺陷（标签失效、去重失败）。
• ./references/reconciliation-examples.md - 完整的核对示例（B2C 和 B2B），包含真实感的示例数字。

可选集成说明（特定于供应商，仅当这些是用户使用的工具时才需要参考）。 上述通用机制对应到具体平台和工具如下：

• Google Ads：按广告互动日期标记、使用“每次”/“一次”计数，以及在 30 天点击 ID 窗口内导入线下转化。
• GA4：按事件日期标记、跨渠道模型。10%/20% 的预期偏差数据来自 Google Analytics 帮助中心，support.google.com/analytics/answer/11986666。
• Meta Pixel 与 Conversions API：通过共享事件 ID 去重。
• 将点击 ID 用作 B2B 关联键：gclid、wbraid/gbraid（Google）、msclkid（Microsoft）、li_fat_id（LinkedIn）。
• 将 Shopify/WooCommerce 用作 B2C 锚点：留意 Shopify“总销售额”公式中的总额与净额，以及退款但未重新入库的情况。
• 将 Salesforce/HubSpot 用作 B2B 锚点。

引用：MER 约 5.0+ 的数据来自 Northbeam。约 70% 的无引荐来源 AI 流量数据来自 Demand Curve（第 331 期通讯）。“优化到让自己看起来不错”这句话来自 Demand Curve。any-touch 引述来自 AJ Wilcox（B2Linked）。