企业微信私域数据看板怎么建

先砍：一个数字要能改变某个人的动作

上板的门槛就一条：写得出「这个数变差了，谁会在什么时候做什么」。写不出来的指标一律不上，不管它多好拿。累计客户总数是最典型的一个 —— 它只会涨，涨了没人做什么，跌了说明出大事而那时你早就从别的渠道知道了。

• 累计类：累计客户数、累计消息量。单调增长，不承载任何决策，最多在汇报页放一个。
• 过程量而非过程率：只看发了多少条、加了多少人，不看通过率和回应率，等于只看投入不看效果。
• 没有对比基准的绝对值：本周新增 320 是好是坏，取决于上周多少、同期多少、目标多少。三者都没有的数字读不出结论。
• 员工发送条数排名：这类指标一挂出来，行为就会被指标本身改造，最后你测的是「谁更会刷数」。

五类指标，按运营链路切而不是按接口切

按接口能力分组的看板会长成「客户模块 / 群模块 / 消息模块」，这个分法对开发友好，对使用者毫无意义 —— 没有任何一个人的工作是「负责群模块」。按客户从进来到留下的链路切，每一段对应一个明确的责任人。

1. 1获客段：新增客户数、来源分布、添加通过率。通过率是这一段唯一有诊断力的数 —— 新增掉了，先看是发起量掉了还是通过率掉了，两者对应完全不同的动作。
2. 2激活段：首次回应率、首响时长分布、24 小时内双向对话率。用分布不用均值，均值会被一批秒回的自动欢迎语拉平，看不出真正没人管的那部分。
3. 3活跃段：周期内有双向消息的客户数、沉默天数分布。沉默天数是私域最被低估的指标，一个客户从「七天没说话」滑到「三十天没说话」，是可以提前干预的。
4. 4转化段：进入下一阶段的数量与停留时长。这一段的数几乎全部来自你的业务系统，会话侧算不出金额，也不该去凑。
5. 5健康度：流失与被删除、退群率、人均在跟进客户数。它是给管理者看的负向指标，用来发现「增长是靠透支承接能力换来的」。

三个数据源，性质完全不同

看板做不准，八成不是算错了，是把三种性质不同的数据当成一种在用。分清楚它们，比选什么 BI 工具重要得多。

• 事件流：发生即产生、只追加、带事件时间。所有过程指标（通过、回应、进群、退群、沉默）只能从这里来，它是唯一能回答「当时发生了什么」的数据。
• 接口拉取的快照：客户档案、归属、群成员这类当前状态。它回答「现在是什么样」，回答不了「上个月是什么样」。
• 业务系统：订单、金额、工单、合同。转化段的数字全在这里，与会话侧通过客户身份映射关联。

落地上，用 wecomapi 的事件回调把变更收成一张只追加的流水表，先快速 ACK 再异步入库，看板的过程指标全部从这张表算；接口拉取的快照单独存，而且要存成带生效区间的历史表，不要就地覆盖。就地覆盖会让上个月的归因随着今天的归属变化而变化，这类错误查起来极其痛苦，因为报表每次跑出来都是自洽的。

快照拉多勤，取决于它被用来算什么，不取决于拉不拉得起。wecomapi 按账号订阅、订阅内可无限次调用接口，不按调用次数计费，真正的约束是公平使用策略和你自己这边的写入放大 —— 一次全量会把下游的写入、索引和缓存全搅一遍。所以更该做的是把快照分成两份：进历史表的那份按日切一版通常就够，看板上「当前状态」那一栏才需要更勤，而后者不该参与任何历史口径的计算。

会话内容是第四类，单独对待。它有明确的前置条件与合规边界，默认不进看板；确有需要时也只做聚合口径，不在看板上展示个人级明细。这条不是技术选择，是合规选择，动手之前先让法务和 HR 过一遍。

口径必须先于图表定死

「活跃客户」在三个部门有三个定义，这是私域看板最常见的翻车方式。周会上两个人拿着两个数字争半小时，最后发现两边都没错，只是一个按客户去重、一个按跟进关系计数。定义没定死之前，任何图表都是在制造争论。

1. 1一个指标一个负责人、一句话定义、一段可执行的 SQL 或计算逻辑。三者缺一，这个指标就不算存在。
2. 2去重口径写进指标名。同一个客户被两个成员加过，运营关心的是「一个人」，主管考核关心的是「两条跟进关系」 —— 那就叫两个名字，分别叫「客户数（去重）」和「跟进关系数」，别让读者猜。
3. 3时间维度统一用事件时间，不用入库时间。用入库时间的后果是补数或链路抖动会让历史数字自己变化。
4. 4自然日边界和时区写死在一处。跨零点的会话归哪天，这种小事不定，日环比就永远对不齐。

这套定义要和数据放在一起、能被查询到，而不是躺在一份文档里。最省事的做法是把指标定义做成一张表，看板上每个数字旁边挂一个链接指过去。它能省掉的答疑时间，一个季度就够回本。

最容易算错的四处

下面四个坑不挑团队，做私域数据的基本都会踩一遍，区别只是发现得早还是晚。

• 分母漂移：留存率的分母用「当前存量客户」而不是「当期进入的那批人」。这样算出来的历史留存率每天都在变，昨天看到的数字今天复现不了，也就没法用它判断改动有没有效。
• 用今天的状态倒推历史：拿现在的标签分层去算上个月的转化，结论永远漂亮 —— 因为没转化的那批人早就被改成了别的标签。要用带生效区间的历史表，不要用当前快照。
• 重复计数：同一客户被多个成员添加、同时在多个群里、跨账号存在。做去重要先有稳定的客户身份映射，映射没建好之前，所有客户数都要标成「含重复」。
• 迟到事件：昨天的事件今天才到，T+1 的表跑完之后数据还在变。允许回补，同时在看板上标出数据截止时间和最近一次回补时间。不标的结果是有人拿着上午的数字去开下午的会。

迟到事件还有一个连带影响：实时看板和 T+1 看板会对不上，而且永远对不上。与其解释，不如在设计时就说清两者用途不同 —— 实时看板用来发现异常，T+1 用来做判断，不要拿实时的数去做复盘结论。

搭建顺序：流水、汇总、实时

顺序错了会返工两次。正确顺序是先把事件流水稳稳落下来，再做 T+1 汇总，最后才考虑实时。「事件管道要早于报表」的理由站内讲私域系统那篇已经展开，这里只补看板侧特有的一条：先做实时大屏的团队，第二个月才会发现自己手上没有可用来定口径的历史样本 —— 而口径几乎都是靠对着历史反复重算才定得下来的，没有样本就只能拿线上数据当草稿纸。

1. 1第一周：只做流水。把 wecomapi 推来的事件原样落库，带事件时间、接收时间和原始报文，先不算任何指标。这一步的价值是它让后面所有口径变更都能重算。
2. 2第二周：做三五个指标的 T+1 汇总，跑通口径评审。指标少不是缺点，是让口径能被认真讨论的前提。
3. 3之后：按需要补实时，且只给需要即时反应的那两三个指标做实时，其余留在 T+1。

// 示意逻辑，字段与表名均为自拟；事件类型与精确字段以 wecomapi 文档为准
app.post("/wecom/callback", async (req, res) => {
  if (!verify(req)) return res.sendStatus(401);
  res.sendStatus(200);                       // 先快速 ACK，落库放到队列里
  await queue.push(req.body);
});

// 消费侧：只追加，不更新；事件时间与接收时间分开存
async function consume(evt) {
  await facts.insertIgnore({
    event_id:   evt.id,                      // 幂等键，重复投递直接忽略
    happened_at: evt.happenedAt,             // 算指标只用这个
    received_at: Date.now(),                 // 只用来观测迟到程度
    type: evt.type, customer_id: evt.customerId, owner_id: evt.ownerId,
    raw: evt,                                // 留原始报文，口径改了能重算
  });
}

// T+1 汇总：按事件时间分桶，允许回补最近 N 天
SELECT date(happened_at) d, count(distinct customer_id) active_customers
FROM facts WHERE type IN ('msg.inbound','msg.outbound')
  AND happened_at >= now() - interval '7 day' GROUP BY 1;