news 2026/10/5 11:44:12

RFM客户分层模型从原理到SQL实操:用数据分析优化用户运营策略

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
RFM客户分层模型从原理到SQL实操:用数据分析优化用户运营策略

做用户运营这些年,我最大的一个体会就是:80%的团队在做客户分层时,用的还是“按消费金额排序,取前20%”这种粗暴打法。结果就是运营资源投给了一批高客单但已经流失的“僵尸大户”,真正的绩优股反而被晾在一边。大概两年前我开始系统地去啃CDA数据分析师那套体系,其中一个对我工作改变最大的东西,就是RFM模型。今天把这套方法从头到尾拆一遍,包括底层逻辑、SQL计算实操、踩坑记录和进阶玩法。这篇文章适合正在做用户运营、CRM数据分析,或者想转行做数据分析师的朋友,尤其是那些手头有用户消费数据但不知道怎么用起来的人。

RFM模型不是一个新概念,但真正用得好的团队确实不多。它不是简单地给客户打个分,而是通过三个最核心的行为维度,把客户价值这件事还原成可视化的结构,再反向指导运营动作。下面我尽量用做项目复盘的口吻,把整个从搭建模型到落地应用的过程说透。

1. 为什么客户分层必须看RFM,而不是只看消费金额

很多老板和管理者最关心的问题就是:谁是我最值钱的客户?大部分人会直接拉一张消费总金额的TOP100榜单,然后告诉运营“重点维护这些人”。这套逻辑在客户量小的时候勉强能用,但一旦你的客户池超过几万甚至几十万,只看金额一定会出事。

1.1 消费金额高的客户不一定是高价值客户

举个例子。你有一个客户A,一年前在某品牌买了一套上万元的高端厨电,之后再没来过;另一个客户B,过去三个月里每个月都来买一些几百块的耗材。从单一金额看,A的贡献远高于B,但如果你是这家店的运营,你会把下个月的优惠券重点发给谁?答案显然是B。A已经处于沉默状态,大概率连你的短信都不点开,发再大的优惠券也是打水漂。B则处于活跃期,推荐新品、引导升级套餐,转化率都会明显高很多。

RFM模型在这里的价值,就是把“价值”这件事拆成了三个可独立衡量的角度:

  • R(Recency,最近一次消费时间):衡量客户离现在有多久没买了。这个指标直接反应客户的“温度”——越近越热,越远越冷。
  • F(Frequency,消费频率):在一定周期内买了多少次。频率代表客户的“粘性”——买得越频繁,习惯越固定。
  • M(Monetary,消费金额):在一定周期内累计花了多少钱。金额代表客户的“钱包份额”。

三者组合起来,就能避免“只看金额”这个单视角带来的盲区。A客户是“高M低R”,B客户是“中M高R高F”,他们的运营策略完全不同。R、F、M不是三个并列指标,而是三条互相补充的线索,组合起来才能画出一张完整的客户价值画像。

1.2 经典8类客户分层:一张表看懂逻辑

RFM最常用的是二分法:每个维度按中位数或阈值分成“高/低”两类,理论上三三组合能得到8种客户类型。业内习惯把这8类客户命名为:重要价值客户、重要发展客户、重要保持客户、重要挽留客户、一般价值客户、一般发展客户、一般保持客户、一般挽留客户。

为了让你快速建立直觉,我把8类客户的特征和策略整理成一张表:

客户类型RFM核心特征建议运营动作
重要价值客户高高高又在买、又常买、又买得多重点维护,VIP专属权益,优先体验新品
重要发展客户高低高最近买了大单,但频率不高追加热销关联品,办会员/储值提升复购
重要保持客户低高高曾经买得多,但有一阵没来了召回为主,用专属优惠/服务通知激活
重要挽留客户低低高历史贡献大,已沉默大力度召回,电话回访,找流失原因
一般价值客户高高低常买但每次花得少做交叉销售,关联高毛利品
一般发展客户高低低新客或边缘客培养习惯,发新人礼包,引导二次购
一般保持客户低高低频率还行但金额低,已趋冷用日常促销提醒唤醒
一般挽留客户低低低几乎流失、没什么贡献低成本触达,不行就放弃或养着

这张表最大的价值在于让运营能够有的放矢。以前做活动是全量群发,现在你能针对“重要保持客户”定向设计一套“回来就送专属券”的方案,转化率和ROI完全不是一个量级。

1.3 很多资料没讲透的口径问题

第一次落地RFM时,最容易翻车的地方不是模型本身,而是指标口径。R、F、M看起来定义简单,实际一算全是坑。

先说R。R最常见的定义是“截至计算日,客户最近一次下单时间与计算日之间的天数”。但下单时间到底取哪天?是支付时间还是订单创建时间?我的建议是取支付成功时间,因为创建订单之后可以取消、可以赖账,只有支付成功才代表真实交易发生。另外还要注意,在退款场景下,如果客户最近一笔订单支付后又退款了,那这笔订单是否还算数?我的口径是剔除退款订单后再取最近的支付时间,因为客户实际没有留下真实消费。

再说F。F最朴素的定义是“统计周期内购买次数”。但算次数时按订单数还是按购买天数?一个客户一天下5单,账面上是5次,但本质上就是同一天的需求。我更倾向于使用“有效购买天数”作为F,这样更贴近真实粘性,尤其是做电商的,一个促销日里用户拆单太常见了。

最后说M。M最常用的定义是“统计周期内实际支付金额”。这里有两个细节需要注意:一是是否扣减退款,我建议使用净实付金额(累计支付金额减去累计退款金额),否则刷单用户会把模型带偏;二是是否要剔除运费。我一般建议区分业务场景,如果客单价本身包含运费,就不用剔除;如果运费是单独收的,剔除后更公平。

2. 从订单表到RFM评分:SQL和Excel都能跑通的3步流程

明确口径之后,接下来的实操流程就清晰了。这里我给出一个可以直接抄作业的流程,核心是从订单明细表产出每个客户的R、F、M原始值,再做评分和分层。整个过程分三步:定窗口、算指标、打评分。

2.1 确定数据窗口和客户范围,别一上来就梭哈全量表

在动手算之前,先回答三个问题:

  • 统计周期取多久?我一般取近12个月。太短像季度,数据的季节性波动会让结果失真;太长则早期行为对当下的指导意义已经很弱。如果你做的是高客单低频生意(比如装修、婚庆),周期可以放宽到24个月;如果是快消高频生意(奶茶、便利店),12个月甚至6个月就够。
  • 客户范围怎么定义?是否包含只注册未购买的用户?我的建议是:RFM只对“有过至少一次成功交易”的用户进行计算。未成交用户单独放一个“潜在客户”池,不参与打分。另外要排除B端、内部测试账号、明显异常的刷单号。
  • 金额口径怎么统一?用实付金额还是毛利?在客户价值评估这个场景,我推荐用实付金额。因为毛利需要关联成本表,跨部门取数容易扯皮,而且客户分层不需要那么精细化;等做完RFM,再对头部的“重要价值客户”做毛利分析也不迟。

这三个问题不先定下来,后面所有SQL和评分全都会白搭。举一个真实案例:某团队统计F时把“申请退款但尚未处理完成”的订单也算进去了,结果给一个已经流失用户打了“高频率”标签,运营还专门给他发了一堆优惠券,一周后发现此人已退款,亏了两次。这就是口径不清导致的连锁问题。

2.2 用SQL计算每个客户的R、F、M原始值

假设你有一张订单明细表,字段大致如下:

  • customer_id:客户ID
  • pay_time:支付时间
  • order_no:订单号
  • pay_amount:实付金额
  • refund_time:退款时间(未退款则为NULL)
  • status:订单状态(success/cancel/refund)

第一步先生成“有效订单”子集:排除取消订单、排除退款订单、排除账号状态异常的单子。

WITH valid_orders AS ( SELECT customer_id, DATE(pay_time) AS pay_date, pay_amount FROM order_table WHERE status = 'success' AND refund_time IS NULL AND pay_time >= DATE_SUB(CURRENT_DATE(), INTERVAL 12 MONTH) )

第二步聚合出每个客户的R、F、M原始值:

SELECT customer_id, DATEDIFF(CURRENT_DATE(), MAX(pay_date)) AS recency_days, COUNT(DISTINCT pay_date) AS frequency_days, SUM(pay_amount) AS monetary_value FROM valid_orders GROUP BY customer_id

这段SQL的核心逻辑有三点:

  • MAX(pay_date)取最近一次支付日期,用DATEDIFF换算成天数,就是R值,越小代表越近。
  • COUNT(DISTINCT pay_date)计算有效购买天数,这里刻意去重,防止一天多个订单刷高F。
  • SUM(pay_amount)计算累计净支付金额,就是M值。

如果你用的是Excel,同样可以在PQ里做分组:去重订单、清洗退款、按客户ID分组汇总、用MAX日期和透视表计算R/F/M。逻辑完全一样,只是工具不同。Python的话,一条groupby加agg就能处理,不展开写了。

2.3 评分规则怎么定?五等分法比简单二分法好使

得到原始值之后,还需要把R、F、M转化为可比较的分数。这步处理得好不好,直接影响后面分层的稳定性。

我推荐使用五分位评分法。也就是说,把每个指标从低到高切成5个档位,打分为1到5分。注意一个方向性细节:R值(天数)是越小越好,所以实际打分是反着的——R越小,得分越高。F和M则是值越大得分越高。

以SQL为例,可以通过窗口函数PERCENT_RANK()计算百分位排名,再用CASE WHEN落到对应的档位:

WITH rfm_raw AS ( -- 上一段的R/F/M计算结果 ), rfm_score AS ( SELECT customer_id, recency_days, frequency_days, monetary_value, CASE WHEN PERCENT_RANK() OVER (ORDER BY recency_days) <= 0.2 THEN 5 WHEN PERCENT_RANK() OVER (ORDER BY recency_days) <= 0.4 THEN 4 WHEN PERCENT_RANK() OVER (ORDER BY recency_days) <= 0.6 THEN 3 WHEN PERCENT_RANK() OVER (ORDER BY recency_days) <= 0.8 THEN 2 ELSE 1 END AS r_score, CASE WHEN PERCENT_RANK() OVER (ORDER BY frequency_days) <= 0.2 THEN 1 WHEN PERCENT_RANK() OVER (ORDER BY frequency_days) <= 0.4 THEN 2 WHEN PERCENT_RANK() OVER (ORDER BY frequency_days) <= 0.6 THEN 3 WHEN PERCENT_RANK() OVER (ORDER BY frequency_days) <= 0.8 THEN 4 ELSE 5 END AS f_score, CASE WHEN PERCENT_RANK() OVER (ORDER BY monetary_value) <= 0.2 THEN 1 WHEN PERCENT_RANK() OVER (ORDER BY monetary_value) <= 0.4 THEN 2 WHEN PERCENT_RANK() OVER (ORDER BY monetary_value) <= 0.6 THEN 3 WHEN PERCENT_RANK() OVER (ORDER BY monetary_value) <= 0.8 THEN 4 ELSE 5 END AS m_score FROM rfm_raw )

这里最关键的决策点是分位数的选择。五分位法比二分法更适合国内零售业务,因为二分法会把约一半人分到“高M”组,完全失去了区分度;五分位则能把真正的头部20%单独圈出来。当然,如果你客户池很小(比如只有几千),五等分会很稀疏,退回到三分位或者结合业务阈值也可以。

还有一种做法是“业务阈值法”,比如M值超过1万算5分、5000-1万算4分,R值7天内算5分、8-15天算4分。这种方法的优势是可解释性强、但阈值需要业务部门反复确认,而且业务一变阈值就得改。没有绝对优劣,但我自己更喜欢五分位,因为它是数据驱动的,不需要拍脑袋。

分打好之后可以做加权综合分:综合分 = 0.3*R + 0.2*F + 0.5*M。但要注意,加权综合分只能用来做客户排名,不能用来定义“高/低”。真要分8类客户,还是用R/F/M各自的高/低阈值来做交叉,而不是综合分一刀切。

3. 分层后的运营策略:不同客户不同打法

模型算完、分打完,这只是第一步。RFM项目的成败,其实取决于分层结果能不能被运营团队真正用起来。如果你把8类客户名单发给运营,对方只回一句“然后呢”,那说明策略没有跟上。下面我拆解几种典型客户群的具体打法,都是验证过效率比较高的思路。

3.1 重要价值客户(R高F高M高):维护比促单更重要

这类客户是金字塔尖,通常在整体客群中只占5%-10%,但贡献了30%-50%的收入。针对他们,我建议运营上做“特权感”而不是“多卖货”。典型动作包括:定向的VIP专属客服、新品优先体验、生日礼物、线下活动邀请等。核心目标不是让他们多买一单,而是延长生命周期、提升忠诚度。

这里有一个反向教训。某美妆品牌曾给这批客户发了一张某品类“满199减100”的大额券,结果转化率反而不如普通客户高。原因是这类客户买的是高端线,凑单阈值和他们的消费习惯根本不匹配,大额券在他们眼里反而显得品牌掉价。所以对重要价值客户,少打扰、多给权益,比垂涎他们的钱包更有用。

3.2 重要保持/挽留客户(R低、F/M高):召回要分节奏做

这两个群体是典型的“沉默的金矿”。他们的共同特征是历史贡献很大,但已经有一段时间没有光顾了。区别在于:重要保持客户是近期刚刚沉默(R处于中低),还有机会尽快拉回;重要挽留客户则已经沉默了较长时间,需要更大力度的刺激。

实操中,我见过最高效的召回方式是“首次触达用服务属性内容,二次触达用利益点”。第一波先给一条关怀信息,比如“您购买的某产品有新版固件/服务升级了”或者“您账户中有积分即将到期”,目的是唤起记忆,不产生压迫感。如果两三天内没有回应,再发一个有明确时间窗口的专属召回券,比如“7日内有效、满500减80”,制造稀缺感。如果这波还没反应,基本可以判断当前周期内流失已成定局,强行召回的成本可能会大于客户未来带来的收益。

3.3 一般发展客户(R高F低M低):新客养成,先追频次

这类客户的“最近消费时间”很近,但频次和金额都低,本质上是还没有形成购买习惯的新客户。从运营角度讲,他们是“最容易培养成中长期客户”的群体,因为温度还热着,关键是趁热打铁。

我的建议是,在一个月内做三次触达,形成“记忆点”:第一次是购买后第7-10天的回访,附带一个“新人专享复购券”;第二次是第20天左右,推送一个关联品类或者更高客单价的新品,试探其消费升级意愿;第三次是第30天左右,做一次权益提醒,比如“您还有一张券即将过期”。这三次触达的目标不是单笔转化,而是让用户记住你,习惯在你的平台上消费。

3.4 用分层结果做营销效果对比:一个实际案例

2023年我给一家零售客户做会员运营项目时,把全量客户跑完RFM之后,匹配了一次“春季大促”活动的结果。当时运营原本准备全量群发5元无门槛券,预算约15万元。我建议改成:重要价值客户不发现金券而是发双倍积分权益,重要保持客户发满减券,一般发展客户发新人礼包券。同样的预算,裂变控制在8万元以内,并且通过对比发现:定向分层的转化率是之前盲目全量群发的2.3倍,单客ROI提升了近1倍。最直观的说服力就在这个数字上。

4. 实操中避坑指南:这些坑我全都踩过

RFM模型本身不复杂,但实操过程中有大量细节会让你的结果“看上去没毛病、用起来全是病”。下面几条坑,我基本都真金白银地踩过一遍。

4.1 异常值处理:大单客户会把M评分打偏

零售数据里总有极端值。比如一个客户买了100台设备用于公司内部采购,虽然在订单明细里是真实成交,但如果你用这个数据来定义所有客户“高金额”的阈值,会造成一大批普通高价值客户的M评分被压缩到1-2分。处理方式有两种:

  • 缩尾法:把M值超过95%分位的金额强制拉低到95%分位对应的数值,保留排名信息但消除极端影响;这是我在常规项目中比较喜欢的方式,操作成本低。
  • 对数变换:对M值取对数后再做五等分,压缩长尾数据的差值范围。缺点是业务方解释起来有门槛,比如“M值对数6.8分”没法直接给运营团队讲。

另外,一定要把刷单和内部采购单独打标签剔除。团队里有一个口径是“单笔金额超过正常客单价30倍且收货地址为公司地址”的订单全部不提。这个规则先和业务确认,再落到取数SQL里。

4.2 不同品类客户放一起算,会得出荒唐结论

如果你的业务横跨多个品类,比如一个平台既卖9.9元的数据线,又卖上万元的电脑,那么把两个品类的客户放在同一个模型里算M评分,实际上是对高客单品类客户严重有利、低客单品类的客户全部被压到低分区。最后你可能得出“卖数据线的客户全是低价值客”的错误结论,但这个结论是完全被商品结构扭曲出来的。

解决思路有两种。一是分业务线建模:数据线和电脑各自跑一套RFM;二是引入相对M:如果一定要放到同一个模型,先把每个客户的消费金额除以该客户所属品类的平均客单价,得到一个标准化后的“相对钱包份额”再参与打分。实操中我更常做前者,因为不同业务线连运营团队都是分开的,分别建模更好落地。

4.3 数据口径变了,历史标签必须重建

RFM标签不是做一次就一劳永逸的。尤其是当底层数据仓库的字段逻辑发生变化时,比如取消订单从“物理删除”改成“状态标记”、退款流程从“立即退款”改成“T+1退款”,都会导致同一批客户的RFM值在重建日前后不可比。我的经验是:

  • 每一期RFM标签,必须在表里同时记录model_version和calc_date。
  • 发布到业务方之前,先抽30个客户人工校验,和运营同事共同确认是否有明显的逻辑错误。
  • 做月度趋势分析时,不要直接跨月对比标签,除非确认数据口径在这段时间内完全一致;否则你对比的可能是两套统计逻辑。

4.4 RFM的“8种客户”不是都要运营

最后是一个很容易踩的心态坑。很多同学刚学会RFM,就把8类客户每一个都制定一套运营策略,还搞出8条不同文案、8种不同券模板。结果运营根本没那么多精力和预算去执行,最后停留在PPT里。我给的建议是先做价值集中度分析:统计每一类客户的人数占比和营收占比,优先针对“人数占比不高、营收占比很高”的2-3个类型设计策略。剩下的先不动,等跑顺了再逐步扩展。

5. 进阶:RFM为什么不够用,以及我常做的改进

RFM模型很经典,但在今天的精细化运营要求下,它有几个天生的盲区。不是说要抛弃它,而是要在它之上再叠一层“增强滤镜”。

5.1 只描述历史,不预测未来

RFM的所有指标都是过去的交易行为的统计视图。它告诉你“谁过去有价值”,但没法直接告诉你“谁未来有价值”。比如一个刚注册的新客,本周买了一次,虽然RFM得分很低,但结合他访问频次、加购行为、活动点击等即时互动信号来看,他可能比一个“三个月前连续买了5次、但现在已冷却”的用户潜力更大。

我现在做增强版的做法是:在RFM的基础上,叠加一个“E(Engagement,互动度)”指标,比如最近30天的登录次数、浏览深度、加购次数、内容点击率。这就把「购后沉默但仍在浏览」的用户和「彻底流失不看一眼」的用户区分开了;前者在挽回优先级上更高,后者则可以进入低成本唤醒流程。

5.2 引入时间衰减,让F和M更敏感

传统RFM对F和M做的是简单累加,这意味着一个用户半年前买了5次和昨天买了5次,在这个模型中的F值完全一样。这其实不太合理——近期的行为应当比远期的行为更能反映用户当下的状态。

改进的方法是时间衰减加权:给每次交易按“距今的月数”赋一个权重,越近权重越高。例如权重可以设定为0.9^(距今天数/30),然后把每单金额乘上这个权重后再累加,得到的weighted_M会比原始M更灵敏地反映“当下的消费质量”。R本身已经天然包含“近与远”,不需要再做衰减,重点放在F和M上。

5.3 用LTV来给“重要价值客户”按优先级排座次

RFM能帮你圈出重要价值客户群体,但在这个群体内部,仍然有优先级差异。我通常会在分层完成之后,再计算一个简单的LTV预估:LTV = 平均客单价 x 年均购买频次 x 预估留存年数。然后用这个LTV在“重要价值客户”内部做二次排序,把最强的10%单独拎出来做“战略级客户”管理。这样比单纯看RFM综合分要更贴近业务逻辑。

最后再说一个我个人在实际执行中反复验证过的观点:RFM项目最大的失败风险不是计算复杂度,而是“只算不用”。模型跑出来了,报表发到群里,然后就没有然后了。所以我会在搭建模型的同时,就强拉着运营和CRM团队一起定义“分层之后的第一条动作”,哪怕是最简单的一组消息推送,也一定要落地。另一个小技巧是,每次分层完先抽三五十个客户人工核一遍再看细节,避免被个别脏数据带到沟里去。这套东西,确实是CDA体系里面偏“重”但很实用的一环,我自己是在做会员项目时把它彻底吃透的。希望这篇梳理能帮你少走一些弯路,把RFM真正用出效果来。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/5 11:44:09

Abaqus Point-Based螺栓建模:用点定义连接的高效范式

1. 项目概述&#xff1a;为什么“Point-Based”是螺栓建模的效率分水岭在Abaqus里做结构连接仿真&#xff0c;尤其是带大量螺栓的装配体&#xff0c;我踩过的坑比别人走过的路还多。十年前刚接手风电塔筒法兰连接项目时&#xff0c;光是手动创建240个M36螺栓的预紧力、接触对、…

作者头像 李华
网站建设 2026/10/5 11:39:24

YOLOV5+VOC 20类目标检测实战包:380MB含数据集、权重与训练日志

简介&#xff1a;本资源为基于YOLOV5的VOC目标检测实战项目&#xff0c;面向具备一定深度学习基础、希望快速上手目标检测训练与推理的开发者与学习者。项目覆盖火车、船、人、电视、飞机等20个类别的检测任务&#xff0c;提供可直接运行的代码、数据集与训练好的权重参数&…

作者头像 李华
网站建设 2026/10/5 11:37:19

OpenShell实战指南:高效定制Windows开始菜单与工具栏

1. 项目概述&#xff1a;OpenShell到底是个什么工具先说结论&#xff1a;OpenShell&#xff08;也就是很多人还习惯叫它 Classic Shell 的那个开源项目&#xff09;是一款专门用来自定义 Windows 开始菜单、资源管理器工具栏和任务栏行为的免费工具。我最早接触它是在 Windows …

作者头像 李华
网站建设 2026/10/5 11:36:43

变步长扰动观察法光伏MPPT仿真:原理、建模与参数整定实践

做光伏MPPT仿真&#xff0c;很多人第一次把扰动观察法&#xff08;P&O&#xff09;跑通时会松一口气——功率曲线终于爬到最大功率点附近了。我第一次跑通时&#xff0c;盯着示波器上的波形反而更焦虑&#xff1a;功率确实爬上去了&#xff0c;但在最大功率点附近来回跳&am…

作者头像 李华
网站建设 2026/10/5 11:35:57

Qwen-Image-2.1开源多模态模型实战指南

1. 这不是又一个“刷榜模型”&#xff0c;而是图像理解能力真正跃迁的开源信号最近在 Hugging Face 上刷到 Qwen-Image-2.1 的权重发布页&#xff0c;下载量曲线像坐了火箭——三天破万&#xff0c;评论区清一色是“实测比上一代快30%”“CLIP替换后workflow没崩”“AA-Image两…

作者头像 李华
网站建设 2026/10/5 11:35:34

SpringAI函数调用实战:原理、用法与避坑指南

SpringAI的项目&#xff0c;如果十一假期陪着点儿&#xff0c;多半绕不开FunctionCalling。这玩意儿翻译过来叫“函数调用”&#xff0c;也有些资料里写“工具调用”“Tool Calling”&#xff0c;不管叫什么&#xff0c;本质都是让大模型在你给的范围内&#xff0c;把“聊天能力…

作者头像 李华