把口碑传播与可归因渠道放在同一张来源记录里,关键不是判断哪个渠道“功劳更大”,而是先区分两类证据:可归因渠道提供的是点击、表单、订单等系统侧事件;口碑传播提供的是当事人转述、推荐关系和线下对话。记录时应让口碑字段只承载“谁向谁推荐、推荐发生在哪一步”,让归因字段继续承载渠道标识和转化事件,两者用同一个客户或线索编号关联,而不是互相覆盖。
假设一位老客户在微信群里推荐了你的服务,新客户随后通过搜索品牌词进入官网并提交表单。系统会把这条线索记到自然搜索或品牌词渠道,口碑推荐在报表里几乎看不见。这不是数据错误,而是两种记录口径天然不同:归因渠道记录的是最后一次可追踪的接触,口碑记录的是人传人的关系链。若直接把口碑当成“未归因流量”塞进渠道字段,后续比较渠道成本时就会失真。
可核对的证据分三层:系统侧事件(访问来源、表单提交时间、订单编号)、当事人侧陈述(推荐人是谁、何时推荐、推荐了什么)、关系侧事实(双方是否认识、是否在同一社群或同事关系)。三层证据都指向同一线索编号时,口碑来源才成立;只有当事人事后回忆而没有系统事件对应,应标为待核实,而不是直接并入某渠道。
实际操作中,可以在现有线索表上增加几个只读字段,而不是新建一套并行报表。以下为字段示意,具体字段名可按现有系统调整:
lead_id:贯穿系统事件与人工记录的唯一边号。attributed_channel:保留系统原有渠道值,如自然搜索、付费广告、社媒推荐位,不因口碑存在而改写。referral_flag:是/否/待核实,表示是否存在可确认的人传人推荐。referrer_note:推荐人身份与推荐发生的环节,只写事实,不写评价。evidence_type:系统事件、当事人陈述、关系确认,可多选。first_touch_note:首次听说品牌的途径,若与系统渠道不同,单独保留。这样做的结果是:渠道报表继续按原口径统计,口碑分析则通过 referral_flag 和 evidence_type 单独筛选。两者不互相污染,后续若要评估口碑带来的线索质量,可以在这组字段上做单独对比,而不是把口碑硬塞进渠道成本比较。
同一线索可能首次听说来自朋友推荐,最后转化来自搜索广告。若来源字段没有说明指哪一层,任何记录都会引起争论。建议在字段说明中写死:attributed_channel 指系统可追踪的最后非直接接触,first_touch_note 指当事人自述的首次听说途径。两个值允许不同,且都保留。
如果当事人说“朋友介绍”,但无法确认推荐人、推荐时间和推荐内容,就标为待核实,不进入口碑线索统计。待核实的线索仍保留在原渠道中,避免因个别口述而整体调整渠道数据。下一步动作是回访确认推荐关系,确认后再更新 referral_flag。
搜索、广告、社媒和销售各自的指标口径不同,不能混用。口碑记录不应被用来计算点击率或广告成本,渠道数据也不应被用来证明口碑规模。若需要同时呈现,用同一线索编号做交叉筛选,而不是合并成一个“综合来源”字段。
以下情境为假设,用于说明比较方法,不代表任何真实项目结果。
attributed_channel 保持该值,不改写。referral_flag=是,referrer_note 写明A与推荐发生的群,evidence_type 选当事人陈述。evidence_type 增加系统事件。evidence_type 增加关系确认;若A无法确认,则回到待核实。lead_id 对齐。这个流程的实际动作是回访确认推荐关系,它的结果决定 referral_flag 是否从待核实变为是。若确认成立,下一步才能把该线索纳入口碑线索质量对比;若不成立,线索留在原渠道,不做额外处理。
某渠道请求量、抓取量或表单量归零,不能单独证明口碑记录方式正确,也不能证明渠道失效。常见合理解释包括:统计窗口变化、标签部署调整、季节性波动、竞争环境变化,或该渠道本就只承担辅助接触。要区分这些解释,至少需要同时核对系统事件时间线、当事人陈述和关系确认三类证据;只有一类证据变化时,先记录变化,不急于改写来源字段。记录来源的目的不是给渠道排名,而是让每一次线索都能被回溯到具体证据。