>

数据指标系列 | 数据采集方式:埋点和无埋点的适用场景

GIO 增长团队 2019-11-14
1036

「数据指标系列文章」旨在分享埋点方案设计的方法论和实际场景应用分析,为企业又快又准地搭建起高质量数据指标体系提供帮助。系列文章将持续在 GrowingIO 博客发布,欢迎大家关注。

本文作者:GrowingIO 产品经理   檀润洋  


产品经理都会使用用户行为分析平台 GrowingIO 来监控用户核心行为表现,探索新的产品机会,分析用户转化或留存的原因。而正确的数据采集是实现上述场景的必要条件。


在多年的实践中,我们逐渐发现,只用一种数据采集方式无法解决日益复杂的数据分析需求,无法适应高速迭代的产品开发节奏。GrowingIO 提供了埋点采集和无埋点采集两种方式来适应产品经理的不同诉求。


产品经理需要了解什么场景下使用无埋点事件,什么场景下使用埋点事件,以便于满足他的分析诉求。在了解场景之前,产品经理需知上述数据采集方式的特性和边界,才能扬长避短,充分发挥两种采集方式的优势。


1. 埋点采集


埋点, 顾名思义就是借助埋点(写代码)来采集数据,在需要监测用户行为数据的地方加上一段代码。


经过数据校验后的埋点数据是准确的,稳定性高,适合监控和分析;且埋点往往可以添加较多的业务属性,方便产品经理对事件进行业务属性拆解和下钻分析,能很好地从业务逻辑切入行为分析,理解行为背后的业务思路。


当然,埋点也存在一些劣势:

  1. 埋点是需要跨团队协作的;
  2. 埋点不能回溯历史数据;
  3. 往往由于埋点数量有限,许多用户行为数据可能缺失,影响数据分析的效率。


最终可能导致诸如:没有埋上点,埋点数据异常,埋点上线业务已经下线,想分析的维度忘了「埋」上去等等。


在这里,我们想特别强调的是第一点——团队协作,它可能会被很多人忽视,却是在完成埋点的过程中很重要的要素。


这是一家较为成熟的公司的埋点流程:



图自文章《完整埋点方案设计的四要素


从上图可以看到,埋点这件事,往往不是一个人或者一个团队就能完成的事情;它需要跨团队协作,需要业务人员、分析师、打点工程师、数据校验工程师等的通力合作。在实际工作中,跨团队协作常会遇到部门墙问题,沟通问题,资源优先级问题等等。同时,产品经理很难从一开始就掌握所有用户路径,很可能存在漏埋、错埋的现象,又要重新协调排期和资源,费时费力。


事实上,如果产品经理等业务人员总是能用上准确的、及时的数据,并能深度分析,那么这家公司的组织能力、数据治理的能力,以及数据驱动的文化往往都很优秀(当然这种公司的业务表现也很好)。


2. 无埋点采集


无埋点,事实上并不是真正的不需要写代码,而是前端自动采集全部事件并上报所有的数据,并通过「圈选」来获取需要使用的事件。GrowingIO 在服务上千家客户的过程中积累了大量的经验,无埋点采集的准确性在不同开发框架下都有大幅度提升。 


圈选本身不需要组织协作,产品经理可以不依赖任何人就能采集到数据,并马上在分析工具中使用,所见即所得。以往花费几天的工作,借助无埋点秒级完成。而且圈选可以回溯过去7天数据,较好地解决了“忘了埋点”这个痛点。


然而,没有一种数据采集方式可以解决一切问题,这种方式依然有其弊端。

  1. 部分业务维度无法采集:比如,能够知道用户点击了购买,但不知道购买了什么。
  2. 滑动等行为,无埋点采集暂时无法实现。
  3. 无埋点采集的数据是通过界面位置和上下级关系来标示自己的,一旦界面发生较大变化,会导致数据无法持续采集,需要重新圈选。
  4. 数据准确性也会受客户产品开发框架、开发规范以及能力的影响。


产品经理在使用时要了解这些埋点和无埋点这两种数据采集方式的优势和弊端,并判断哪种采集方式可以支持你的业务需求。


3. 什么场景下用无埋点?什么场景下用埋点?


数据采集方式的选择是基于业务场景的,那么,不同的业务场景下应该选取什么样的数据采集方式呢?


先来看看,你是否遇到过如下场景?

  • 做了一场运营活动,但没有埋点的产研资源;

  • 想衡量交互细节,而需要查看的交互细节非常多;

  • 想查看一个用户在访问时的一切行为轨迹,探索用户使用产品场景;

  • 产品每周发版,想要快速衡量每次发版的效果;

  • 要做一个分析,发现没有所需事件,打点和积累数据来不及,又需要尽快产出结论;

  • 当新功能上线时,你突然发现有一个重要的元素忘了埋点。


这类场景更适合使用无埋点事件,基本上也只能使用无埋点事件。这类场景,我们称之为「探索式数据场景」,它们具有如下属性:

  • 业务属性弱,交互属性强;

  • 需求及时性强,要快速落地得出结论;

  • 数据使用周期短,不需要长期监控;

  • 相比准确性,更需要趋势稳定;

  • 非核心数据,数据可及性 (access data) 强。


你是否也遇到过如下场景?

  • 需要每天、每周、甚至每月汇报 KPI 表现;

  • 需要分析过去一年核心 KPI 的增长情况;

  • 需要对业务进行深度分析:比如不同 SKU 的购买转化分析;

  • 需要进行归因分析:比如产品不同入口的带来的销售额分析。


这类场景是核心 KPI 监控和深度业务分析,建议使用埋点事件,尤其是深度业务分析只能使用埋点事件。这类场景,我们称之为「监控与分析式数据场景」,它们具有如下属性:

  • 数据稳定准确,反应真实业务场景;

  • 需要长期监控,数据需要长期存储;

  • 业务属性丰富,可以做深度业务分析;

  • 监控核心 KPI,指标需要少而精;

  • 需要设置数据权限,数据可及性 (access data) 弱。


这两类场景不是互斥的。作为产品经理,我们近乎同时遇到这两种场景。


一个用无埋点采集方式就能解决的问题,若使用埋点,既不能立刻看到数据,也会浪费公司工程资源;一个用埋点采集才能解决的问题,用了无埋点可能会导致数据不稳定,业务维度少等问题。



埋点和无埋点各自有自己的优势和劣势,因此有着不同的适用场景。面对不同的场景,我们需要明确目的是什么——是探索,监控,还是深度业务分析? 我们需要采集的事件多吗?我们为了实现这个目标拥有的资源是什么?结合各种情况综合判断,去采用更合适的数据采集方式。


“柢固则生长,根深则视久”,数据采集正是数据驱动的“根”。通过无埋点和埋点技术优势相结合,“准确性”和“便捷性”得以兼顾,让更多企业在数据增长体系搭建初期就能够打下坚实的基础。进而通过数据获得分析和洞察,指导商业解决和业务发展,实现数据驱动增长。


💡推荐阅读: