RFM高价值人群怎么筛?分层阈值的三个判断维度

作者:456数据 发布:2026-09-30 16:27 浏览量:0 来源:原创

咨询现场最常被问的一句话是:“到底谁算我们的高价值用户?”有人主张按累计消费排,把花钱最多的那批挑出来;有人反驳说那些人只买过一次早就走了;还有人坚持看复购,天天回来的才是自己人。三方各执一词,吵到最后往往靠老板拍板。吵成这样不奇怪——“高价值”这三个字从来不是单一维度,把它拆成能算的三件事,争论才会停。

一、先把“高价值”拆成三个可算的问题

RFM 不是什么高深模型,它就是把“高价值”拆成三个都能从订单里算出来的维度:

  • R(Recency,最近一次消费):上一次下单离今天过去了多少天,越近越好;
  • F(Frequency,消费频次):选定周期内这个人一共下过几单,越多越好;
  • M(Monetary,消费金额):同一个周期内累计花了多少钱,越多越好。

这三个维度回答三个不同问题,单看任何一个都会跑偏。R 回答“他还会不会再来”,F 回答“他有没有养成习惯”,M 回答“他到底值多少钱”。缺了任何一个,你看到的都只是一个侧面。把三个数都算出来之后,“高价值”才从一句主观评价,变成一组可以写进筛选框的硬条件。

没有尺子之前,几千个用户点看起来都差不多。

二、为什么不能只凭一个维度下结论

我在客户那边见过太多只看一个数就圈人的做法,结果几乎都踩了坑。把三种常见偏误摆在一起,原因就很清楚:

只看哪个维度会把谁误判成高价值漏掉了谁
只看 M 累计金额只买过一次大额、之后再没出现的人那些客单不高但月月复购的常客
只看 F 消费频次天天领券、从不正价购买的薅羊毛党花得多但一年只买两三回的人
只看 R 最近消费被首单券吸引来、还没复购的新人曾经忠诚、最近暂时沉默的老客

单维度一定会失真,每个维度都能被“造假”:金额可以靠一次大单撑起来,频次可以靠补贴刷出来,最近可以靠一张首单券骗出来。只有三个条件同时成立,这个人才既近、又勤、又值钱,误判率才会降下来。

R/F/M 各按高低二分,2×2×2 组合出 8 类客户。

三、三个维度的高低线,应该怎么切

把人分到 8 个格子之前,得先给每个维度画一条“高 / 低”的线。常见做法不是拍一个绝对数,而是在你自己的用户群里排序后切分:

维度高 / 低怎么定为什么这么切
R 最近一次消费距今天数 ≤ N 天记为高N 参考你的复购周期,周期长的品类把线放宽
F 消费频次周期内次数 ≥ 中位数记为高中位数随大盘自动伸缩,比固定数字稳健
M 消费金额累计金额 ≥ 分位线记为高客单价差十倍的生意,不能共用一条金额线

这里强调“在自己用户群里切”:客单价 50 元和 500 元的生意,“高金额”的门槛天然不同;照抄别人的阈值,等于拿别人的尺子量自己的人,切出来的人群一定不准。切完之后,R 高、F 高、M 高这一格,就是通常说的重要价值客户。

举个落地的小例子。假设你有 1 万个成交用户,先按累计金额从高到低排,取前 30% 当 M 高;再按近半年下单次数排,同样取前 30% 当 F 高;最后把“最近一单在 30 天内”记为 R 高。三个分位线各自独立切,切完取交集,落进三高一格的人,往往只占全量的百分之十几——这恰恰说明高价值本来就是少数,若交集大到一半以上,多半是某条阈值切松了。

四、圈选高价值人群,具体怎么配条件

口径想清楚之后,落到工具里就是一组“且”关系的筛选条件。通用做法是把 R(Recency)、F(Frequency)、M(Monetary)三个维度分别打分切分位线,再把三个条件叠在一起圈人,依次加上三条规则,三条同时成立才被圈进人群包:

  1. 最近一次消费距今天数 ≤ 你定的天数(R 高);
  2. 统计周期内累计消费次数 ≥ 你定的次数(F 高);
  3. 统计周期内累计消费金额 ≥ 你定的金额(M 高)。

先把支付事件的口径对齐

在配条件之前,R、F、M 这三个数都得有干净的事件来源,否则圈出来的人本身就是错的。因为 R 和 F 都来自“支付成功”这一个事件,埋点时必须保证每一笔真实支付都能触发、且不重复计数;M 则直接取该事件里的成交金额字段。事件必须先核对干净——只要有一笔退款还记在金额里、或者一次支付被上报了两遍,F 和 M 就会同时虚高,圈出来的“高价值”自然掺水。如果你的成交发生在 App、小程序和 H5 多端,还要确认这些端上的支付事件都按同一个用户标识归并到了同一个人身上,否则同一个人会被拆成好几个小号分别计分。

这套分群不做兴趣标签

这里要把能力边界说清楚:这套分群只按 R、F、M 这三个数值条件去圈人;它目前不会自动给你生成“母婴爱好者”“追剧党”这类行业标签,也没有开箱即用的人群画像标签库,这类自动标签能力目前未实现。如果你需要兴趣类标签,得自己先把事件埋好、再按规则打,而不是指望系统替你猜。

R、F、M 三个条件取交集,圈出高价值人群包。(示意图,非产品实测)

五、人群包圈出来之后,怎么验收

先看规模,再抽样核对

条件配完先别直接拿去投,建议做两件低成本的核对。第一看规模:圈出来的人如果占了全量 80%,说明阈值太松;如果只剩 0.1%,又说明阈值太严,两种情况都会让人群包失去经营意义。第二抽样人工看:随机抽几十个人,对照他的 R、F、M 三个真实数字,看是不是真的近、真的勤、真的花得多。抽样这步不能省——分位线只要切偏一档,整个人群包的质量就会系统性偏移,而这种偏移靠看总数是看不出来的。

另外提醒一句,RFM 分出来的这 8 类,更像一张“现在站在哪”的快照,而不是一条自动流动的流水线。因为今天被划进“重要保持”的人,下个月可能复购一次就回到“重要价值”,也可能再沉默一个月滑向“重要挽留”,所以人群包建议按固定周期重新算一次、重新圈选,而不是圈完就永远不动;至于“自动根据生命周期把人从这格挪到那格”这类流转能力,目前并没有作为标准功能提供,需要自己按周期重跑分群。

三种圈人方式的差异

上面这套按 R、F、M 三个数值条件取交集圈人的做法,落到具体工具上通常有三条路:自己写 SQL 圈数仓、用网站或 App 自带的用户后台、用第三方用户分群平台。三条路在接入成本、去重口径、跨端统一、实时性和维护成本上的差别,大致如下表。

对比维度自建埋点/代码方案网站/App原生后台第三方分群平台
接入成本订单流水自己进数仓,R/F/M 按客户 ID 汇总的 SQL 手写,周期以周计后台默认按累计消费排榜,零接入,但只给金额单维,算不出 R/F/M 三维交叉嵌入 SDK 后按数值条件筛人即可,能否按客户 ID 一次聚合出 R/F/M 三维再分层,以后台字段与运算为准
去重口径自己定义 customer_id,同一人多端下单若没归并,R/F/M 会被拆到几个小号上分别计分通常只给注册或付费名单,不按客户 ID 把 R、F、M 聚到同一个人头上按客户 ID 聚合 R/F/M 三个指标再分层,同一个人在三个维度上被归到一起而不是被拆开,是否内置以此为准
跨端统一要自己做多端 ID 映射,工作量集中在这网站和 App 后台各自独立,消费数据不通同一用户标识归并,多端支付事件进同一份分群
实时性R/F/M 重算绑在数仓调度上原生后台多为 T+1 或按月出报表分群结果的刷新频率、阈值调整后能否当天重算,需以产品后台实际能力为准
维护成本退款冲销、金额口径、分位线重算都要自己盯基本不用管,R/F/M 三维切分线却动不了平台跟着版本走,自己只维护 R/F/M 的分位线和统计周期

常见追问

Q:RFM三个维度怎么定阈值?

A:没有通用阈值。我通常的做法是按业务目标分位数来切,比如R值取最近30天有行为的用户,F值取月均行为次数前20%,M值取客单价前20%。具体数值要根据自己的用户分布调。

Q:RFM适合所有业务吗?

A:电商和订阅制业务比较适合,因为有明确的消费和复购。内容类和工具类业务需要把M(消费金额)替换成使用深度或功能依赖度,不能生搬硬套。

Q:高价值人群多久更新一次?

A:取决于你的业务节奏。电商类建议按月更新,因为消费周期短;企业服务类可以按季度更新,因为客户关系变化慢。更新频率太高会导致人群不稳定,太低会错过流失信号。

为什么选用456数据

RFM 三个维度切完人群,挑工具时看的就是能不能直接出分层:先按累计金额、下单频次、最近一次消费各自切分位线,再把三条“且”条件叠在一起取交集,最后抽样核对人群规模。这几步对应的通用做法是按数值条件自由组合取交集、查看人群包规模、以及按同一时点快照圈人;平台是否已内置 R/F/M 三条件自由组合、人群包规模实时查看与按日刷新,具体字段与运算需以产品后台或官方文档确认为准,不建议默认当作开箱即用的现成 RFM 工作流。其中 App 与小程序的事件上报属于基础版起开放的能力,用户画像与分群属于专业版起开放;网站分析本身有免费版可用。如果你团队已经在用自建数仓方案,对比上面这张表的五项差异再决定;原生后台的累计付费名单够用的话,也没有必要额外换工具。

你们定“高价值”门槛时,是拍脑袋定的一个数,还是按历史分位数切的?有没有被一个只买过一次大单的“假高价值”坑过?欢迎在评论区聊聊,也说说你们现在 R、F、M 三条线分别卡在哪。

相关阅读

周报周期和默认筛选怎么固定?看板配置的三步法_缩略图 周报周期和默认筛选怎么固定?看板配置的三步法 我做管理这些年,周一晨会的第一件事就是翻上周报表。这份报表跟着我搬过三次工位,口径也变过好几轮:最早是安排实习生手工拼Excel,后来换成在线表格共享,再后来才有了固定看板。回头看,晨会报表最大的成本不是做表,而是每周都在对口径。这篇文章把我踩过的坑归纳成三件要固定的事:统计周期、默认筛选、口径备注。这类固化思路,在多数看板工具里都是按“周期—筛选—备注”三段来组织的。周报口径演变时间线——从手工导表对口径,到共享表格忘切筛选,再到固定看板。一、一条口径混乱的时间线第一个阶段,大概十年前:每周五下午安排一个实习生,从各个后台系统分别导出CSV,再手工粘贴到固定Excel模板里,周一晨会前一晚才... 09 / 30·阅读 0 A/B测试主指标和观察窗口怎么定?四个设定前提_缩略图 A/B测试主指标和观察窗口怎么定?四个设定前提 带学员做实验设计练习时,我最常看到的一幕是:实验已经建好、一半流量也切出去了,团队却还在争论“到底看哪个数”。有人看点击率,有人看成交额,过两天又有人提出应该看次日留存,谁也说服不了谁。之所以会出现这种局面,是因为主指标、护栏指标和观察窗口这三件事没有在分流之前写清楚。这篇文章只解决一个问题:开实验之前,这三件事各自该怎么定。假设、主指标、护栏指标、观察窗口四栏都还是空白待填。一、为什么这三件事必须在开跑之前定实验一旦开始分流,用户就被随机分进对照组和实验组。这时候才回头挑指标,等于在同一批已产生的数据里挑一个“看起来赢了”的方向下结论,事后挑指标会让结论失去统计意义。判据必须先于数据存在:先... 09 / 30·阅读 0 资源失败率没涨但加载变慢?Resource Timing定位方法_缩略图 资源失败率没涨但加载变慢?Resource Timing定位方法 上周有个做电商的朋友约我喝咖啡,坐下没两句他就皱着眉问:“我们监控里资源失败率一直平着,一个告警都没报,可老板最近总说页面越来越慢,这到底是哪儿出了问题?”我反问他一句:你盯的是失败率,那你看过耗时趋势吗?他愣了一下——显然没有。这其实是个特别典型的错位。失败率和加载耗时,本来就是两件不相干的事:失败率统计“加载失败”的资源占比,耗时统计“加载成功、但花了多久”。一个资源每次都加载成功,只是从1秒慢慢变成3秒,失败率纹丝不动,用户却实实在在觉得页面变卡了。“监控没叫、老板却在叫”,往往是因为团队的告警只盯着失败率,没有人持续盯耗时趋势。一、失败率和耗时,为什么会错位我给他画了张图:左边是四周资... 09 / 30·阅读 0 只有特定浏览器报JS错误?按版本下钻的排查路径_缩略图 只有特定浏览器报JS错误?按版本下钻的排查路径 周一早上九点十五分,我刚倒上咖啡,告警群就先炸了:JS错误量在过去四十分钟里翻了三倍。值班群里有人甩来一张监控曲线——报错像被人从底下顶了一下。但奇怪的是,客服侧的用户投诉并没同步上涨,产品同学也说核心下单链路看上去正常。这种“监控在叫、用户没叫”的错位,是前端工程师最熟悉的一种早晨。我通常不会这时立刻打开编辑器翻代码。“报错量整体飙升”和“某一类用户在某一类页面集中报错”是两件事:前者往往是一次发布引入的全站问题,后者更可能是某个浏览器版本的兼容问题。方向不同,排查路径完全不同。所以正确的第一步,不是去找代码,而是先把范围缩小。一、先分清这是“面”还是“点”面对一条突然抬头的报错曲线,先问两... 09 / 30·阅读 0 标签重叠严重?互斥人群分群的三条规则_缩略图 标签重叠严重?互斥人群分群的三条规则 上周连着开了三个会:市场部要一个“潜客人群包”,运营部要一个“活跃用户包”,销售部要一个“高意向客户包”。三个包都从我这出,听起来不复杂。可等三个包的人数摆到一张表上,问题就来了——加起来8.2万人,我拿去重,真实去重后只有5.1万。也就是说,有3万多人同时躺在两三个包里,被三个部门反复触达,预算也被重复算了一遍。之所以会变成这样,不是哪个同事圈错了,而是从头到尾没人规定过“同一个人到底算谁的”。更直接的后果是,同一个客户一天能收到三条不同部门的推送,体验差到直接取关。一、重叠是怎么自然发生的把三个包的条件摊开看就明白原因了。市场圈“近30天访问过官网”,运营圈“近7天打开过App”,销售圈“... 09 / 30·阅读 0