一、前言

神策数据微信小程序 SDK，是一款用于微信小程序端的数据采集埋点 SDK。具体而言，是指开发者将 SDK 集成到开发的微信小程序我的项目中，通过配置或者在特定机会调用 SDK 提供的接口采集用户数据并通过网络发送到指定的服务端。

二、数据采集

对于 SDK 而言，数据采集是指在用户行为触发时（例如：小程序启动、点击了某个按钮等），依照既定的数据格式，将用户的行为进行数据化。依据采集形式的不同，能够分为代码埋点、全埋点和自定义全埋点：

代码埋点是指调用 SDK 提供的 track() 接口采集自定义事件；

全埋点是指 SDK 通过代理生命周期函数与各个事件处理函数来实现预置事件的采集；

自定义全埋点是指将 SDK 主动采集预置事件的性能敞开，由开发者手动调用 SDK 提供的特定接口 quick() 实现预置事件的采集。

神策数据微信小程序 SDK 还提供了全埋点版本和自定义埋点版本：

全埋点版本是 SDK 主动代理了微信小程序的 App、Page 和 Component 三个接口，主动采集预置事件依赖于全埋点版本的 SDK；

自定义埋点版本是指不采纳 SDK 主动采集预置事件的性能，开发者手动调用 SDK 提供的接口实现预置事件的采集。

2.1 代码埋点

2.1.1 概要介绍

代码埋点又称为自定义埋点。具体是指 SDK 初始化之后，在相干的事件处理函数中调用 track() 接口，将采集到的数据保留到发送队列中，而后依照肯定的发送策略将数据发送到指定的服务端。例如：小程序中某个 view 元素被点击，如果想采集这个 view 元素的点击事件，须要在 view 元素的事件处理函数中调用 track() 接口，通过代码埋点采集 view 元素的点击事件数据。

2.1.2 应用场景

代码埋点有很多长处：

精准管制埋点地位，有针对性地对须要的数据进行采集；

灵便的自定义事件和属性，不便采集丰盛的业务相干数据；

能够满足精细化的剖析需要。

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

埋点老本绝对比拟大，每一个控件的埋点都须要增加相应的代码；

更新代价比拟大，每一次更新埋点计划都须要批改代码并发版；

对用户业务代码侵入性较大，埋点代码较为扩散，不好对立治理，可维护性较差。

因而，代码埋点实用于须要精准管制埋点地位、灵便的自定义事件和属性等精细化需要的场景。

2.2 全埋点

2.2.1 概要介绍

全埋点也能够称为主动埋点，SDK 通过代理 App、Page 和 Component 的生命周期函数与各个事件处理函数来实现预置事件的采集。全埋点指集成 SDK，并且开启相应的配置项后，就能够主动采集用户的局部行为数据。微信小程序 SDK 全埋点的采集范畴（预置事件）包含：小程序启动、显示、进入后盾、页面浏览、分享、元素点击等，事件触发与采集规定如表 2-1 所示：

表 2-1 全埋点预置事件采集规定（点击查看高清大图）

2.2.2 应用场景

全埋点有如下长处：

展现宏观指标，满足根本数据分析需要。通过采集 PV、UV 等罕用指标，并对这些根本数据进行数据分析，有助于企业理解用户行为，为进一步数据分析指明方向；

技术门槛低，应用与部署较简略。只须要嵌入 SDK，极大水平地防止了因需要变更、埋点谬误等起因导致从新埋点的简单工作；

升高了开发者的工作量。开启相应的配置项后，主动向服务器发送数据，防止手工埋点的失误。

同时，全埋点也有一些毛病：

全埋点只能采集到用户交互数据，且适宜标准化的采集，自定义属性的采集须要代码埋点来辅助。每个用户的交互行为均有许多属性，全埋点无奈深刻到更细、更深的粒度。例如：在电商行业中，用户点击“购物车”是一次交互行为。全埋点会疏忽用户信息、商品品类等其余维度信息，此时须要配合代码埋点来辅助数据采集；再如用户上滑屏幕时，内容瀑布流的底部载入、商品或广告的加载展现、下拉菜单中内容的数据点击等状况，这类自定义行为的采集须要代码埋点来辅助实现。因为全埋点仅适宜规范的计划采集，一些数据分析平台也开始反对用户为每个事件增加自定义属性，如此能大大扩大事件剖析的效力；

小程序 SDK 全埋点是通过代理 App、Page 和 Component 三个接口并且代理相应的生命周期函数，在相应的生命周期函数中退出咱们的埋点逻辑实现的。因而，如果某天微信不容许重写 App、Page 和 Component 三个接口了，那么全埋点性能将无奈应用，不过这种可能性比拟小。

因而，能够晓得全埋点实用于以较小的埋点代价采集尽可能多的用户行为数据的场景。

2.3 自定义埋点

2.3.1 概要介绍

有些状况下，开发者的小程序我的项目中不容许代理 App、Page 和 Component 这三个接口，或者预置事件中的自定义属性须要异步能力获取到，此时就须要应用自定义全埋点性能。

自定义全埋点是指集成 SDK 后，开发者敞开 SDK 主动采集的性能，并在指定的生命周期函数内手动调用 SDK 提供的 quick() 接口采集预置事件。自定义全埋点采集的范畴（预置事件）包含启动、显示、进入后盾，事件触发与采集规定如表 2-2 所示：

表 2-2 自定义全埋点预置事件采集规定（点击查看高清大图）

2.3.2 应用场景

自定义全埋点有如下长处：

展现宏观指标的同时减少一些自定义的业务分析属性。这些分析属性的值通过后端接口获取，在发送预置事件时设置，既采集了 PV、UV 又能满足一些精细化的剖析需要；

应用自定义埋点版 SDK 进行自定义全埋点时，SDK 不会代理 App、Page 和 Component 等接口。

同时，自定义全埋点也有一些毛病：

须要开发者依照特定写法调用 SDK 指定接口；

相较于全埋点会减少开发者一些工作量。

因而，自定义全埋点实用于须要给预置事件增加异步获取自定义属性值的场景，以及不能被 SDK 代理 App、Page 等接口的小程序我的项目。

2.4 预置属性采集

预置属性是 SDK 事后采集小程序的某些属性，例如：页面门路（$url_path）、启动场景（$scene）、屏幕宽高（$screen_height、$screen_width）等。这些属性会由 SDK 主动采集，而后和手动采集的属性一起发往指定的服务端。

这些属性是主动采集的，不须要开发者减少代码，极大地减少了数据采集的范畴和便利性。采集的预置属性，是数据分析中波及的重要剖析维度，主动采集极大地升高了开发和采集的老本，是能够拿来即用的局部。

预置属性采集性能的优缺点：

长处：主动帮用户采集了很多页面上的相干属性，让数据更加全面，剖析维度更加丰盛。

毛病：主动采集的预置属性在 SDK 内是曾经固定的，无奈主动采集与用户业务相干的属性（业务相干属性能够通过自定义属性采集）。

预置属性波及的面十分广，属性的品种也有很多，会在后续的专题中具体解说，在此就不过多开展了。

三、数据发送

3.1 数据存储

每个微信小程序都能够有本人的本地缓存，并通过微信提供的 API 对本地缓存进行读写和清理，API 的应用如表 3-1 所示：

表 3-1 微信小程序提供的不同 API 比照（点击查看高清大图）

同一个微信用户、同一个小程序 storage 下限为 10MB，storage 以用户维度隔离：

1、同一台设施上，A 用户无奈读取到 B 用户的数据；

2、不同小程序之间无奈相互读写数据。

3.2 发送的程序

SDK 采集的是客户端的数据，用户的行为数据通过网络申请发送到指定的服务端。然而，网络申请是有稳定的。如果是先后连在一起触发的数据，可能会呈现先发后到的状况。例如：全埋点状况下小程序启动时，会间断发送小程序启动、小程序显示、小程序页面浏览三个预置事件，不过达到服务器的程序可能是小程序页面浏览事件先到，小程序启动事件最初达到。直观来看，用户行为会十分不合理：先触发了小程序的页面浏览事件，才触发小程序的启动与小程序显示事件。

为了保障发送的程序，SDK 在数据发送之前会构建数据发送队列，保障用户行为数据依照正确的程序入库，造成正确的行为序列。这是如何做到的呢？SDK 在发送数据队列中的数据时，默认会依照程序发送：以后一条数据返回发送胜利的状态后，顺次发送下一条数据，这保障了大部分失常流程的数据发送正确。然而，万一后面的数据发送卡住了，始终没有状态返回怎么办？SDK 的解决方案是设置超时工夫：

send_timeout: 队列发送超时工夫，默认值 1000 毫秒，如果数据发送工夫超过 send_timeout 还未返回后果，会强制发送下一条数据；

datasend_timeout: 数据发送超时工夫，默认值 3000 毫秒，如果数据发送工夫超过 datasend_timeout 还未返回后果，会强制勾销该申请。

因而，构建数据发送队列能够解决客户端行为数据发送程序错乱的问题。

3.3 发送的形式

3.3.1 实时发送

微信小程序 SDK 中的数据采集默认状况下应用的是即时采集、即时发送的策略。因为没有应用本地缓存，缩小了简单的缓存、读取和发送的管制流程。须要留神的是，线上小程序中应用的数据接管地址须要配置 request 非法域名（微信公众平台 → 开发 → 开发设置 → 服务器域名中进行配置），否则 SDK 采集的数据无奈发送。

通过网络发送数据时，无奈防止的是当网络状况不佳时，会有数据发送失败的问题。数据一旦发送失败，因为没有缓存的逻辑，就会造成数据失落。因而，微信小程序 SDK 减少了批量发送的性能。

3.3.2 批量发送

批量发送形式下，当数据产生后会先将数据存储在 storage 中（存储的数据有条数限度，最大能存储 300 条），达到发送条件后才会把存储在 storage 中的数据合并发送进来。其中，发送条件包含：

工夫距离：每隔肯定工夫（默认 6 秒）发送一次数据；

存储数据条数：存储数据达到肯定条数（默认 6 条）时发送一次数据；

进入后盾：当小程序进入后盾时发送一次数据。

上述三个发送条件满足任意一个即可发送数据。

如果数据发送不胜利，会将发送的数据保存起来，满足发送条件后，与之后的数据一起尝试发送。这样，能够缩小网络申请、节俭服务器资源，并且无效地升高一些数据发送过程中的失落问题。

四、调试事件信息

集成 SDK 并触发一些事件后，默认会把采集的数据实时发送至神策后盾。那么咱们如何得悉 SDK 采集的数据是否残缺，发送是否胜利呢？这里咱们提供了两种调试事件信息的形式：本地调试和实时数据查看。

4.1 本地调试

默认状况下，SDK 会将采集的数据信息打印在微信开发者工具的 Console 面板，如图 4-1 所示：

图 4-1 SDK 打印的数据信息

在开发工具的 Console 面板看到打印的数据信息后，示意 SDK 采集到了小程序中的数据，然而并不代表发送胜利。查看数据的发送状况能够通过在微信开发者工具的 Network 面板查看 SDK 的数据申请，如图 4-2 所示：

图 4-2 SDK 发送的数据申请

如上图所示，Network 面板中有 SDK 的数据申请，并且申请状态码为 200，示意 SDK 胜利地将采集的数据发送至神策后盾。

4.2 实时数据查看

4.1 节中介绍了客户端 SDK 采集数据的过程，那么采集的数据会发送到哪里呢？能够在神策后盾实时数据中查看。在神策剖析后盾 → 埋点治理 → 实时导入数据查问中，点击“开始刷新”按钮，能够看到有数据进入。如图 4-3 所示：

图 4-3 神策剖析后盾的实时导入数据查问

五、总结

本文对于微信小程序 SDK 进行了简明扼要的介绍，概述了微信小程序 SDK 的基本功能，旨在让大家对于它有一个初步的理解。对于具体应用和实现原理等相干常识，会在后续的文章中逐渐向大家介绍。

文章起源：公众号神策技术社区