一、前言

神策分析 Web JS SDK，是一款轻量级用于 Web 端和 H5 端的数据采集埋点 SDK，它的核心功能是数据采集和发送数据到指定的服务端。具体而言，是指使用原生 JavaScript 技术实现代码埋点、全埋点、可视化全埋点、网页热力图和触达图等功能。下面，我们将对这些功能逐一进行介绍。

二、数据采集

对于 SDK 而言，数据采集是指在用户行为触发时（例如：进入某个页面、点击了某个按钮等），按照既定的数据格式，将用户的行为进行数据化。按照采集方式的不同，可以分为代码埋点、全埋点和可视化全埋点等。

2.1代码埋点

2.1.1 概要介绍

代码埋点又称为自定义埋点。具体含义是：在 SDK 初始化之后，对于每一个关注的事件，调用 track() 等相关接口，将采集的数据保存到发送队列中，然后按照一定的发送策略将数据发送到指定的服务端。例如：某个 li 元素被点击，如果想采集这个 li 元素的点击事件，就需要在 li 元素的 click 事件代码中采集数据。

2.1.2 使用场景

代码埋点有很多优点：

（1）精准控制埋点位置。

（2）灵活的自定义事件和属性，方便采集丰富的业务相关数据。

（3）可以满足精细化的分析需求。

当然，代码埋点也有相应的缺点：

（1）埋点代价比较大，每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且需要技术人员参与。

（2）更新的代价比较大，每一次更新埋点方案，都必须修改代码。

（3）所有前端埋点方案都会面临的数据传输时效性和可靠性的问题，这个问题只能通过在后端采集数据来解决了。

因此，可以知道代码埋点适用于需要精准控制埋点位置、灵活的自定义事件和属性等精细化需求的场景。

2.2全埋点

2.2.1 概要介绍

全埋点又可以称为自动埋点。具体含义是：当集成使用了 SDK，开启了对应的配置项，就可以自动采集数据。采集的范围包括：页面浏览、页面元素点击、视区停留等。

（1）页面浏览：用户打开网站或者 H5 页面时，立即触发一次页面浏览事件，然后采集相关数据并发送到指定的服务端。

（2）页面元素点击：用户在网站或者 H5 页面内，对于 a input button textarea 元素进行点击时，触发页面元素点击事件，然后采集相关数据并发送到指定的服务端。

（3）视区停留：用户在网站或者 H5 页面内，有效停留一点时间，比如 4 秒（时间可以自定义），触发了 document 的滚动。此时，会采集相关数据，记录有效浏览，并发送到指定的服务端。

2.2.2 使用场景

全埋点有如下优点：

（1）展示宏观指标，满足基本数据分析需求。通过展现 PV、 UV 等网站分析的宏观指标，告诉运营人员每个控件被点击的量有多少，哪些控件值得做更进一步的分析，有助于企业了解用户行为，为进一步数据分析指明方向。

（2）技术门槛低，使用与部署较简单。只需要嵌入 SDK，极大程度避免了因需求变更、埋点错误等原因导致重新埋点的复杂工作。

（3）用户友好性强。自动向服务器发送数据，避免手工埋点的失误。

同时，全埋点也有一些缺点：

（1）全埋点只能采集到用户交互数据，且适合标准化的采集，自定义属性的采集需要代码埋点来辅助。每个用户的交互行为均有许多属性，全埋点无法深入到更细、更深的粒度。

例如：在电商行业中，用户点击 “购物车” 是一次交互行为。全埋点会忽略用户信息、商品品类等其他维度信息，此时需要配合代码埋点来辅助数据采集；再如用户上滑屏幕时，内容瀑布流的底部载入、商品或广告的加载展示、下拉菜单中下拉内容的数据点击等情况，这类自定义行为的采集需要代码埋点来辅助实现。由于全埋点仅适合标准的方案采集，一些数据分析平台也开始支持用户为每个事件添加自定义属性，如此能大大扩展事件分析的效能。

（2）全埋点是前端数据采集方式之一，因此具有前端埋点的天然缺陷。例如，数据采集不全面、传输时效性较差、数据可靠性无法保障等问题。全埋点的技术原理依赖网站终端技术开发的严谨性与规范性、网络状态、网络口径等因素。

因此，可以知道全埋点适用于以较小的埋点代价采集尽可能多的用户行为数据的场景。

2.3可视化全埋点

2.3.1 概要介绍

运营人员能够对用户行为进行分析的前提，是对大量数据的掌握。在以往，这个数据通常是由开发者在控件点击、页面浏览等事件中通过编写埋点代码来完成数据采集的。然而传统的操作模式每当升级改版时，开发和测试人员就需要不断重复的对代码进行更新，整个流程耗时长，无法满足业务的需求。

可视化全埋点应运而生，它可以通过一个操作界面，直接指定采集某个页面的浏览事件或某个元素的点击行为。例如，订单详情页面的浏览事件、提交订单按钮的点击、支付按钮的点击等。同时，可以为这个点击行为定义一个特定的分析事件来记录和追踪。

可视化全埋点为埋点工作提供了一个可视化的操作工具和界面，让埋点变得更加显而易见和易于操作，只需要简单的选择关注的按钮，并设置相应的采集属性，即可完成埋点工作，如图 2-1 所示。

图 2-1 可视化全埋点

2.3.2 使用场景

介绍了可视化全埋点的功能之后，下面我们来看下它有什么优缺点：

优点：

（1）让埋点行为可见，操作起来更容易。

（2）降低埋点的技术壁垒，运营人员可直接埋点，无需研发参与。

（3）降低埋点成本，提高了埋点的效率。

（4）避免了代码层面的变动，减少了代码变动出 bug 的风险。

缺点：

（1）可视化全埋点目前还只是提供部分元素点击事件的埋点，埋点的范围比较有限。

（2）不支持增加自定义属性。

下面，我们列举一个常见的运营场景：

运营需要对一个公司推出的拉新活动做一个分析，分析不同拉新活动的效果，不断调整拉新策略和偏重。

通常，运营将设计好的追踪数据节点和格式设计好发给研发部门埋点。研发部门会安排人力，并排期开发。开发完成后，由于代码上的变动，需要进行测试验收。测试验收后，才可以进行版本的发布。这个过程因为还涉及到部门的交互，整个流程耗时会比较长。

这是第一版的准备工作，提前花一些时间还是可以接收的。但第一版的分析结果出来后，需要快速迭代新的运营策略时，此时活动依然在进行。必须保证快速调整和迭代，按照以往的流程就来不及调整了。因为活动不可能停滞，等待重新埋点上线。这种情况极大的限制了运营的效率。

因此，可以通过可视化全埋点来解决上述问题。

它灵活、方便，不需要开发者对数据埋点添加任何代码，只需要运营人员连接管理平台并选择页面中需要埋点的元素，即可添加随时生效的页面埋点。

这让运营人员可以独立完成一个运营计划的设计、推广和效果分析的闭环。并且操作方便快捷，相比于以往的开发者参与代码修改需要排期开发、测试以及发版的流程上来说，时效性上有了一个巨大的提升。以往运营人员进行一次运营活动，在设计、沟通需求、开发、测试、发版、分析运营数据这个庞大的流程中消耗大量时间。

同时，如果考虑到运营过程中的调整，那以往的流程更是一个灾难。可视化全埋点恰恰能够很好的解决这个痛点，让运营人员可以掌握整个运营活动的闭环。快速的迭代和分析运营效果，极大提高运营的效率，提升运营的价值。

2.4网页热力图

2.4.1 概要介绍

网页热力图又可以称为点击图，即应用一种特殊高亮的颜色形式，显示页面或页面组区域中不同元素点击密度的图示。在用户行为分析领域，点击分析被应用于显示页面或页面组（结构相同的页面，如商品详情页、官网博客等）区域中不同元素点击密度的图示。包括元素被点击的次数、占比、发生点击的用户列表、按钮的当前与历史内容等因素。

网页热力图的数据来源自页面元素点击采集的数据，如图 2-2 所示。通过网页热力图可以显示页面的点击率和点击占比的信息，同时可以观察用户的点击习惯和分析一些关键位置按钮的点击效果。

图 2-2 网页热力示意图

2.4.2 使用场景

网页热力图是一个很直观和典型的数据可视化分析的功能。对于网页来说，点击是最重要的用户行为。所有的用户操作都离不开点击，所以通过网页热力图观察点击的频率和占比是非常有价值的。

对于运营人员来说，直观展示出页面元素的点击分布和占比，可以直接看到用户点击的痕迹和分布，了解页面上最受欢迎的点击位置，呈现访客热衷的区域，帮助运营人员或管理者评估网页设计的科学性。

另外，相比于其他的柱状图、折线图和数据表格的可读性，网页热力图直接将原始页面展示给运营人员，可以直观的得到分析的结果，看到用户的点击频率和占比。

2.5网页触达图

2.5.1 概要介绍

网页触达图，以水平线的方式划分页面被用户浏览的比率，适用于一些有纵向滚动条的页面。触达图依赖全埋点的预置事件 $WebStay 的采集。默认情况下，用户在浏览页面时，有 4 秒的停留时间，即为有效浏览。最终根据所有用户有效浏览页面的高度占比，来计算和划分网页触达图。

我们默认首屏展示的内容，所有用户都已经浏览，另外计算有 4 秒的停留即为有效浏览。当用户打开页面后，停留时间大于等于 4 秒时，触发了页面的纵向滚动，此时计算当前页面的底部到顶部的高度差，并记录和采集数据。最终，如果该用户在页面上有多次这样的有效浏览行为，我们计算一个最大的高度差，作为该用户的浏览深度。

通过网页触达图可以分析出整个浏览页面的用户触达深度和比例，有益于运营人员和网页设计人员将重要的引流入口放到客户触达比例较高的部分，实现更高的引流和转化比。

2.5.2 使用场景

对于数据分析的同学来说，会通过 PV、UV 监测页面流量是否增加，使用网站访问深度监测网站用户粘性等。同时，也存在下面的需求：

（1）想要了解某网页用户关注的页面位置怎么办？

（2）想要通过某活动落地页用户的浏览深度优化设计方案，提升运营效果，怎么办？

网页触达图就是为了解决以上问题而设计产生的。

触达图的展示，通过水平的触达线，展示页面或页面组（结构相同的页面，如商品详情页、官网博客等）等区域中用户浏览页面深度的占比，并动态地展示页面中鼠标所在位置的用户触达率，如图 2-3 所示。

图 2-3 网页触达示意图

其中，首屏默认为 100%，正常情况下页面越往下滚动，浏览的占比越低。因此，网页触达图可用于分析如详情页、着陆页等类型页面中用户的浏览深度，帮助优化页面的内容、结构的设计。

2.6预置属性采集

预置属性是 SDK 预先采集页面上的某些属性，例如：页面路径 $url 、页面标题 $title 、屏幕宽高（$screen_height、$screen_width ）等。这些属性会由 SDK 自动采集，然后和手动采集的属性一起发往指定的服务端。这些属性是自动采集，不需要开发者增加代码，极大增加了数据采集的范围和便利性。采集的预置属性，是数据分析中涉及的重要分析纬度，自动采集极大降低了开发和采集的成本，是可以拿来即用的部分。

介绍了预置属性采集功能之后，下面我们来看下它有什么优缺点：

优点：自动帮用户采集了很多页面上的相关属性，让数据更加全面，分析维度更加丰富。

缺点：因为逻辑是在 SDK 内已经固定的，所以无法满足细分或者定制化的需求（有定制化的需求，需要自定义属性采集）。

预置属性涉及的面非常广，属性的种类也有很多，会在后续的专题中详细讲解，在此就不过多展开了。

三、数据缓存与发送

在介绍完 SDK 的数据采集功能之后，我们来介绍下其他的核心功能：数据缓存与发送。

3.1数据缓存

大部分 Web JS 数据采集使用的是即时采集、即时发送的策略，没有使用本地缓存。这样减少了复杂的缓存、读取和发送的控制流程。但是，无法避免的是当网络情况不佳时，数据发送失败的问题。数据一旦发送失败，由于没有缓存的逻辑，就会造成数据丢失。

另外，一个常见的场景是：关闭页面时，有发送数据的需求。例如：点击了某个按钮，跳转到另外一个页面。此时，由于发送数据的同时切换页面引起浏览器环境的破坏和中断，导致发送数据的请求有未发送出去的风险，从而导致了数据的丢失。基于以上原因，SDK 增加了缓存模式。

数据产生后，首先缓存在浏览器的 localStorage 中。对于存储的数据可以配置发送策略：默认是每 6 秒发送一次数据，或者当存储数据达到 6 条时发送一次数据。如果数据发送不成功，会默认重新发送。直到发送成功后，才会从 localStorage 中移除。这样，可以有效的降低一些数据发送过程中的丢失问题。

不过，由于 localStorage 的存储空间有限制，默认只能存储 200 条数据，超过的数据会按照默认的即时 img 请求发送数据。由于浏览器本身不具有固定设备内存可以使用，localStorage 也有存储数据的限制，所以无法大规模缓存数据，只能限定缓存部分数据。

数据存储的形式不止一种，为什么 SDK 选择 localStorage ？

早期的浏览器只能通过 cookie 来存储数据，后来我们逐渐增加了 localStorage ，sessionStorage 等存储方式，现代浏览器还包含 IndexedDB 。

比较下这几种方案的特点，如表 3-1 所示：

表 3-1 缓存方案对比

（1）cookie：因为存储的数据量不能超过 4K，数据量较小，且 cookie 会被带在 http header 中。

（2）sessionStorage：只可以存储 session 内的数据。

（3）IndexedDB：NoSQL 数据库，本地可以存储 250M 以上的数据。数据量很大，但是性能一般，在 500 ms 内，且操作相对麻烦。

（4）localStorage：可以理解为是一个文件存储，可以大约存储 5M 的数据，不同浏览器实现不一致，这个数据量比较合适。

综合考虑后，针对用户行为这样的数据，localStorage 相对合适。同步的 API 可以确保数据的一致，同时性能好，频繁写入几乎感觉不到延时。

3.2数据发送

3.2.1 发送的方式

常见的数据发送方式有 img 发送、ajax 发送和 beacon 发送，下面对这几种发送方式进行简要的介绍：

（1）img 发送：默认使用 img 发送数据。对于跨域的兼容比较好，发送的形式就是创建一个 img 元素，src 带上所有要发送的数据。执行过程无阻塞，不会影响用户体验，而且相对与 XMLHttpRequest 对象发送 GET 请求，性能上更好。局限性是 get 请求所携带的数据大小是有限的。

（2）ajax 发送：常见的一种请求方式，为了不影响业务流程，默认是异步发送数据。采用的是 post 形式发送数据，数据较为安全，且发送数据的大小基本不受限制。

（3）beacon 发送：当关闭页面发送数据的时候，经常受到页面容器 destroy 的影响，会导致数据来不及发送，进而产生丢失的问题。beacon 是浏览器的新发送策略，可以避免页面容器 destroy 时数据发送丢失的问题。不过，目前该功能还未普及。

另外，需要补充强调的是：批量发送是采用 ajax post 异步形式发送数据的。批量发送，是建立在上面提到的缓存数据的基础上。SDK 默认是选择立即发送的 img 方式。

当通过配置项，将发送修改为批量发送模式时，会将数据先进行 localstorage 缓存，然后一次性将多条数据整合到一起，通过一个请求发送到指定的服务端。由于数据体相对来说比较大，默认使用的是 ajax post 异步发送的方式。

下面从几个角度来分析 img、Ajax、sendBeacon 的优缺点，如表 3-2 所示。

表 3-2 发送方式对比

3.2.2 发送的顺序

SDK 采集的是网页端的数据，用户的行为数据通过网络请求发送到指定的服务端。但是，网络请求是有波动的。如果是先后连在一起触发的数据，可能会出现先发后到的情况。比如：点击按钮跳转页面，会先发送的一个点击事件，紧接着跳入新页面，会发送一个页面浏览事件。

事实上，经常会出现用户的行为序列中点击事件和页面浏览事件颠倒的问题。直观来看，用户行为会非常不合理：先触发了后一个页面的页面浏览事件，接下来的行为却是前一个页面的某个按钮的点击事件。

那如何解决这个问题呢？答案是构建发送队列。发送队列有两个优点：

（1）为了不影响用户的业务流程，SDK 一般采用的是异步加载的方式插入页面。因此，会有一些页面一打开就需要触发的事件，在触发时 SDK 还未正常引入核心源码并完成初始化。此时，SDK 就会将触发的事件存入发送队列中。等待 SDK 源码加载完毕并初始化成功后，立即执行发送队列。这样保证了数据不会丢失，解决了异步加载 SDK 的问题。

（2）保证用户行为数据按照正确的顺序入库，形成正确的行为序列。这是如何做到的呢？SDK 在发送队列中的数据时，默认会按照顺序发送，当前一条数据返回发送成功的状态后，依次发送下一条数据，这保证了大部分正常流程的数据发送正确。但是，万一前面的数据发送卡住了，一直没有状态返回怎么办？SDK 的解决方案是设置超时时间：

queue_timeout: 队列发送超时时间，默认值 300 毫秒，如果数据发送时间超过 queue_timeout 还未返回结果，会强制发送下一条数据。

datasend_timeout: 数据发送超时时间，默认值 3000 毫秒，如果数据发送超过 datasend_timeout 还未返回结果，会强制取消该请求。

构建发送队列可以解决 Web 端行为数据发送顺序错乱的问题。

四、总结

本文对于 Web JS SDK 进行了简明扼要的介绍，概述了 Web JS SDK 的基本功能，旨在让大家对于它有一个初步的了解。关于具体使用和实现原理等相关知识，会在后续的文章中逐步向大家介绍。

本文作者

郭政

神策数据 | Web JS SDK 技术顾问

我是郭政，神策数据 Web JS SDK 技术顾问，主要从事 Web 方面技术的研究和学习。希望能在开源博客中，和大家多交流，多学习。平时喜欢看看书，跑跑步，希望保持自己身体和心灵一直在路上。

交流合作

本文著作权归「神策数据开源社区」所有，商业转载请联系我们获得授权；非商业转载请注明出处，并附上神策数据开源社区订阅号二维码。

你还可以扫描二维码，加入社区交流群，与大家一同讨论。也欢迎关注我们的公众号，最新内容尽在掌握！