背景

用户行为日志和埋点是所有电商绕不过去的功能点，它为决策提供了重要数据支撑。随着小程序装修体系的上线后，首页，活动页更加的多样化，对于每个坑位的数据，以及后续的影响更加的重视。埋点数据采集对于促销活动的策略制定、及时调整及转化效果的验证都至关重要。

日志上报

上报方案

上报的接口采用POST，考虑到上报的数据非常多，GET并不适用；
上报方式，采用setTimeout，10秒后上报收集到的所有事件数据，并且清除定时器，当上报成功后重新开始定时器。
锁机制，日志必须带有用户，店铺或者其他必要属性才有意义，这时候需要等待这一类数据返回后，再解锁开始上报。
上报时机：小程序appShow事件是所有事件的开始，所以从这里开启定时器；appHide清除定时器，直接上报。
根据上报类型划分：批量上报，独立上报。大部分的事件都是走批量上报，但是存在一些特殊事件为了保证其准确性，及时性，降低丢失率使用独立上报。

javascript

复制代码

`const timer = (() => {
let _timer;
return {
start() {
if (_timer) {
return;
}
_timer = setTimeout(() => {
_timer = null;
// 上报
}, 10000);
},
clear() {
clearTimeout(_timer);
_timer = null;
},
};
})();
class ubCore {
constructor(){
// 事件数据集合
this.events = [];
// 锁
this.lock = true;
// 监听全部必要的属性等到有值后解锁
EventBus.on('xx',(v)=>{
if(v){
this._unlock();
}
})
}
_unlock(){
/**

解锁
清空计时器
做一次手动上报

**/
}
add({eventkey, options}){
/**

收集事件到events集合
判断eventkey，appShow时开始定时器, appHide时关闭定时器，直接上报

**/
}
queueReport(){
/**

判断lock是否解锁 , 解锁后才允许上报
将events上报成功后重新开启定时器

**/
}
report(){
// 直接上报不通过定时器
}
}`

工作流程

节点曝光埋点

曝光的定义及场景

定义：节点区域进入可视区域达到一定比例，也就是要进入到用户的视野范围内才算真正意义上的曝光，如果只是单纯的渲染出来并不算。

曝光的场景（坑位）：页面内轮播的每一张图，热区图中的每个热区，热区轮播中的每张图下的不同热区，所有的商品列表下的每个商品等等。

解决方案

小程序内可以使用标准API监听元素与可见区域的相交变化。

wx.createIntersectionObserver().relativeToViewport().observe()

createIntersectionObserver，创建观察者，设定触发回调比例

relativeToViewport可以设定可视区域

observe设定需要观察的节点和回调方法

优点：

可控的相交比例
回调触发会根据相交比例，可以避免不必要的执行。

javascript

复制代码

`class exposure {
// 根据API分析它需要的参数包括组件实例，目标节点，相交比例，回调函数
constructor(that, node, thresholds, callback) {
this.that = that;
this.node = node;
this.thresholds = thresholds;
this.callback = callback;
}
static creat_exposure(that, node, thresholds, callback) {
const Ep = new exposure(that, node, thresholds, callback);
Ep.createObserver();
}
createObserver() {
let obs = this.that.createIntersectionObserver({
thresholds: this.thresholds,
});
obs.relativeToViewport().observe(this.node, (res) => {
// res中可以获取该节点上dada-开头的属性数据，再进行事件的上报
...
// 回调
this.callback(res);
// 当目标节点曝光过后停止监听避免重复触发
obs.disconnect();
});
}
}`

由于装修体系的存在，页面上的每个坑位都是没办法预先设定的，结合上诉，可以根据数据做处理，每个数据对应一个节点或者是一个坑位，统一节点命名规则，并将关键数据通过类似data-id属性挂载在节点上，这类属性是统一归纳出来，比如坑位名称，坑位号，坑位id等等，之前都是在wxml上配置，最后在获取数据后遍历每个数据根据命名规则进行监听。

tips：注意点setData必须和监听同步执行。

javascript

复制代码

``// wxml
<block wx:for="{{list}}" wx:key="index">
<view class="product-wrapper"
id='exp-{{item.id}}'
data-id="{{item.id}}">
</view>
</block>
// js
Promise.resolve()
.then(()=>{
this.setData({ productList })
productList.forEach((item) => {
exposure.creat_exposure(this, #exp-${item.id}, [0.7], (res) => {});
});
})``

行为链路追溯

背景需求：用户在下单或者加入购物车这2个事件触发时，如果用户经过首页，活动页，需要知道用户是从哪个坑位进入的。

工作流程

在事件加入events集合时（ubCore.add）这一步骤中，额外建立一套新的流程，根据这些事件进行数据过滤，形成新的行为记录，并储存起来。

数据处理

几个问题

如何确保一个页面只有一个关于用户楼层坑位点击的数据
页面前后切换记录的增删
存在多个活动页，不同id情况下的记录处理
配置需要记录的页面路径

初始化过滤

大致分为几个步骤

根据接收到的页面生命周期pageShow做初始化过滤。不管是页面还是前进还是后退，都会触发当前页面的pageShow事件，在这个节点做一个清洗操作【根据getCurrentPages()获取当前页面的路径和参数，在集合中查看是否有值，有值就删除记录，包括后面页面的记录】。因为A->B，B的记录一定是空，不会做处理。只有当发生后退情况下D->C ，C页面的记录一定有值，并且处于C页面后只有2种情况（1）重新记录新的坑位（2）继续后退，不管是哪种情况都可以把当前页面先进行记录清空。
根据制定的规则进行过滤，指定的页面，事件类型是elementClick，带有坑位标识，过滤出符合条件的数据后，在这个节点再做一次清洗操作【根据getCurrentPages()获取当前页面的路径和参数，在集合中查看是否有值，有值就删除记录，包括后面页面的记录】，最后放入集合。