个人理解中的RFM是为了研究用户（买家）的一个算法模型，身为产品从业者的我们都喜欢谈目标用户，而何谓目标用户，我们可以简单把他们归结为付费用户，也就是为我们产品带来收入的人群。而PM一项很重要的职能就是分析数据，根据单一用户的购物行为对其分析不仅要浪费大量的人力资源，浪费时间且不可行，而且若缺乏一套具体的算法模型也难以脱离个人主观性。而研究用户，洞察人性却又是PM的主要工作内容，在产品迭代过程中，通常需要根据用户的属性进行归类，也就是通过分析数据，对用户进行归类，以便于在推送及转化过程中获得更大的收益。了解用户的行为感受是必不可少的职责，而RFM就是一种了解付费用户结构的基本方法。由于该模型设计到具体算法，网上大多数文献说得都比较复杂分散，而且存在重大歧义，如RFM中R值的概念Josh Bycer认为R值越大用户回购率越高，而真实情况未必如此。本文档主要是为了归纳汇总RFM模型的概念以及适用场景，以尽量直白的方式呈现给读者。奈何才疏学浅，许多地方未必正确，不足之处望指导。

R-Recency（近期）-最后一次购买是多久以前；R值越大，表示客户交易发生的日期越久，反之则表示客户交易发生的日期越近。

F-Frequency（频率）-购买频率；F值越大，表示客户交易越频繁，反之则表示客户交易不够活跃。

M-Monetary（消费）-设定时间段内客户的总消费金额；M值越大，表示客户价值越高，反之则表示客户价值越低 。 这是衡量客户价值最重要的指标。

1.谁是我的重要价值客户，他们都有什么特点？

2.谁是我需要重点保持联系的客户，他们都有什么特点？

3.谁是我的重要发展客户，他们都有什么特点？

4.谁是我的重要挽留客户，他们都有什么特点？

根据三维图表，以RFM为XYZ轴，1代表高，0代表低

1.重要价值客户（111）：最近消费时间较短、消费频次和消费金额都较高。这是门店应该主要关注的VIP客户。

2.重要保持客户（011）：最近消费时间较长，消费频次和消费金额都较高。说明这是个一段时间没来的忠实客户，我们需要主动和他保持联系。

3.重要发展客户（101）：最近消费时间较短、消费金额高，但消费频次较低。忠诚度不高，很有潜力的用户，必须重点发展。

4.重要挽留客户（001）：最近消费时间较长、消费频次不高，但消费金额高的用户，可能是将要流失或者已经要流失的用户，应当吸引客户回流。

        RFM模型的最终目的是为了区别出有价值的用户在此基础上细分用户类型做到精准运营，实现效率最大化。RFM模型较为动态地显示了客户消费轮廓，这对个性化的沟通和服务提供了依据，根据用户群体、产品特性，产品的周期去改善三项指标的状况，从而为更多的营销决策提供支持。在RFM的分类基础上，去进行的基础维护运营，根据关键运营指标，选取重点需要优化的用户群体，进行差异化运营，从而刺激用户持续的消费、留存。RFM模型同时也能作为监控用户行为的有效工具，让管理者了解客户的行为从而反思现存的营销模式，为企业后续的发展方向做出战略性部署。

         RFM模型主要用于电商领域，但是我们也可以替换RFM相关的字段使其适用于互联网产品。作为CRM一个模块的RFM应用范围以及应用之广此处便不再展开。

【干货】电商归因模型技术方案

1)总体运营指标：从流量、订单、总体销售业绩、整体指标进行把控，起码对运营的电商平台有个大致了解，到底运营的怎么样，是亏是赚。

2)网站流量指标：即对访问你网站的访客进行分析，基于这些数据可以对网页进行改进，以及对访客的行为进行分析等等。

3)销售转化指标：分析从下单到支付整个过程的数据，帮助你提升商品转化率。也可以对一些频繁异常的数据展开分析。

4)客户价值指标：这里主要就是分析客户的价值，可以建立RFM价值模型，找出那些有价值的客户，精准营销等等。

5)商品类指标：主要分析商品的种类，那些商品卖得好，库存情况，以及可以建立关联模型，分析那些商品同时销售的几率比较高，而进行捆绑销售。

6)市场营销活动指标，主要监控某次活动给电商网站带来的效果，以及监控广告的投放指标。

7)风控类指标：分析卖家评论，以及投诉情况，发现问题，改正问题。

8)市场竞争指标：主要分析市场份额以及网站排名，进一步进行调整。

电商运营数据分析包括哪些内容？

作者介绍

@杭州阿坤

母婴电商行业数据分析师兼数据产品经理；

致力于研究电商行业的数据驱动增长，

以及数据产品从0到1的搭建；

“数据人创作者联盟”成员，“最佳创作奖”获得者。

01 电商归因目的

对于电商平台来说，当流量进入时，我们需要引导其完成购买任务，以实现流量价值最大化，在互联网红利消耗殆尽之时，流量会越来越贵，我们需要精细化运营每一份流量。

我们在做各种banner活动、Feed流推荐优化、活动页等进行效果评估，无法知道该位置最终产生了多少收益，也就很难针对该位置进行有效的改进。

如果进行单因数AB测试进行改版的效果评估，那也会存在如下2个问题：

单因素变量控制并不容易做到完全可控，如果产品处在增长期，产品增长本身就是一个影响因子，很容易忽略此类因素的影响。

评估方式低效，如果 2 天内只控制 1 个坑位变动，那么评估 20 个坑位内容改变就需要 40 天时间，这样的效率任何企业都无法接受。

因此，我们希望用数据分析中归因的方式解决坑位运营中评估的问题。

我们引入电商坑位归因的概念，把每一笔的成交都归给转化路径中不同的坑位。根据坑位的曝光转化价值来评判坑位的好与坏。把宝贵的流量尽可能都引导到转化率更高的坑位，以此达到精细化运营的效果。当然有了这个坑位价值评判的机制后各个坑位的改版也能准确的评估，真正做到了数据驱动增长。

02 归因类型简介

首次触点模型：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个「待归因事件」功劳为 100%。

末次触点归因：

多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为最后一个「待归因事件」功劳为 100%。

线性归因：

多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为每个「待归因事件」平均分配此次功劳。

位置归因：

多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个和最后一个「待归因事件」各占 40% 功劳，其余「待归因事件」平分剩余的 20% 功劳。

时间衰减归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为越靠近「目标转化事件」做出的贡献越大。

对于电商平台来说，末次触点归因是比较适合电商站内销售归因的。虽然用末次触点归因实现方案上比简单，但是直接将价值100%归因给购买或者转化之前最后一次接触的渠道，而完全不考虑整个过程中消费者到底接触过多少个触点。转化之前发生了太多的事情，该模型完全忽视了漏斗上层和中层部分的行为对转化的影响。

因此我们公司融合首次触点归因和末次触点归因，计算用户进入一级流量入口后再到完成的完整购物链接行为。一级流量流入的定义为：各个入口之间无法进行跳转，只能通过切换tab进行跳转或者返回初始位置后重新点击进入。这样我们就可以基于购物的完整链接的最外层进行销售归因，并且也能知道用户购物的完整路径，同时保证销售归因后各个入口坑位的销售额之和等于当日的销售额。

使用这种融合归因方式，也可能知道中间步骤的转化率。比如活动会场页和商品详情页的相关推荐，虽然对电商平台整体进行销售归因时，不会计算活动会场页各个模型的销售，也不会计算商品详情页的相关推荐。

但是由于我们记录了用户进入一级流量入口后的详细路径，因此我们单独研究活动会场页和商品详情页的效率时，也是可以计算得到各个模块的销售来进行对比分析。但是切记不能和一级流量入口的销售混合在一起看，这样会导致销售归因发生重复。

用户购物路径模拟图

03 电商归因实现方案

对于电商归因我们进行了三个方面的归因，包括：曝光归因、点击归因、销售归因。即归因出所有的商品曝光来自哪里，所有的商品点击来自哪里，所有的销售来自哪里。这样就可以追踪各个流量入口的曝光链路归因指标。比如各个流量入口的商品曝光点击率、商品点击支付率、商品曝光价值等等核心监控指标来评价各个流量入口的效率。

电商归因准确的前提是埋点日志的完整性，因为我们是通过需要归因的事件往前找到用户的购买路径，这样的好出是大大减少计算量，也基本解决的归因的问题。因此用户行为日志的完整记录才能真实还原用户的购买路径，否则就可能导致归因出错，最终造成错误的评价数据。

首先需要在埋点体系中引入PageId的概念，PageId的作用是每当用户产生一次跳转行为进入一个新页面时，为这个页面赋予一个新的PageId；而当用户点击返回时，不会产生新的PageId。PageId是越靠近的当前时间的页面浏览的行为越大，且不会重复，类似于自增ID的实现逻辑。PageId的实现当然是写入埋点SDK当中，这样保证所有的埋点事件都带上PageId，并且也无需开发同步每次单独写逻辑。

然后根据埋点日志去还原用户的行为路径，全程都可以仅仅使用SQL逻辑就能计算完成。

首先要确定所有要归因的end事件（末端事件），包括商品曝光、商品点击、商品加购成功（加购后可以通过server的订单表判断用户是否完成了付款，也达到了销售的归因目的）。

然后在确定所有归因head事件（首端事件），即之前就定义的好的各个一级流量入口。

我们平台比较特殊，是工具类App同时拥有电商业务，这样一级流量入口会比较多，但是可以枚举完成的，不仅仅包括常规电商App的流量入口，还可以在各个工具页面嵌入电商入口，这样复杂性要强于一般的电商App。

我们的埋点日志都会记录用户发生各个行为的本地时间，用end事件时间去找最接近的这个时间的head事件，直接用SQL的left jon关联日志表就能完成计算。

这样在首尾2段时间内的所有埋点日志行为就是我们需要日志。

然后筛选出这些日志中的所有点击事件，过滤掉其他无效事件。

再对所有剩下的日志进行排序，按照本地时间排序，这样就得到了一条完整的用户有效行为的路径记录。

对于这部分数据我们就可以进行存储使用了，这部分数据为归因后用户完整链路记录数据。

再基于PageId过滤掉同个页面相同PageId的事件，保留本地时间最晚的那一条事件记录。

这样就得到了用户进入一级流量入口后真正进行末端事件的有效路劲。

这部分数据也需要存储记录，并且这个部分真正归因完成的用户行为路径，此时的得到各个一级流量入口就行归因得到此末端事件的来源。

通过这样计算后就了解各个一级流量入口的商品曝光点击情况，也能知道销售情况。

利用这些数据就能衡量各个流量入口的效率情况，也同样也可以中间承载页面的效率如何。

就能帮助产品运营更好的改善各个功能以及迭代各式各样的活动。

用户进行一次加购的路径还原

通过上述方法的计算，我们最终得到的用户加过链路步骤为：【1，2，9，10，11】，并且入口事件【1】就此次加购事件的归因来源。

另外再来举个商品详情页相关推荐的例子，下图所示的用户行为最终得到的链路步骤为：【1，2，9，10，11，12】，由于我们是完整保留用户的路径，因此我也只能这次加购事件不仅来源于1，也有一部分功能功能来于11，也就是商品详情页的推荐，因此我们也能计算出商品详情页的推荐效率如何，后续算法团队迭代模型时也能根据这个数据来衡量优化的好与坏。

商品详情页之间的横跳类型用户路径

04 总结

通过以上方案得到电商归因模型数据，可以大大提高运营同学的运营效率，不再是盲人过河实的凭感觉去优化各个坑位和活动，已经可以通过数据清晰公平的判断运营每一次迭代的结果。

但是仅仅根据坑位归因决定坑位价值，容易出现短期偏见，即追求短期利益，比如在一款内容产品中镶嵌一些游戏元素，可以让用户停留更久、数据表现更好。但从长期来看，这种行为破坏了整个产品的价值定位，因为内容产品原本提供的是内容并不是游戏，产品也不并是为了追求用户停留时长而是为了实现价值。这是两者都存在的短期偏见。

因此不能仅仅根据坑位归因后的销售转化价值来评价坑位，还需要综合考虑产品价值定位、战略发展等因素，才能围绕长期目标进行健康发展。

运营指标与告警策略思考

构建电商数据分析的基本指标体系，主要分为8个类指标。

1.总体运营指标：从流量、订单、总体销售业绩、整体指标进行把控，起码对运营的电商平台有个大致了解，到底运营的怎么样，是亏是赚。

2.网站流量指标：即对访问你网站的访客进行分析，基于这些数据可以对网页进行改进，以及对访客的行为进行分析等等。

3.销售转化指标：分析从下单到支付整个过程的数据，帮助你提升商品转化率。也可以对一些频繁异常的数据展开分析。

4.客户价值指标：这里主要就是分析客户的价值，可以建立RFM价值模型，找出那些有价值的客户，精准营销等等。

5.商品类指标：主要分析商品的种类，那些商品卖得好，库存情况，以及可以建立关联模型，分析那些商品同时销售的几率比较高，而进行捆绑销售，有点像啤酒喝尿布的故事。

6.市场营销活动指标，主要监控某次活动给电商网站带来的效果，以及监控广告的投放指标。

7.风控类指标：分析卖家评论，以及投诉情况，发现问题，改正问题。

8.市场竞争指标：主要分析市场份额以及网站排名，进一步进行调整。

一、运营指标

用户指标数据 ，通过可以衡量用户体验的的核心行为表现数据指标来衡量效果

业务性能监控， 各API状态等后台不可见的算法流程和内容

举例：

新闻产品： 首页推荐结果的点击率、各类新闻的占比等（拟合推荐策略效果）

电商产品 ：单店日销售额、促销产品影响面（评估促销收益比）

云服务产品： 云服务可用率、云服务作业成功率

游戏产品： 业务规则监控（用户胜率、攻击频率上限）、系统可靠性监控

由于业务规则监控取决于业务方自己的业务属性较多，下文举例系统可靠性监控。

【1】请求数，请求到达速率

【2】正常响应数，正常响应占比

【3】错误响应数，错误响应占比

【4】响应延时

【5】消息队列长度，排队堆积时间、消息量

互联网系统根据计算机网络模型，可靠性监控可以分为下面4层。

【1】 应用层 ：用户访问的前端页面、后端接口请求

【2】 服务层 ：db，中间件等各种进程

【3】 硬件层 ：cpu，内存，磁盘，网络

可靠性监控思考：

【1】不应该用采集的难度决定你使用什么指标去告警。

例如：很多情况下cpu使用率可能是最好采集的，但是未必是最值得告警的。

【2】不要给运维他们想要的告警，而是要做“真正”想要的告警。

例如：运维告诉你它需要对db进程的cpu使用率超过x%的时候告警，它给你的是一个他认为最优的解决方案。但是他真正想要的是知道db服务是否有异常，cpu使用率超过x%未必是最好的告诉你服务是否出现异常的指标。

二、规则告警

告警规则 ：根据历史数据定义一个正常波动区间，超出波动区间就报警。

告警策略主要字段： 名称、资源类型、监控对象、告警级别、告警策略（根据资源类型展示不同的数据信息）、监控指标对象、告警指标间处理逻辑、触发条件、告警频率、状态、最近改变时间

吿警方式 ：

短信、电话 ：成本高，实时性好，到达率高

办公APP ：成本低，实时性中，到达率中

邮件 ：成本低，实时性差，到达率高

告警收敛：

【1】服务运营指标收敛 策略：按服务名、运营指标去重

【2】模块告警收敛 策略：按照集群名称做去重

【3】接口告警收敛 策略：按照接口名称做去重

【4】告警频率收敛 策略：按照M分钟N次限制告警

【5】不同时段区分告警 方式策略：工作日/非工作日，白天/夜晚区分

【6】逐层上报 告警策略：先模块负责人告警，n分钟未恢复升级，m分钟未恢复再升级

【7】黑白跳动 策略：当系统由正常变为异常，异常恢复正常都通报

是否告警：

曲线平滑 ：故障一般是对近期趋势的一个破坏，视觉上来说就是不平滑

绝对值的时间周期性 ：静态或者动态设置最近一段时间的最低值、最高值

波动的时间周期性 ：假设两个曲线不重合，在相同时间点的波动趋势和振幅也是类似的（即不同时间段的上、下限值的差是一致的）

波动回归正常值 ：当曲线开始回升到历史范围的时候，一般可以确认这个时间段是真的故障了。同时也可优统计误警率，漏警率。

告警自动消除：

告警的实质就是“ 把人当服务用 ”。在一些事情还没有办法做到程序化执行的时候，用告警通知人的方式去干预系统达到修正的目的。后续通过收集异常问题，并制定相应的自动化解决方案，实现告警的自动消除。

三、产品画像

产品画像，可以结合已有的运营指标、研发指标、部署指标、故障指标去实现云服务产品画像。

在选取指标时，需要注意：

【1】指标真实有效，即服务可用率，故障率等指标的归属责任方式明确的

【2】指标同步时，明确指标状态、流程，避免数据在同步过程中变为2份数据。一般也采用ETL离线同步的方式，结合全量表同步与增量表同步。

以上就是关于浅谈RFM模型全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！