做小程序开发久了都会遇到同一个问题：产品经理问某个按钮的点击率是多少，用户平均在商品详情页停留多久，而我们手里只有微信后台提供的粗粒度数据，根本回答不了细颗粒度的业务问题。这时候就需要自己搭建一套自定义事件监控体系。本文从点击事件上报和页面停留时长两个最常用的场景入手，给出可直接落地的完整方案，包括埋点封装、生命周期处理、边界情况兜底以及上报策略优化。
一、封装统一的点击事件上报模块
最不推荐的做法是在每个按钮的bindtap回调里手写wx.request发数据。一旦埋点散落在几十个页面里，后续要调整上报字段或者更换数据通道，改动成本会非常高。正确的方式是抽一个独立的监控模块，所有页面和组件统一调用它。
先在项目里新建utils/monitor.js，核心是一个track函数，接收事件名和附加参数，内部负责补齐公共字段（时间戳、页面路径、用户标识、设备信息），再决定上报方式。
// utils/monitor.js
const app = getApp();
// 本地缓存队列，避免高频请求
let reportQueue = [];
function track(eventName, params = {}) {
const payload = {
event: eventName,
params,
timestamp: Date.now(),
route: getCurrentPages().length
? getCurrentPages()[getCurrentPages().length - 1].route
: '',
sessionId: app.globalData.sessionId || '',
// 只上报必要字段，减少流量消耗
basicInfo: {
network: app.globalData.networkType,
model: app.globalData.systemInfo.model
}
};
reportQueue.push(payload);
// 攒够5条或者超过3秒就批量上报
if (reportQueue.length >= 5) {
flush();
} else if (!flushTimer) {
flushTimer = setTimeout(flush, 3000);
}
}
function flush() {
if (!reportQueue.length) return;
const data = reportQueue.splice(0);
clearTimeout(flushTimer);
flushTimer = null;
wx.request({
url: 'https://ipipp.com/api/track/batch',
method: 'POST',
data: { events: data },
fail: () => {
// 上报失败时写回本地，下次启动再补发
wx.setStorageSync('failedTracks', data);
}
});
}
module.exports = { track, flush };页面侧的使用就变得非常轻量。注意不要把埋点代码和业务逻辑揉在一起，最好在bindtap里只调一次track，参数用扁平结构，方便服务端解析。
const { track } = require('../../utils/monitor');
Page({
onBuyTap(e) {
track('goods_buy_click', {
goodsId: this.data.goodsId,
price: this.data.price,
entry: this.data.entryFrom
});
// 后续是正常业务逻辑
this.placeOrder();
}
});如果不想侵入业务代码，还可以用行为代理的方式：在外层容器上统一绑定bindtap，通过事件对象的target.dataset识别被点击元素是否带有data-track属性，有就自动上报。这种方式适合快速给大量旧页面补埋点，缺点是参数只能从dataset里取，表达能力有限。
二、页面停留时长的统计原理与实现
停留时长的本质是两个时间戳的差值：用户进入页面的时刻和离开页面的时刻。小程序页面有两个非常关键的生命周期钩子——onShow和onHide。onShow在页面每次显示时触发，包括首次加载和从后台切回；onHide在页面被覆盖、跳转到其他页面、切后台或息屏时触发。用这对钩子就能准确切分出用户的一次有效浏览区间。
最常犯的错误是只记onLoad和onUnload，中间用户切到聊天窗口十分钟再回来，这十分钟会被错误计入停留时长。正确的做法是每次onHide时结算一次区间，onShow时重新开始计时。
// behavior-stay.js，用 Behavior 复用到所有页面
const { track } = require('./monitor');
module.exports = Behavior({
data: {
_enterTime: 0,
_totalStay: 0
},
pageLifetimes: {
show() {
this.setData({ _enterTime: Date.now() });
},
hide() {
this._settleStay();
}
},
methods: {
_settleStay() {
if (!this.data._enterTime) return;
const stay = Date.now() - this.data._enterTime;
this.setData({ _enterTime: 0 });
if (stay < 1000) return; // 过滤误触快速切换
track('page_stay', {
route: this.route,
stayMs: stay,
// 标记是主动离开还是切后台
leaveType: this._leaveType || 'unknown'
});
}
}
});还有一个必须处理的边界：用户直接杀掉小程序进程，或者从页面右上角胶囊按钮退出，此时onHide可能来不及执行或数据来不及发出。解决办法是在onHide里先写本地缓存，用wx.setStorage落盘，下次冷启动时读取补发。同时可以在App.onHide里触发一次强制flush，尽量在进程存活期间把队列清空。
// app.js
App({
onLaunch() {
// 补发上次未成功上报的数据
const failed = wx.getStorageSync('failedTracks');
if (failed && failed.length) {
wx.removeStorageSync('failedTracks');
}
},
onHide() {
// 小程序切后台时立刻结算并上报
const pages = getCurrentPages();
const current = pages[pages.length - 1];
if (current && current._settleStay) {
current._leaveType = 'background';
current._settleStay();
}
require('./utils/monitor').flush();
}
});三、上报策略：采样率、数据量与成本的平衡
埋点上线后如果全量上报，一个日活十万的小程序，每人每天产生几十条事件，服务端压力和带宽费用都不小。实际工程中通常引入采样机制：对核心事件（如支付点击）全量上报，对次要事件按比例采样。采样要基于用户标识做哈希而不是简单取模随机数，这样才能保证同一个用户的行为链路完整，不会出现前半段有数据后半段没有的情况。
// 基于用户ID的稳定采样，同一用户永远命中同一策略
function isSampled(userId, rate) {
let hash = 0;
for (let i = 0; i < userId.length; i++) {
hash = (hash * 31 + userId.charCodeAt(i)) >>> 0;
}
return (hash % 100) < rate * 100;
}
// 事件分级配置
const EVENT_CONFIG = {
goods_buy_click: { rate: 1 }, // 核心事件全量
banner_click: { rate: 0.5 }, // 一般事件采一半
page_stay: { rate: 0.2 } // 高频事件采两成
};除了采样，还要注意上报时机对体验的影响。wx.request并发数量有限制，埋点请求过多会挤占业务接口。建议把埋点请求的header加上特殊标记，便于网关层做低优先级处理；同时在页面onUnload时只做入队不立刻发送，真正统一在App.onHide或下一次onShow时批量flush。这套组合拳打下来，既能拿到细颗粒度的用户行为数据，又不会让监控本身成为性能负担。