产品经理之流失率+留存率≠100% ,MAU DAU

产品经理之流失率+留存率≠100% ,MAU DAU  

我蛮赞同这种说法的,所以转载过来,方便以后查阅。


这篇东西想写有很久了,但是迟迟未能动笔“留存率”与“DAU/MAU”自相矛盾,今日去参加TalkingData的沙龙颇有感触。个人觉得那本“白皮书”是很有里程碑意义的东西“留存率”与“DAU/MAU”自相矛盾,它是中国游戏数据界第一本公开界定基本统计量的文本(如果之前有,TalkingData不知道,那我也就更不知道了)。但同时,对个别统计量(留存率、流失率)我也有自己的看法“留存率”与“DAU/MAU”自相矛盾,所以今天终于开始敲键盘。

 

首先声明,我很钦佩Jet公开界定基本统计量的勇气“留存率”与“DAU/MAU”自相矛盾,并且“白皮书”里大部分的东西我是赞同的。但是我认为基本概念应该是逻辑自洽的,并且在表述上应尽量减少歧义的可能。所以我对“流失率+留存率100%”这样的表述不是很赞同。

 


我理解Jet的意思,按照上下文的定义,“流失率”加“留存率”确实不等于100%”。但是,谁能说这样的表述和我们的日常逻辑不是相悖的呢“留存率”与“DAU/MAU”自相矛盾?这就好比说,集合A并上集合A的补集不等于全集,这难道没有逻辑错误吗“留存率”与“DAU/MAU”自相矛盾?可为什么按照上下文的定义“流失率+留存率100%”又是正确的呢?

 

原因在于定义“留存率”与“流失率”的时候,我们偷了一个懒,直接将长期以来的定义拿了过来。其实这就是我为什么说想写这篇东西很久的原因。因为一直以来“留存率”的定义,或者说“留存率”这个叫法是不准确的“留存率”与“DAU/MAU”自相矛盾

 

在解释“DAU/MAU”的时候,我们科学的认为“用户不可能天天登陆”,但在判定新用户是否留存的时候我们却很武断的认为“只有在取样点(第二、三或七天)登陆才算是流存”,这显然是没有把理智的思维观贯穿始终。这就是这篇东西的标题叫做“‘留存率’与‘DAU/MAU’自相矛盾”的原因“留存率”与“DAU/MAU”自相矛盾

 

我们过去一直说的次日留存率、三日留存率、七日留存率并不是严格意义上的留存率,而是比留存率要小的登录率“留存率”与“DAU/MAU”自相矛盾,我们在表述上一直偷了这个懒,于是导致了上面不符合逻辑的结果,即“流失率+留存率100%”。将“留存率”改成“登录率”,那么不等于“100%”就很好理解了。

 

打破很久以来的认知确实是很难的事情“留存率”与“DAU/MAU”自相矛盾,但是为了行业的规范与发展我们确实有责任这么做,所以我个人认为“登录率”是一个更加“留存率”与“DAU/MAU”自相矛盾实事求是“留存率”与“DAU/MAU”自相矛盾的叫法。游戏中的账户与自然人不一样,自然人两天不呼吸必死无疑,但是离线两天的用户很有可能第三天回到游戏中“留存率”与“DAU/MAU”自相矛盾,所以我更加大胆的认为,既然没人能断定必然的“留存”与“流失”,也就没有必要保留这两个模棱两可,容易引起歧义的定义,今后统一用“登录率”取而代之。也就是新用户看:次日/三日/七日登录率。老用户看:后X日登录率(统计日后X日有过登录的用户,占统计日登录用户的比例)、次周登录率、次月登录率“留存率”与“DAU/MAU”自相矛盾

你可能感兴趣的:(iOS优化)