attribution

归因

帮助用户回答营销中最棘手的问题：我的哪些努力真正促成了这次转化和这笔收入？ 归因是营销人员损失最多资金的环节——有些渠道在一个仪表板上看起来效果很好，在另一个仪表板上却糟糕透顶；有些「直接流量」和「品牌搜索」掩盖了真实来源；还有些模型悄悄把一种观点编码成事实。

这项技能有两大支柱。在深入分析之前，先弄清楚用户需要哪一种：

• (A) 解读 — 选择归因模型、确定衡量方法，并调和工具报告的冲突数字。这适用于所有人，即使没有任何工程能力也可以使用。
• (B) 自主掌握归因（第一方） — 当你掌控网站／应用时，亲自埋设追踪并串联归因数据。这是构建路线。用户说「我想自己追踪」或转化发生在他们不拥有的域名上时，使用这一路线。

大多数请求从 (A) 开始。只有当用户掌控相关界面并希望构建方案时，才采用 (B)。

产品背景：检查 .agents/product-marketing.md，若存在则阅读——业务类型、销售周期和主要转化几乎会影响这里的每一项建议。

职责边界——这项技能不负责的内容

先说明以下边界，避免重复构建相邻技能涵盖的内容：

• 通用事件追踪、追踪计划、UTM 设置、GA4／GTM → analytics。归因假定追踪已经存在。两者的界线是：analytics 负责「追踪哪些事件以及如何触发」，归因负责「如何将触点关联到转化，并让这种关联延续到收入。」
• 广告平台像素、CAPI、服务器端转化追踪 → conversion-tracking。归因使用平台报告的数据并纠正其中的偏差；它不负责设置像素。
• 销售管道阶段、潜在客户生命周期、CRM 收入仪表板 → revops。归因会向销售管道提供数据，但不定义阶段。
• 在 AI 搜索中获得曝光／衡量 AI 搜索表现 → ai-seo。归因只会将 AI 流量列为盲点。

---

支柱 A — 解读

1. 归因能告诉你什么，不能告诉你什么

在处理任何数字之前，先设定预期：

• 归因反映方向，不代表真相。 它是基于不完整数据构建的因果模型（Cookie 会过期、会话会中断、线下触点会消失，人们可能在一台设备上调研、在另一台设备上购买）。将它视为有力线索，而非最终定论。
• 每种模型都代表一种观点。 「首次触点」认为全部功劳都应归于首个广告；「末次触点」则认为应归于促成转化的点击。两者都错，只是偏差方向相反。选择模型，就是选择相信谁的说法——要明确说明这一点。
• 归因差异很常见，因此要将实际结果与功劳分配区分开。 各渠道报告的转化总和几乎总是超过实际转化数，因为每个平台都会根据自己的归因窗口和展示后转化规则，将同一笔销售归为己有。应以单一事实来源为准，去重后只统计一次实际转化，并单独解释平台归因的功劳。两者不会完全吻合，而且模型分配不能取代转化台账。

当用户要求一个唯一的真实数字时，请重新界定问题：「我们可以给你一个合理可信且一致的数字，并说明哪些渠道呈上升趋势。不存在单一客观真相——原因如下，但我们仍可以据此做出决策。」

2. 归因模型

经典规则模型，以及数据驱动模型——还有它们各自会在哪些方面失真。最后一次非直接触点是最后触点模型的一种变体（跳过杂项），并非独立的流派。

模型	归因规则	最适合的场景	失真之处
首次触点	100% 归给第一个已知触点	漏斗顶端 / 需求开发估值；周期较短	忽略促成交易的所有因素；过度归功于提升认知的渠道
最后触点	100% 归给转化前的最后一个触点	直接响应、快速电商	过度归功于漏斗底部渠道和品牌搜索 / 直接流量；忽略了需求是如何产生的
最后一次非直接触点	100% 归给最后一个触点，跳过“直接”流量	低成本解决直接流量干扰的方法	仍是单触点模型；只是换了盲区
线性	将功劳平均分给每个触点	每一步都重要的长周期、多触点旅程	把一次随意访问和一次演示同等看待；美化高频渠道
时间衰减	越接近转化的触点，功劳占比越高	更看重近期触点的长周期旅程	低估漏斗顶端；仍是一个假设，而非测量结果
位置模型（U 形）	首次触点占 40%，最后触点占 40%，中间触点占 20%	有明确“促成”和“成交”时刻的 B2B 场景	40/40/20 的比例是任意设定的；中间触点得到的功劳太少
数据驱动（算法 / Shapley）	根据模型估算的边际贡献分配功劳	转化量充足的大批量账户	黑盒；需要足够的数据量；无法识别从未输入模型的线下 / 暗触点

平台可用性说明： Google Ads 和 GA4 已于 2023 年将首次点击、线性、时间衰减和位置模型从可选报告模型中移除。这些界面提供数据驱动和最后点击（GA4 还提供基于付费渠道的最后点击变体）。应将完整表格作为概念来讲解，也可在自己的事件路径 / CRM / 数据仓库中计算这些模型——而不是将其视为 Google 下拉菜单中的选项。

经验法则：

• 对于销售周期较长的情况，切勿只报告单一模型。将首次触点和最后触点并列展示——真相介于两者之间，而两者的差距本身就是洞察。
• 数据驱动归因需要足够的数据量。Google Ads 过去要求 DDA 在 30 天内至少有约 3,000 次广告互动和约 300 次转化；现在已取消硬性最低要求，DDA 也成为默认选项，但 Google 仍建议在 30 天内达到约 200 次转化和 2,000 次广告互动，以保证质量。低于此水平时，DDA 往往会向最后点击的先验判断靠拢——看似科学的噪声。在 Google/GA4 数据稀少时：优先选择最后点击（或接受 DDA ≈ 最后点击）。在其他环境（第一方数据 / CRM / 数据仓库）中：计算位置模型，或并列比较首次触点和最后触点。
• 模型远不如保持一致重要，并且应配合模型之外的合理性核查（支柱 A §4，自述数据）。

有关模型计算方法、将一次旅程按六种规则模型评分的示例，以及浅显易懂的 Shapley 解释，请参见 references/attribution-models.md。

3. 三种测量范式

模型会在你跟踪的数据范围内拆分功劳。范式则用于探究因果关系——严谨程度越来越高，成本也越来越高：

范式	定义	回答的问题	需要条件	注意事项
MTA（多触点归因）	串联用户级触点，并应用模型	“哪些触点出现在转化旅程中？”	干净的跨设备用户级跟踪	Cookie 丢失和隐私限制会严重损害用户级数据；点击路径会系统性地高估搜索和直接流量，低估展示渠道
MMM（媒体／营销组合建模）	对一段时间内的支出与结果进行自上而下的回归分析	“各渠道的总体贡献是多少，包括线下和品牌渠道？”	2–3 年的每周数据，以及支出变化	反映相关性；响应较慢；需要预算出现真实波动才能进行学习
增量分析（地理区域留出、PSA、幽灵广告、开／关测试）	对照实验：比较曝光组与未曝光组	“这个渠道是否带来了原本不会获得的增长？”	能够暂缓投放；流量规模足以达到统计显著性	黄金标准，但一次只能测试少数项目

**如何选择：**预算较小／周期较短 → 良好的 UTM + 最后一次非直接触点归因 + 自我报告调查，胜过复杂模型。预算中等、渠道较多 → 用 MTA 做日常分析，并定期对投入最大的项目进行增量分析。预算较大，且有线下和品牌支出 → 用 MMM 分析整体组合，再用增量分析验证 MMM 的系数。每当两个渠道都声称带来了同一笔转化时，增量分析就是最终裁决依据。

按预算 × 销售周期 × 渠道数量划分的决策表，以及如何解读地理区域留出／PSA 测试（不是统计教程），见 references/measurement-paradigms.md。

4. 自我报告归因

这是最少被利用、也往往最诚实的信号，尤其适用于周期较长和暗社交场景。转化后询问“你是怎么知道我们的？”可以捕捉跟踪机制从结构上无法捕捉的信息：播客、口碑、Slack 社区、创始人的推文、“朋友告诉我的”。

• **适用场景：**考虑周期长、口碑效应强、由品牌／社区驱动，或暗社交活动频繁（见 §5）。如果很大一部分用户旅程被归为“直接流量”，说明你有一个应由自我报告填补的缺口。
• 在转化发生时提问（注册、首次购买、申请演示）——此时回忆最准确，记忆尚未淡去。
• **措辞：**开放式问题（“你最初是怎么知道我们的？”）可以捕捉暗社交；简短的选项列表更便于量化，但会预先影响回答。最佳实践：提供已知渠道的选项列表，并加入可自由填写的“其他／补充说明”。
• 将其视为交叉验证的依据，而非绝对真相——回忆并不准确，人们会归功于印象最深刻的触点，而非第一个触点。将调查中的占比折算为贡献时应打折（例如，22% 的人回忆起 YouTube，说明其提升了认知度，并不代表 YouTube 应获得 22% 的转化功劳）。在制定分配规则之前，结合增量分析／平台数据变化进行判断。
• 在实现方面，这是一个写入 CRM／分析系统、作为人员属性保存的表单字段——见支柱 B 和 references/first-party-tracking.md。

5. 调和相互冲突的数据源

大多数归因工作背后的问题是：**“Google 说是 50，Meta 说是 40，GA 说是 60，我的 CRM 说是 35——到底谁对？”**谁都不对。以下是处理框架。

为什么每个数据源都会系统性地失真：

数据源	偏向	原因
广告平台（Google/Meta/LinkedIn）	高估自身	会把自身归因窗口内的浏览转化和点击转化都算进去；每个平台都会把同一笔销售算作自己的成果；它们有动机让数据看起来更好
GA / 网站分析工具	最后一次非直接点击	无法追踪跨设备用户，也会漏掉 Cookie 被拦截的用户，还会把未知流量归入直接流量
CRM	销售代表填写或表单记录的内容	人工录入、潜在客户来源被覆盖、线下交易没有数字轨迹
自我报告调查	印象深刻的触点	回忆偏差；会低估再营销等平淡但真实的触点

如何进行交叉验证：

1. 选定一个转化次数的事实来源——通常是 CRM 或后端（资金实际发生流转的系统）。其他来源都用于解释转化来自哪里，而不能重新定义转化的数量。
2. **绝不要跨平台求和。**如果 Google 和 Meta 都声称带来了一次转化，那就是一笔转化有两个认领方，而不是两笔转化。请对照事实来源的总数去重。
3. **看趋势是否一致，而不是绝对数值是否吻合。**如果每个来源都显示本季度付费搜索增长、自然搜索下降，那么即使没有两个数据完全相同，这个趋势也值得信赖。
4. 当平台争抢同一批转化时，用自我报告调查结果作为决胜依据；当影响重大、值得测试时，则使用增量性测试。不要把平台与 GA 之间的差距转化为倍数规则（Meta 声称的转化量是 GA 的 2 倍 ≠“Meta 的数据乘以 2”）——应调查归因窗口和浏览转化，再以增量性测试为依据进行任何数据调整。
5. **预期并为差距做好准备。**报告“平台声称有 N 次转化；我们能核实 M 次；差值来自过度认领、浏览转化和未追踪转化——以下是我们最佳的分配结果。”
6. 尽可能将交叉验证落实为规则——一旦通过留出组测试或可信的调查结果确定了某个渠道的可信区间，就在报告中应用有记录的渠道级调整（在测试窗口内，将部分归因从直接流量／品牌流量转移到归因不足的渠道），而不是假装原始 MTA 就是真相。详情见 references/measurement-paradigms.md。

最终结果应是带有置信度的诚实分配，而不是精确到小数位的虚假调和。

6. 盲点

转化会藏在这些地方，让真正有效的渠道看起来表现不佳：

• 直接流量——杂物抽屉。包括书签和手动输入的 URL，也包括被剥除来源信息的流量、从应用跳转到网站的流量、暗社交流量，以及追踪丢失的任何触点。直接流量占比高，可能包含真正的直接访问、回访用户和衡量损失。在将其视为追踪缺陷之前，先调查其构成。
• 品牌搜索——先在别处发现你，之后再通过 Google 搜索你品牌名称的人。末次触点归因会把功劳记到付费／自然品牌搜索上；真正的驱动因素其实是促使他们进行搜索的因素。请区分品牌搜索与非品牌搜索，否则就会削减漏斗顶部的投入。
• 暗社交——不携带来源信息的分享：私信、Slack/Discord、播客、新闻简报、截图。这类流量在结构上对追踪不可见；自我报告是唯一能看到它的方式（§4）。
• AI 流量——助手和 AI 搜索越来越多地影响买家，随后买家会通过品牌搜索或直接访问进入网站，因此分析工具无法看到 AI 触点。请明确标记此类流量，并将更深入的工作交给 ai-seo。

当直接流量和品牌搜索占主导时，最常见的解释是：漏斗顶部正在发挥作用，只是归因将其隐藏了起来。下结论前请先确认：排除现有客户、来源信息丢失和线下发现渠道，再查看自我报告归因或开展增量性测试。这是营销中最常见的误判，正反两种方向都有，因此请说明证据支持哪一种解释。

7. 按业务类型划分

默认做法差异很大。此处仅作总结；完整操作手册见 references/by-business-type.md。

• B2B SaaS（周期长、销售辅助）： 用户旅程持续数周至数月，且涉及多位参与者，因此单触点模型会严重误导。以 CRM 作为真实数据源，并行使用 首次触点 + 基于位置的模型，重点关注 演示/注册时的自我报告，并将 销售管道/收入 归因（→ revops）视为真正的成绩指标。线下触点（活动、销售沟通）会让多触点归因在此处最不可靠，而自我报告最有价值。
• 电商 / DTC（周期短、自助服务）： 用户旅程快、量大，支出集中在付费社交媒体和搜索上。以 平台 ROAS 为基准，但不要盲目信任它（iOS/CAPI 会造成虚高）；当支出达到一定规模后，通过 MMM 验证，并在最大渠道开展 增量测试/地理区域留出测试；同时使用 购后调查，捕捉像素遗漏的信息。对于周转快的 SKU，末次触点归因有其合理性；而 MMM + 增量测试才是分配实际预算的方式。

---

支柱 B — 掌握自己的归因（第一方）

当用户控制网站/应用并希望自行部署归因时，使用此方法——尤其适用于转化发生在不归你所有的域名上的情况（SavvyCal/Calendly/Cal.com 预约、Stripe Checkout 页面）。本支柱基于真实的生产环境构建；包含代码模式的完整操作手册见 references/first-party-tracking.md。要点如下：

身份图谱

第一方归因的核心只有一个：将匿名浏览行为与最终转化关联起来。

1. 访客匿名到达；你的分析工具会分配一个匿名 distinct_id，并在其事件上记录首次触点属性（$initial_referrer、$initial_utm_*）。
2. 转化发生时（注册、预约、购买），调用 identify() 并传入稳定 ID（邮箱或用户 UUID）。这会将匿名历史合并到已知用户身份中——首次触点信息由此一直保留到转化。
3. 现在，每个转化事件都可以按首次触点渠道进行拆解。关键就在这里。

弥合 identify() 缺口

第一方归因最常见的失败原因是：从未调用 identify()，因此转化无法与浏览历史关联，每位客户看起来都像是凭空出现的。（此表述改编自 Tessa Kriesel 的 PostHog 方法。）解决办法是在每次真实转化时调用 identify。先审计——许多 SaaS 应用已在注册时调用 identify；不要重建已有的有效流程。找出具体尚未部署埋点的转化，只修复这些环节。

串联第三方域名上的转化

唯一需要复杂处理的情况，是转化在你无法控制的域名上完成（预约工具、托管式结账）。你无法在那里运行自己的分析工具，因此：

1. 点击时，捕获阶段的链接装饰器会通过该工具的元数据透传功能，将访客的匿名 distinct_id 附加到外部链接 URL 上（例如 ?metadata[ph_distinct_id]=<id>）。一个文档级监听器即可覆盖所有 CTA——无需逐个修改链接。
2. 第三方工具会存储该元数据，并在其 webhook 中返回。
3. 你的 webhook 处理程序会触发一次身份合并（以预约邮箱作为 distinct_id，以传入的匿名 ID 作为 $anon_distinct_id 调用 $identify），并发送一个转化事件——将预约关联回营销旅程。

防护措施（不可跳过）

• 匿名性防护——默认拒绝。 只传递匿名 ID。调用 identify() 后，当前 ID 会变成用户的邮箱/UUID；如果将其泄露到第三方 URL，或基于它进行合并，就会破坏用户档案（用户 A 的邮箱会被合并到预约者的档案中）。拒绝看起来像个人身份信息（包含 @）的 ID，限制长度；如果身份不明确，什么也不发送。如果应用通过 UUID 识别用户，请测试 distinct_id === device_id，而不是检查是否包含 @。
• 首次触点数据质量。 重定向会覆盖真正的首次触点。对引荐来源分类时，应排除 OAuth/结账来源（accounts.google.com、checkout.stripe.com、login.*）、自有子域名（自引荐）和开发主机（localhost）。这通常只需更改设置，无需修改代码，而且是投入产出比最高的修复。
• 跨子域名串联。 营销网站 → 子域名上的应用必须共用一个分析项目 + 跨子域名 Cookie，否则用户旅程会在交接处中断。预计在生产环境验证串联之前，数据几乎为零——不要被空数据吓到；同时使用基于营销活动时间窗口的启发式回退方案，并补录串联前的用户群体数据（详见参考资料）。

报告与最后一公里

最初的成果是一条洞察：按首次触点渠道拆分的转化事件（$initial_utm_source / $initial_referring_domain），以及与收入关联后的渠道 → 转化 → 收入。请在工具中确认首次触点与最后触点配置（很多工具默认采用最后触点；首次触点归因应使用 $initial_*）。

但仅有首次触点，还无法运行 §2 中的多触点模型。存储完整、有序的触点路径（不只是 $initial_*），构建轨迹就能为解读轨迹提供数据——你可以用基于位置、线性或时间衰减模型为自己的用户旅程评分，而不只是了解这些模型。

最后一公里——将数据写入 CRM（由 Tessa Kriesel 提出的生产环境优化方案）。分析工具中的拆分是一份报告；销售和生命周期团队要采取行动，归因信息必须写入记录。同步一个包含 confidence 和 basis 的 source 字段（基于用户旅程关联、用户自述或基于营销活动时间窗口的回退方案），以及根据媒介判断的付费与自然流量，并将结果汇总到客户账户（而非仅联系人——一个 B2B 组织中可能有多个人，工作邮箱与个人邮箱混用）。如何让销售管道/生命周期流程使用这些信息，是 revops 的职责。

这种模式与工具无关：PostHog、Segment、Amplitude 均支持 identify + merge，GA4 则可通过 user-id 实现；只要工具支持元数据透传 + webhook，第三方串联就可行。references/first-party-tracking.md 中以 PostHog + SavvyCal 为完整示例。

---

输出格式

交付一份归因解读，而非数据倾倒：

# Attribution Readout — [date]

## The question
[What decision this informs — e.g. "where should next quarter's budget go?"]

## Source of truth
[Which system defines the conversion count, and why]

## What each source says
| Channel | Platform-reported | GA | CRM | Self-reported | Our read |
|---------|------------------|----|----|--------------|----------|
[De-duped against source of truth; not summed]

## Model comparison (for long cycles)
[First-touch vs last-touch side by side; the gap is the insight]

## Confidence & gaps
[The attribution gap, the blind spots, what we can't see]

## Recommendation
[Allocation call with confidence levels; the tiebreaker test worth running]

工具集成

实现方式请参阅 tools registry。主要工具：

工具	最适用场景	MCP	指南
PostHog	第一方归因、识别／合并、漏斗	-	posthog.md
GA4	Web 分析、模型比较、用户 ID 关联	✓	ga4.md
Dub	短链接和点击归因	✓	dub-co.md
Segment	CDP — 将识别／跟踪事件发送至每个目标	-	segment.md
HubSpot	CRM 线索来源和自填字段	✓	hubspot.md
Salesforce	将 CRM 作为收入事实来源	-	salesforce.md
Supermetrics	将各平台数据汇集到一处以便核对	✓	supermetrics.md
RB2B	识别匿名 B2B 网站访客	-	rb2b.md

---

相关技能

• analytics — 事件跟踪、跟踪计划、UTM、GA4/GTM 设置。请在归因工作之前完成。
• conversion-tracking — 广告平台像素、CAPI、服务端转化跟踪和跟踪审计。
• revops — 管道阶段、线索生命周期、CRM 收入报告。归因数据会流入其中。
• ai-seo — 深入了解 AI 搜索归因盲点。
• ab-testing — 对照实验；将增量思维应用于站内变更。