app营销：口碑传播与可归因渠道同时存在时怎样记录来源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3ba9aed05c00.html
📄
app营销：口碑传播与可归因渠道同时存在时怎样记录来源
当同一批新用户里既有分享邀请带来的，也有广告点击或搜索进入的，记录来源的关键不是二选一，而是把“谁先触达”和“谁最后说服”分开存字段。只保留一个来源字段，必然在口碑与可归因渠道之间丢失信息；正确做法是同时记录首次触点、末次可归因触点，以及分享关系是否成立。
矛盾现象：安装量对得上，来源却对不上
常见情况是：投放后台显示带来一批激活，应用内又出现一批通过好友分享进入的用户，两边数字相加超过实际新增。这并不一定说明某一方在虚报。它更可能说明同一个用户被两个系统各记了一次，而这两个系统统计的根本不是同一件事。
可归因渠道记录的是“点击或曝光到安装”的链路，口碑传播记录的是“人与人的推荐关系”。前者回答用户从哪来，后者回答用户为什么来。把两者塞进同一个来源字段，就会在去重时被迫删掉一边，剩下的数字看似干净，实际已经失真。
两种解释：重复计数，还是链路本就重叠
第一种解释是重复计数：用户先看到广告，之后又收到好友分享，安装时两个系统都判定自己有功。第二种解释是链路重叠：用户确实通过分享链接进入，但该分享链接本身带有渠道参数，于是被归因系统算作某个投放渠道。两种解释对应的处理方式完全不同。
- 如果是重复计数，需要的是去重规则和优先级，而不是删掉口碑记录。
- 如果是链路重叠，需要的是在分享链接上保留分享者标识，同时允许渠道参数继续存在。
区分二者的证据不在总量，而在明细：看同一设备或同一账号是否在短时间内出现两条来源记录，看分享关系表中是否存在对应的邀请人，看渠道回传时间与分享发生时间的先后。如果两条记录时间接近且能对应到同一个邀请人，链路重叠的可能性更大；如果两条记录来自不同设备标识、彼此无关联，重复计数的可能性更大。
记录来源时先固定三个字段
不要试图用一个“来源”字段承载所有信息。至少拆成三个独立字段，并明确各自只回答一个问题。
first_touch：用户第一次被记录到的触点，可以是广告、搜索、内容或分享，只记录时间最早的那一个。last_attributable_touch：安装前最后一次可被系统识别的点击或曝光，保留渠道标识和点击时间。referral_relation：分享关系是否成立，记录邀请人标识与接受时间，不参与渠道去重。
这三个字段并存时，一个用户既可以被记为“首次来自搜索、末次来自投放、同时存在分享关系”。后续分析时，想看拉新效率就用末次触点，想看传播结构就用分享关系，两者不再互相覆盖。
一个假设例子：同一用户被记了两次
假设某用户先在信息流看到广告但没有点击，两天后收到好友发来的邀请链接并完成安装。投放系统按曝光归因记为渠道 A，分享系统按邀请关系记为口碑。若只保留一个来源，无论选哪个都会让另一方看起来无效。
按三字段记录后：first_touch 为渠道 A 曝光，last_attributable_touch 为邀请链接点击，referral_relation 为有效。此时可以进一步判断：如果邀请链接点击是可归因的，那么这次新增应计入分享链路；如果邀请链接无法回传点击，则只能依赖分享关系字段，不能强行把它算作渠道 A 的功劳。
这个判断会直接影响下一步动作：当分享关系字段的覆盖率明显高于可归因点击时，说明分享链路大量依赖非点击路径，接下来应优先完善邀请关系的记录，而不是继续加大投放去补归因缺口。
什么情况下可以只保留一个来源
如果业务目标只是粗看新增规模，且不打算区分拉新与传播，那么单一来源字段可以维持。但只要出现以下任一条件，就必须拆字段：需要评估分享带来的用户质量、需要给渠道结算、需要判断投放与口碑是否互相替代。此时单一来源不再够用，继续使用只会让后续决策建立在被删减过的数据上。
需要提醒的是，某个渠道的归因量下降或分享记录变少，不能单独证明记录方式正确。它也可能来自回传延迟、用户关闭追踪、分享链接失效或统计口径调整。先核对字段是否完整，再判断数字变化的原因。
