日常工作中，最多的事就是做功能优化。本文作者通过案例，给大家分享了如何用RFM模型进行功能优化的产品实践，希望可以帮到大家。
———— / BEGIN / ————
当一款产品突破0-1阶段后，产品经理马上就要思考如何优化迭代产品。我们都知道这款新产品还不够完善、不够完美，但是优化要从何处入手呢？
一款产品在设计时可能会参考竞品来做出很多业务模块，即便这些模块并不是核心业务，比如：发现、圈子、打卡、问答等等。之所以做这些模块的原因要么是认为“竞品有，我也要有”，要么是认为“用户也许会需要它”。
虽然在需求侧这种东西都是可以自圆其说，但是从产品本身的角度来说它们就是一种累赘，既是研发的累赘，也是运营维护的累赘，后果就是让产品的定位不准确，甚至因为分流而损失掉一部分用户。
那么如何能快速确定下一个版本产品的优化方向呢？拍脑袋想肯定是不行的，说不定会画蛇添足。我在使用RFM模型做用户分层时，发现这个模型的指标维度也许可以用于产品功能优化，并尝试做了验证。
给RFM模型指标的新释义
大家都知道RFM模型是用于用户分层的，它有三个指标：最近一次交易间隔时间、交易频次、交易金额。他们背后的意义分别是用户的流失风险、用户的忠诚度、用户的价值。我尝试在调整指标定义的基础上，用这个模型分析评估产品功能。
首先，修改指标定义
分析的前提有2个：
-
产品模块内没有用户购买行为。我尝试的产品内没有支付业务，所以是否适用无法判断。
-
产品各功能模块相对独立，且用户使用时长相似，例如打卡和阅读这两个功能就不适合在同一维度进行比对。
修改RFM指标定义：
然后，设定分析指标
以平均值为标准，高于平均值记为1，低于平均值记为0。
上图列举了各种假设情况下的分析结果，可以作为我们对一个功能模块调整的依据。产品设计在一定程度上是感性的，但不能没有理性。多数情况，理性的分析才能给我们指引正确的方向，所以用数据支撑决策是非常必要的。
举个例子
第一步 通过埋点获取每个用户在被评估功能模块产生的R、F、T数据。频率和累积使用时长统计范围以1个月为时间跨度。
第二步 求被评估模块的R、F、T均值，以及每个模块的R、F、T均值。
第三步 比对均值，如下图示意红色表示高于均值，黄色表示低于均值。
（模块及数据均为虚拟，仅用作示意）
第四步 按预设指标分析
结果：
-
经验圈——100考虑重构：有用，但低频，内容也不够好。
-
每日一句——111重点保持：很好，不要乱优化，尝试A/B测试。
-
你问我答——001考虑重构：内在美，要学会吸引用户。
-
话题——110重点优化：金玉其外，败絮其中。
-
学习组——000考虑砍掉：啥啥都不行。
-
每日阅读——100考虑重构：有用，但不吸引用户，也不能留下用户。
-
小知识——101重点优化：有用，但是低频。
-
英汉互译——110重点优化：金玉其外，败絮其中。
经过分析我们得到了针对每个模块的调整方向，相较于仅仅考虑跳出率、转化率，这个方法为我们提供了更多依据。对于迭代成长中的产品，切忌拍脑门对某一个功能进行调整，作为产品人每提出一个方案都应该有理有据，不然很容易被其他部门质疑甚至diss。
本方法仅是对如何快速评估功能模块并确定调整方向的一个探索，结论是否准确还需要通过大量实验验证，仅供大家参考。
失效因素
以下几点因素会使该方法出现失效情况，需要格外注意。
时间
时间是影响分析的一个重要因素，以上文举例的学习型app为例：
我们不能简单的把时间跨度按周、按月、按年划分，因为考试前后用户的频次、使用时长会有明显起伏。
用户生命周期
用户群细分的越精准，获取的数据就会越趋近，得出的结论就越可靠。
我们不能仅凭少量高质量用户的行为数据就判断应该向大量新用户提供哪些服务。不能简单的把所有用户放在一起统计，因为有一些用户完成了某阶段学习后就会产生长时间离开、甚至卸载行为。在没有精准的细分用户群体的情况下，简单粗暴的方式是去掉极端值，让“少数服从多数”。
功能定位
确定你要评估的功能模块能够符合模型基本假设：
-
R：用户离开越久越有流失风险。
-
F：用户访问频次越高越有粘度。
-
T：用户停留的越久越有沉浸感。
这就是为什么我在开篇设置了“支付模块不适用分析”的前提。因为用户在使用支付功能时明显是不想停留很久，反而更希望可以在短时间内完成支付操作。支付就是典型不适合用这种模型分析的。如果一个功能最初的定义就是低频，那么我们用高频来评估它“好”与“坏”就会得出错误结论。
我们不能僵硬的执行任何一个分析模型或分析方法，就像老祖宗讲究天时、地利、人和一样，只有综合全面的考虑，才能够离真实更近，让数据说实话。
