前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >PowerBI RFM 4.0 - 第一篇 - 滚动连续评估法-业务解释

PowerBI RFM 4.0 - 第一篇 - 滚动连续评估法-业务解释

作者头像
BI佐罗
发布2020-09-07 15:22:49
1K0
发布2020-09-07 15:22:49
举报
文章被收录于专栏:PowerBI战友联盟PowerBI战友联盟

我们此前已经发布了三个版本的 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秒以内是什么感觉,挑战下自己,我们一起研究。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-09-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 PowerBI战友联盟 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 部分效果解释
  • 需要执行的动作
  • PowerBI 实现思路
    • 更复杂的日期表
      • 滚动计算方法
        • R 的计算
          • F 的计算
            • M 的计算
            • 性能问题
            • 总结
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档