如何判断产品的健康度

作者: 人人都是产品经理社区 | 来源:发表于2019-06-14 17:18 被阅读7次

    你的产品现在是否健康,是否可持续发展,如何判断产品正在往好的地方发展,还是往坏的地方发展呢?这篇文章我会和你一起讨论一下,关于产品健康度的意义以及衡量方式。

    题图来自Unsplash,基于CC0协议

    产品健康度公式

    有一个公式,可以比较容易的判断产品健康度:

    通过新用户在日活用户当中的占比进行判断,新用户占比越高,产品健康度越低,新用户占比越低,产品健康度越高。

    产品健康度(H)=1 - 用户 / 今日登录用户

    这个公式遵循“老用户”至上的原理,新用户在日活当中的占比越低,表示老用户占比越高。

    这表示产品具备留住新用户,并将新用户成功转化为老用户的能力。

    同时,这也可以引申出另一个更精准的判断公式。

    对于一款健康的产品而言,新用户在今日登录用户中的占比会越来越低,因为昨天的新用户,将会成为今日的老用户,从而带来分母的增长,但每一天的新用户却并不是累计增长的。

    H1=前日产品健康度

    H2=昨日产品健康度

    H3=今日产品健康度

    H3>H2>H1

    如果在某一天,我们发现健康度比昨日低,也就是H3低于H2时,基本都会由两种情况构成:A. 存在爆发式增长;B.老用户流失

    对于前者而言, 意味着我们需要特别注意这批用户的留存状况,只有将这部分爆发增长的用户进行有效的留存,才能最终成为我们的有效用户。对于后者而言,极有可能是在老用户常用的功能板块出现了异常情况,甚至于老用户无法登录的情况也时有发生。

    此时,需要立即进行产品测试,要立即排除可能影响数据的BUG,再进行深入分析。

    案例

    这是 我曾经接手过的一个项目,我们观察 了 7 天数据如下。

    新增用户与日活用户已经不在一个数量级了,这让我们难以从健康度上进行有效的判断。我们更多的是去判断连续多日的数据,观察健康度是否呈现增长的趋势,昨日的健康度是否比前日的健康度更高。

    案例当中,红色表示负值,也就是该日的健康度出现了下降。这个健康公式尽管适合大部分的C端产品,但也有不适用的情况。

    产品早期,场景触发的应用,产品后期并不太适合使用这个公式。

    当产品过于早期,没有稳定的用户留存方式,还无法积蓄老用户时,这个公式就不太合适了,就如同肉眼可见的病症 就不需要公式作为仪器来观察。

    还有一些由场景触发的应用,不太适合这个公式,比如小程序,典型的场景化触发式应用,留存极低,新用户在今日登录用户占比可超过50%以上,即使统计出来了也没有意义,这是载体本身所具备的特性。

    我们在案例当中也能直观的发现,当用户量足够大时,健康度会无限趋近100%,这并不表示产品是健康的,仅仅表示新用户和老用户在量级上的差异,这种差异,已经影响了我们对产品健康度的观察。

    针对第三种情况,用户量足够大的产品,我们也有另一套健康度判断方式,相对会复杂一点。

    用户生命周期越长,产品越健康

    这是我们探讨的第二种判断产品健康度的方式,累计用户百万以上的产品,都可以尝试使用这种方法。实际上,产品初期,用户较少时,也可以尝试使用这种方法,他比第一种会更加精准,只是成本比较高。

    通过用户生命周期来判断产品健康度,本质上是去判断这个周期里的时长,也就是说用户从使用产品到流失,中间会经历多少时间?

    我们可以将生命周期的长度,理解成用户的生命力,用户生命力越长,表示产品的健康度越高。我曾和一些创业者交流自己的项目,当谈及到用户生命力时,多数情况会直观的表达具体的天数,比如30天生命力,45天生命力,我们其实对于用户在产品的寿命有准确的认知和判断。

    通过用户生命力进行产品健康度判断的原理,其实在于我们对 “活跃”这个词的理解。所谓的活跃用户,意思是指今日,或者特定时间段内有登录行为的用户,再引申一点,活跃用户,其实就是还活着的用户集合统计。站在用户存续和死亡的角度来看待活跃度,就不难发现 这个活跃度存在一个上限值。

    我们可以借助用户生命周期,将已经确定死亡的用户抛出,而活跃度的上限值,也就是该时间点疑似存续的所有用户。假设用户的生命周期是25天,某日的活跃上限值,便是最近25天累计的新增用户,而不是全部的注册用户。这样的局部统计方式,会让数据量级的影响降低许多,可分析性也会高许多。

    实际上 ,我一直不太提倡与总用户结合产生的比值,他几乎是不可逆的,这项比值注定越来越低,能够分析得到的信息,其实非常薄弱。在资深产品经理里,我们或多或少会掌握一些局部统计的方法,这能让我们挖掘更多数据背后的信息,也比全局的统计更加清晰和精准。用户生命力越高,能够同时存在的用户数也就越多,生命力为45天的产品 与生命力为60天的产品,在其他条件相同的情况下,前者日活数据必然低于后者日活数据。原因则是因为后者汇集了60天的用户数量,比前者多了15天。

    案例

    在相同的案例里,我们发现用户的日活始终在450000左右徘徊,尽管每天都会新增10000多用户,但并没有带动日活的增长。通过更深一步的数据分析,我们发现这款产品里用户的生命周期是90天,周期段的总用户只有90万(90*10000),局部日活已经达到了50%。在这种情况 提升日活最好的方法,是延续用户的生命周期,日活率不变的情况下,提升总量就能带来日活数据的增长。我们通过对活跃用户进行深度的解刨分析,会发现判断产品健康度特别直观,就好像已经具备了洞察一切玄机的眼睛。

    在活跃用户里,罗列用户生命力的正态分布是指将某一天具备登录行为的用户,按照生命力的时间输出正态分布的图形,观察每一种生命力的占比。

    示意案例

    假设一款产品 用户生命周期为7天,这款产品某日的活跃用户有100人。我们可以通过生命力的正态数据得到以下数据。

    通过对用户生命力的正态分布进行数据分析,结合产品健康度的原理认识, 很容易得到一些信息,比如新用户占比过多,又或者用户在生命里的哪一天开始断崖式下跌。

    提高活跃的方法,从本质上都是推进用户生命里的延续,将第一天的推向第二天,将第二天推向第三天,最终将生命7天调整为生命力10天,达到延长用户生命周期的效果。延续用户生命周期便是在提高产品健康度。

    如何获得用户生命周期相关的数据呢?

    基于用户生命力的数据分析,成本非常高,只有数百万乃至上千万用户体量的产品,才具备构造深度数据分析的能力。这需要我们记录每一个用户的活跃天数,间隔时间,他甚至需要单独的表格,单独的字段用来存储数据。

    手工版统计

    我在一个创业项目当中也使用了这个数据分析的方法,为了减少开发资源的占用,基本都是通过excel表格进行计算。简单来讲,我需要研发人员导出一份用户表,包含用户的注册时间,用户ID,就像这样。

    我还需要研发人员每天导出一份今日登录用户的表,包含用户ID,登录日期,像是这样:

    然后使用vlookup函数,以及一些数据标签,进行统计,最终我会得到这张结论表:

    其中“-”表示用户还未注册,“0“表示用户未登录,“1”表示用户有登录行为。最后还需要统计,每位用户的登录次数,间隔次数,以及一些复杂的表格处理,最终得到我所想要的健康度衡量指标。

    是不是特别麻烦,因为创业初期,实在没有办法用开发资源实现这个命题,毕竟产品不稳定的情况,投入数据挖掘分析的资源,并不是很明智。一般团队没有很强的研发资源,只能向案例中的我一样,用繁琐的手工统计方式,还不一定准确。

    当然,这是以前的环境,现在就不太一样了。现在有一些工具非常巧妙,极大的降低了精准统计的门槛,也许只需要接入SDK,就能看清用户的生命力。解刨你的活跃数据。(难道你不觉得这种数据分析方法,很像解刨吗,抛弃表面现象,看活跃数据的哪部构成)

    “友盟”作为第三方数据统计系统,提供了针对用户生命周期进行监控的能力。

    我们可以自定义用户的新手阶段,流失阶段,尽管现在还不能自定义成长阶段和沉默阶段,实际上已经能挖掘出许多有价值的信息了。

    通过对新手阶段的用户进行更深层次的分析与解读,可以知道在100位新手里,有多少会进入到成长阶段,有多少会在新人阶段就会流失,这个数据会让我们非常惊讶,你会发现很多用户其实在新人阶段完成前已经流失了。

    新人流失,是流失用户的重灾区之一。

    对于很多产品而言,这或许是第一次 把新人的定义从“点”转变成了“线” ,我们观察的不是用户的第一次注册激活行为,而是在一个周期里的生长过程。

    对于用户的成长阶段,也按照用户的单日访问时长分成了若干等级,我们可以自定义每个等级对应的数据阀值。友盟将用户等级与用户价值画上了等号,用户价值越高,等级越高。而判断用户价值的方法,则是通过单日使用时长。我们认为用户与产品的互动时间越长,表示用户对产品的依赖性越强,越是产品的忠实用户。而这类型忠实用户对产品具有极高的商业价值,不论是付费的头部玩家,或则是带动新用户的流量玩家,都来自于这部分忠实用户。

    现在你只需要借助友盟提供的关于用户增长,用户生命周期的统计模块,就能完成一次局部数据分析,就能够对活跃数据进行更深层次的解刨。实际上不仅仅是对活跃数据进行解刨,友盟提供的用户生命周期里。还包括了对用户阶段性数据进行第二次解剖的能力。比如:通过对成长阶段的数据进行分析,挖掘出用户的质量分布,我们的主要用户群体是集中在高价值用户,又或者低价值用户,这将会一目了然。

    再谈产品健康度

    通常情况,我会将用户划分成5个阶段,包括新人阶段,成长阶段,稳定阶段,沉默阶段,流失阶段,每个阶段都有其特殊的定义和对待方式。

    新人阶段

    启动10次以内 都可以划分为新人阶段,我会关心新人阶段的成长性和流失率,为了提高新用户的成长性,还会构造一些新人专属的业务模块,从而提升新用户变老用户的几率。

    成长阶段

    这个环节仅次于对新人阶段的重视,处于这个阶段的用户多数已经知晓产品的使用方式,以及产品为用户提供的价值,但仅仅是这样还是不够的,我们会将用户的知晓转变成行动,

    我们会把成长阶段的用户划分两个标签,低频用户,高频用户,并且想办法提升高频用户的占比。(对应友盟的低价值用户与高价值用户)

    稳定阶段

    这部分群体是产品的老玩家,我们在做一些转化的任务时会优先拉拢的群体,但在产品日常迭代中,反而会刻意忽略这部分老玩家。

    因为他们的占比比较小,且稳定性比较高,我们更多时间会考虑如何获取更多的新用户,如何让新用户向老用户发展。

    沉默阶段

    低频用户十分容易进入沉默阶段,我们可以理解成两次行为之间的间隔时间太长,以至于进入了假死状态。

    当沉默阶段的用户有了增长趋势时,我们就会非常关注产品内活跃度模块的设计和补充,通过增加使用场景的方法,增加用户的使用次数。

    “流失阶段”

    这表示用户已经彻底流失了,我们只能进行总结和复盘,原则是我不太提倡 换回老用户,原因在于 ,叫醒老用户的成本比获取一个新用户的成本还高许多。

    对于产品健康度而言,需要更细致的数据划分,也就是我们要对一些“汇总”数据进行解刨,找到问题的根源所在。最粗糙的健康度公式 便是去判断 新用户在日活用户当中的占比, 占比越高,产品质量越差, 因为这些新用户没有能成长为老用户。

    但仅仅从表面进行数据分析,很容易让比值无限接近于0%,两者的数量差距实在太大,这就要求我们对局部数据进行分析,把一些有干扰的数据进行抽离。比如,我们仅需要对7天内注册的用户进行健康度分析,而不需要把今天的注册用户,与过去一年乃至数年的用户进行综合分析。在分母的位置,减少一些干扰,就能提高数据的参照性 以及可读性。

    对数据进行局部分析在以前可能是很重成本的一种分析手段,但现在,你可以用友盟这样的第三方系统,很便捷的就能达到我们的目的。

    产品的健康度与用户的生命周期密切相关,实际上,我们的日活就等同于存续用户的集合。在局部分析里,日活率通常不会以累计用户作为分母,仅会以生命周期范围内的用户总数作为分母。假设一款产品的用户生命周期为45天,那么45天内的用户总和,便是计算活跃率的分母,超过45天的用户,等同于死亡用户。

    又或者,我们惊讶的发现用户生命周期的到了延长,对应的就增加分母的覆盖范围即可。在这个理论之下,提升产品健康度,提升日活数据的方法就呼之欲出了,比如 延长用户生命周期,又或者减少新人流失率,减少成长阶段的流失率。

    以下是三种 局部分析的数据模型,抛砖引玉,一起讨论下吧。

    模型均是将单日活跃用户按照生命力的数值进行正太分布。

    模型1:新人多,老人少

    这个模型表示 产品获客能力非常不错,但产品自身的留存能力极低, 获取到的新用户缺少转化为老用户的能力,只能是来多少用户流失多少用户。

    如果你的产品出现此症状,可以考虑暂缓拉新推广的任务,优先弥补产品自身的粘性,继续进行拉新,恐怕是没有意义的

    模型2:新人少,老人多

    这个模型表示产品自身粘性能力已经比较成熟了,具备新用户转老用户的能力。此时,你可以放心的进行推广,列表,甚至买流量

    模型3:新人少,老人也少

    这个模型表示 新用户最终未能成为老用户,我们发现用户分布的峰值处于第四天的位置,这表示,用户的流失点建立在第四天,对应正常使用的状况。当你出现这种状态时,可能存在以下原因,不妨仔细思考一番。

    1. 用户生命周期比预估的还要短,也许只有5天或则6天的生命力

    2. 某个通用模块存在残缺,影响了普通用户的使用体验

    我们可以将产品没有吸引力,没有持续的推动力都归结于 生命周期短暂,也可以将所有阻塞性的原因都归结于BUG。此时,应该要做的事情,延长用户的生命周期。

    作者:影子

    本文为「人人都是产品经理」社区和友盟+联合举办的“2019「友盟杯」数据分析大赛”中获奖作品,未经作者及平台许可,禁止转载

    本文部分数据有脱敏处理,非全部真实数据

    有关产品测评大赛合作事宜,请联系邮箱:denis@woshipm.com

    相关文章

      网友评论

        本文标题:如何判断产品的健康度

        本文链接:https://www.haomeiwen.com/subject/gjbpfctx.html