我们此前已经发布了三个版本的 RFM 分析，截至第三版，我们得到：
RFM 3.0 的最大精妙之处在于：
- 将 RFM 的三维结构平面化，好重复利用人类的平面直观视觉。
- 可以进行图表切换，快速在可视化与明细之间转换。
- 可以立马转换为行动，对该采取行动的用户可以通过钻取采取对应的行动。
已经非常完善了，在一年时间内没有看到什么新的突破案例，那么我们有必要来彻底提升 RFM 的分析架构。
在市面几乎所有的 RFM 分析中都存在两个巨大业务障碍：
- 划分复杂。 由于 RFM 将客户分为 8 类，在操作实务上往往过于复杂导致必须细分更多行动规则，不太好用。
- RFM本身并不说明状态的好坏。 虽然我们可以知道在某一时刻的 RFM 分类，但这个时刻究竟是怎么演化过来的呢。
为此，我们需要做到：
- 将 RFM 进一步简化到可以界定更为明显的行为。
- 可以看到 RFM 的各类占比趋势以在更高层面知道业务发展的好坏。
- 对于不好的转变，找出细节，并采取行动。
另外，由于客户维度可能存在众多用户，导致在针对客户维度计算时还会遇到性能问题，这也是一个具体的技术痛点。
在 RFM 4.0 中，我们将解决上述所有问题。
部分效果解释
在 RFM 4.0 中，我们将展开连续评估，这使得 RFM 的评估得到持续对比。而且得到一个莫大的好处：
由于我们滚动 12 个月进行计算，那么 R（Recently 这个维度）就自然消失了。我们认为在滚动的周期里，所有出现的元素均视为有效，那么就降低了一个维度，将 RFM 转化为了“连续滚动 FM”模式。
什么是滚动 12 个月？
对于 2020.08.31，向历史滚动 12 个月就是：2019.09.01 到 2020.08.31。
对于 2020.07.31，向历史滚动 12 个月就是：2019.08.01 到 2020.07.31。
对于 2020.06.30，向历史滚动 12 个月就是：2019.07.01 到 2020.06.30。
滚动 12 个月的最大好处就是它会包括一个年内的所有月份，而年通常是一种非常广泛的周期，因此使用滚动 12 个月是很有意义的。
来解读 RFM 4.0 的重要部分：
左上图，表示最近一年的每个月对应的滚动 12 个月的客户数。这反映了客户发展的趋势是越来越多。
左下图，表示不同 FM 分类的用户占比发展趋势，当然是希望 F↑M↑ 的占比越来越大，同时希望 F↓M↓ 的占比越来越小。而事实也的确如此。
右上图，表示最近一年的每个月对应的滚动 12 个月的客户相对于上个月的滚动 12 个月的留存率。这对估计用户的粘性非常关键。本案例表示，相对于一年内的每个月，按滚动12个月来看，都至少有 95% 以上的用户是留存的。
右下图，则更清楚的表示不同 FM 分类的用户所占比例的趋势。
从这个案例中不难得到以下的业务洞察：
1、整体用户量，稳中有升。
2、用户留存率稳定，且超过 95 %，说明运营策略是十分有效的。
3、优质 FM 资源类别所占比重在逐月增加。
4、劣质 FM 资源类别所占比重在逐月减少。
业务洞察结论：客户运营趋势发展稳定且向好发展，优质客户占比达44%，且劣质客户在有效控制和转化。
需要执行的动作
最近一个月从 F↑M↑ 转换为 F↑M↓ ，表示最近 12 个月总消费额有所下降，向这类客户推介高净值的产品。
最近一个月从 F↑M↑ 转换为 F↓M↑ ，表示最近 12 个月消费频次有所下降，向这类客户推介更多可能的相关产品。
最近一个月从 F↓M↑ 转换为 F↓M↓ ，表示最近 12 个月低频消费，且消费额下降，向这类客户经常推介精准产品，保持留存。
最近一个月从 F↑M↓ 转换为 F↓M↓ ，表示最近 12 个月消费额很低，且几乎没有购买了，判断这类客户是否定位客户，如不是定位客户，应控制资源投入。
PowerBI 实现思路
这里给出在 PowerBI 中的实现思路，读者可自行尝试，我们会在后续文章给出更加充分的描述。
更复杂的日期表
这类分析一般是在完成月阶段，而由于是滚动 12 个月，因此，我们需要确保日期表需要满足：
- 可以标识完成月。
- 可以标识有足够滚动 12 个月的数据。
整个分析必须确保图表中的任何月都有滚动 12 个月的数据，不然会产生错误效果。
滚动计算方法
滚动 12 个月的计算方法核心是对时间区间的缩放，如下：
代码语言：javascript复制DATESINPERIOD( Model_Calender[Date] , MAX( Model_Calender[Date] ) , -12 , MONTH )这样就可以缩放到根据当前月的前 12 个月。
R 的计算
由于滚动带来了完全一致的周期，R 可以视为一样的要素，因此，R 就被忽略了。
这个手法非常厉害。
F 的计算
F 本来是频次的含义，由次数除以周期，由于现在的周期是恒定的，那么只需要计算交易次数即可。
M 的计算
M 表示交易额，只需要普通的聚合加总计算即可。
性能问题
到这里，这套 RFM 的核心业务模式以及设计思路就交待完毕。还有一个核心问题，就是性能，由于这里的 RFM 更加精简，已经可以确保很不错的性能了。
但在遭遇到上万的客户，分别计算时，例如：
由于要对具体的客户采取行动，所以需要知道客户的具体划分归属，以及变化，在客户量大的时候会导致显著的性能问题，我们用 5000 客户在一个月内计算，大致性能如下：
大概要 33 秒完成，这是一个非常慢的速度，如果查看 DAX Studio 来分析引擎时间，则有：
这仅仅是计算一个月的情况，如果是要对比计算，或多月计算，则面临更显著的问题。
总结
本文开启了 RFM 4.0，我们讲述了要解决的业务痛点以及部分效果。感兴趣的小伙伴可以自己先行尝试，具体内容包括：
- 连续型滚动（Rolling）12 个月的各 RFM 指标计算。
- 更强大的日期表。
- 如果有兴趣，还可以研究非常深度的性能优化问题。
我们慢慢来一步步揭开，好玩的还在后面。
另外，这些内容未来回进入 DAX Pro 做成模板，您现在不妨就可以熟悉 DAX Pro 的使用，当这些优化的计算方法被做成模板时，您将切实地感到您在使用成果，而不是自己苦苦地思考。微软做平台，我们做模板，您拿去就用。下回分解。
如果将恐怖的34秒甚至不知道多久降低到1秒以内是什么感觉，挑战下自己，我们一起研究。
