企业微信获客怎么做来源归因

归因只有一个地基：来源在通过那一刻写死

来源字段有一个别的字段都没有的性质：它只在一个瞬间可写。加好友通过的那一刻，你手上同时有「他从哪个码进来」和「这是哪个客户」两条信息；错过这一刻，两条信息就分家了，之后无论查什么都只能靠时间接近度猜。

所以来源写入必须和通过事件绑在同一段逻辑里：用 wecomapi 的事件回调拿到通过事件，在同一次消费里把来源落库，而不是先建档、再由另一个任务回来补。写不进去时把记录标成待补并告警，不要静默留空 —— 空值和确实没有来源在库里长得一样，混起来之后归因覆盖率就再也算不准。

• 未知来源必须是一个正式的枚举值，不是空，也不能塞进其它渠道。它的占比就是归因覆盖率，藏起来只会让所有渠道对比虚高。
• 来源写一次就不再改。渠道后来改名、活动后来合并，改的是映射表里的展示名，不是客户主档上那个键。
• 线下、名片、转介绍这类天然拿不到码的入口，各给一个显式来源值，靠话术或人工回填，别都归到未知。

三种承载来源的方式，先选主键

能把从哪来这件事带进来的方式就三类，粒度、成本和可信度差别很大。

• 一码一渠道：一个投放位一个码，码本身就是来源标识。可信度最高、实现最简单，代价是码的数量随投放粒度线性膨胀，几十个还行，几百个就需要一套码管理。
• 带参数的中转页：先落到你自己的页面或短链，记下完整参数，再引导添加。参数能带得很丰富，但多一跳就会掉人，而且中转页和最终添加之间的关联要自己拼，拼不上就退化成未知来源。
• 事后回填：欢迎语里问一句，或者由承接人手动选。覆盖最广、可信度最低，只适合做兜底和交叉校验，不能当主口径。

判断是：把码作为归因主键，中转页参数作为补充维度，回填只做兜底。三种混用时要规定优先级并写死 —— 同一个客户身上三个来源打架，取哪一个不该由代码执行顺序决定。

码的粒度切到哪一层，用一句话判断：切到你能据此做取舍的最小单位。如果一个渠道下三个投放位你永远会同进同退，那它们共用一个码；如果你会因为某个位效果差就单独砍掉它，那它必须有自己的码。按这条切出来的码，数量通常比拍脑袋列的清单少一半，而每一个都真的会被看。

参数怎么设计：码上只放一个引用键

常见的错法是把渠道、活动、投放位、日期全塞进码携带的参数里，拼成一个长串。问题不是长，是它把结构固化在了已经发出去的码上：想加一个维度，只能作废重发。

该做的是码上只放一个短引用键，其余全部放在自己库里的映射表：键指向一条码记录，码记录上挂渠道、活动、批次、承接人、生效与失效时间。要加维度就加列，已经在外面流传的码不受影响。

1. 1引用键别用自增数字。可枚举的键会被人顺着扫一遍，把你的投放结构摸清楚，用足够长的随机串。
2. 2码记录要带批次。同一个渠道分三次投放，报表上要能分开看，靠的是批次而不是渠道。
3. 3码要有失效时间，且过期之后的行为要明确定义。活动结束半年还有人扫到旧码，这些人算哪次活动的？不定义，他们就会污染当期数据。
4. 4一个码对应多个承接人时，分流结果必须落成一条记录。只在内存里轮询分配，事后就说不清这个客户当初为什么分给了他。

归因链路是六跳，每跳都要有分母

只统计两个数 —— 投了多少、成交多少 —— 是归因做不下去的根本原因：中间掉在哪一跳看不见，优化就只能靠猜。完整链路有六跳，每跳单独出数。

1. 1曝光：码被展示了多少次。这一跳只在自己的媒介里采得到，采不到就承认采不到，别用估算值填。
2. 2扫码：多少人扫了但还没动作。它和下一跳的差值反映的是引导文案和落地体验。
3. 3发起申请：多少人真的点了添加。
4. 4通过：多少人被通过了。这一跳掉人通常是承接不及时，和渠道质量无关，别记到渠道头上。
5. 5首次会话：多少人开口说了第一句。这是第一个反映客户质量的数。
6. 6转化：按你自己的业务定义，但定义要固定，中途改口径等于把历史数据作废。

前三跳在你自己的域内采集，后三跳来自 wecomapi 事件回调推送的关系变更与消息事件：收到后先快速 ACK 再异步处理，把每一跳各写成一条带时间戳的流水，而不是只更新主档上一个状态位。状态位只能回答现在在哪，流水才能回答在哪一跳掉的、掉之前停了多久。

// 示意逻辑，evt 是归一化后的内部事件对象
// 精确的事件类型、字段与端点以线上文档为准
async function onPassed(evt) {
  await ack();                                   // 先快速 ACK
  if (!(await dedupe.first(evt.id))) return;     // 事件 ID 幂等

  const code = await codes.load(sourceKeyOf(evt)); // 码上只有一个引用键
  await funnel.mark(evt.customerId, "passed", evt.ts, {
    channel: code?.channel ?? "unknown",         // 拿不到就显式记 unknown
    batch:   code?.batch,
    owner:   evt.staffId,
  });

  await post("https://manager.wecomapi.com/message/sendText", {
    guid:    evt.accountId,
    toId:    evt.customerId,
    content: welcomeOf(code),                    // 按渠道给不同的第一句
  });
}

重复扫码、删了再加、多人承接

真实数据里这三种情况占比不低，处理方式不统一，报表就会自相矛盾。

• 同一个人扫了多个码：主档上只保留第一次生效的来源，其余写进来源触点流水。要做多触点分析时用流水，日常报表用主档，两个口径分开命名，别都叫来源。
• 删好友再加：客户主体保留，来源新增一条触点记录，当期转化按最近一次生效的来源归因。把它当成全新客户会把留存率算高，因为同一个人被算了两遍。
• 同一个人被两个成员加上：来源按各自的承接关系分别记，报表按人去重。这也是为什么客户主档必须是人、身份表多对一挂上去。

还有一件必须分清的事：来源和承接归属是两个字段，转接不改来源。客户从 A 销售转给 B 销售，用 wecomapi 的事件回调感知到归属变更之后，写的是归属表的新记录，来源字段一个字都不该动。把它们做成同一个字段，一次批量转接就能把整个季度的渠道报表洗掉，而且没有任何报错。

多触点模型不要一上来就做。私域里绝大多数决策 —— 这个渠道要不要继续投、这批码要不要停 —— 用加好友那一刻的末次触点就能做，而多触点模型需要的曝光级数据你多半还没采全。等归因覆盖率稳定在八成以上，再谈权重分配。

渠道好不好，不看加了多少人

加人数是最容易被操纵的指标，也最没有决策价值。判断一个渠道看三个数：通过率、首次回复率、三十天留存或转化率。

这三个数按渠道拆开看，结论经常和直觉相反：加人最多的渠道往往首次回复率最低，因为它的引导方式筛掉的是意愿而不是资格。按加人数分配预算，等于持续买入最不想说话的那批人。

• 渠道对比必须在同一个时间窗内做。不同月份投放的两个渠道，留存率没有可比性。
• 码停用要有流程。活动结束、承接人离职、渠道合作终止，任何一种都该触发码失效，否则后续流量会归到一个已经不存在的渠道上。
• 每季度核一次归因覆盖率。这个数往下掉，通常意味着某个新入口没接上采集，而不是渠道结构变了。

归因数据别只喂给报表。来源在客户加进来的第一秒就知道，它是当时唯一确定的信息，用来决定第一句说什么、进哪条跟进节奏、分给谁承接，收益比月底那张表大得多。只做报表的归因系统，通常在第二个季度就没人维护了 —— 因为它不参与任何日常动作，坏了也没人立刻发现。