留存率的误区与应用

业界之中,类似于形而上的思考方式,加上KPI的压力,使得工作的目标被迷失,如同刻舟求剑的生搬硬套指标,最终成为数据的奴隶。显然,这是一种错误、并不可取的方法论。
比如留存率,这一反应用户转化效果的指标,被剥离出业务的范畴而被滥用,形成了知道数据是什么样,却不明白数据说明了什么意义,最终沦为汇报工具。
对比下面两种情况,可见一斑:
1.周留存率定义:以某一天为统计基期,在一周内,有任意一天存在使用记录,定义为周留存率;
2.7天留存率定义:同样的,以某一天为统计基期,在第七天有使用记录,定义为7天留存率。
两者的名称比较接近,但含义却相距玄远。在日常的应用中,更是大相径庭。然而,对于某些产品线丰富的公司而言,应用统一的SDK进行统计,用一套BI体系去测度所有产品的情况并不少见。因此,将两种本来各有应用场景的指标,人为的标准化成了一套内容。于是乎,有了对某类周期性使用的产品(比如财经股票类)7天留存率的考察,而忽视了周留存率。甚至用统计基期活跃用户来进行7天留存率的统计,要知道,某一天的活跃用户包含着新增与既往的留存用户,在无视既往留存用户生命周期的时刻,特别是在大力推广一阵子之后,活跃用户沉积了大量新晋的留存和质量尚不明晰的新增,如此考察活跃用户的7天留存率,除了能让汇报更好看些之外,实在想不出更有用的场景。
好吧,跳出这个逻辑,我们来探讨一下基于业务逻辑的数据模型。
首先,第一个问题是何谓模型?答案耳熟能详,即按照模型,我们能让这东西运转起来。那么产品的模型,自然就是产品价值假设实现的运转。
紧接着,第二个问题应运而生——价值假设如何运转,产品是给用户使用,那么实现用户转化为产品的用户,以及进一步转化为创造价值的用户(可以是付费,可以是创造内容),便是价值的运转。
继续,第三个问题是产品的运行状态,我们聊了价值如何运转,但运转速度的快慢也需要测度。于是这里有了复合增长(新增-流失),有了用户生命周期(延长的话,能够在给定的新增下,增加留存,进一步增加日活跃)等等;
最后,却是非常重要的是产品在价值实现的运行中,用户与对象是否的关系、结构是否良性,中心化是否明显。合理的产品结构,特别是web2.0之后的互联网产品,往往是去中心化的。然而,有些时候在KPI的压迫下,驱动运营的力量,让用户或者是对象强烈的中心化。

待续

2015-06-04 15:09445数据分析