引言

       上篇文章中我们浅谈了一下埋点是什么，埋点需要具备哪些要素，哪些场景下需要埋点和业界内常用的埋点方式。这篇文章着重谈一下埋点技术上的实现原理，还望看官们不喜勿喷。

埋点的原理

       埋点的核心在于在应用程序或网页的特定位置插入代码，以捕捉用户的某些动作（如点击、浏览、完成交易等）。当用户执行相应操作时，这些代码就会被触发，并将相关数据发送到分析平台进行后续处理。

主流埋点技术简析

一、前端埋点

1、代码埋点

代码埋点是最经典的帮助工程师了解用户是如何使用产品的埋点方式。因为是工程师人工将埋点结合到代码逻辑中，理论上只要是客户端种的操作，再复杂也能采集到。

常见的如：页面停留时间，页面浏览深度，视频播放时长，用户鼠标轨迹，表单项停留及终止等等。尤其是一些非点击的、不可视的行为，非代码埋点实现不可。

代码埋点的原理是通过在代码中手动添加埋点代码，通过监控用户行为事件来收集用户数据。这种方式需要开发人员的配合，适用于网站或应用开发过程中。代码埋点的优点是灵活性高，可以准确记录用户行为数据，但缺点是维护困难。例如，在电商网站中，可以在商品详情页的购买按钮处添加一个点击事件的埋点，记录用户点击该按钮的时间、位置和商品信息等数据。这种方式通过技术手段实现，也被称为自定义埋点，

2、客服端SDK

客户端SDK通常是一组库和工具，它们被设计用来帮助开发者更容易地与特定的服务或平台进行交互。实现一个SDK通常需要考虑跨平台兼容性、安全性、稳定性和性能等因素。

客服端SDK可以分为以下几类

1.     iOS SDK：顾名思义，就是以iOS操作系统进行开发的SDK工具包；

2.     Android SDK：同样是以安卓操作系统进行开发的，可应用在所有安卓类软件中；

3.     H5 SDK：指以网页操作系统为生的SDK，可应用在web网站、H5网页、公众号（功能实质是H5开发）等；

4.     小程序 SDK：小程序是这两年新兴的产品应用，依赖于不同的软件平台。所以需要基于不同的平台进行开发，比如微信小程序、支付宝小程序、百度小程序等，同时还需要分iOS和Android两大系统进行开发。

3、服务端SDK

       服务端sdk具体通过后端上报数据，即业务应用采集到数据后，通过自身的服务端传到大数据系统的服务端，即“业务服务端-数据服务端”，而非客户端SDK的“业务服务端-客户端SDK-数据服务端“。

类型：由于每个业务的状况不同，开发语言都不是唯一的，所以针对服务端类型的SDK都会基于不同的语言提供相应的开发版本，包括Java SDK、Pyhon SDK、PHP SDK、CSDK等等

二、可视化埋点

代码埋点的缺点对于网站还好，但对于移动应用来讲无疑是格外低效的。为了解决这个问题，在一部分厂商选择全埋点的同时也有大量厂商选择了一种所见即所得埋点的道路，即可视化埋点。

可视化埋点的好处是可以直接在网站或移动应用的真实界面上操作埋点，而且埋点之后立即可以验证埋点是否正确。此外，将埋点部署到所有客户端也是几乎实时生效的。

因为可视化埋点的这些好处，分析的需求方，业务人员，没有权限触碰代码或者不懂得编程的人都可以非常低的门槛获取到用于分析的数据。可谓是埋点的一大进步。

可视化埋点的部署原理也很简单。

支持可视化埋点的SDK会在被监测的网站或移动应用被访问时向服务器校验是否有新的埋点，如果发现更新的埋点，则会从服务器下载并且立即生效。这样就能确保服务器收到最新的埋点后，所有客户端都能在下一次访问时得到部署了。

可视化埋点和全埋点有着对埋点和分析全然不同的追求：

可视化埋点的理念是提升原工作流程的效率——依然要梳理需求、设计埋点；

全埋点则是将工作流都进行了简化——反正数据会被采集回来，这两步的必要性就容易被忽视。

这里不能说孰优孰略，因为事先严谨的计划和事后发散的探索都是分析中的不同角度。况且这两种埋点也完全不是排他的，完全可以同时使用。

但不可否认的是，可视化埋点局限性也很多：

第一，   可视化埋点也只是针对点击可见元素的，其中可见元素最常见的就是点击行为了。对于点击操作的埋点也确实是目前可视化埋点的主攻点。但从实际情况看，复杂页面、不标准页面、动态页面都给可视化埋点增加不可用的风险，一旦遇到就只能代码埋点。

第二，  对于点击操作附带的业务属性，虽然也可通过进一步选取属性所在元素来获取属性信息，但国内除了易观方舟外，其他厂商支持得好的就比较少了。

第三，  为了确保埋点准确性，可视化埋点也逐步整合了更为复杂的高级设置，例如：“同页面”、“同版本”、“同层级”、“同文本”……。但加上了这些复杂设置的可视化埋点，还是那个为提效而生的可视化埋点吗？

三、无(全)埋点

全埋点，一些国内的团队也称“无埋点”、“无痕埋点”以及“自动埋点”。是一种对全自动埋点方式的探索，而且从名字看仿佛是个一劳永逸的解决方案，那我们先看看什么是全埋点。

客户端埋点一般分为访问级、页面级、页内行为级：

用户访问一个网站或启动一个移动应用时几乎所有的厂商都会自动采集上报用户的访问；

当用户访问不同页面时，有一部分厂商就会选择不默认自动采集，而将其作为一个选项交给用户；

而对于用户在某一个页面内详细的操作行为，只有极少数厂商支持自动采集上报。

实现了后两种自动采集的厂商，通常会说自己是全埋点。但页内行为级的采集也还可以进一步探讨其采集的范围。最常见的就是自动采集可交互元素和自动采集所有元素的差别：

可交互元素包含：链接、表单项（如按钮、输入框等）、HTML的对象级元素等；

不可交互元素就太多了，绝大多数的页面元素都属于此类。

由于实际上网页和移动应用中的大家可以看得到的界面很多都并不是标准元素，所以实际上界面上很多看似可交互的元素也都是无法自动采集上报的。这一点不可不谓之遗憾。

全埋点确实会自动采集非常多的数据，而且未来在使用数据的时候就可以从数据库中直接查询，不会面临我想看的时候因为没有埋点采集而获取不到的情况。这是非常受分析师喜爱的方式，因此经常会听到“能采集就尽量都采集，后续分析总能用得到”。

其次，埋点是比较耗时的工作，需要业务方提供方案，工程师进行埋点，测试团队进行测试。而由于实际工作中埋点数量比较多，每次发布新功能或新活动都需要新的埋点，所以埋点不但费时，而且错误率也难以控制。

有了全埋点，数据用不用都先收回来，由于都是程序自动完成，业务人员想要A而工程师埋成B这种错误也几乎不存在。

然而任何事务都有它的两面性。

第一，全埋点的“全”并非真的全部。基本的电脑浏览器和移动应用中页面内常见的用户操作包括鼠标行为、键盘行为和手指行为。例如网页端常见的鼠标点击、鼠标滑动、屏幕滚动、键盘录入、光标选取甚至静止等；移动端除了类似点击的按下，还有多指开合、拉动、用力按下等。但这些操作并不会都被“埋点”，能埋点的通常仅限点击或者按下，这显然是远远不够的，甚至我们都不能称之为全埋点。

 第二，全埋点的“全”以采集上报的数据量为代价，随着数据量上升导致客户端崩溃的概率也会上升。尤其是移动端，更多的数据量意味着更多的电量、流量和内存消耗。从这个角度来看，想做到真正的“全”在现阶段也是很难。

 第三，即使全部行为数据可以被接收回来，具体分析时的二次梳理和加工也无法避免，甚至痛苦。因为机器无法在采集时能按照我们想要的方式对全部事件进行有意义的命名，甚至无法保证采集上来的事件都正好是正确的。于是前期埋点时节省下来的人力成本，这个时候又都搭进去了。

 第四，现阶段全埋点对于用户身份信息和行为附带的属性信息也几乎无能为力。

那么这个功能到底是我需要的吗？这其实是个度的问题。关于这个问题，需要结合实际情况，如果你更需要随机探索过去点击行为的趋势，那么这个功能就合适，否则还有更好的选择。

数据上报

数据上报是指将数据从一个系统或应用程序发送到另一个系统或应用程序的过程。在各种领域中，包括科学研究、商业和政府机构，数据上报是非常常见的。通过数据上报，组织可以收集、整理和分享信息，以便进行分析、决策和监测。

由于SDK在嵌入应用程序前，就已经打通与服务端的接口并进行上报。所以此时SDK是已经界定了一系列的上报逻辑，以及需要传什么数据。

原始数据：其实就是一条条原始数据记录，每条数据附带那一刻采集的诸多信息，包括用户ID、设备数据、埋点数据等，但这些数据并不是每条都必带的，取决于当时的环境是否有提供这些信息。

Session：指某一次节会话信息，主要为了记录用户行为习惯。因为每个用户操作习惯、时长都不同，有可能突然不再操作，又可能隔几分钟在操作，对于这样的情况需要基于业务场景的诉求，定义这些session逻辑，并分别创建不同的sessionid去分割。比如停止操作几分钟后、程序退出或切换至后台等是否需要定义。

Cookie：主要是网站使用的一种识别用户的数据集，一般存储在用户本地终端上，以便于用户在不同时间操作时都可以快速调用且识别为同一个设备用户。与session区别在于，Cookie存储在浏览器内，数据量有限且相对没那么安全

前端埋点收集到的数据需要上报给服务端，目前较为常用的方案有以下几种

第一，传统XHR请求

优点：可以灵活地设置请求头属性，post请求可以发送大体量数据，满足特定场景的埋点需求。

缺点：数据量大的请求占用带宽资源多，增加服务器压力。页面销毁时的监控埋点大概率上报失败。

第二，  Image对象

 利用图标对象的src属性发送get请求上报数据

优点：上报数据的请求不需要接收响应，可灵活跨域，src请求体量小，速度快，页面销毁时的监控埋点会等上报请求发送完毕，再执行页面卸载。

缺点：无法发送大体量数据，页面销毁时有监控埋点会让页面关闭速度变慢，影响用户体验。

第三，   Beacon API

Beacon api 是w3c新引入的补充性api，就是用来解决web页面在触发卸载销毁事件unload期间会中断所有异步xhr请求的问题。这个API给navigator对象增加了一个sendBeacon()方法。这个方法接收一个URL和一个数据有效载荷参数，并会发送一个POST请求。可选的数据有效载荷参数有ArrayBufferView、Blob、DOMString、FormData实例。它会保证页面在已经关闭的情况下也会发送请求。

不过它也有缺点：

1.      只支持post请求，并且发送的数据量不会像正常xhr的post数据量那么大，最大数据量大小是由客户端（用户浏览器）版本决定的，chrome@70版本测试大概15MB左右。

2.      因为是新补充的api，会存在浏览器兼容性问题，如图：

综上，埋点数据上报在上报轻量级的数据时可以采取image src属性进行上报，特定场景需要采集大量级的数据可以改用普通post请求方式，在需要监测用户关闭浏览器时上报数据，首选采用beaconApi方式，若用户的当前浏览器不支持该方法，可降级为image方案。目前很多大厂已采用这种混合式埋点方案。