ad-conversion-tracking

转化跟踪

在广告系列预算花出第一美元之前，先验证转化跟踪是否真正反映了实际情况。

• **这项技能旨在防止的反模式：**团队把跟踪当作上线清单上的一个勾选项，仅凭设置截图就打勾，直到支出报告开始变得不合常理时，才发现跟踪早已失效。GrowthSpree 审计过的 B2B SaaS 搜索广告账户中，有 70-80% 至少存在一个重大转化跟踪问题。
• **指导原则：**错误的转化数据不只是报告失实，还会主动训练竞价算法去寻找错误的人群——“如果你的跟踪不准确，平台做出的每一个优化决策都将基于错误数据”（PPC Hero）。

最终产出是一份验证报告，其中列出每项检查的证据，并以明确的 GO / NO-GO 决策和具名审批人收尾。

范围与交接

这项技能负责验证，绝不负责实施。它会生成清单、逐项核查证据并给出结论；编写或安装跟踪代码应由实施负责人负责（在访谈中确认）。相邻事项交由相关技能处理：

• 上线后对账跨平台数据 → mbfinotti/advertising-skills@ad-attribution-gap。
• 账户层面的效果根因诊断 → mbfinotti/advertising-skills@ad-account-diagnostic（该技能会将跟踪 FAIL 问题交回此处）。
• 落地页转化率审查 → mbfinotti/advertising-skills@paid-landing-page-audit。
• 持续监控创意效果衰退 → mbfinotti/advertising-skills@ad-creative-fatigue。

访谈

一次只问一个问题；跳过已知或在设置中可见的问题。这是一次战术性检查，不是正式访谈——简明扼要即可。

1. 广告系列将在哪些平台上投放？
2. 漏斗类型：B2B 潜在客户开发、B2C 电商，还是两者兼有？
3. 浏览器像素/标签之外，是否还运行服务端事件？
4. 谁负责实施——你、开发团队，还是代理机构？（修复事项会指派给他们。）
5. 是否已启用同意横幅？流量是否包含受同意法规约束的地区？
6. 此次上线的预算是多少？（这决定了闸门背后有多少预算面临风险。）
7. 上线日期是固定的还是可以调整？固定日期意味着优先修复几乎不费力的设置和触发器问题，并将点击标识符链延期至上线之后，作为已接受的风险事项；日期可调整，则可以在一次发布中完成整批缺陷修复，并一次性重新学习。
8. 这是仅针对本次广告系列的一次性放行，还是你打算在未来几个季度持续信赖这套跟踪设置？长期复用的意图会提升点击标识符链和共享事件 ID 的优先级——它们对未来每个广告系列都有帮助；一次性使用的意图则只提升能够满足本次上线要求的检查项。
9. 上线前的投入上限是多少：你自己在标签管理器中投入的时间、开发与 CRM 的协调，还是还包括法务审批？没有开发权限，就将修复清单限制在设置和标签管理器层面的工作；报告会逐项列明并删除低于此限制的事项，同时说明因此牺牲的测量能力以及接受这一损失的人——绝不悄悄删去，也绝不只把它们排在最后。

答案 7-9 会重新排列“缺陷清单”中的修复顺序。请记录这些答案——报告必须说明哪些缺陷被延期，以及延期由谁授权。

证据门槛

切勿仅凭配置截图给出 GO 判定——设置页面看起来正确，甚至调试器中显示标签已触发且状态为绿色，都不能证明测量准确。要给出 GO 判定，必须至少完成一次真实测试转化，并端到端追踪：

1. 执行操作。
2. 检查负载。
3. 在平台界面中收到事件，且值和币种正确。
4. 完成去重。
5. 排除测试数据。

有一种明确命名的例外情况：全新且尚无流量的媒体资源，在验证期间无法在平台界面中显示转化（事件可能需要数小时才会显示，且新建的转化操作会先处于等待状态）。此时，可凭借调试模式证据和正确的负载，获得有明确标注的临时通过——并且必须在首批真实转化到达时立即重新验证。

验证顺序

共 9 个步骤，顺序固定。只有前面的步骤都通过后，才能解读每一步的证据：

• 在确认标签实际发送了什么之前，无法评估平台界面。
• 在两个来源都有事件到达之前，无法评估去重。
• 必须在观察期生成数据之前排除测试数据——排除筛选器不会追溯生效。

不要按效率给这些步骤排序，也不要调整顺序，把耗时较少的步骤放在前面：这个顺序是一条依赖链，按投入产出比排序会显得过于精确。效率排序适用于这套顺序生成的修复清单（缺陷检查清单），而不是顺序本身。

逐步记录证据。

1. 设置和转化操作配置。 确认主要转化的指定与业务目标一致——与收入相关的操作设为主要转化，页面浏览和微转化设为次要转化，并从出价中排除。Rawsoft 发现，有一个账户设有 13 个主要转化操作，其中只有 4 个是业务成果，因此智能出价针对每月超过 150 万次的噪声转化进行了优化。对于潜在客户开发，请确认每次点击计数一次（而不是每次点击都计数）。证据：主要操作列表，以及每项操作对应的业务成果；每项操作的计数方法。
2. 进入标签调试／预览模式。 使用标签管理器的预览模式，以及平台的测试事件或标签检查工具。证据：转化页面上可见且已启用的转化标签，并且只在预期触发条件下触发。
3. 端到端执行一次真实测试转化。 按照付费点击的用户实际流程操作——访问带有点击标识符的 URL，接受（并另行拒绝）同意横幅，然后完成操作。B2C：下一个真实的低金额测试订单（使用近乎零折扣的优惠码，或之后退款）。B2B：提交一条带有唯一 QA 值的测试潜在客户记录，并确认该记录进入 CRM。证据：测试订单／潜在客户 ID，以及其携带的标识符。
4. 检查事件载荷。 在浏览器的网络检查器或标签调试工具中读取实际请求：确认事件名称、值、货币、每次转化对应的事件 ID、点击标识符，以及使用时的哈希标识符均正确。证据：复制到报告中的载荷字段。
5. 在平台界面中确认事件。 测试事件应出现在平台的事件管理器中，并标记为浏览器或服务器事件；转化操作应显示记录状态正常。任何状态为配置错误或近期无转化的主要操作，都应自动判定为 NO-GO。得出事件缺失的结论前，应等待数小时，让报告延迟数据补齐。证据：每项主要操作的状态；平台中可见且值和货币正确的测试事件。
6. 验证去重（见下文），适用于浏览器和服务器事件同时运行的情况。证据：该测试操作只计为一次转化；去重率。
7. 排除并清理测试数据（见下文）。证据：筛选器已启用，测试转化已撤回，测试订单已退款／移除。
8. 观察期。 在评估是否扩大规模之前，让真实信号累积几天——从业者确认转化已连续上报几天的信号，以便平台理解目标（Pearmill）；与后端或 CRM 对账，则应等待大约 4 天，让数据稳定下来（Enalitica）。证据：每日计数趋势；差异在阈值范围内（见“目标”部分）。
9. 记录并签字确认。 填写输出格式报告，注明审批人和日期，并作出 GO／NO-GO 决定。缺少明确审批栏的发布检查清单，在发布压力下容易被跳过（Marketing Machine 的模板包含带有审批人和日期的 GO／NO-GO 区块）。证据：已完成的报告本身。

去重检查

当浏览器标签和服务端端点都发送一次转化时，平台需要一个共享键，才能将其计为一次。必须满足三个条件（Analyzify）：

• 两个来源发送相同的共享转化事件 ID（订单 ID 就很合适）。
• 事件名称匹配（必须完全一致，包括大小写）。
• 时间戳位于平台的匹配窗口内——最好只相差几秒。

需要检查的故障情况：

• 服务端生成了不同的事件 ID，或完全没有发送事件 ID——平台无法匹配，每次转化都会被计算两次。
• 每次页面加载都生成新的事件 ID，而不是每次转化生成一个——刷新页面就会产生一次“新”转化。
• 两个来源的事件名称大小写或命名不匹配。
• 时间戳偏差导致事件对超出匹配窗口。

请明确指出错误的修复方式，因为它很容易让人动心：删除服务端事件来阻止重复计数，完全是本末倒置——这会悄无声息地丢弃更可靠的信号来源。正确的修复方式始终是使用共享事件 ID。

共有三种确认方式，它们所需时间并不相同：

efficiency (do first) : dedup rate > browser-vs-server count comparison > match-quality score
effort                : browser-vs-server count comparison > dedup rate == match-quality score
value for this goal   : dedup rate > browser-vs-server count comparison > match-quality score

在匹配质量评分上，所需投入与价值并不一致。它在投入轴上的位置与去重率并列最低：两者都是事件管理器已计算好并在一个屏幕上显示的单一数字，无需提取数据，也无需对齐。这也正是它虽然不费力，却在效率排名中垫底的原因：它在这里是三种方式中最没用的一种。

1. 去重率，在平台的事件管理器中查看——只需一个屏幕，几乎不费力，而且能直接回答问题。健康的设置通常会显示约 90% 以上的浏览器事件已去重（TAGGRS 显示某个受监控设置中的浏览器事件去重率为 95.35%，服务端事件为 100%）。每次都从这里开始。
2. 同一操作的浏览器与服务端事件计数——提取并对齐两份报告，大约需要一小时。当去重率看起来不对、无法获取，或测试操作被计算了两次时，进行此检查；如果去重率正常且测试操作只计算了一次，这只是确认而非发现，因此可以等到观察期结束后再做。
3. 匹配质量评分——应将其视为完整性信号，绝不能视为准确性信号。它衡量事件数据的格式是否完整、是否可匹配，而不衡量转化是否真实（AnyTrack），因此它本身绝不能确认已完成去重。记录该评分即可；不要在上线窗口期间花时间提高它。

请根据账户情况重新排序：如果平台的事件管理器不显示去重率，或分析师已经维护了浏览器与服务端计数报告，就将第 2 项移到最前面。

缺陷清单

这些缺陷会浪费预算，并附有能发现每项缺陷的检查方式。

影响说明缺陷会对测量造成多大程度的破坏：

• 严重：阻止上线。
• 高：阻止上线，除非报告中明确接受风险。
• 中：列入修复清单。

修复投入说明读者需要花费多少时间进行修复、协调，以及撤销修复。

各行按效率排序——即单位修复投入所获得的影响——因此首行应优先修复，而非最便宜或最严重的一项。

缺陷	可发现该问题的检查	影响	修复工作量
将噪声操作指定为主要操作	检查设置（步骤 1）	严重	几乎为零——切换一次指定设置即可，一键可撤销
容器在预览中正常工作，但从未发布	在预览模式之外测试线上网站	严重	几乎为零——发布容器
将每次操作都计数的设置用于潜在客户表单	检查设置（步骤 1）	高	几乎为零——每项操作只需设置一次计数选项
将内部／QA 流量计为转化	检查筛选器状态（测试数据排除部分）	中	几乎为零——将筛选器从测试切换为启用
标签在页面加载时触发／使用全页面触发器，而非在操作完成时触发	在调试模式下加载页面，但不进行转化	严重	一小时——在标签管理器中重新设置触发器，无需开发
点击按钮时触发，而非在成功得到确认后触发	在提交过程中途放弃；检查是否没有任何内容触发	高	一小时——同上，另外还需绑定一个成功信号
将机器人／垃圾表单提交计为转化——并据此训练算法	为表单启用垃圾信息防护；在观察期内检查潜在客户质量	中	一小时——表单级防护，可自行配置
刷新／返回确认页面时再次触发（没有唯一交易 ID）	测试转化后刷新确认页面；检查是否产生第二个事件	严重	如果订单 ID 已传入标签，则需一小时；如果没有，则需一两天开发
单页应用的路由变更导致标签再次触发	在调试模式下切换虚拟页面	高	如果标签管理器规则可修复，则需一小时；如果应用必须发送事件，则需一两天
缺少值／值被硬编码，或货币错误／缺失	检查载荷（步骤 4）	对基于价值的出价而言是严重问题	如果值已存在于数据层，则需一小时；如果需要先将其暴露出来，则需一两天开发
浏览器端和服务端重复计数（没有共享事件 ID）	检查去重情况	严重	几天——需要开发人员协调两个发送端，并重新部署以撤销更改
同意横幅完全阻止标签运行，或同意状态始终未传递给标签	分别通过接受和拒绝路径执行测试转化	高	几天，另需法律审核批准——请参阅下方的合规成本
点击标识符被重定向链剥离，或被浏览器 Cookie 容量上限截断	检查落地页 URL 以及转化时持久化的标识符	高	几天到几周——涉及重定向、存储和漏斗的每个步骤
跨域结账过程中身份信息丢失	在调试模式下走完整个跨域流程	高	一周到一个季度——需要两个域名的负责人协调
两个方面与该顺序不一致，因此应分别说明：

efficiency (fix first) : settings-class toggles > trigger corrections > refire guard
                         > value & currency > bot protection > shared event ID > consent path
                         > click-identifier chain
compliance cost        : consent path > click-identifier persistence
                         > server-side sender (shared event ID) > every other row: none

单看影响，共享事件 ID 应排在靠前位置；但它排在第六，是因为几天的开发协作就能完成同样关键的修复，而切换一次指定设置只需点击一下。内部流量筛选仅为中等优先级，但出于同样的原因反而排在靠前位置。

重复触发保护、数值与币种修复以及机器人防护并列：只要所需数据已传到标签，这三项都只需一小时的标签管理器工作，因此仅看影响就能将它们区分开来。

• 缺少重复触发保护，会导致账户中的每一次转化都被错误计数。
• 数值错误只会影响按价值出价的账户。
• 机器人提交属于中等优先级。

合规成本指修复所触发的审核，以及它所消耗的可逆性，而不是罚款。

• 同意路径（最高）：改变拒绝路径上触发的内容，涉及合法依据的判断，因此发布前需要隐私或法律团队签字批准；一旦记录在案，想悄悄回滚也很困难。
• **点击标识符持久化：**将存储与保留决策扩展到跨域场景，并延伸至 CRM 记录，通常会因此重新审查隐私声明。
• **服务端发送方：**将事件数据迁移到团队自行选择的基础设施，从而引发浏览器标签从未涉及的数据驻留和处理方问题。
• **其他每一行：**无需外部审核的配置变更。

**默认级别：**上线前清除包括共享事件 ID 在内的所有项目，并以书面形式接受同意路径和点击标识符链路的风险。如果受同意法规管辖的流量占大多数而非少数，则再上调一级——在上线前也修复同意路径，因为此时接受风险造成的信号损失会影响整个营销活动，而不只是略微削弱效果。

**效率排序会搁置什么：**服务端重建——共享事件 ID，以及其背后的点击标识符链路。这两项在价值和工作量两方面都排在首位，因此每一轮中，设置切换都会排在它们前面。一个账户如果只修复本周成本低廉的问题，可能会多年依赖浏览器标签运行，却再也没有人衡量其信号损失。

出现以下任一情况时，应将它们提升到默认级别之上：

• 访谈问题 8 的答案表明，这套设置旨在可靠运行数个季度。
• 漏斗属于 B2B，在这种情况下，标识符写入 CRM 记录是离线结果导入得以实现的必要条件，而不只是改进项。
• 用户旅程跨越多个域名，此时标识符必然会丢失，后续也没有任何修复方法能找回它。

**删除，而非降级。**如果某项限制会排除某一行，而非仅降低其优先级，就应将该行从此账户的修复清单中删除，并在报告的 deleted 行中记录，以及注明因此放弃的衡量能力。上线前没有工程资源，意味着删除共享事件 ID、同意路径重建和点击标识符链路；报告随后应明确说明营销活动在明知缺少哪些能力的情况下上线，以及由谁接受了这一决定。

如果流量完全不涉及受同意法规管辖的地区，就应直接删除同意路径这一行，并标注为不适用。将被排除的项目放在排序的最末尾，仍会让人觉得这是有意安排的工作，最终变成上线预算中从未包含的范围。

此排序只是默认方案，并非硬性规定。它会随具体情况和执行者而变化，因此在向用户展示前，应根据你已了解的用户情况重新排序：

• 如果团队中有内部工程师，所有依赖开发的项目都会缩短到约一小时，并应提升共享事件 ID 的优先级。
• 如果已部署的标签管理器配有构建好的数据层，数值与币种修复以及重复触发保护的工作量都会减少。

访谈中的第 7 至第 9 题也会影响排序：紧迫的上线日期会降低点击标识符链路的优先级；而长期复利目标则会提升它和共享事件 ID 的优先级，使其排在只对本次上线有帮助的项目之前。 排名决定哪些缺陷入选，而不是决定上线顺序。所有入选项仍会在同一批次上线，并且只重新学习一次（学习阶段的影响）；当工作量上限无法容纳所有事项时，排名决定哪些事项进入该批次。

点击标识符链路。 信号丢失类缺陷有一个共同根源：必须在首次点击时捕获点击标识符——在任何重定向发生之前——然后持久化保存，在漏斗的每个步骤中传递，包括跨域跳转，并附加到订单或潜在客户记录中。

剥除查询字符串的重定向链，以及导致 Cookie 在几天内过期的浏览器存储上限，是悄无声息地破坏归因的原因；单个追踪重定向只要丢弃标识符，就会破坏整个广告系列的衡量。对于 B2B，存储在 CRM 记录中的标识符是导入线下结果的必要条件。

B2B 与 B2C

验证主干流程相同；价值处理和时机则有所不同。

维度	B2C 电商	B2B 潜在客户开发
核心转化	购买，即时	表单提交／潜在客户，然后是线下阶段
价值	每笔订单的动态价值 + 货币	每个销售漏斗阶段的价值；验证是否将点击 ID 捕获到 CRM 中
事件后的修正	通过转化调整处理退款（重述／撤回）	通过 CRM 结果导入处理潜在客户取消资格
点击到收入的延迟	几分钟到几天	几周到几个月——“B2B 归因混乱、零散，不可能做到完全黑白分明”（AJ Wilcox）
转化量	通常达到平台的学习最低要求	往往不足；验证优化事件是否有足够的转化量

两者相同的事项——明确说明即可，无需重新推导：标签调试／预览、共享事件 ID 去重机制、平台 UI 状态检查、同意处理，以及带载荷检查的测试转化。

两项 B2B 专属检查：

• 确认归因窗口覆盖销售周期：如果某次转化发生在点击 40 天后，那么在 30 天的点击窗口下，这次转化根本不会被计入（Tucker Evans，B2Linked）。
• 确认主要转化是仍有足够转化量的最深阶段：优化到该阶段之前，大约需要 30 天内有 30 次转化（Jyll Saskin Gales 的 30 天 30 次规则）；否则，应优化到转化量更高的上游事件，并导入下游结果。

排除测试数据

验证本身会污染数据；应在稳定观察期之前清理，而不是之后。

• 双重过滤陷阱。 排除内部流量需要同时具备定义（哪些 IP／标记算作内部流量）和已启用的过滤器。许多分析设置默认将过滤器设为测试状态，此时内部流量会被标记，但不会被排除——这是最常被遗漏的步骤（NiceLookingData）。确认过滤器显示为已启用，而非测试状态。
• 过滤器不会追溯生效。 必须在上线前设置排除规则；已经记录的数据仍会受到污染。
• 通过平台的转化调整（将价值设为零／移除）撤回测试转化，并在后端退款或删除测试订单，以确保后端与分析数据之间的核对结果准确。对于 B2B，请从 CRM 中删除 QA 潜在客户。

学习阶段的利害关系

为什么计数缺陷的严重性很高：平台必须达到最低优化事件量，才能退出学习阶段。

• 过度计数（重复事件、机器人、重复触发）会让平台基于虚假信号退出学习阶段——算法随后会倾向于优化那些触发虚假事件的人群（EasyInsights）。
• 计数不足（同意信号丢失、标签损坏）会让营销活动无限期卡在门槛以下（Niblin）。

一个经审计的账户，其主要指标仅显示 31 次转化，而数百次真实操作未被计入，躺在次要报告中——导致账户人为地卡在学习门槛以下（Jyll Saskin Gales）。

一次性修复发现的所有缺陷，然后让平台重新学习一次：修复后约 24 小时内，智能出价就会开始基于更好的数据重新学习（GrowthSpree）。逐个修复会导致学习阶段连续重置。

输出格式

验证结果应交付为一份报告：标题（营销活动、日期、平台、漏斗类型、服务端标记、上线日期、面临风险的预算）、涵盖全部九个步骤的逐项检查表（结果、影响、修复工作量、证据）、去重率和差距摘要，以及决策区块（GO / NO-GO、修复顺序、阻碍项、延期项、已删除项、重新验证、审批人、日期）。完整的 NO-GO 示例请参阅 ./references/output-report-example.md。

每项检查都必须报告为 pass / fail / unknown / not applicable 之一——unknown 不等于 pass。根据证据门槛，全新属性应判定为 PROVISIONAL GO (new property - no traffic yet)，绝不能判定为普通的 GO。

故障模式

• 通过截图验证——只检查了设置，没有追踪数据。证据门槛正是为此而设。
• 为修复重复计数而删除服务端事件——方向相反；应恢复该事件并修复共享事件 ID。
• 只测试同意路径——信号会在拒绝路径中悄然丢失；两条路径都要测试。
• 筛选器仍处于测试状态——已标记不代表已排除；请确认状态显示为 active。
• 在等待中或配置错误的转化状态下上线——状态恢复正常前一律 NO-GO。
• 只在预览中验证——容器从未发布；请在正式网站上测试。
• 逐个修复——每次修复都会重置学习阶段；应将所有缺陷合并到一次发布中，只重新学习一次。
• 将匹配质量当作准确性——它衡量的是载荷完整性；重复事件也可能获得极高评分。
• 追求零差距——平台与分析工具之间 10-20% 的差异是结构性的，也是正常现象（Ruler Analytics）；在上线前耗费时间消除这种差异，只会无谓地延迟上线。

目标与衡量

只有满足以下所有条件，门槛才算通过，才能发出 GO。持续修复并重新验证，直至全部满足：

• 端到端追踪一次真实测试转化，并在平台 UI 中以正确的价值和币种显示。
• 每项主要转化操作的记录状态均正常；任何主要操作配置错误或显示近期没有转化，都会自动判定为 NO-GO。
• 浏览器端/服务端去重率达到约 90% 或更高，且每次测试操作恰好计为一次转化。
• 平台与分析工具之间的差距处于正常的 10-20% 范围内（Ruler Analytics）。
• 电商分析数据与后端数据之间的差距低于 25%；超过 35% 时应在上线前调查（Enalitica）。
• 服务端与浏览器端之间的差距不超过 10% 属于正常；如果差距达到 30%，且匹配率低于 50%，则构成上线阻碍——在这种情况下扩大投放规模，就是“花更多钱，更快地优化一个损坏的模型”（Journify）。
• 测试数据已排除，筛选器处于 active 状态，测试转化已撤回，测试订单已退款。

上线后，每周跟踪平台与后端的比率：即使比率不为零，只要保持稳定就是正常的；如果比率每周波动，说明管道正在丢失事件——转交给 mbfinotti/advertising-skills@ad-attribution-gap。

平台说明（可选）

仅在用户指定平台时加载；上述核心检查清单仍保持厂商中立。

去重键和时间窗口：

• Meta 会在 48 小时内根据 event_id 和事件名称进行去重。
• TikTok 会根据 event_id 和事件名称进行去重，合并 5 分钟后、且在首个事件发生后 48 小时内收到的事件，并保留最先收到的事件。
• LinkedIn 会针对每条转化规则使用共享的 eventId 进行去重，保留 Insight Tag 事件并丢弃 Conversions API 重复事件（与 Meta 的模式相反）。
• Google Ads 根据 transaction_id 进行去重，并使用 gclid 匹配点击。

各厂商的点击标识符： gclid（Google，以及 wbraid/gbraid）、fbclid（Meta）、li_fat_id（LinkedIn）、ttclid（TikTok）、msclkid（Microsoft）。

学习阶段最低要求：

• Meta 广告组每 7 天大约需要 50 个优化事件才能退出学习阶段。
• Google Target CPA 文档说明，最低要求为 30 天内 15 次转化，并建议使用 30 次进行评估。

将具体数字视为参考值；各平台可能会调整这些数字。