看到这篇文章——如何通过统计分析工具做好APP的数据分析和运营,感觉并没有深入的讲解针对一款App,如何收集数据,如何分析数据。而是从表面,只是见到数据而描述数据罢了。本次为系列文章App数据分析之旅,共两篇:第一篇讲解App数据分析之旅,如何收集数据;第二篇讲解App数据分析之旅,如何分析数据。那么,我们就开始App数据分析之旅吧。
为什么要针对App收集数据,想必大家能够举出很多理由。大家可以想一下,尽量不要设计到数据后期的分析,不要涉及产品优化,不要设计用户体验,更不要设计运营优化,等等。因为,这些都不是理由,而是结果,根据数据分析做出的响应调整。
收集产品数据最基本的,是为了观察产品各个功能之间,以及产品功能中各个节点的运行状态。 产品人员除了提出产品相关的MRD(市场需求文档)、PRD(产品需求文档)之外,还应该有针对性的提出DRD,即数据需求文档(Data Requirement Document)。DRD与PRD之间的关系最为密切,因为DRD是随着产品业务逻辑展开的。 当然,中大型公司会有独立的数据分析部门,可以由他们来负责提出相应产品的DRD。如果是中小型企业,提出DRD的工作,由产品人员来承担,也是大有可能的。 那么,我们要怎么收集App的相关数据呢?不要着急,我慢慢给大家分析。 1、了解产品业务逻辑。主要是App的用户操作流程,主要有:功能之间的逻辑关系,单一功能上的逻辑先后关系。以我的实际工作为例,App登录(当然,这不是主要的业务逻辑,只是拿来举例子的)。业务逻辑,梳理的形式和工具很多,有些人喜欢用图,可以PS;有些人也喜欢用图,但用的是PPT和连线;有些人喜欢用ord,有的会用思维图。 2、将业务逻辑节点化。App功能之间、单一功能重要节点的梳理,将节点列出优先级,因为有些节点是不重要的,没有必要对其统计。或者目前的业务中,有些统计不需要。经过梳理和讨论,就得到了第3步中,需要统计的节点、事件以及参数。 3、将节点化的业务代码化。这一步骤,主要是将列出的重要节点(需要统计的节点)添加统计事件和统计参数。 4、交付开发调整DRD。如果你没有开发经验,也不懂开发,那需要多向开发了解请教,那样你提交的DRD,会相对合理。如果你是开发出身的产品人员,而且又做过这部分工作,和开发沟通起来会很顺畅的。(当然,这里还是建议大多非开发出身的产品人员,学一些基本的开发知识,也可以多和产品聊聊开发,也是为了工作嘛) 5、后期数据库中有了相应节点的统计情况,之后就可以拿来分析了。这一部分,我会在第二篇中具体来讲的。 这一年移动相关的工作经验,颠覆自己之前在PC方面数据分析的认知。原来,数据分析可以是这样的,而不只是单纯一味的描述数据。也希望,这篇文章,能够对大家有启发。如果能够让大家也有上面和我一样的感受,真的是很荣幸。 最后,谢谢大家的浏览,后续会更新第二篇App数据分析之旅,如何分析数据,敬请期待!