不要再因为数据指标吵架了！

逛招聘的时候看到不少数据分析师的招聘需求，以为会个SQL+Excel+Python应该不成问题，但是分分钟被教做人了。

SQL、Excel、Python的确可以解决不少问题，但是不懂业务的数据分析师估摸着就是别人眼里取数快点的取数机,emmm

还是自带技能的那种。

我也不是大佬说不来太多关于业务上的知识，就聊聊关于和业务挂钩最多的 数据指标 这类基础的东西，当然全部都提及也不现实，不和业务挂钩的指标都是瞎扯淡，对当前业务有参考价值的统计数据才叫数据指标，否则他们就是堆数字。

每个人对于数据指标的理解都有些许的区别，但是在业务上对于数据口径的统一是最基本的，如果你对于某项指标的理解和给你数据的研发理解不同，争吵或许不会，但是分析出来的结果应该是大相径庭的。(大佬轻喷)

所以有句话讲的很棒，没有绝对的对错，只求彼此的认同。

DAU / MAU

这两个指标有什么可以争议的地方?

其实刚开始我也是这么想的,深入了解后感觉有一番学问。

DAU - Daily Active User

MAU - Monthly Active User

从全称我们就可以把它拆解为三个部分：

• 在你目前分析的业务中如何定义日和月？
• 在当前的业务中如何定义活跃？
• 当前业务中如何定义用户？

在你目前分析的业务中如何定义日和月？

日和月本身的含义没什么好解释的,自然日和自然月。

但是这里需要注意的是:

• 当你所负责的业务有全球业务时,你应该最近24小时的数据变化，而不是自然日。
• MAU != DAU之和，切记切记
• MAU 统计切记要去重, MAU <= 最大日活 + 新增用户 <= 总用户量

在当前的业务中是如何定义活跃的？

活跃的定义一般分为基于数据统计系统的定义和业务定义两种。

这里的数据统计系统的定义是指类似友盟、百度统计、GA…等等统计系统统计出来的结果,这些统计系统基本都是根据事件上报统计的。

那到底什么是事件上报？

事件上报就是设定某一操作事件，当用户执行了该操作就上报给后台的统计系统。例如当用户加载成功页面(page view 事件)或者点击某个按钮(onclick 事件)统计系统会加以记录并统计。

那这样的统计就一定没有问题吗? 并不是的，我们先理清一个思路，这里统计系统假定了下面这样一个操作：

有事件上报 -> 该用户活跃

这样就假定了事件上报一定来自用户主动操作,往往这样的事件上报会导致你业务活跃度暴增,其他的业务指标没有什么变化。

而业务定义中同样也是基于事件上报，不过这里往往指定的是关键事件，类似登陆，签到等等。

这样的操作基本是来自于用户主动操作的事件统计准确率更高。

但是业务定义的这些事件上报机制就没有弊端吗？

当然也不是的，这里需要维护一个不断迭代的关键事件列表,同时在工作中也增加了沟通的成本,需要内部周知，且有较好的培训机制为让之后的新同事也知道内部有这样一个事件列表的存在。

当前业务中如何定义用户？

用户的定义往往需要根据实际情况去判断,用户是根据人统计、根据设备统计还是复合前两者？

我们先讲讲上述统计的优缺点：

认人的统计方式 - 每位注册用户都有唯一的用户标识，但是没有登录的用户就统计不到了

认设备的统计方式 - 每台设备都有唯一的标识码，但是现在谁还没几部电脑、手机、IPAD？

所以脱离业务谈指标还是有点够呛:

我们可以按照实际需要遵循不同的用户统计方式。

讲到这，DAU 和 MAU这两个指标算是理解了大概，更多深入的理解还是需要结合实际业务不断加深。

当然也不要忘了下面这句话:

没有绝对的对错，只求彼此的认同

以上就是我对DAU、MAU这一对数据指标的学习和理解希望对你有帮助~