当渠道归因冲突、需要选择模型或自建第一方归因时…

营销转化与收入来源不清、各工具数字冲突，或需选择/解释归因模型并决定是否自建第一方归因时使用。

适用场景

解决思路

1. 先判断用户需要哪个支柱：解释/选择模型/对账走 Pillar A；控制站点/App 且想自建归因走 Pillar B。多数请求先走 Pillar A。
2. 检查并读取 .agents/product-marketing.md（若存在），用业务类型、销售周期、主要转化来驱动后续推荐。
3. 明确边界：事件跟踪/跟踪计划/UTM/GA4/GTM 归 analytics；广告平台像素/CAPI/服务端转化跟踪归 ads；管道阶段/线索生命周期/CRM 收入报表归 revops；AI 搜索测量归 ai-seo。归因只消费平台上报数字并纠偏，不设置像素，不定义阶段。
4. 设定预期：归因是方向性而非真相，是基于不完整数据的因果模型；每个模型都是观点；渠道上报转化总和几乎总大于真实转化，归因缺口正常，任务是缩小并解释缺口，而非让数字完美对齐。
5. 当用户要求唯一真实数字时，改述为：可以提供可辩护、一致的数字和趋势判断，但单一客观真相不存在，并说明用于决策的替代方案。
6. 理解 first-touch：100% 给第一个已知触点；适合漏斗顶/需求生成估值、短周期；谎言是忽略成单环节，过度归功于认知渠道。
7. 理解 last-touch：100% 给转化前最后触点；适合直接响应、快速电商；谎言是过度归功底漏斗和品牌搜索/direct，忽略需求创造。
8. 理解 last non-direct：100% 给最后触点但跳过 direct；适合便宜地修复 direct 污染；谎言是仍是单触点，只是移动盲点。
9. 理解 linear：每个触点等权；适合每个步骤都重要的长多触点旅程；谎言是把随手访问当 demo，偏爱高频渠道。
10. 理解 time-decay：越接近转化的触点权重越高；适合 recency 重要的较长周期；谎言是低估漏斗顶，且仍是假设而非测量。
11. 理解 position-based（U-shaped）：40% 首、40% 末、20% 中；适合有清晰 创建 和 关闭 时刻的 B2B；谎言是 40/40/20 切分武断，中间触点被亏待。
12. 理解 data-driven（algorithmic/Shapley）：按建模的边际贡献分配；适合高转化量账户；谎言是黑箱、需要量、看不到未喂给它的线下/暗触点。
13. 规则：长销售周期不要孤立报告单一模型；并排展示 first-touch 和 last-touch，真相在两者之间，两者差距就是洞察。
14. 规则：data-driven attribution 需要量；Google Ads 历史上要求约 3,000 广告交互和 30 天内约 300 转化，后来放宽并默认 DDA，但低量仍是噪音；量薄时用 position-based。
15. 规则：模型远不如保持一致，并配一个模型外 sanity check（自报归因）重要。
16. 理解 MTA（多触点归因）：拼接用户级触点并套模型；回答哪些触点出现在转化旅程中；需要干净的跨设备用户级跟踪；注意 cookie 丢失和隐私已削弱用户级数据，会静默低测。
17. 理解 MMM（媒体/营销组合建模）：用花费与结果的时间序列做自上而下回归；回答每个渠道的聚合贡献，包括线下/品牌；需要 2–3 年周级数据和花费波动；注意是相关性、反应慢，需要真实预算波动才能学习。
18. 理解 Incrementality（geo holdout、PSA、ghost ads、on/off）：暴露组 vs withheld 的受控实验；回答渠道是否带来否则不会有的 lift；需要能 withhold 且样本量足够显著；注意是金标准，但一次只能测少数事项。
19. 如何选择测量范式：小预算/短周期 → 好的 UTM + last-non-direct + 自报调查胜过花哨模型；中预算多渠道 → MTA 做日常 + 对最大 line items 定期做 incrementality 测试；大预算且含线下和品牌 → MMM 管组合 + incrementality 验证 MMM 系数；当两个渠道争同一转化时，incrementality 是决胜。
20. 使用自报归因：在转化后询问「How did you hear about us?」，捕捉跟踪结构上看不到的东西：播客、口碑、Slack 社区、创始人推文、朋友告知。
21. 自报归因最适合：长考虑周期、高口碑、品牌/社区驱动、重暗社交；如果大量旅程是 direct，就存在自报形状的洞。
22. 自报归因在转化时刻问（注册、首购、demo 请求），回忆最高，趁记忆未消退。
23. 自报归因措辞：开放式（「How did you first hear about us?」）捕获暗社交；短选项更易量化但预偏答案；最佳实践是已知渠道选项加自由文本 other/tell us more。
24. 自报归因当作三角验证输入而非真理：回忆模糊，人会归功于 memorable touch 而非第一个触点；它是让跟踪模型保持诚实的外部检查。
25. 自报归因构建侧：把表单字段写入 CRM/analytics 作为 person property，见 Pillar B 和 references/first-party-tracking.md。
26. 对账冲突来源时先解释各来源为何系统性说谎：广告平台（Google/Meta/LinkedIn）偏向多算自己，因为按自己的窗口计入 view-through + click 转化，每个平台都计同一笔销售，且有动机好看。
27. 对账冲突来源：GA/网页分析偏向 last non-direct click，因为丢跨设备、丢被 cookie 屏蔽用户，把未知都倒进 direct。
28. 对账冲突来源：CRM 偏向 whatever rep typed / 表单捕获，因为人工录入、线索来源被覆盖、线下交易无数字痕迹。
29. 对账冲突来源：自报调查偏向 memorable touch，因为回忆偏差，低算无聊但真实的触点如 retargeting。
30. 三角验证步骤 1：为转化计数选一个 source of truth，通常是 CRM 或后端（钱真实发生的系统）；其他来源只解释这些转化从哪来，不能重新定义有多少。
31. 三角验证步骤 2：永远不要跨平台相加；如果 Google 和 Meta 都声称同一转化，那是一笔转化两个声称者，不是两笔；按 source-of-truth 总数去重。
32. 三角验证步骤 3：读方向一致性，而不是绝对值匹配；如果所有来源都说 paid search 涨、organic 跌，这个趋势可信，即使数字对不上。
33. 三角验证步骤 4：当平台争同一转化时用自报归因做 tiebreaker；当 stakes 值得测试时用 incrementality。
34. 三角验证步骤 5：预期并预算缺口；报告「平台声称 N；我们能验证 M；差额来自 over-claiming + view-through + 未跟踪——以下是最佳分配」。
35. 对账输出：给出带置信度的诚实分配，而不是精确到小数的假对账。
36. 识别盲点 Direct：它是垃圾抽屉，包含书签和输入网址，也包含被剥离的 referrer、app-to-web、暗社交、任何跟踪丢掉的触点；direct 占比大是测量问题，不是渠道。
37. 识别盲点 Branded search：人从别处发现你然后 Google 你的名字；last-touch 把功劳给 paid/organic branded search，真正驱动是让他们搜索的东西；必须分品牌 vs 非品牌，否则会砍掉漏斗顶。
38. 识别盲点 Dark social：无 referrer 的分享，DM、Slack/Discord、播客、newsletter、截图；跟踪结构上不可见，自报是唯一看见方式。
39. 识别盲点 AI traffic：助手和 AI 搜索越来越多影响买家，然后经 branded search 或 direct 送来，AI 触点在 analytics 不可见；命名它并把更深工作交给 ai-seo。
40. 贯穿线：当 direct 和 branded search 主导，说明漏斗顶在工作而归因在隐藏它；这是营销中最常见的误读，要明确说出来。
41. 业务类型分叉 B2B SaaS（长周期、销售辅助）：旅程跨周-月且多人，单触点模型严重误导；锚定 CRM 为 source of truth，并排 first-touch + position-based，重 demo/signup 自报，把 pipeline/revenue 归因（→ revops）当真正记分牌；线下触点使 MTA 最弱、自报最强。
42. 业务类型分叉 Ecommerce/DTC（短周期、自助）：旅程快、量大、花费集中在 paid social + search；锚定平台 ROAS 但不信（iOS/CAPI 膨胀），一旦花费可观用 MMM 验证，并对最大渠道做 incrementality/geo-holdouts，用 post-purchase survey 捕获像素漏掉的东西；快速周转 SKU 可用 last-touch，MMM+incrementality 用来分配真实预算。
43. Pillar B 适用：用户控制站点/App 并想自己埋点归因，尤其是转化发生在非自有域名（SavvyCal/Calendly/Cal.com booking、Stripe Checkout）。
44. 第一方归因核心是身份图：1 访客匿名到达，分析工具分配匿名 distinct_id 并在事件上盖 first-touch 属性（$initial_referrer、$initial_utm_*）。
45. 身份图 2：在转化（注册、预约、购买）时用稳定 id（email 或 user UUID）调用 identify()，把匿名历史合并到已知 person，first-touch 因而存活到转化。
46. 身份图 3：之后每个转化事件都能按 first-touch 渠道拆分，这就是全部游戏。
47. 关闭 identify() gap：最常见的第一方失败是什么都没调用 identify()，转化永不 join 浏览历史，每个客户都像凭空出现；修复是在每个真实转化调用 identify。先审计——很多 SaaS 已在 signup identify，不要重建有效部分；找到特定未埋点转化，只关闭那些。
48. 拼接第三方域转化步骤 1：点击时用 capture-phase link decorator 把访客匿名 distinct_id 经 metadata passthrough 附到出站 URL（如 ?metadata[ph_distinct_id]=<id>）；一个 document-level listener 覆盖所有 CTA，无需逐链接修改。
49. 拼接第三方域转化步骤 2：第三方工具存储该 metadata 并在 webhook 返回。
50. 拼接第三方域转化步骤 3：webhook handler 触发 identity merge（$identify，用 booking email 作 distinct_id、走私的匿名 id 作 $anon_distinct_id）加 conversion event，把 booking 接回营销旅程。
51. Guardrail 匿名保护 fail closed：只走私匿名 id；identify() 后当前 id 变成 email/UUID，把它泄漏进第三方 URL 或在其上 merge 会污染 profiles（A 的 email 折进任何预约者）。拒绝像 PII 的 id（含 @），限制长度，身份不明确时什么也不发；若应用用 UUID identify，测试 distinct_id === device_id 而非 @ 检查。
52. Guardrail first-touch 数据质量：重定向会覆盖真实 first touch；从 referrer 分类中排除 OAuth/checkout referrers（accounts.google.com、checkout.stripe.com、login.*）、自己的子域（self-referrals）、dev hosts（localhost）。这通常是设置改动而非代码，是性价比最高的修复。
53. Guardrail 跨子域拼接：营销站 → 子域上的 app 必须共享一个 analytics project 加 cross-subdomain cookie，否则旅程在交接处断裂。预期 stitch 在生产验证前数字接近零——不要因空数据恐慌；用 campaign-window 启发式 fallback，并同时回填 pre-stitch cohort。
54. 报告第一步：转化事件按 first-touch 渠道拆分（$initial_utm_source / $initial_referring_domain），并与收入 join 成 channel → conversion → revenue；确认工具里 first-touch vs last-touch 配置（很多默认 last-touch，第一方归因要 $initial_*）。
55. 报告第二步：仅 first-touch 不能跑 §2 的多触点模型；存储完整有序 touch path（不只是 $initial_*），让 build track 喂给 interpretation track，从而能对自己的旅程打 position-based/linear/time-decay。
56. 最后一公里进 CRM：分析工具里的 breakdown 只是报告；销售和 lifecycle 会基于写在记录上的归因行动。同步一个 source 字段，带 confidence 和 basis（journey-linked vs self-reported vs campaign-window fallback），加上从 medium 读出的 Paid-vs-Organic，并 roll up 到 account（不只是 contact——一个 B2B 组织是多个混合工作/个人邮箱的人）。pipeline/lifecycle 之后如何使用它是 revops 的职责。
57. 模式不依赖工具：identify + merge 存在于 PostHog、Segment、Amplitude，以及 GA4 的 user-id；第三方 stitch 适用于任何有 metadata passthrough + webhook 的工具。PostHog + SavvyCal 是 references/first-party-tracking.md 中的 worked example。
58. 交付 Attribution Readout 而非数据堆：包含 The question（这个决策是什么，如下一季度预算去哪）、Source of truth（哪个系统定义转化计数及原因）、What each source says 表（按 source-of-truth 去重，不相加）、Model comparison（长周期时 first-touch vs last-touch 并排，差距即洞察）、Confidence & gaps（归因缺口、盲点、看不到什么）、Recommendation（带置信度的分配建议，以及值得跑的 tiebreaker 测试）。
59. 实现时参考 tools/REGISTRY.md；关键工具：PostHog（第一方归因、identify/merge、funnels）、GA4（网页分析、模型对比、user-id stitching）、Dub（短链 + 点击归因）、Segment（CDP，路由 identify/track 到各目的地）、HubSpot（CRM lead-source + 自报字段）、Salesforce（CRM 作收入 source of truth）、Supermetrics（拉平台数字到一处对账）、RB2B（去匿名化 B2B 网站访客）。

适用边界 · 注意事项

• 还没有基础事件跟踪/跟踪计划/UTM/GA4/GTM 时，先做 analytics；归因假设跟踪已经存在。
• 需要设置广告平台像素/CAPI/服务端转化跟踪时转 ads；需要定义管道阶段/线索生命周期/CRM 收入报表时转 revops；需要深入测量 AI 搜索时转 ai-seo。
• 不控制站点/App，或转化不在可干预的域上且没有 metadata passthrough/webhook 能力时，不要走 Pillar B 自建第一方归因，改用 Pillar A 解释与对账。