产品经理的埋点选择

1 评论 7430 浏览 59 收藏 8 分钟

产品经理需要了解什么场景下使用无埋点事件,什么场景下使用埋点事件,以便于满足他的数据诉求。

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

在多年的实践中,我们陆续发现,只用一种数据采集方式无法解决日益复杂的数据分析需求,无法适应高速迭代的产品开发节奏。越来越多的公司(如网易,美团,有赞等)开始采用多种采集方式协同使用的方法进行数据分析。

产品经理需要了解什么场景下使用无埋点事件,什么场景下使用埋点事件,以便于满足他的数据诉求。

在了解场景之前,产品经理须知道上述数据采集能力的特性和边界,才能能扬长避短,充分发挥两种采集能力的优势。

埋点事件, 顾名思义就是借助埋点(写代码)来采集数据,在需要监测用户行为数据的地方加上一段代码。经过数据校验后的埋点数据是准确的,稳定性高,适合监控和分析。埋点往往可以添加较多的业务属性,方便产品经理对事件进行业务属性拆解和下钻分析,能很好地从业务逻辑切入行为分析,理解行为后的业务思路。

当然,实现上述目标,付出的代价相对比较高。

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

其次,埋点不能回溯历史数据。

最后,往往由于埋点数量有限,许多用户行为数据缺失,分析过程中数据缺失比较严重。

最终导致诸如:没有埋上点,埋点数据异常,埋点上线业务已经下线,想分析的维度忘了「埋」上去等等。另一面讲,如果产品经理等业务人员总是能用上准确的,及时的数据,并能深度分析,那么这家公司的组织能力,数据治理的能力,数据驱动的文化往往都很优秀(当然这种公司的业务表现也很好)。

无埋点事件,当然它并不是真正的不需要写代码,而是前端自动采集全部事件并上报所有的数据,并通过「圈选」来获取需要使用的事件。圈选数据不需要组织协作,产品经理不依赖任何人就能采集到数据,并马上在分析工具中使用,所见即所得。

以往花费几天的工作,借助无埋点秒级完成。而且圈选可以回溯过去7天数据,较好的解决了忘了「埋点」这个痛点。

然而,没有一种数据采集方式可以解决一切问题,这种方式依然有其弊端,产品经理在使用时要了解这些弊端,并判断这种采集方式是否可以支持你的业务需求。

常见的弊端:

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

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

你是否遇到过如下场景?

  • 做了一场运营活动,工程师没有埋点资源。
  • 想衡量交互细节,而需要查看的交互细节非常多。例如优化搜索流程。
  • 想查看一个用户在访问时的一切行为轨迹,探索用户使用产品场景。
  • 每周发版,衡量发版的效果。
  • 要做一个分析,发现没有所需数据,打点和积累数据来不及,又需要尽快产出结论。
  • 当老板向你要一个数据,你没有采集这个数据。
  • 当你发现新上线的功能,有一个重要的元素忘了埋点。

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

  • 发日报,周报汇报 KPI 表现。
  • 分析过去一年核心KPI 的增长情况。

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

  • 深度业务分析:比如不同 SKU 的购买转化分析。
  • 归因分析:比如产品不同入口的带来的销售额分析。

第一类场景更适合使用无埋点事件,基本上也只能使用无埋点事件。

这类场景,我们称之为探索式数据场景,它们具有如下属性:

  • 业务属性弱,交互属性强;
  • 需求及时性强,要快速落地得出结论;
  • 数据使用周期短,不需要长期监控;
  • 相比准确性更需要趋势稳定;
  • 非核心数据,数据可及性(access data)强。

第二、三类场景核心KPI监控,建议使用埋点事件,深度业务分析也只能使用埋点事件。

这两类场景,我们称之为数据监控与分析式数据场景,它们具有如下属性:

  • 数据稳定准确,反应真实业务场景;
  • 需要长期监控,数据需要长期存储;
  • 业务属性丰富,可以做深度业务分析;
  • 核心KPI,指标需要少而精
  • 需要数据权限,数据可及性弱。

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

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

面对不同的场景我们需要明确目标是什么,是探索,监控还是深度业务分析? 我们需要采集的事件多吗?我们为了实现这个目标拥有的资源是什么?我们的 Deadline 是什么?

结合各种情况综合判断,采用合适何种埋点方式。

 

本文由 @谭永志 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 只写出了 是什么 为什么 怎么做都没写 不怎么样这文章

    来自福建 回复