付费广告上线前验证转化追踪是否准确、去重并给出…

在付费广告活动发布前，用端到端测试转化和证据门禁检查追踪配置、事件去重、价值/币种、同意与测试数据排除，并产出带审批人的 GO/NO-GO 报告。

适用场景

解决思路

1. 明确边界：本技能只验证，不实施；产出检查清单、证据和结论；写或安装追踪代码交给实现负责人；跨平台数字对账交给 mbfinotti/advertising-skills@ad-attribution-gap；账户级效果根因诊断交给 ad-account-diagnostic；落地页转化率审核交给 paid-landing-page-audit；创意疲劳监控交给 ad-creative-fatigue。
2. 一次只问一个访谈问题，跳过已知或在设置中可见的内容，保持简短。
3. 询问平台：活动将在哪些平台运行。
4. 询问漏斗类型：B2B lead gen、B2C ecommerce 或两者。
5. 询问服务端事件是否与浏览器 pixel/tag 并行，还是仅浏览器。
6. 询问实现负责人：你、开发团队还是代理；修复交给他们。
7. 询问 consent banner 是否上线，流量是否包含 consent-regulated region。
8. 询问预算：本次发布的预算大小，决定 gate 背后风险。
9. 询问上线日期是硬性还是可移动：硬日期提升近零成本设置和触发修复，并把 click-identifier chain 推到上线后作为风险接受项；可移动日期让全部缺陷批次一次发布并只重学习一次。
10. 询问是一次性放行还是打算信任数季度的追踪设置：复利意图提升 click-identifier chain 和 shared event ID；一次性意图只提升能清掉本次发布的检查。
11. 询问上线前努力上限：自己花在 tag manager 的小时数、开发与 CRM 协调、还是需要法律签署；无开发访问把修复列表限制在设置和 tag-manager 工作，低于该线的项按名称从列表删除，报告中写明损失的测量指标和接受人，绝不静默丢弃或排在最后。
12. 记录访谈第 7-9 题的答案；报告必须说明哪些缺陷被推迟以及由谁授权。
13. 执行 Evidence gate：绝不只凭配置截图发 GO；设置页看起来正确、debugger 中 tag 绿色都不算测量准确。
14. GO 要求至少一个真实测试转化端到端追踪：动作已执行。
15. GO 要求至少一个真实测试转化端到端追踪：payload 已检查。
16. GO 要求至少一个真实测试转化端到端追踪：平台 UI 收到事件且 value 和 currency 正确。
17. GO 要求至少一个真实测试转化端到端追踪：已去重。
18. GO 要求至少一个真实测试转化端到端追踪：测试数据已排除。
19. 唯一例外：全新 property 且无流量，验证会话内无法在平台 UI 看到转化（事件可能数小时才出现，新 conversion action 处于 waiting 状态）；可基于 debug-mode 证据加正确 payload 给 provisional PASS 并标注，首次 live conversions 到达时必须重新验证。
20. 按九步固定顺序执行验证；前一步不成立时后一步证据不可读；不要按效率排序、不要重排为便宜优先；该顺序是依赖链；按步记录证据。
21. 步骤1 Settings 和 conversion-action configuration：确认 primary conversion designation 匹配业务目标，收入相关动作 primary，page views 和 micro-actions 设 secondary 且排除出 bidding；Rawsoft 发现一个账户 13 个 primary conversion actions 仅 4 个业务结果，smart bidding 优化了 150 万+ 月噪音转化；lead gen 确认 count-once 而不是 count-every per click；证据：primary actions 列表，每个映射到业务结果；每个动作的 counting method。
22. 步骤2 进入 tag debug/preview mode：使用 tag manager 的 preview mode 和平台的 test-event 或 tag-inspection tool；证据：conversion tag 在转化页可见且 armed，仅在预期 trigger 上 firing。
23. 步骤3 执行真实测试转化端到端：走付费点击的完整用户旅程，落地 URL 带 click identifier，接受并单独拒绝 consent banner，完成动作；B2C 下真实低价值测试订单（近零折扣码，或之后退款）；B2B 提交带唯一 QA value 的测试 lead 并确认落到 CRM record；证据：测试订单/lead ID 及其携带的 identifier。
24. 步骤4 检查 event payload：在浏览器 network inspector 或 tag debug tool 中读实际请求，确认 event name、value、currency、per-conversion event ID、click identifier、使用的 hashed identifiers；证据：payload 字段复制进报告。
25. 步骤5 在平台 UI 确认事件：测试事件出现在平台 event manager，标记 browser 或 server，conversion action 显示健康 recording status；任何 primary action 处于 misconfigured 或 no-recent-conversions 状态自动 NO-GO；得出事件缺失结论前允许几小时 reporting lag；证据：每个 primary action 的状态；测试事件可见且 value/currency 正确。
26. 步骤6 当 browser 和 server 事件都运行时验证去重；证据：测试动作只计一次；dedup rate。
27. 步骤7 排除并清理测试数据；证据：filter state active，测试转化 retracted，测试订单 refunded/removed。
28. 步骤8 Soak：让真实信号积累几天再做 scaling 判断；实践者确认 conversion 已有几天 reporting signals 让平台理解目标；与 backend 或 CRM 对账应等约 4 天让数据稳定；证据：每日计数趋势，gap 在阈值内。
29. 步骤9 记录并签署：填写 output-shape 报告，指定 approver，写日期，发布 GO / NO-GO；跳過明确 approval field 的 launch checklist 会在发布压力下被跳过；证据：完成的报告本身。
30. Deduplication 条件：browser tag 和 server-side endpoint 都发送转化时，平台需要 shared key 才计一次；必须有 shared per-conversion event ID（order ID 可用）并由两个来源完全相同地发送。
31. Deduplication 条件：event names 精确匹配，包括 casing。
32. Deduplication 条件：timestamps 在平台 matching window 内，理想相隔几秒。
33. 检查去重失败模式：server 生成不同 event ID 或完全省略，平台无法匹配，每次转化计两次。
34. 检查去重失败模式：每次 page load 生成新 event ID 而不是每次 conversion，刷新会造出“新”转化。
35. 检查去重失败模式：两个来源的 event-name casing 或命名不匹配。
36. 检查去重失败模式：timestamp drift 把 pair 推出 matching window。
37. 明确错误修复：为停止 double-counting 删除 server event 完全反了；应恢复 server event 并修 shared event ID；删除会静默丢弃更有韧性的信号来源。
38. 三种确认不等时：efficiency 先做 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。
39. 确认1 Dedup rate：在平台 event manager 一屏，近零努力，直接回答问题；健康设置约 90%+ browser events 被去重（TAGGRS 监控设置 95.35% browser / 100% server）；每次都从这里开始。
40. 确认2 Browser vs server event counts 对同一动作：约 1 小时拉取和对齐两份报告；当 dedup rate 看起来错误、不可用或测试动作计两次时运行；当 rate 健康且测试动作只计一次时这是 confirmation 不是 discovery，可等到 soak。
41. 确认3 Match-quality score：只作为 completeness 信号，绝不作为 accuracy 信号；它评价 event data 格式良好和可匹配程度，不评价 conversions 是否真实，不能单独确认去重；记录它，不要花发布窗口改进它。
42. 重新排序：若平台 event manager 隐藏 dedup rate，或分析师已维护 browser-vs-server count report，则把确认2 移到最前。
43. Defect checklist 判读：Impact 中 Critical 阻止发布；High 除非在报告中明确 risk-accepted，否则阻止；Medium 进修复列表。
44. Defect checklist 判读：Fix effort 衡量清除缺陷读者需花的小时、协调和可逆性。
45. Defect checklist 行按 efficiency（每单位修复努力买到的 impact）排序，顶行最先修，不是最便宜也不是最 critical。
46. 缺陷：噪音动作被指定为 primary；检查 Settings review step 1；Impact Critical；Fix near-zero，designation toggle 一键可逆。
47. 缺陷：Container 在 preview 可用但从未发布；检查在 preview mode 外测试 live site；Impact Critical；Fix near-zero，发布 container。
48. 缺陷：Lead form 上设置为 count-every；检查 Settings review step 1；Impact High；Fix near-zero，每个动作一个 counting setting。
49. 缺陷：Internal/QA traffic 被计为 conversions；检查 filter state check；Impact Medium；Fix near-zero，把 filter 从 testing 翻到 active。
50. 缺陷：Tag 在 page load / all-pages trigger 触发，而不是 completed action；检查 debug mode 加载页面但不转化；Impact Critical；Fix 1 小时，在 tag manager 重新触发，无需 dev。
51. 缺陷：在 button click 触发，而不是 confirmed success；检查中途放弃 submit，确认没有 firing；Impact High；Fix 1 小时，同上加绑定 success signal。
52. 缺陷：Bot/spam form fills 被计入并教给算法；检查表单 spam protection，soak 中检查 lead quality；Impact Medium；Fix 1 小时，表单级保护，自助。
53. 缺陷：Confirmation page 在 refresh/back 时 refire 且无 unique transaction ID；检查测试转化后刷新 confirmation page，寻找第二个 event；Impact Critical；Fix 若 order ID 已到 tag 则 1 小时；若没有则一周 dev。
54. 缺陷：Single-page-app route change 触发 tag refire；检查 debug mode 在 virtual pages 间导航；Impact High；Fix 若 tag-manager rule 可修则 1 小时；若 app 必须发自己的 event 则一周。
55. 缺陷：Missing/hard-coded value、wrong 或 missing currency；检查 payload inspection step 4；Impact 对 value-based bidding 为 Critical；Fix 若 value 在 data layer 则 1 小时；若必须先暴露则一周 dev。
56. 缺陷：Browser + server 都被计入（无 shared event ID）；检查 Deduplication check；Impact Critical；Fix 一周，跨两个 sender 的 dev 协调，且反转需 redeploy。
57. 缺陷：Consent banner 完全阻止 tag，或 consent state 从未到达它；检查在 accept 和 reject 两条路径运行测试转化；Impact High；Fix 一周加法律签署，见 compliance cost。
58. 缺陷：Click identifier 被 redirect chain 剥离，或被 browser cookie caps 截断；检查落地 URL 和转化时持久化的 identifier；Impact High；Fix 一周到一季，牵涉 redirects、storage 和每个 funnel step。
59. 缺陷：Cross-domain checkout 在旅程中途丢失 identity；检查 debug mode 走完整跨域旅程；Impact High；Fix 一周到一季，跨两个 domain owners 协调。
60. 两个轴与默认顺序不一致，单独说明：efficiency（先修）为 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) > 其他行 none。
61. 解释：Impact 单独会把 shared event ID 放接近顶部；它落到第六，因为一周 dev 协调买到的 critical fix 与一键 designation toggle 相同；internal-traffic filter 只是 Medium 却因同样原因反排到接近顶部。
62. 解释：refire guard、value-and-currency fix 和 bot protection 不是并列；当所需数据已到 tag，三者都花同样 1 小时 tag-manager 工作，所以仅靠 impact 区分：缺 refire guard 会错计账户每次转化；value 错只影响按 value bidding 的账户；bot fills 是 Medium。
63. Compliance cost 是修复触发的 review 和花掉的可逆性，从不是罚款：Consent path 最重，改变 reject path 上什么 firing 是关于 lawful basis 的决定，需要 privacy 或 legal sign-off 才 ship，文档化后难以悄悄回滚。
64. Compliance cost：Click-identifier persistence 把 storage 和 retention 决定扩展到跨域和 CRM record，通常重新打开 privacy notice。
65. Compliance cost：Server-side sender 把 event data 迁到团队选择的基础设施，引发 browser tag 从未引发的 data-residency 和 processor 问题。
66. Compliance cost：其他每一行是配置变更，无外部 reviewer。
67. 默认 rung：发布前清除到并包括 shared event ID；以书面形式 risk-accept consent path 和 click-identifier chain。
68. 当 consent-regulated traffic 是受众多数而非一小片时，再进一档，发布前也修 consent path，因为 risk-accepted signal loss 会淹没 campaign 而非只是削减。
69. Efficiency order 会饿死 server-side rebuild（shared event ID 及其背后的 click-identifier chain）；两者都在 value 和 effort 轴顶部，但 settings toggle 每一轮都排在它们前；只修本周便宜项账户会多年运行在 browser tag 上且没人测量 signal loss。
70. 在以下条件把 server-side rebuild 提升到默认 rung 之上：Interview question 8 回答为打算信任数季度的设置。
71. 在以下条件提升：漏斗是 B2B，identifier 落到 CRM record 才使 offline outcome import 成为可能，而不只是改进。
72. 在以下条件提升：旅程跨域，identifier 按构造会丢失，下游修复无法挽回。
73. Delete, don't demote：当约束让某行不可行而非降低优先级，把该行从本账户修复列表划掉，并记录在报告 deleted 行及其损失的测量指标。
74. 发布前无工程资源会删除 shared event ID、consent-path rebuild 和 click-identifier chain；报告要说明 campaign 明知没有这些仍要发布，以及谁接受。
75. 不触及 consent-regulated region 的流量把 consent-path 行直接删除为 not applicable；把 ruled-out 行停在顺序底部仍读作有人打算做的工作，并会作为 launch 未预算的 scope 回来。
76. 该排序是默认不是法律；按你对用户的已知信息重新排序：团队内 in-house engineer 把每个 a week of dev 行压缩到一小时并提升 shared event ID。
77. 重新排序：已部署且已建 data layer 的 tag manager 把 value-and-currency 和 refire-guard 行压缩。
78. 重新排序：Interview 7-9 的答案也会移动它；硬 launch date 降级 click-identifier chain；复利 mandate 把它和 shared event ID 提升到只清本次发布的项之上。
79. 排序只决定哪些缺陷进入批次，不决定 shipping 顺序；所有进入的仍一次批次发布并只重学习一次；当 effort ceiling 容不下全部时，排序决定批次内容。
80. Click-identifier chain 做法：click identifier 必须在 first hit 捕获（任何 redirect 前），然后持久化，跨每个 funnel step 包括 cross-domain hops 携带，并附加到 order 或 lead record。
81. Click-identifier chain 风险：redirect chains 剥离 query strings 和 browser storage caps 在几天内过期 cookies 会静默摧毁 attribution；单个 tracking redirect 丢掉 identifier 就会破坏整个 campaign 的测量；B2B 中 identifier 存在 CRM record 才使 offline outcome import 成为可能。
82. B2B vs B2C 共享验证骨架；value handling 和 timing 不同：B2C core conversion 是 purchase，立即；B2B 是 form fill/lead，然后是 offline stages。
83. B2B vs B2C：B2C value 是每订单 dynamic value + currency；B2B value 按 pipeline stage，验证 click-ID capture 到 CRM。
84. B2B vs B2C：B2C post-event correction 用 refunds via conversion adjustment（restate/retract）；B2B 用 lead disqualification via CRM outcome import。
85. B2B vs B2C：B2C click-to-revenue lag 分钟到天；B2B 周到月。
86. B2B vs B2C：B2C volume 通常清过平台 learning minimums；B2B 经常饿死它们；验证 optimized event 有 volume。
87. B2B vs B2C 完全相同：tag debug/preview、shared-event-ID dedup mechanism、platform-UI status check、consent handling、带 payload inspection 的 test conversion；不要重复推导。
88. 两个 B2B 特定检查：确认 attribution window 覆盖 sales cycle；点击后 40 天落地的转化在 30-day click window 下根本不计。
89. 两个 B2B 特定检查：确认 primary conversion 是仍有足够 volume 的最深 stage，约 30 conversions in 30 days 才优化到它；否则优化到更高 volume 的 upstream event 并 import downstream outcomes。
90. Test-data exclusion：验证本身会污染数据；在 soak period 前清理，不是之后。
91. Test-data exclusion 两部分 filter 陷阱：Internal-traffic exclusion 需要定义（哪些 IPs/markers 算 internal）和 activated filter；许多 analytics 设置默认 filter 为 testing 状态，internal traffic 被标记但未排除，这是最常漏的一步；验证 filter 读作 active 而不是 testing。
92. Test-data exclusion：Filters 不是 retroactive；排除必须在 launch 前到位；已记录数据仍被污染。
93. Test-data exclusion：通过平台 conversion adjustment（value 置零/移除）retract 测试转化，并在 backend refund 或 delete 测试订单，保持 backend-vs-analytics reconciliation 诚实；B2B 从 CRM 删除 QA lead。
94. Learning-phase stakes：平台在优化事件达到最小 volume 后退出 learning phase。
95. Learning-phase stakes：Over-counting（duplicates、bots、refires）用假信号退出 learning，算法随后优化向触发 phantom events 的人。
96. Learning-phase stakes：Under-counting（consent loss、broken tags）把 campaign 无限困在阈值之下。
97. Learning-phase stakes：一个审计账户 primary metric 只显示 31 conversions，而数百真实动作未被计入 secondary reporting，人为卡在 learning threshold 下。
98. Learning-phase stakes：把所有发现的缺陷一次批量修复，然后让平台只重学习一次；smart bidding 在修复后约 24 小时内从更好数据开始重学习；串行一次修一个会触发串行 learning resets。
99. Output shape：交付一份验证报告：header（campaign、date、platform(s)、funnel type、server-side flag、launch date、budget at risk）。
100. Output shape：包含覆盖九步的 per-check table（result、impact、fix effort、evidence）、dedup rate 和 gap summary、decision block（GO / NO-GO、fix order、blockers、deferred、deleted、re-verify、approver、date）；完整 NO-GO 示例见 ./references/output-report-example.md。
101. Output shape：每个检查报告 pass / fail / unknown / not applicable 之一；unknown 不是 pass；全新 property 按 Evidence gate 以 PROVISIONAL GO (new property - no traffic yet) 通过，绝不 plain GO。
102. 避免 failure mode：Screenshot verification——设置已审、什么都没追踪；Evidence gate 就是为此存在。
103. 避免 failure mode：Deleting the server event to fix double-counting——反了；恢复它并修 shared event ID。
104. 避免 failure mode：Testing only the consent-accept path——reject path 是信号静默死亡处；两条都测。
105. 避免 failure mode：Filter left in testing state——tagged 不是 excluded；验证状态读 active。
106. 避免 failure mode：Launching on a waiting/misconfigured conversion status——自动 NO-GO 直到状态健康。
107. 避免 failure mode：Verifying in preview only——container 从未发布；测试 live site。
108. 避免 failure mode：Serial fixes——每次修复重置 learning；把所有缺陷批量进一次发布、一次重学习。
109. 避免 failure mode：Reading match quality as accuracy——它衡量 payload completeness；duplicates 可以得分很好。
110. 避免 failure mode：Chasing a zero gap——10-20% platform-vs-analytics discrepancy 是结构性且正常；花发布前窗口消除它会无谓延迟 launch。
111. Objective：gate 清过且只有那时发 GO，当以下全部成立；迭代修复并重新验证直到成立。
112. Objective：一个真实测试转化端到端追踪，出现在平台 UI 且 value 和 currency 正确。
113. Objective：每个 primary conversion action 处于健康 recording status；任何 primary action misconfigured 或 no recent conversions 自动 NO-GO。
114. Objective：Browser/server dedup rate 达到或高于约 90%，每个测试动作恰好一个 counted conversion。
115. Objective：Platform-vs-analytics gap 在正常 10-20% band 内。
116. Objective：Ecommerce analytics-vs-backend gap 低于 25%；高于 35% 发布前应调查。
117. Objective：Server-vs-browser gap 到 10% 正常；30% gap 加 match rate 低于 50% 是 launch blocker，scaling 它是 spending more money to optimize a broken model faster。
118. Objective：测试数据已排除，filter active、test conversion retracted、test order refunded。
119. 发布后每周跟踪 platform-vs-backend ratio：稳定 ratio 即使非零也健康；ratio 周周摆动意味着 pipeline 丢事件，交接给 mbfinotti/advertising-skills@ad-attribution-gap。
120. Platform note optional：仅当用户说出平台时加载；上面核心 checklist 保持 vendor-neutral。
121. Platform note：Meta deduplicates on event_id + event name within 48-hour window。
122. Platform note：TikTok deduplicates on event_id + event name，合并 5 分钟后到达且距首个 48 小时内的事件，保留 first received。
123. Platform note：LinkedIn deduplicates on shared eventId per conversion rule，保留 Insight Tag event 并丢弃 Conversions API duplicate（与 Meta 模型相反）。
124. Platform note：Google Ads deduplicates on transaction_id，用 gclid 做 click matching。
125. Platform note：Click identifiers by vendor：gclid（Google，另 wbraid/gbraid）、fbclid（Meta）、li_fat_id（LinkedIn）、ttclid（TikTok）、msclkid（Microsoft）。
126. Platform note：Learning-phase minimums：Meta ad sets 约需 50 optimization events per 7 days 退出 learning；Google Target CPA 文档写 15-conversions-per-30-days 最小，30 推荐评估；把精确数字当方向性，平台会改。

适用边界 · 注意事项

• 不用于上线后平台与 CRM/后端数字对账；那属于 mbfinotti/advertising-skills@ad-attribution-gap。
• 不用于安装或修改追踪代码；本技能只验证，实施由实现负责人处理。
• 不用于账户级效果根因诊断、落地页转化率审核、创意衰退监控；分别交给 ad-account-diagnostic、paid-landing-page-audit、ad-creative-fatigue。