什么是埋点？

第一次听说埋点还是在某飞，听到产品总监提到这个词。简单来说，在正常的业务逻辑中嵌入数据采集代码的过程就叫埋点。如今在一家数据采集与应用公司，对埋点认识也深入许多，记录一份好的埋点方案应该怎么设计。

现状和痛点

数据口径不一致

随着企业数字化转型愈受重视，多数 IT 团队或多或少都会进行埋点的设计，但是一家公司包含多个团队可能都在各自为战，埋点采集的数据无法实现 1+1 > 2 的作用。简单来说，可能一个页面浏览时长的采集，单位可能就有毫秒、秒、转换好的时分秒，无法统一管理分析；

埋点实施经验不足

埋点是一项专业性很强、系统性也很强的工作。遇到过某家大型民营银行之前的埋点个数足有 2000 多，耗时耗力不说，真正是否能实现价值也很难说。代码如何实现埋点、采哪些、在哪一端采、如何实现最小可行性的埋点方案，如何验证，前期做好功课，后期使用才会更省心。

团队配合困难

首先，进行埋点的同事和业务开发的同事不一定是一拨人，埋点同事需要先了解业务，再去针对性的实施埋点，本身就有难度，也需要耗费大量精力。其次，埋点的需求公司一般不会作为高优先级去做，也就很难有话语权；最后，采集的数据，数据分析人员如何使用、如何衡量业务指标，推进产品优化，也需要长时间的打磨。

设计原则

深入业务分析场景

埋点方案一定要结合业务场景来设计，不然采集的数据也没有意义。比如运营人员关心的指标是购买转化率，则埋点方案需要采集包括用户从看到某个促销活动到最终购买的整个过程。

多维度结合设计

对于需要采集的行为，需要结合多维度。对于用户行为事件来说，需要采集 who, when, where, how, what 等信息，完成每个事件的维度 /属性/字段的采集，对事件发生形成一个快照。

最小可行性原则

埋点不是愈多愈好，没有意义的埋点不需要加，可以合并为一个事件就不需要拆分。比如登录、注册的行为可以使用同一个事件，属性 element_content 不同即可。

埋点内容包括哪些？

页面和元素的采集

全埋点

全埋点，又称无埋点，只要在产品中集成对应的 SDK，就可以实现一些预置事件的自动采集。优点，开发工作量小；缺点：埋点质量通常较差。

自定义埋点

自定义埋点，又称代码埋点，全埋点无法实现的，各种自定义指标的采集，都需要自定义埋点实现。优点：数据准确度较高；缺点：开发工作量大。

自定义埋点使用原则

• 质量要求高，业务流程关键步骤；
• 开发资源充足；
• 数据准确性要求高；

  前后端埋点选择

  前端

  用户的行为正常都是在前端触发的，所以埋点一般也会选在前端。客户端开发者对于埋点实施，一般配合度较高，但是客户端可能由于网络波动等原因，存在丢数据的风险。

  后端

  对于服务器行为或者只能在后端才能采集到的业务行为，如发券，支付成功，只能选择后端埋点。后端开发者一般配合度不高，因为业务代码轻易不改动，也可能存在时钟不同步的问题；对使用者来说，后端虽然属性较少，但业务属性更容易获取，数据准确。

  公共属性设计

  想要记录一个人的行为简单来说需要包含两个维度，事件维度和用户维度，这也是进行数据分析的核心依据。所以想要丰富事件和用户维度，属性设计必不可少。公共属性包含事件属性和用户属性，拿加入购物车的事件举例，什么时间发生的事件、触发事件的地点在哪里、使用什么设备、加入的是什么商品，都属于事件属性，发生事件的人姓名、性别、会员等级、是否有优惠券等信息属于用户属性。需要在所有事件上都携带的，就是公共属性，所以公共属性也是埋点设计方案的重要一环。

  时长类事件设计

  前面的事件都属于即时上报的，有的事件需要持续一段时间，就属于时长类事件，比如视频播放时长、页面浏览时长、视区停留时长。
  在代码实现方面，需要定义开始时间、结束时间，相减得到 event_duration，再进行代码埋点上报。或者上报事件还是通过即时上报，比如上报视频开始播放事件、结束播放事件，到了分析系统再进行事件切割实现时长的功能。

  产品性能行为设计

  埋点设计很重要的一点是为产品优化提供数据支撑，所以需要在性能方面埋点，比如页面报错的埋点，页面加载时间的获取等。

  总结

  兵法有云：兵马未动粮草先行，在数据分析体系中，数据采集是最基本也是最重要的。埋点做不好，各种分析模型、数据应用都是无本之木无源之水，希望本文能对埋点工作提供点思路。