营销案例分享：口碑传播与可归因渠道同时存在时怎样记录来源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b7fcde0c96ee.html
📄
营销案例分享：口碑传播与可归因渠道同时存在时怎样记录来源
把来源记录拆成两层：一层是“谁把信息带到了这个人面前”，另一层是“哪个可点击或可结算的入口完成了这次转化”。当一位新客户说“朋友推荐”，同时又通过带参数的链接或活动码下单，这两层信息都要保留，但不要合并成一个字段。合并之后，你无法判断口碑是独立起作用，还是只是给可归因渠道做了背书。
先判断这次口碑是否可独立识别
口碑来源能不能单独记录，取决于推荐人是否愿意被记录、以及被推荐人是否记得推荐人。若推荐发生在私聊、线下聚会或封闭社群，且推荐人不愿被点名，那么可识别的只有“被推荐人自述有推荐”，无法确认推荐人身份。此时应把来源记为“自述口碑”，而不是硬填一个推荐人。
可独立识别的条件是：推荐人同意留名，或被推荐人主动提供推荐人的可核对信息，例如昵称加一个双方都知道的接触场景。满足这个条件时，才建立推荐关系记录。不满足时，只记录自述口碑，并注明无法回访推荐人。这个区分会直接影响下一步：可识别口碑可以进入推荐人回访和答谢流程，不可识别口碑只能用于文案和渠道假设，不能用于结算。
可归因渠道优先记录动作，口碑记录关系
可归因渠道记录的是动作：点击了哪个链接、扫了哪个码、用了哪个活动码、在哪个页面提交。这些动作有明确的触发点，适合作为转化归因依据。口碑记录的是关系：谁向谁说了什么、在什么场景下说的。两者维度不同，不应互相替代。
实际操作时，在客户记录里保留两组字段。第一组是“转化入口”，填链接标识、活动码或表单来源页。第二组是“推荐关系”，填推荐人标识、推荐场景、被推荐人自述原话。若两组都为空，才归入“无来源”。这个动作的结果是：后续做渠道复盘时，可归因入口能算动作转化，口碑关系能算推荐网络，两者不会互相污染。
假设示例：推荐人留名与不留名的两种记录
假设一个卖手冲咖啡器具的小团队做了一次老客户推荐活动。客户A把活动页转给朋友B，B通过A的专属码下单，并在备注里写了“A推荐”。这时专属码是可归因入口，备注是口碑关系，两条都记录。如果B没有用专属码，只是下单后说“朋友推荐”，且不愿说朋友是谁，那么只记录“自述口碑”，不填推荐人，也不把这次订单算进任何推荐人的答谢。
这个假设示例说明：同一个订单，可能同时存在可归因入口和口碑关系，也可能只有其中一项。记录方式不同，后续能做的动作就不同。有专属码时可以核对推荐人并进入答谢；只有自述口碑时，只能用于判断“口碑可能是影响因素”，不能用于结算或定向回访。
规模化后出现例外时，先查记录口径是否被改过
个别样本成立、规模化后出现例外，常见原因不是口碑失效，而是记录口径被中途改过。例如早期人工记录时，客服会把“朋友推荐”直接填进来源字段；后来接入带参数的链接后，同一个字段又被用来填链接标识。两种口径混在同一列，规模化后就无法区分。此时应做的动作是回查字段定义和填写规则，而不是先下结论说口碑不可归因。
另一个合理解释是：口碑和可归因渠道在不同阶段起作用。口碑可能发生在认知阶段，可归因渠道发生在转化阶段。若只记录转化阶段的入口，就会把口碑漏掉；若只记录口碑，又会把可归因入口漏掉。判断依据是看被推荐人能否说出推荐人、以及转化时是否使用了可识别入口。两个条件都满足时，两条都记；只满足一个时，只记满足的那条，并注明另一条缺失。
记录来源后，下一步动作取决于哪条信息可用
如果可归因入口可用，下一步是核对入口对应的渠道或活动，检查该入口带来的转化是否与口碑关系重叠。如果推荐关系可用，下一步是回访推荐人，确认推荐场景，并决定是否进入答谢流程。如果两条都不可用，下一步不是补填来源，而是检查收集环节是否缺少提问或缺少标识。
需要避免的是把口碑自述直接当成可归因渠道，或把可归因入口直接当成口碑证明。前者会让渠道数据虚高，后者会让推荐关系丢失。记录来源的目的不是给这次转化找一个唯一答案，而是保留足够信息，让后续能分别验证口碑和渠道各自的作用。
