详解微信小程序（Taro）手动埋点和自动埋点的实现

每一个公司要想用户增长，都要收集和分析用户操作数据，因此埋点是必不可少的事情。
而对于前端职业发展来说，传统的手动埋点，无疑是繁琐又无聊的事情，能简化就简化。

一、手动埋点

手动埋点就是在每一处需要的地方，都加一段上报埋点的代码。影响代码的阅读体验，且散落的埋点代码不方便管理。
以页面 pv 为例，我们此前是在每一个页面中上报 pv：

二、自动埋点

自动埋点可分为全自动埋点和半自动埋点。全自动埋点则是不管需不需要，将所有的点都埋了。前端肯定开心了 “以后埋点产品都不要不要找我啦”，可数据同学就哭唧唧了。

比如，腾讯和 taro 团队共同推出 腾讯有数自动化埋点，接入超级简单。比如配置 proxypage 为 true 即可 “上报所有页面的 browse 、leave、share 等事件”，配置 autotrack 为 true 即可 “自动上报所有元素的 tap、change、longpress、confirm 事件”。

可从数据量和有效性来说，「全埋」等于「不埋」，因为「全埋」一方面对数据存储量要求很高，另一方面会给我们负责数据清洗的同学带来大量工作。

所以接下来，还是从中寻求平衡，着重看半自动埋点。

1、页面曝光（pv）

页面曝光（pv），理想的上报方式是：

在一个统一的地方（如 trackingconf.ts），配置好每个要埋点的页面的标识符（即 pagesn）
页面显示后，自动判断下是否需要上报（是否在 trackingconf.ts 配置文件中），要就直接上报。

具体实现

（1）统一配置埋点字段，pagesn 表示页面在埋点系统中的标识符

当然，如果你的业务允许三七二十一，上报所有页面 pv（带上 path 让产品自己筛选），那（1）这步可以省了，直接看（2），这种方式可称为「pv 全自动埋点」。

（2）封装 usepv hook，在页面展示时，获取当前页面 pagesn、判断是否要埋 pv、要的话发送 pv

（3）然后封装页面组件 wrappage ，使用上述的 usepv()：

（4）最后在所有页面组件，包一层 wrappage 即可实现「所有页面按需埋点」：

后续新开发一个页面，除了用 wrappage 包裹外，只需要在第（1）步的 trackingconf.ts 中增加该页面的 pagesn 即可。

提问环节

好奇宝宝们可能要问了：

（1）wrappage 里这样封装了 usepv()，应该如何支持上报自定义字段呢？
举个例子，产品希望 src/auto/home/index.tsx 这个页面上报 pv 的时候，额外上报一下 当前页面 url 查询参数即 params。
很简单，就是这个页面不要用 wrappage 包裹，而是拿到 params 后直接调用 usepv 函数：

（2）这里每个页面组件，都要用 wrappage 包裹一下，对业务还是有侵入型了，原生小程序可以改写 page，在 page 中直接 usepv()。taro 项目应该也可以这么做，实现 0 业务侵入吧？

taro 项目中，确实可以也可以和原生小程序一样，在 app 中统一拦截原生 page，但这样的话，上面「某些页面要计算额外参数并上报」就不好解决了。

2、页面分享

微信小程序中，存在两种分享：

• 分享给好友：useshareappmessage。
• 分享到朋友圈：usesharetimeline。小程序基础库 v2.11.3 开始支持，目前只在 android 平台可用。

具体实现

以 useshareappmessage 为例（usesharetimeline 同理）：
（1）仍在 trackingconf.ts 统一配置文件中，增加分享埋点的标识字段 elesn （及额外参数）

（2）封装 useshareappmessage 方法，业务调用 taro.useshareappmessage 的地方全局替换为这个 useshareappmessage。

这样，如果有个页面需增加分享好友的埋点，直接在 trackingconf.ts 中增加 sharemessage 的 elesn 即可，usesharetimeline 同理。

提问环节

好奇宝宝们可能要问了：页面需要增加分享好友/朋友圈的埋点，可否 0 配置（即不用修改上述的  trackingconf.ts 文件）？
与前文中「pv 全自动埋点」类似，只要和产品约定好捞数据的方式也可以，比如笔者和产品约定了：
每个页面分享好友/朋友圈，elesn 都是 444444，然后产品通过 pagesn 判断是哪个页面，通过 share_to 判断是分享好友 / 朋友圈，对于分享好友的场景，再通过 from_ele 判断通过右上角分享还是点击页面中的按钮分享。
这样页面分享也可以全自动埋点了。

3、元素埋点

元素自动埋点的调研遇到阻力，尚未落地。下文主要谈不同思路遇到的问题，有好的建议欢迎评论区沟通。

我们元素埋点，较高频的有曝光、点击事件，中低频的有滚动、悬停等事件。

手动埋点的方式就是在元素指定事件触发的时候，手动执行 sendimpr 上报埋点（带上页面唯一标识符 pagesn、 元素唯一标识符 elesn）。

那这个环节是否可以省事一些呢？对业务无侵入，大概的做法还是：

在 component 指定事件触发增加个 hook -> 判断是否要上报埋点 -> 满足条件则上报

问题一分为二：

（1）拦截元素事件回调

可以拦截并遍历小程序 component 接收到的 options.methods，如果是一个自定义函数，则在函数被调用的时候判断第一个参数（假设命名为 e）的 type 是否等于 tap 等事件。这时候可以根据 e 等信息决定是否满足埋点上报条件了。
原生小程序中的实现，大致如下：

taro 项目中，不能直接在组件代码里用 component，但可以迂回一些的方式实现相同目的，比如：

然后在 app.tsx 中直接引入 myproxy.js 即可

（2）如何自动生成元素唯一标识符

目前是通过埋点系统中申请下来的 elesn 来唯一标识元素的，如果想要自动标识，可细分为：

• xpath：在 pc / mobile 中还可以，但在小程序中不支持直接获取节点的 xpath / 根据 xpath 获取节点。微信小程序可否支持通过 xpath 获取 dom 元素？
• 自动获取 组件方法名：原生小程序中，因为直接拦截了 component options 中的 methods，所以在事件触发时可以获取到原始的方法名，但 taro 项目中不行，因为 methods 被代理了一道，事件触发后，你看到的方法名都是 eh。
• ast 解析源码分析出页面名、方法名和方法对应的注释来标识元素：taro 项目中目测只能用这个方法，但成本较大，且「在代码不断迭代后，存量数据是否还能用」也是个问题，所以笔者未做尝试。

三、总结

本文概述了一下微信小程序（taro）从手动埋点到自动埋点的思路。并按照页面埋点（pv、分享）以及元素埋点，分析了实现方式：

• 页面 pv：
  • 封装 usepv，根据当前页面 path 从配置文件中读取出 pagesn
  • 封装页面组件 wrappage 调用 usepv()
• 分享好友/朋友圈：自定义 useshareappmessage、usesharetimeline，根据当前页面 path 从配置文件中读取出 pagesn 和分享 elesn，然后获取传入参数后埋点上报
• 元素埋点：提供了改写 component 方法来拦截事件回调的思路，但因元素唯一标识符不能自动获取，所以不大适合自动化埋点。

到此这篇关于详解微信小程序（taro）手动埋点和自动埋点的实现的文章就介绍到这了,更多相关小程序手动埋点和自动埋点内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！