app推广方法：口碑传播与可归因渠道同时存在时怎样记录来源，先区分两种来源记录的目的
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /501806ca2a06.html
📄
app推广方法：口碑传播与可归因渠道同时存在时怎样记录来源，先区分两种来源记录的目的
结论是：如果一次安装或注册同时来自可归因投放和口碑推荐，不要强行二选一，而应把“首次可识别触点”和“最终推荐触点”分开记录，再为每条记录标注归因置信度。只有当你需要把某个渠道的投入产出直接对应到收入时，这种双记录才需要进一步收敛为单一归因口径；否则双记录可以并存。反例是：如果后台只能保留一个来源字段，且业务按最后一次点击结算，那么把口碑推荐写成主来源会掩盖投放实际带来的启动量，后续预算判断就会失真。
先区分两种来源记录的目的
可归因渠道记录解决的是“这次转化由哪次投放或哪个链接触发”，它依赖点击标识、安装参数或渠道包。口碑传播记录解决的是“用户为什么愿意尝试”，它往往来自熟人推荐、群聊讨论或内容被转发。两者不是同一层信息，混在一个字段里，后续既无法核对投放成本，也无法判断推荐内容是否有效。
实际动作是给每条转化记录增加两个字段：first_touch和referral_touch。前者写系统能识别到的渠道标识，后者写用户主动说明的推荐来源。这样做的直接结果是，报表可以分别统计投放带来的启动量和口碑带来的启动量，而不是让两者互相覆盖。
口碑来源要记录到什么颗粒度
口碑传播通常没有稳定的链接参数，记录颗粒度取决于你下一步要做什么。如果只是想知道“有没有人在推荐”，记录“用户提到朋友推荐”就够用；如果要判断哪类推荐内容更有效，就需要记录推荐发生在哪个场景，例如微信群、朋友圈转发、线下交流或社区帖子。
假设一个例子：某工具类应用在投放落地页和用户邀请之间同时获得安装。若只记录“邀请”，会低估落地页的作用；若只记录“落地页”，又会漏掉邀请带来的信任加成。此时可以记录为first_touch=投放链接、referral_touch=熟人邀请、confidence=中，并注明用户是先看到投放内容、后经熟人确认才完成安装。这个例子的数字和场景仅用于说明记录方法，不代表真实项目结果。
什么情况下必须收敛为单一归因
当你需要按渠道结算费用、计算单个渠道的获客成本，或对外汇报时只能给出一个来源，就必须提前确定收敛规则。常见规则有两种：按首次可识别触点归因，或按最终推荐触点归因。两者成立的条件不同：前者适合评估拉新投放的启动作用，后者适合评估推荐机制对转化的推动作用。
会使双记录失效的反例是：多个团队共用一张表，但没有人负责维护归因置信度。时间一长，referral_touch会被随意填写，first_touch又缺少渠道标识，最终两个字段都不可用。这时不如先只保留一个主来源字段，并明确写入口径，等记录流程稳定后再拆开。
用置信度标记避免把推测当事实
口碑来源常常来自用户口述或客服备注，它和系统回传的点击标识不是同等可靠。可以给每条来源记录加一个简单的置信度：高表示有明确链接或系统标识，中表示用户主动说明且能对应到具体场景，低表示仅凭推测或模糊描述。置信度不参与收入计算，只用来决定这条记录能否进入正式分析。
- 高置信度记录可以直接进入渠道效果对比。
- 中置信度记录适合用于观察趋势，不宜单独作为预算调整依据。
- 低置信度记录只保留在明细中，不进入汇总报表。
这样处理的结果是，口碑传播不会被当成可精确归因的投放渠道，可归因渠道也不会吞掉口碑信息。下一步动作是每周抽查一批双来源记录，核对first_touch和referral_touch是否都有填写依据；如果抽查中发现大量记录只能填到低置信度，就应先简化字段，而不是继续增加维度。
