别再给所有人发同一条消息：vibe 项目的用户分群与定向触达实战

先讲一个虚构的教学例子

阿远做了一个健身打卡应用，叫“七日环”。上线三个月，用户涨到了八千人，他想推一个新功能：连续打卡满七天，送一张进阶训练计划。他在后台写了一条群发消息，标题是“你离进阶只差一步”，发给了全部八千人。结果当天就有三百多人退订，评论区一片骂声。问题出在哪？那八千人里，有刚注册一天的新手，有打卡断了两个月的人，有早就买了进阶计划的老用户。对新手来说，“只差一步”是胡说八道；对断更的人来说，这条消息像是在嘲讽；对老用户来说，这是重复推销。同一句话，发给八千个处境完全不同的人，注定要得罪其中的大多数。

这个例子是虚构的，人名、产品名、数字和经过都是编出来讲道理用的。但它背后的教训是真实的：用户不是一群人，而是一群处境完全不同的人。分群要解决的，就是“别再给所有人发同一条消息”这个问题。本文讲分群怎么做、做到什么程度、以及做到哪一步就该停手。

先划界：这篇讲什么、不讲什么

分群这个词很宽，先把边界划清楚，不然很容易做成一个大而无当的“用户画像系统”，做三个月还没法上线。

第一，分析指标不是分群。日活、留存、转化率这些数字告诉你产品整体健不健康，分群告诉你“哪一群人”健康、“哪一群人”出了问题。前者是仪表盘，后者是手术刀，两件事不要混在一个功能里做。

第二，生命周期邮件序列不是分群。邮件序列讲的是“在用户旅程的第几天发什么”，分群讲的是“这条消息应该发给谁”。序列需要分群来决定收件人，但序列本身的文案节奏、发送间隔是另一篇的话题，本文只讲“人怎么分”。

第三，挽回流失用户不是分群。挽回是分群的一个应用场景：先分出“正在流失的那群人”，再对他们做挽回动作。但分群本身的应用远不止挽回，新手引导、付费转化、功能推广都要用到同一套分群能力。本文讲的是这套通用能力，不是某一个场景。

第四，推荐系统的冷启动也不是分群。推荐解决的是“给这个人推什么内容”，分群解决的是“把哪些人归为一组”。推荐可以用分群的结果做输入，但推荐算法本身——协同过滤、内容相似度——不在本文的讨论范围里。

划完界，本文只讲一件事：怎么把用户分成有意义的群，并且让每一群人收到对他们来说恰当的东西。

分群不是贴标签：从行为出发

很多团队做分群的第一步就走偏了：先去贴标签。男、女、二十岁、三十岁、来自北京、来自上海。标签贴了一大堆，消息还是不知道发给谁。因为人口属性回答的是“这个人是谁”，而运营真正需要回答的是“这个人现在处在什么状态”。

状态要从行为里看。最近一次打开是什么时候、打卡连续了几天、有没有用过核心功能、有没有付过费、付费之后还活不活跃。这些行为数据拼起来，就是一个人当前的状态。一个注册三天、每天都打开的人，和一个注册三个月、最近两周没打开的人，处境完全不同，哪怕他们年龄相同、性别相同、来自同一个城市。

行为分群有一个经典的起点：新近度、频率、付费额，也就是常说的 RFM 思路。最近一次活跃是什么时候、活跃有多频繁、花了多少钱。这三个维度交叉一下，就能分出最基础的几群人：活跃的付费用户、活跃的免费用户、沉睡的付费用户、沉睡的免费用户、新注册还没开始用的用户。这五群人，基本覆盖了你做任何运营动作时需要区分的对象。先把这五群分出来，再考虑要不要分得更细。

分得更细的时候，要按“能不能据此采取不同的行动”来判断。分出“连续打卡七天的人”和“连续打卡三十天的人”，如果对这两群人你打算做完全不同的事，这个区分就有价值。如果对这两群人你打算做的事一模一样，那这个区分就是多余的，只会让规则越来越复杂、越来越难维护。分群的粒度不是越细越好，而是“每一个群都对应一个不同的动作”刚刚好。

还有一个常见的误区：把分群当成一劳永逸的事。用户是流动的，今天的新手下个月就是老用户，今天的活跃用户下个月可能就沉睡了。分群规则要定期重算，至少每天跑一次。静态名单只适合一次性活动，比如“给上个月注册的用户发一封问卷”，长期运营一定要用动态规则，让用户在群与群之间自然流动。

分群的四种做法与取舍

分群的实现方式有四种，从简单到复杂，成本和能力一路往上涨。选哪种，取决于你的用户量和你的团队规模，选错了要么不够用，要么过度建设。

第一种是静态名单。运营人员手动圈人，导出一份名单，针对这份名单发一次消息。优点是零开发成本，半小时就能干活；缺点是名单一导出就过期了，用户状态变了名单不会跟着变。适合一次性活动、内测邀请、小范围灰度，不适合长期运营。

第二种是静态规则。规则写在代码里或者配置里，比如“注册超过七天且最近三天活跃过”。规则固定不变，但人群每天按规则重算。优点是实现简单、结果可预期；缺点是规则一多就难管理，改规则要改代码、要重新部署。适合用户量不大、分群需求还比较简单的阶段。

第三种是动态规则。规则可以由运营人员在后台自己配置、自己改，不用等开发排期。人群按规则实时或每天重算，规则改了，人群跟着变。优点是灵活，运营可以自己试错；缺点是规则配错了会立刻影响真实用户，所以必须配上预览和测试功能。适合用户量上万、运营动作频繁的阶段。

第四种是模型打分。用算法给每个用户算一个分数，比如流失风险分、付费意愿分，然后按分数分群。优点是能发现人看不出来的规律；缺点是成本最高，需要数据积累、模型训练、效果评估，而且分数的含义很难向运营人员解释清楚。适合用户量很大、数据很丰富的阶段，不适合刚起步的产品。

我的判断是：绝大多数 vibe 项目从第二种起步就够了。先写几条静态规则，把最基础的五群人分出来，跑上一两个月，看看运营动作是不是真的需要更灵活的规则，再决定要不要升级到动态规则。直接上模型打分，是最常见的过度建设，模型还没训练好，运营早就等不及了。

规则怎么写才不会打架

规则一多，就会打架。一个人同时满足“新手”和“活跃用户”两条规则，该收到新手引导还是活跃用户专属内容？一个人既在“沉睡用户”群里，又在“付费用户”群里，该收到挽回消息还是付费用户福利？这些问题不在规则设计的时候想清楚，上线后就会变成用户投诉。

第一个办法是定优先级。给每一条规则、每一次触达定一个优先级，优先级高的先执行，低的后执行。一个人同时命中多条规则时，只执行优先级最高的那一条。比如“付费用户福利”的优先级高于“沉睡挽回”，因为对付费用户发挽回消息是冒犯，对沉睡用户发福利只是浪费。优先级不是拍脑袋定的，要按“发错了的代价”来排：发错了会得罪人的排前面，发错了只是浪费的排后面。

第二个办法是互斥。某些群之间天然互斥，一个人不能同时属于两个群。比如“新手”和“老用户”互斥，“已付费”和“未付费”互斥。互斥关系要写进规则引擎里，一个人进了 A 群就自动退出 B 群，不要靠运营人员手动维护。手动维护的互斥关系，迟早会漏。

第三个办法是规则版本化。每一次规则的修改都要留记录：谁改的、什么时候改的、改之前是什么、改之后是什么。规则改错了，要能一键回滚到上一个版本。没有版本化的规则系统，出了问题连“是什么时候变坏的”都查不出来。

第四个办法是先预览再发布。规则配好之后，先算出这次会命中多少人，抽几个样本出来看看是不是你想要的那群人。命中人数突然比预期多十倍，或者样本里混进了明显不该在的人，都是规则写错的信号。预览这一步不要省，它是你上线前最后一次发现错误的机会。

触达渠道与频次上限：发得对，还要发得克制

分群分对了，只是成功了一半。另一半是：用什么渠道发、发多少次、什么时候发。发得不对，分群分得再准也是白搭。

渠道选择要按消息的轻重来定。轻消息走站内通知或者应用内横幅，用户打开产品的时候自然看到，不打扰。重消息走邮件，用户不在线也能收到，但要接受打开率低的现实。最重的消息才走短信或者电话，而且一年用不了几次。很多产品的问题是渠道用反了：轻消息用短信轰炸，重消息只放在站内等用户自己发现。

频次上限是分群系统里最容易被忽视、也最容易惹祸的部分。没有频次上限，一个人可能在同一天收到五条消息：新手引导一条、功能推广一条、活动通知一条、挽回消息一条、付费提醒一条。每一条单独看都合理，加起来就是骚扰。我的建议是：每人每天最多收到两条运营类消息，每周最多五条，超过上限的消息自动顺延到第二天或者直接丢弃。事务类消息不算在内，比如订单确认、密码重置，这些是用户主动触发的，不在限制范围里。

勿扰时段也要定。晚上十点到早上八点不要发运营消息，这是底线。更进一步，可以让用户自己定勿扰时段，或者按用户所在的时区自动避开深夜。发消息的时间要按用户的本地时间算，不要按服务器时间算，半夜三点收到推广消息的用户，第二天早上第一件事就是退订。

退订和偏好设置是分群系统的安全阀。用户要能一键退订某一类消息，而不是只能全部退订或者干脆卸载。退订之后要立刻生效，不要再发“最后一封确认邮件”去骚扰已经退订的人。偏好设置越细，用户越不容易一键全退：他可以关掉活动通知、留着产品更新，这对你我都好。

效果怎么衡量：没有对照组，就不要谈效果

分群上线之后，最常见的问题是：怎么知道它有没有用？运营人员凭感觉说“这次活动效果不错”，其实可能只是赶上了周末、赶上了发薪日、赶上了竞品出问题。没有对照组，所有的“效果不错”都只是猜测。

正确的做法是每一次触达都留一个对照组：同一群人里随机抽 5% 到 10% 不发消息，看看他们和收到消息的人有什么差别。打开率、点击率、转化率、留存率，四个指标一起看。只看打开率会骗自己：标题党能骗开信，但骗不来转化。只看转化率也不够：一次活动带来了转化，却把留存打掉了，长期看是亏的。

对照组的比例要按群的大小来定。群里有十万人，留 5% 做对照组足够了；群里只有五百人，留 10% 也就是五十个人，统计上基本没有意义。小群的衡量办法是拉长时间看趋势，而不是盯着一次活动的数字。小群更应该关注定性反馈：收到消息的人有没有投诉、有没有回复、有没有在群里说这条消息正好是他需要的。

还有一个归因陷阱要避开：不要把所有增长都算在分群头上。用户本来就会自然回流、自然付费，分群的功劳只是“比不分群多出来的那一部分”。对照组存在的意义，就是帮你把“自然发生的”和“分群带来的”分开。没有对照组，你会越算越乐观，最后得出“分群带来了百分之百的增长”这种自己都不信的结论。

衡量结果要反哺规则。某个群的打开率连续三次低于平均水平，说明这个群的划分可能有问题，或者这个群收到的消息不对路。某个群的退订率突然上升，说明触达频率或者内容出了问题。分群不是做完就扔在一边的东西，它需要每个月复盘一次：哪些群还在用、哪些群已经没人用了、哪些群需要合并、哪些群需要拆细。

隐私与合规底线：分群不是监视

分群做到一定程度，一定会碰到隐私问题。因为分群的本质就是“根据用户的行为把他们归类”，而归类这件事本身就可能让用户不舒服。底线要提前定好，不要等到用户投诉或者监管找上门才想起来。

第一条底线是最小收集。只收集分群真正需要的数据，不要因为“以后可能有用”就全量收集。地理位置精确到城市就够了，不要精确到街道；行为数据记“用过哪个功能”就够了，不要记每一次点击的坐标。数据收集得越少，出问题的时候影响越小。

第二条底线是敏感属性不要碰。种族、宗教、政治观点、健康状况、性取向，这些属性不要用来分群，哪怕技术上很容易做到。不是因为法律条文怎么写的，而是因为一旦用户发现你按这些属性给他们分组，信任就彻底没了。有些线不是不能碰，是碰了就回不来了。

第三条底线是透明。用户应该能看到你把他分到了哪一群、为什么分到这一群，并且能改。最起码，用户要能在设置里看到“你收到这条消息，是因为你最近七天没有打开应用”这样的解释。解释不清的分群，就是黑箱，黑箱迟早会被当成监视。

第四条底线是删除要彻底。用户注销账号或者要求删除数据的时候，分群结果、行为记录、打分模型里的输入，都要一起删掉，不能只删账号、留着画像继续用。删除的范围要写进隐私政策，执行的过程要有记录。

给 vibe coding 的建议：这个功能怎么做才不翻车

分群是个很适合 vibe coding 的功能，因为规则清晰、验收明确，AI 写起来不容易跑偏。但有几个地方，AI 特别容易给你挖坑，需要你亲自把关。

第一个坑是 AI 喜欢把分群做成“用户画像大屏”。你跟它说“做个用户分群”，它可能给你做一堆标签、一堆图表、一个花里胡哨的画像页面，但发消息的时候还是只能全量发送。你必须在需求里写死：分群的验收标准是“能按群发消息”，不是“能看到画像”。先做发送能力，再做展示。

第二个坑是 AI 写的规则经常没有互斥和优先级。规则一条一条单独看都对，合起来就打架。需求里要写明：规则要有优先级、互斥关系要写进引擎、一个人同时命中多条规则时只执行最高优先级的那一条。验收的时候专门造几个“同时命中多条规则”的测试用户，看看系统到底发了哪一条。

第三个坑是 AI 容易忽略频次上限。规则引擎写完了，发送逻辑写完了，但没有任何地方限制一个人一天能收到几条消息。等用户投诉了才发现，补起来要改好几个地方。需求里要把频次上限写在最前面：每天两条、每周五条、超过自动顺延。

我的建议是：把分群拆成三个验收里程碑。第一个里程碑是“能按规则分出五群人、能按群发消息”，先把主流程跑通。第二个里程碑是“规则有优先级和互斥、有预览、有版本记录”，把规则引擎做扎实。第三个里程碑才是“对照组、效果衡量、频次上限、偏好设置”，把运营闭环补齐。不要一口气全做完，第一个里程碑上线跑一个月，看看运营是不是真的在用，再往下做。

上线检查清单

最后是一份可以直接拿去打勾的清单。上线之前逐项确认，缺哪项补哪项，不要凭感觉上线。

第一，分群按行为划分，不是按人口属性贴标签，最基础的五群人已经分出来。第二，每一个群都对应一个不同的运营动作，没有“分出来却不知道干什么用”的群。第三，分群规则每天重算，用户在群与群之间能自然流动。第四，规则有优先级，互斥关系写进引擎，一个人同时命中多条规则时只执行最高优先级的一条。第五，规则修改有版本记录，能一键回滚。第六，规则发布前能预览命中人数和样本，命中人数异常时有提醒。第七，每人每天最多两条运营消息、每周最多五条，超过自动顺延，事务类消息不计入。第八，晚上十点到早上八点不发运营消息，发送时间按用户本地时区算。第九，用户能一键退订某一类消息，退订立刻生效。第十，每一次触达都留了 5% 到 10% 的对照组，打开率、点击率、转化率、留存率四个指标一起看。第十一，敏感属性不用来分群，只收集分群真正需要的数据。第十二，用户能看到自己为什么收到某条消息，注销时分群结果和行为记录一起删除。第十三，每月复盘一次分群效果：哪些群还在用、哪些群要合并、哪些群要拆细。

十三项看着多，但每一项背后都至少对应一个真实踩过的坑。分群这个功能，用户平时感觉不到它的存在，只有在收到一条“正好是我需要的”消息时，才会觉得这个产品懂他。把分群做扎实，就是在用户还没开口之前，先一步理解他。