带你轻松遍历用户生命价值与流失挽救(下):流失分析与产品化

2020 年 7 月 06 日

带你轻松遍历用户生命价值与流失挽救(下):流失分析与产品化

前言第一篇是从用户生命周期出发,用一个短视频的案例来做分析,阐述了用户价值体系。本文下篇,将从价值与流失的分析角度来做一些分享。本文涉及到的知识点有:用户生命周期、流量方向的分析方法论、用户分群、用户挖掘、算法、渠道归因、拉新、端承接、运营、产品等。除了遍历这些知识外,文章的核心部分是关于两个数据产品的(关于数据产品方向文章没有做更多阐述)。


用户水池与流失


关于流失与召回,这个是长久不衰的一个话题。 在业务活动中,涉及到的角色还是蛮多的,比如产品角色、运营角色、数据分析角色、甚至渠道市场角色都有。


本文将从数据分析的角度来探索一个关于流失的业务场景,以及通过驱动运营、投放等一系列的动作来应对流失挽救,这些落地就成为一个系统化的工作。


曾经繁荣的第三方应用市场,这几年前来逐渐走向没落。从百度巨资吞了 91 助手,到应用手机厂商崛起达到顶峰,整个应用市场已经经历过多轮洗牌。


“荚,再见!豌豆荚、PP 助手宣布下架,从此再无免费软件?” 你是否还记得豌豆荚这些应用?它们也曾在繁华的第三方应用市场里激起过一点浪花。


到现在,不管是应用宝、360 手机助手、华为、小米等应用商店,都在构建自己的城池。


记得在 2016 年左右一个拓新的成本从之前的几块钱升到 10 块钱、最高时能到几十元,留住老用户或许一条短信、一点积分、活动就可以,相对的成本是很低廉的。从用户生命周期与成本来讲,留住老用户的成本与拓新的成本是完全不同的。留住老用户的成本之所以很低,是因为老用户知道套路,而新用户对套路无感且教育成本就很高了。


运营的同学在每日面对刚涌进来的、将要离开的、已经离开的这几个类型的用户还是很头痛。一边是通过渠道拼命买量拉来的新用户,一边是保持耿直不变或缓缓下降的 DAU 曲线。如果把每日 NU 数据曲线叠加到 DAU 上,从这个 DAU 曲线缓缓下降的趋势来看,每日的 NU 增量或许大几十万,每日不活跃用户也是大几十万或上百万。从数据的表现来看用户的新增与流失相当,一边是花钱买量,一边是留不住用户,如果赶上产品、业务、环境形势问题,更是一个让人心碎的问题。


下图中给出的是 2016 年某个第三方应用市场的日 DAU、次日留存、7 日留存的的数据情况, 从数据上明显看出来,这个 Android App 的 DAU 量级在短短几个月中一直抖动着下滑。





结合数据来看,每周的 WAU 中有千万级别的用户,但是在一周内 AU 角度流失的用户占比为 30%,在 LU 中流失的比例为 50%以及以上。 从每月的数据来看,50%以上的 AU 将会最终流失掉,LU 的流水占比也是在 50%。



用户不断的流失,就像水池的水位不断的在下降,用户流失超过新用户的补给,且速度越来越快、规模越来越大。如果不做任何动作,这个水池迟早会干枯。就像前面说的,很多业务都会面临类似的问题,这种问题不管怎么样都是要解决的。 那如何解决呢?


先来看几个问题:


  • 挽救了这些用户对业务有什么好处?

  • 流失的用户都来自哪里?

  • 流失的用户都会有什么先兆?

  • 在资源有限的情况应该挽救哪些用户?


如果能够解决上面的事情就已经够了吗?实际上还是不够的。还需要:


  • 需要清晰的知道用户长的样子。

  • 通过哪些角度来刻画流失用户,各群体用户中流失用户的规模都是多少?

  • 用户流失的可能性有多大,如何第一时间发现征兆?

  • 发现征兆后如何挽救?

  • 该如何形成自动化流失与挽救呢?


差不多需要将以上的问题都回答了,才可以把流失问题认识的清晰一点。


流失与深度挖掘数据据价值


要研究这个课题,首先需要定义什么叫流失用户、活跃用户、新用户流失。


这里简单的引用一篇文章,是在 2012 年发表的一篇名为《网站的活跃用户与流失用户》 这一篇讲述的非常清晰:


  • ”活跃用户,这里是相对于“流失用户”的一个概念,是指那些“存活”着的用户,用户会时不时地光顾下网站,同时为网站带来一些价值。同时,我们还需要知道到底有多少用户可能已经抛弃了我们的网站,不可能再为网站创造任何的价值,也就是所谓的流失用户。

  • 流失用户,是指那些曾经访问过网站或注册过的用户,但由于对网站渐渐失去兴趣后逐渐远离网站,进而彻底脱离网站的那批用户。当然,一个网站一定会存在流失用户,这是网站用户新老交替中不可避免的,但流失用户的比例和变化趋势能够说明网站保留用户的能力及发展趋势。


这里我给出的公式就是”当前时间点 – 用户注册时间点 > 流失临界时间间隔“。


结合本案例,我们要研究是移动互联网 App 方向,可以用 “当前时间点- 用户首次安装且激活时间点> 流失临界时间间隔”,这个时间拐点是需要通过分析来得到的。


例如下图的流用户流失高风险是在第 20 周至第 25 周。(至于本次案例讲解的 APP 的流失时间拐点,同理的分析方法可以得到的)



有次团队里数据同学做用户分群,遇到了几个纠结问题,比如该如何分群,分群的意义,分群该从哪个角度入手,如何将流失率等计算出来,是否要细化到个体去做挽救等等。


举个例子来说,我们在研究用户流失、用户使用的那些产品有什么特点、用户看了什么内容、搜索了什么、消费了什么这些问题的时候,换一个角度来说就是在研究用户-产品-内容三者之间的关系,拿人、货、场理论来套用也是没得挑。


拿第三方应用分发这个业务来说,用户安装了第三方应用市场, 使用这个应用市场 App 的搜索、推荐、信息流、搜藏、 自动更新、备份等,来寻找自己的需要的 App。这个过程从人货场来解析就是:


人: 就是用户。


货: 一切内容就是 App。


场:第三方应用各种功能场景。


从 BI 的分析模型角度来讲,这里研究的几个关系的意义:


  • 用户、产品、业务内容之间关系来讲,可以从高低风险的的角度来刻画不同的流失用户群。

  • 理清用户、产品、业务的价值边界,让产品功能定位更清晰。

  • 在内容定投上,结合用户画像与标签,可以在前期分析发现用户显性特征、群体特征,用作小流量定投效果测试。



做用户研究的课题时,切入点还是蛮多的,比如从业务黏性、用户属性、正负用户体验、用户活跃度等角度进行切入。但之前肯定会梳理一个比较完整的链路来盘点这个事情。例如对某包月业务的用户盘子价值做个分解,拉新用户、增加已有价值、减少流失。



有时在第一次做用户分群时通常切入的点有流失用户群体的研究、活跃用户群体的研究、新用户群体的对比研究,这几个切入点流失用户群体的研究成本是最低的,可能带来的效果是最好的。


切入流失分析流程后,关于流失挽救的过程,网上相关的文章多的数不清,大多数都是些基本必备与固定流程:


  • 流失用户的定义

  • 画像数据的准备

  • 流失模型的搭建

  • 分析流失数据找到特征

  • 建立流失壁垒

  • 开展召回以及活动


把这个流程整理一下就是这样的:



画像构建:有些人不喜欢一上来就开始构建用户画像。因为画像都是一堆标签,画像一般按业务属性划分多个类别模块。因为每一个标签都要经过大量的分析与挖掘,到实际可应用时的周期还是漫长的。标签的精准度与覆盖度也经常受到训练的数据所影响,有时会准备很多画像的基础变量来做更多不同角度研究。


随着自己对业务的分析与拆解,然后可以加入更多的基础变量来参与到模型研究中。关于用户的 pv 行为、用户点击行为、用户的播放行为,我会做更详细的分片拆分,这样能得到更多显著特征与更多特征。当然在某个地方可以叫做连续变量的区间化。



当然,大部分情况下会存在一个比较成熟的画像体系,比如常见的人口统计、社会属性外,还有用户消费画像、用户行为画像,用户兴趣画像等。


人口属性和行为特征是大部分互联网公司做用户画像时会包含的:人口属性主要指用户的年龄、性别、所在的省份和城市、教育程度、婚姻情况、生育情况、工作所在的行业和职业等。行为特征主要包含活跃度、忠诚度等指标。


模型准备阶段:模型算法与标签还是有一些关系的,不同的算法可以用在不同标签中。监督算法中会用到 logic 回归、c5.0 决策树、svm 算法、最优算法、神经网络、矩阵算法。非监督类的,聚类、离散统计分析、随机游走、小波/F 变换,这些算法用在哪些标签会更合适的,给出一个很明确的图(整个训练过程就不进入深谈)。



从另外一个角度来看一下这个体系这个会显得很直观。



流失模型:在分析中会选择一个用户样本进行观察与分析。在流失模型中选择每一个变量参与到模型计算都是需要做不同的评估的。例如用户基础属性中年龄、App 使用时长、兴趣标签、上网行为、手机品牌等,这是从模型角度要考虑的变量,通过找到的一些线索,分析不同用户群体在这些标签上有什么属性,从而识别哪一类用户忠诚度比较高。



流失模型里面不做更多讨论,图示给出流失模型中的某一个节点判断。


人群的分析:经过反复的分析以及定量与定性的分析与刻画,可以从流失角度对用户分群进行定量描述。每一个分群除了含有流失的描述外,还有很多其它相关显著属性来进行刻画,再进一步根据分群的用户特征来做下一步的业务活动。


例如 :第三方应用分发这个业务,根据特征可以划分为十几个用户群体,其中有两个群体可以定位为低活跃低黏性、易流失搜索用户群体。


低活跃低黏性的群体显著特征是一日游用户很多,都是新安装的用户过来看一下就离开了(不排除有潜在的作弊用户可能性)。这个用户的特征是很多用户有 click 响应、95%的用户没有安装任何工具类 App 或游戏类的 App(猜测一下,这个来看新机或潜在作弊刷量可能,或被其它的 APP 或升级功能引导到这个应用市场,也可能中间被渠道截胡了)。


有了这些定量描述后,可以群体的定性刻画与业务上的触达动作。



用户触达及渠道评估阶段:下图给出的三个易流失用户群体的定量描述。有了这些定量描述与群体规模可以在业务上做些事情。


能做什么事情呢?针对这些用户群体指定不同的触达文案、触达活动页面与内容,然后再选择比较合适的通道,像站内信、APP push、短信、电子邮件、成本更高的电话回访等一系列手段,进行用户触达拉活等,过后再进行效果的评估。



比如这三个群体、低活跃低黏性、易流失搜索、边缘性型三个群体,需要开始做用户触达, 考虑成本,在用户触达的方案上选择了 Push 的方式来做流量测试。相比较产品改造的风险和开发时间,Push 有着快速验证的优点。与此同时,为了控制影响,避免骚扰正常用户,在 Push 投放时,一个用户最多只能收到一条,那么可以对流失风险较高的用户进行投放



投放结束后需要总结,从启动率的比较、Push CTR% click ctr%等一系列角度进行分析并输出相关结论。



当然这个过程只是针对不太启动的用户群体做 Push 拉活,也还有很多的其它抓手与触点需要与用户做更多的作用,才能达到想要的结果。


例如在已经曾经值得纪念那款第三方的 APP 分发平台,从运营入口、内容入口、产品入口分别盘点出来的所有渠道资源与触达给用户的内容,可以参考一下, 这块业务没什么可以做深入分析了。



到此,从流失到挽留的一个比较简单的完整动作就此结束了。现在很多 App 的前后台都支持在线的定向投放、小流量测试、a/b 测试等一系列测试功能,对于触达用户拉活还是有特别大的帮助。


总结一下,用户生命周期中的数据驱动,因为涉及到产品运营、数据分析与挖掘、用户运营,在分工上每一个团队关注的重点必然是不同的。


用户流失与数据产品化


数据分析与挖掘,是要研究消费用户群体、建立流失指数、沉淀回流拉动目标群体圈定与用户分析等。这样可以给业务一个瞄准器,可以让大家知道需要触达哪些用户、什么时间节点触达、以什么样的活动可以触达。同时也能给业务传递一套比较客观与科学的上线评估体系,而不用业务自己上线、自己评估、自己说了算( 例如:有的业务会观察组对照组都搞的不对,这种潜在的小故障是不在少数的)。


通过数据分析与挖掘,拿到了瞄准器与打击节奏,接下来就是要解决武器与打击地点的问题,结合产品运营方向、用户运营方向,从产品的运营内活动、Push 渠道不同内容推荐、产品优化与完善的的角度就是要解决用什么手段触达用户了。


我在针对这个方法论提炼一下就是如下图所示:



有了场景、方法论,我们的数据产品经理就有空间去到更多的系统化与产品化,将这整个过程从体系化的角度进行泛化,让更多的前线运营、产品运营同学参与工作。用一个通用词来说就是”赋能“给他们。


这个赋能过程是要从”探索“和”效果评估“的体系化来规划,还需要加上触达资源库管理与用户分群变量管理,讲到这里或许一些懂这个方向产品的读者已经能够构思这款产品该是个什么样子。


如果展开讲,共有六层是要思考:


  • 底层就是需要数据的支持,需要用户画像、标签支持,切入点就是要很容易的添加补充与管理很多标签。

  • 模型支持层就是有各种算法模型的可视化与非常容易的组织,做好更多兴趣标签的挖掘与管理,切入点就是探索与输出更多的模型。

  • 用户分群层,就是根据变量进行人群的细分与各种角度角度刻画,切入点就是定向人群分析、人群差异化分析等等。

  • 策略层,支持人工运营、人工调整,自动化的调整等, 切入点就是系统化与人工方式。

  • 内容层, 包装了大量的个性化内容专题、促活的运营活动、文案引导模板等等等素材库,切入点就是产品化策略优化,运营的策略固化。

  • 触达渠道层,就是要从用户路径角度盘点清楚运营入口、内容入口、产品入口等触达点能够很容易的触达到用户, 切入点就是产品、运营资源库的各种内容。


如下图所示:



这个架构产品化后,会给业务的生产效率带来很大的提升(这里只是放了一个核心图),跟这款产品有关的其它的知识等内容不在这里做阐述与分享。


写在最后


在写完这篇文章后,发现与自己最开始列的大纲还是有很大的差异。原计划是写一个完整的流失分析,在整理过程发现所牵涉的知识面还是非常广的,也让自己整理了很多项目的材料,并对这些材料进行了脱敏处理。


这个文章可以给业务一些参考,也可以给分析师一些分析方向上的参考,同时可以给数据产品经理一个从业务到模型到数据产品的规划参考。按照惯例,里面涉及到的很多案例不做更详细的解释,如果有感兴趣可以私下交流。


作者介绍


松子(李博源),自由撰稿人,数据产品 & BI 老兵一枚。个人公众号:songzi2016。


2020 年 7 月 06 日 16:552551

评论

发布
暂无评论
发现更多内容

免费CA证书安装配置与背后原理浅析

陈德伟

LeetCode题解:83. 删除排序链表中的重复元素,迭代,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

双亲委派模型与 Flink 的类加载策略

Apache Flink

flink

架构师 0 期 | 大数据相关技术

刁架构

架构师训练

Week06总结

SuperLab

网易伏羲问鼎全球AI文创大赛:用户可零门槛生产音视频动画

核桃Eason

人工智能 AI 动画 网易

你的页面健康吗?

Lam

Java 前端 浏览器 性能分析 web前端

Week07总结

SuperLab

架构师训练营第一期-第二周课后-作业二

极客大学架构师训练营

线上医疗未来的发展

anyRTC开发者

ios 音视频 WebRTC RTC 安卓

Java经典面试题详解,突围金九银十面试季(附详细答案)

Java架构师迁哥

小前端探索HTTP

Lam

Java 面试 前端 网络 HTTP

Git:改变世界的一次代码提交

华为云开发者社区

git Linux 代码

滴滴开源AgileTC:敏捷测试用例管理平台

滴滴技术

开源项目 滴滴技术 滴滴开源

iOS造轮子 - UITableView字母索引条

iOSer

ios 面试题 UITableView iOS面试

极客大学架构师训练营-架构师技术图谱-大作业二

叶鹏

深入分析CRM系统对现代企业的作用

Philips

企业管理 CRM 客户关系管理

Week02

SuperLab

week03

SuperLab

Week04

SuperLab

学习Java的三个阶段(学习目标+知识点),一起努力吧!

Java架构师迁哥

flutter之踩坑的日子(3)

霜蓝手环

Flutter Android Apk

10周作业-微服务

飞雪

Week05 总结

SuperLab

网上黑平台系统风控不能出款怎么办

其实很简单

大数据 网络 系统检测

聊聊布隆过滤器

海星

99%的人都能看懂的分布式系统「补偿」机制

华为云开发者社区

分布式 高可用 系统

LeetCode题解:83. 删除排序链表中的重复元素,递归,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

10个常见的软件架构模式

GuoYaxiang

架构模式 软件架构 架构设计

极客大学架构师训练营 - 同城快递业务架构设计 - 大作业一

叶鹏

英特尔重磅发布物联网增强处理器,产品性能、AI能力、功能安全提升显著

intel001

带你轻松遍历用户生命价值与流失挽救(下):流失分析与产品化-InfoQ