为什么要去研究数据采集呢?
大家可以回想一下自己在工作中是否会经常遇到以下问题:
☑ 真实数据与后台获取到的数据差距很大。
☑ 同一数据在不同的指标内有两个完全不同的结果。
☑ 需要统计的数据与采集获取的数据不是同一类。
其实,这些问题的本质都是因数据采集环节定义不清晰造成的,可见,我们必须要重视数据采集的方法与定义,而不仅仅是将需求扔给开发部门完成。
下面先来学习一下日常工作中用到的数据采集方式,具体可以分为如下两类。
非透明采集:指看不到原始数据,只能通过统计上报采集,常见的方法如埋点。
透明采集:直接提取业务线中现有的系统数据库中的数据,如日志服务器数据的整理抽取,在POS机的交易数据库中抽取订单数据等。
(定义1:数据采集方式)
在日常工作中,这两种采集方式通常是结合使用的,可以此来丰富数据采集维度。但必须要强调的是,大家在设计数据采集方案时,一定要把握设计的度,否则很多新入行的产品经理可能会走向如下两个错误极端。
1)采集数据颗粒度过细,导致应用缓慢。
很多产品经理在定义数据指标时,由于不能清楚地定位数据平台的监控范围,害怕遗漏,便将产品中的所有元素都埋上点,导致一个图文资讯类产品在用户打开后流量消耗和看视频一样巨大,严重拖累产品体验。
2)数据统计点过少(颗粒度过大),导致发现问题时无法定位具体原因。
当然,除了以上问题,也出现过另外一种过激的场景:为了避免应用过于臃肿,而只采集了日活、月活、留存等通用的用户数据,当用户量抖动变化时,根本无法定位究竟是什么原因导致的,数据使用者看到了这样的结果却又无法追溯问题,内心其实比不知道用户流失还难受。
让我们继续回到L公司的案例中,了解具体实战中要怎么正确进行数据采集设计。
到底什么是埋点呢?埋点的完整定义如下:
所谓埋点,又称事件追踪(Event Tracking),是指针对特定标识用户的行为或事件进行捕获、处理与传输等操作的全过程。
(定义2:埋点)
通俗点来说,就是在用户使用的客户端中加入一个记录者,忠实地记录用户的每一步操作,帮助我们洞察用户的真正行为。例如,用户到底喜欢什么,厌恶什么,从而让我们获取到正确的一手用户数据。
通常情况下,一个埋点主要由三部分组成:目的、所服务的指标和埋点细节说明。
对于埋点的设计,在工作中有如下三个一般性的设计原则。
反应事件:必须能准确地获取要监测的事件。
描述完整:必须能清晰地反馈用户的完整行为。
用户追踪:必须能判断出哪类用户有问题。
满足这三个一般性设计原则才称得上是一个比较完整的数据埋点方案。
原则1:反应事件
在工作中我们需要统计的用户行为是多种多样的,因此在设计埋点时也应该按照不同的类型进行划分,埋点的监测行为可以分为如下三类事件。
点击事件:用户点击按钮触发的事件。
展现事件:用户的操作界面中出现了多少次该事件。
停留事件:用户停留在该页面的时长。
原则2:描述完整
划分不同的用户事件只是完成了需要监测的事件,为了能清晰地反馈用户行为,我们还需要将用户的行为再做一个细分,用户的行为可以划分为如下两类。
有效行为:指触发了带有业务含义的操作,通常用来分析活动/产品的有效性。比如,Banner广告位点击、推荐商品点击等,据此来得到转化事件的触发率,并评估运营活动/推荐算法的有效性。
点击行为:指用户在产品内的一般性点击,通常用来帮助推进产品迭代。比如,用户经常误触某些元素,我们就要分析是什么设计误导用户认为那里是可以点击的,从而进行产品迭代,将用户的操作引导到有效行为上。
原则3:用户追踪
要想实现用户追踪,我们就需要使用多种埋点方式来获取全面的用户数据。在埋点技术的发展过程中,埋点一共被划分为四类,如下表所示。
下面从两个维度来对这几种埋点方式进行排序。
1)从准确性上来说,代码埋点 = 服务器埋点<可视化埋点<全埋点。
2)从个人推荐上来说,代码埋点 = 服务器埋点 >可视化埋点 > 全埋点。
联系客服