数据驱动增长-埋点那些事

第142篇文章 | 埋点那些事

图题：危险地带。

想要把市场做大，无非是开源节流。开源，即扩大漏斗顶端的流量入口，获取更多的外部流量；节流，在流量一定的情况下，提高每个漏斗环节的转化效果，最大限制地用好每个用户。当互联网人口红利渐渐消失，流量的获取变得超来越昂贵时，节流更为重要，如何精细地用好每一粒流量是每个互联网人都需要思考的问题。而数据正是互联网的新石油，数据驱动增长成为主流。

信息是用来消除决策时的不确定性

人们在决策时总要会依赖过往的经验（信息），以最大限度地消除不确定性。人们喜欢说，我这个数是拍脑袋拍出来的。拍脑袋，就是他根据自身经验得到的估算，这里含有个人主观能动意识。拍脑袋，能多大限度上取得最优的决策取决于决策者的能力。而对于大多数情况、大多数人而言，数据无疑是辅助决策的不二选择。

对于用户行为而言，数据用于辅助决策之前，需要经历以下几个阶段：

数据采集：埋点

数据传输：实时/批量

数据存储：数据建模

数据分析：数据处理、统计、挖掘

数据显现：报表、看板

今天，我们聊聊数据最源头的地方，也就是埋点采集。对于国外一些以数据为驱动的公司，如FB、LinkedIn，他们将数据的埋点采集与产品的设计视为同等重要。

何为埋点？

早期的网页数据采集只有页面打开这个行为，而并不涉及到用户与产品UI页面的交互统计，即我们常说的PV和UV。随着互联网的发展，产品的运营者还需要关注用户与产品页面的交互行为、路径及用户的属性，因此PV和UV已经不能满足运营者对用户行为的分析需求。因此，新的采集方法运转而生：

开发者需要事先在产品页面中写入数据收集的代码。当用户与页面产生交互（浏览或点击），即触发该事件，执行事件埋点的代码，从而将与此事件相关的信息上传以完成信息收集。

埋点的分类：

前端代码埋点

此埋点收集用户行为交互信息为主，在前端页面通过SDK嵌入埋点统计代码。对于每一个行为事件，都需要对其进行定义，嵌入前端，每定义一个行为都需要产品与技术沟通。

优点

简单便捷，前端只需要写很少的代码就可以加上埋点。

通常通过第三方提供分析的SDK，发布后就可以在第三方平台上（如谷歌分析）看到数据。

缺点

只能采集到用户与页面交互的行为，对于其他维度的信息，前端埋点采集不到。

需要需求方、产品、技术沟通，有很大的沟通成本，当需要埋的点过多时，人工操作容易出错。

出现漏埋点错埋时，更正的周期长。每次埋点生效都需要依赖版本的发布，如果出现漏埋，只能等下一次版本发布时加上，中间这个等待的时间周期很长。

埋点规范性不强，不同业务线的产品经理和技术采用的命名规范不一样，会导致埋点混乱。

数据可靠性受多种因素影响：网络状态、统计口径等。

后端代码埋点

此埋点收集用户属性信息为主，将用户属性相关的数据进行统计，如用户注册时间、订单及人口属性等。

优点

可以收集用户其他维度的信息，很好地与前端埋点补充。

可以通过内网完成数据的传输，数据不受网络因素影响。

全埋点

也称无埋点，将埋点SDK直接嵌套到网页中，把用户所有交互行为都尽可能收集回来，不需要前端每次都是写入，神策、growing IO都是采用这种全埋点的方法。

优点

埋点比较规范，有统一的标准。

不需要像前端埋点一个根据需求一个一个地添加，减少人工的重复操作和犯错的可能性。

缺点

在技术实现上，它是前端埋点的一种，因此有前端埋点固有的缺点。

通常需要与手动代码埋点相结合

至于在实操中选用哪种埋点方式，因人而异，以上三种方式，没有所谓的哪种最好，在多大数情况下，适合自己的才是最重要的，需要跟产品发展的阶段、手上可分配的技术资源、运营的需求来决定。

如果只是想看看宏观上的数据，并没有精细化运营的需求，那可以选用全埋点或前端埋点+GA就可以搞定。如果想根据用户的属性，想知道准确的核心的转化数据，那当然后端埋点无疑为最好的选择。像EBizcamp提到的，某OTA的机票埋点随着业务复杂度的增加而在做加法，先后上的埋点包括ctm、action、trace、pv、服务端埋点等五种埋点（这五种都是他们定义的）。

最后的最后，埋点需要专业的人去做。此文不过是路过了，顺便了解了一下。

参考：

《数据驱动 从方法到实践》

END

About Me

至善叔叔

曾工地搬砖工 现互联网管培生

趣事藏在这看似无聊、重复、单调的日常生活中