如何设计埋点方案

一.与埋点相关的一些概念：

(一）.埋点方式

　　1.代码埋点
　　　　代码埋点是最经典埋点方式，实施埋点的研发将埋点代码结合到业务代码中，实现用户行为数据的采集。这种埋点方式能采集到非常复杂的行为，尤其是一些非点击的、不可视的行为，必须用代码埋点来实现。代码埋点按照位置的不同，可以分为前端埋点、后端埋点。前端埋点用来记录用户在客户端的操作行为，后端埋点用来记录客户端进行服务器请求的日志。

　　　　代码埋点分为以下两种方式：

　　　　（1）前端埋点

　　　　　　前端埋点能够收集更全面、精细的用户数据，尤其是不需要请求服务器的行为数据，如：页面停留时长、页面浏览深度、视频播放时长、用户鼠标轨迹、表单项停留及终止等等，只能通过前端埋点实现。但缺点在于，前端埋点的上报一般存在 15% 左右的延迟上报和漏报（客户端未联网、数据打包上报、用户删除行为数据等原因）。另外，如果客户端是 APP，每次上线新的埋点或者更新埋点时，需要发布新的版本才行，但是会存在部分用户不更新版本情况，影响数据质量。

　　　　（2）后端埋点
　　　　　　理论上，只要客户端向服务器发送过请求，服务端埋点能够收集到。相比于前端埋点，能实时采集数据，不存在延时上报，数据很准确；并且，服务端埋点支持与用户身份信息和行为附带属性信息整合；另外，每次上线新的埋点或者更新埋点时，发布后马上生效。

　　　　代码埋点适合精细化分析的场景，我们可以将各种细粒度的数据采集下来，后续做深度分析。当然这种埋点方式很低效，需要经历完整的埋点流程，包括业务梳理（产品运营）、埋点设计（产品运营/研发）、实施/测试/上线埋点（研发/测试）。整个过程需要多方协作，且要求产品运营也具备一定的专业水平，如果发生错漏无法快速补救。

　　2.全埋点
　　　　无埋点、无痕埋点、自动埋点，指的都是全埋点。这种埋点方式想要实现的效果是全自动化埋点，将客户端的用户行为尽可能地全面采集，然后通过界面配置的方式对关键行为进行定义。使用这种方案，每次有用户行为分析的需求，不用再走一次完整的埋点流程，只用在产品中嵌入 SDK，等于做了一个统一的埋点。但是，无埋点也有很明显的弊端。无埋点只能覆盖基本的点击、展示等用户行为；其次，全埋点采集的数据量非常大，随着数据量上升，可能会导致客户端崩溃的概率也会上升。尤其是移动端，更多的数据量意味着更多的电量、流量和内存消耗；第三，即使全部行为数据都被收集回来了，具体分析时也不能避免二次梳理和加工，因为机器无法在采集时按照我们想要的方式对全部事件进行有意义的命名，甚至无法保证采集上来的事件都正好是正确的；第四，现阶段全埋点对于用户身份信息和行为附带的属性信息也几乎无能为力。

　　3.可视化埋点
　　　　可视化埋点也被称为「无码埋点」，它的理念是降低实施埋点的门槛，以此来提升原工作流程的效率。实施埋点时，无需研发人员介入，产品运营可以直接在网站或移动应用的真实界面上操作埋点，而且埋点之后立即可以验证埋点是否正确，并且，埋点部署到所有客户端也是几乎实时生效的。同样的，可视化埋点也有很多局限。首先，可视化埋点也只是针对点击可见元素的，一些动态页面、不可见的行为是采集不到的；其次，对于点击操作附带的业务属性，比较难实现；第三，为了确保埋点准确性，可视化埋点也逐步整合了更为复杂的高级设置，操作起来也很低效。

(二）.埋点方案相关概念

　　1.事件
　　　　记录用户在使用网站、APP 或小程序的过程中触发的行为。
　　　　用户的行为有一部分会在他们使用的过程中自动被采集上来，常见的如：跟访问有关的“页面浏览”，“停留时长”；另外一部分包含具体业务含义的，则需要通过埋点才能得到，例如：“注册”、“登录”、“支付”等等。
　　2.事件属性
　　　　可以通过属性为事件补充相关的信息，例如：位置，方式和内容。
　　　　用户产生行为时就会上报具体的属性值，比如对“购买事件”定义了“支付方式”的属性值，则根据不同的行为可能上报的是微信支付，支付宝支付。事件属性有点像字段，发生这件事件的一些相关字段都可以理解为属性，例如“购买事件”中的支付平台、金额、银行卡等相关字段，都可以被定义为事件属性。
　　3.用户属性
　　　　在分析过程中，需要引入注册用户的更多维度，比如注册用户ID、姓名、用户等级等等，也需要进行梳理，方法同事件属性。

二.埋点方案，以京东排行榜为例

1.首先分析分析当前APP所处的阶段，设置合理的目标。
京东排行榜是为了让用户跟着排行榜购买好物，即为了让用户更多地消费，同时由于推荐的是经得起考验的好物，也希望能在客户心目中留下好的口碑，提高用户对APP购物体验的满意度。
因此，本次埋点的目的是为了收集用户的行为信息，提升用户体验、以及收集用户信息，进行精准推送，提高转化率。