小程序访问统计从零搭建

访问统计是小程序上线后最容易被忽略、又最先被需要的能力。没有数据，你无法判断首页改版是否有效、哪个入口带来的用户最多、留存到底卡在第几步。本文从数据模型、上报方式、存储与展示四个层面，给出一套可落地的自建访问统计方案，适合不想接入第三方 SDK、希望数据完全掌握在自己手里的独立开发者。

先想清楚要统计什么

统计不是越多越好。指标过多会导致上报请求膨胀、分析成本上升。建议先锁定三类核心指标：

• 访问类：PV（页面访问次数）、UV（去重访客数）、会话数（session）。
• 行为类：页面停留时长、关键按钮点击、分享次数。
• 转化类：注册、下单、支付等业务事件的漏斗。

UV 的判定依赖一个稳定的访客标识。小程序没有浏览器 cookie，推荐在本地存储中生成一个随机 ID，并在首次生成时记录时间戳，用于区分新老访客。

function getVisitorId() {
  const KEY = 'visitor_id';
  let id = wx.getStorageSync(KEY);
  if (!id) {
    id = 'v_' + Date.now().toString(36) + Math.random().toString(36).slice(2, 10);
    wx.setStorageSync(KEY, id);
  }
  return id;
}

会话的划分可以简单处理：两次事件间隔超过 30 分钟即视为新会话。会话 ID 在内存中维护，冷启动时重新生成。

上报通道的选择

上报有三条常见路径，各有取舍：

• wx.reportAnalytics：微信官方自定义分析，接入成本极低，但只能在后台看聚合结果，无法导出原始明细，也不支持自定义维度组合。
• 自建 HTTP 接口：灵活度最高，可自由设计字段与存储，代价是需要自己处理鉴权、限流和域名配置。
• 云开发数据库：免服务器、免域名备案，写入即入库，适合个人项目和小体量应用。

如果日活在一万以内，云开发方案性价比最高。用云函数接收上报，写入集合，再用聚合查询出报表。注意云函数需要设置合理的并发与超时，避免高峰时排队。

批量与异步上报

每条事件都发一次请求会拖慢页面，也会放大失败率。正确做法是本地攒批：事件先进入内存队列，达到条数阈值或页面隐藏时统一发送。

const queue = [];
const MAX = 10;

function track(event, props = {}) {
  queue.push({
    event,
    props,
    visitorId: getVisitorId(),
    sessionId: currentSessionId,
    ts: Date.now()
  });
  if (queue.length >= MAX) flush();
}

function flush() {
  if (!queue.length) return;
  const batch = queue.splice(0, queue.length);
  wx.request({
    url: 'https://your-domain.com/api/track',
    method: 'POST',
    data: { events: batch },
    fail: () => {
      // 失败时回填，下次再发，做个上限防止无限堆积
      if (queue.length < 50) queue.unshift(...batch);
    }
  });
}

同时监听 App.onHide 与 onUnload 触发一次 flush，减少数据丢失。对于支付成功这类关键事件，建议单独立即上报，不进入批量队列。

页面停留时长的正确算法

很多统计把停留时长算错，是因为只记录了进入时间，却忽略了页面被切到后台的情况。合理的做法是在 onShow 记录开始时间，在 onHide 和 onUnload 计算差值并累加，这样用户切出去再回来不会被算成超长停留。

Page({
  data: { enterAt: 0, duration: 0 },
  onShow() { this.data.enterAt = Date.now(); },
  onHide() {
    this.data.duration += Date.now() - this.data.enterAt;
    track('page_stay', { path: this.route, ms: this.data.duration });
  },
  onUnload() { this.onHide(); }
});

存储结构与查询

事件表建议采用宽表设计：一条记录包含事件名、访客、会话、时间、页面路径和自定义属性。索引建在时间戳与事件名上，聚合查询按天分组即可得到 PV/UV 趋势。UV 用访客 ID 去重计数，会话数用会话 ID 去重计数。

展示层不必做得很重。一个简单的后台页面，用折线图看趋势、用表格看事件排行，就足以支撑日常决策。真正有价值的是把数据和业务动作挂钩：改版前后对比、渠道来源对比、漏斗各环节的流失率。

几个容易被忽略的细节

• 上报接口要做频率限制，防止恶意刷量污染数据。
• 不要上报用户敏感信息，属性字段只保留业务必要的维度。
• 开发环境的上报打上标记，查询时过滤，避免测试数据混入。
• 预留一个开关，线上出问题时能快速关闭上报，不影响主流程。

访问统计的价值不在于图表好看，而在于让你在每次迭代前有依据、迭代后有反馈。先把最小可用的采集链路跑通，再逐步补充维度，比一开始就设计一套庞大的埋点体系更实际。