通俗易懂理解数据埋点如何做？

最近一段时间在进行数据埋点的重构，目前已经拉通前后端开发、测试、数据（数仓和数分）评审过后进入开发阶段。在这段时间也输出了一些关于数据埋点相关文章，和其他的产品交流如何进行埋点设计的时候反馈有点不太通俗易懂，因此梳理一个较通俗易懂的文章供一起交流学习。

埋点设计相关文章：

如何设计产品数据采集方案？

如何设计产品的数据埋点方案？

数据埋点我们应该如何做？

1、明确业务的诉求，梳理业务的关键指标，以及产品关注和分析的指标有哪些，梳理业务场景。

如用户登录，关键指标是登录率，产品关注的指标是点击率、转化率等相关指标。业务场景有一键登录场景、手机验证码登录场景、三方登录场景、注册场景等场景。

也可以梳理一下各个指标是如何计算的，方便后续变量设计。

如登录的点击率如何计算，一般理解点击率 = 曝光PV/点击PV，在实际的计算中稍有不同，如果用所有的曝光进行计算，可能造成数据的可信度较低。

产生曝光可以分为用户正常进入登录流程产生的页面曝光还是返回时页面的曝光，这个时候可以在变量设计的时候增加前项地址和后项地址来进行对曝光更精准的上报让数据更加准确，有利于产品的策略分析和决策。

2、确定埋点上报方式

目前很多应用的埋点都是通过公共的统计SDK上报的，统计SDK一般有基础属性和事件数据，基础属性如一个移动应用的公共字段包含imei、机型、系统、app版本、手机型号等公共信息，事件数据需要产品根据业务场景进行抽象自己定义。

3、根据场景设计事件与变量、触发机制、上报机制等

事件设计：用户登录的不同登录方式的场景可以抽象到一个事件中进行上报。如所有登录场景的曝光和点击数据可以统一抽象到一个时间中上报以及登录后的结果也可以抽象到一个事件进行上报。

变量设计：根据产品需要分析的指标设计变量，在数据上报的时候包含基础属性和事件属性，因此在设计的时候需要观察基础属性中的上报变量有哪些，如果已经包含了在事件变量中不用重复进行上报。变量设计时变量名要便于以后了解因此尽量保持统一规范。

触发机制：不同的业务定义触发含义不同，有的曝光行为定义为页面加载完成算一次曝光，有的曝光行为定义为用户停留X秒算一次曝光。

上报机制：实时上报或非实时上报。

4、报表设计

报表设计可以在业务埋点上报后确认埋点后再设计，也可以先行设计。先行设计主要是为了在拉通数据在评审时看报表中需要的维度和指标在埋点方案中是否可以实现，以及统计的口径是否符合预期。

5、数据埋点方案的确认

需要拉通和开发、数据（数仓和数分）确定埋点方案的可行性，有的公司的数仓和数分是一起的，有的是分开的。确定设计的埋点方案数据是否可以采集以及报表的相关维度和指标是否可以生成。

6、埋点开发

明确场景的优先级和埋点规划，按照优先级先开发优先级比较高的埋点，埋点方案开发测试完成后，并进行埋点校验。

7、数仓开发和报表开发

数据校验后进入数仓的开发和报表的开发。

不同公司的上报方式不太一致，之前接触的埋点是上报到hdfs和kafka中，hdfs中的数据做离线数据报表做业务分析，kafka中的数据进行实时数据报表开发进行实时数据监控。

整个的数据埋点基本完成后续可能有其他维度或者指标的添加。

个人分享，仅供参考。