微信小程序分享数据对不上：我把 scene、query 和归因链路重做了一遍

上周复盘小程序邀请转化，发现后台“分享带来支付”比实际少一截。最初我以为是埋点漏了，后来发现是分享参数在部分入口里被吞掉，scene 也被当成普通 query 处理。干脆把链路重做。

先把 scene 和 query 分开

以前我在 onLoad 里直接读 options.inviterId，结果扫码、分享卡片、会话转发拿到的字段位置不一样。现在规则很简单：scene 只用来判断入口类型，业务参数统一从 query 解析；如果 query 为空，再尝试从 scene 附带的扩展参数兜底。同时把 1007、1008、1044、1011 这些常见场景值列进枚举，不再用字符串猜。

用 shareToken 代替裸参数

裸传 inviterId 和 source 容易被截断、改写或丢失。我改成生成分享页时由 Node 服务签发 shareToken，把邀请人、来源、活动、过期时间写进 Redis，小程序只带一个短 token。落地页 onLoad 后先请求 /api/share/resolve，服务端再返回可展示的邀请信息。这样即使前端参数异常，也能通过日志定位是哪一步断了。

// 生成分享路径时只带 token
function buildShare(path, token) {
  return { path: `${path}?st=${encodeURIComponent(token)}` };
}
// 服务端解析时校验来源与过期
async function resolveShare(token, ctx) {
  const data = await redis.get(`share:${token}`);
  if (!data) return { ok: false, reason: 'expired' };
  return { ok: true, ...JSON.parse(data), scene: ctx.scene };
}

服务端归因要幂等

用户可能重复进入、切换账号、延迟支付。我把归因事件写进 MongoDB：share_visit、share_bind、pay_success 三类事件，用 userId + shareToken + eventType 做唯一键，避免重复计数。支付回调里只认服务端绑定的归因记录，不再信任前端上报。广告和邀请收益对账时，也能按 token 回查来源。

• 分享标题和图片有缓存，旧参数可能残留，发版后要验证线上卡片。
• 部分机型 query 编码异常，统一 encodeURIComponent 再拼接。
• scene 值以官方文档为准，不要凭经验写死。
• 转化归因要设过期窗口，避免无限期算给邀请人。

“这次最大的感受是：小程序分享不是前端拼个参数就完事，而是“入口识别、参数签发、服务端归因、回调落库”四件事。把链路拆开之后，数据才敢拿来做结算和复盘。”