很多朋友做小程序,页面画完了、接口调通了,就急着提审上线。等到运营问一句“昨天来了多少人、从哪进来的”,才发现后台除了一个总用户数,什么都拿不出来。访问统计这事,真不是上线后再补的活,补的时候数据已经缺了一大截。

先想清楚你要看什么
别一上来就接一堆SDK。先问自己三个问题:
- 是看整体流量,还是看某个活动页的转化?
- 需不需要知道用户从哪个渠道进来(扫码、分享、搜索)?
- 数据是给自己看,还是要给客户出报表?
答完这三个问题,方案基本就定了。个人项目、日活几百,用微信自带的“小程序数据助手”加简单埋点就够;要是给甲方做,通常得有一套能导出、能按天对比的后台。
微信官方数据:免费但要会用
小程序后台自带数据分析,访问来源、留存、页面访问路径都有。问题在于它偏宏观,你想知道“点了立即购买按钮的人有多少”,它给不了。这时候就得自己埋点。
我的习惯是:官方数据看大盘,自建埋点看业务。两者不冲突,别为了统一把官方那套扔了,它的来源归因比你自己猜的准。
自建埋点,越轻越好
小程序端埋点最怕两件事:一是把主流程拖慢,二是请求太多把后台打挂。我的做法是攒一批再发,页面隐藏或定时上报。
// utils/track.js
const queue = []
let timer = null
function flush() {
if (!queue.length) return
const events = queue.splice(0, queue.length)
wx.request({
url: 'https://your-api.com/track',
method: 'POST',
data: { events },
fail: () => {
// 失败塞回去,下次再试,别直接丢
queue.unshift(...events)
}
})
}
export function track(name, extra = {}) {
queue.push({
name,
extra,
page: getCurrentPages().pop()?.route || '',
ts: Date.now()
})
if (!timer) {
timer = setTimeout(() => {
flush()
timer = null
}, 3000)
}
}
注意几个细节:getCurrentPages() 拿页面路径很便宜,别每次都传;失败重试要设上限,不然离线用户会把队列撑爆;事件名统一用下划线,比如 page_view、btn_buy_click,后期写SQL省心。
云开发用户的偷懒方案
如果你用的是云开发,连服务器都省了。建一个 track_logs 集合,前端直接 db.collection('track_logs').add()。但要注意权限,集合设成“仅创建者可读写”会查不了别人的数据,统计场景一般设成“所有用户可读,仅创建者可写”并不合适,更稳的是走云函数写入,前端只调云函数。
// cloudfunctions/track/index.js
exports.main = async (event) => {
const db = cloud.database()
const { events } = event
if (!Array.isArray(events) || events.length > 20) {
return { ok: false }
}
await Promise.all(
events.map(e => db.collection('track_logs').add({
data: { ...e, openid: cloud.getWXContext().OPENID }
}))
)
return { ok: true }
}
一次最多20条、云函数里再补openid,前端就别传了,传了也不可信。
UV别用openid直接count
新手最容易踩的坑:拿openid去重算UV,数据量一大查询就慢。正确做法是按天建聚合,每天跑一次定时任务,把 openid + date 写进一张去重表,或者直接在云开发里用聚合统计。
另外,wx.login拿到的code换openid有频率限制,别每次埋点都换,登录时存一次就够了。没登录的用户可以用本地生成的匿名ID,先统计行为,登录后再关联。
最后两句实话
访问统计不是越多越好。我见过一个页面埋了三十多个点,结果没人看报表。先把“进入页面、关键按钮点击、支付成功”这三层跑通,比什么都强。
还有,埋点代码上线前一定要在真机上验一遍,开发者工具里请求正常、真机上因为域名白名单失败的情况太常见了。数据这东西,宁可从第一天就少而准,也别等一个月后对不上账。

评论 (0)
还没有评论,快来抢沙发吧~