用 sessionStorage 替代 document.referrer 实现可靠广告归因——落地页解析 UTM 参数并存入，后续关键节点读取上报，兼顾同源性、会话一致性与末次点击归因逻辑。
直接用 document.referrer 做渠道归因不可靠——它在跨域、HTTPS→HTTP、用户手动输入或从书签访问时经常为空。真正可控、可落地的前端方案，是主动把来源信息存进 sessionStorage，并在后续关键节点（如注册、下单）读取并上报。
为什么 sessionStorage 比 referrer 更适合广告归因
sessionStorage 生命周期与当前标签页绑定，页面刷新不丢失，关闭标签页即清空，天然适配一次会话内的用户行为链路。它不依赖浏览器策略，也不受隐私模式或 referrer 策略限制，只要你在跳转前写入，目标页就能稳定读取。
- 广告链接点击 → 落地页加载时立即写入来源标识（如 utm_source=wechat_ad）
- 用户浏览商品 → 加购 → 下单，整个流程都在同一 session 内
- 提交订单接口中附带
sessionStorage.getItem('referrer')，服务端即可关联广告来源
具体实现步骤（以标准跳转为例）
假设你有一条微信朋友圈广告，链接为 https://your-site.com/landing?utm_source=wechat_ad&utm_medium=social，需确保该链接打开后，来源参数被持久化。
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
- 落地页（
/landing）加载时执行：
<script>
const url = new URL(window.location.href);
const utmSource = url.searchParams.get('utm_source');
const utmMedium = url.searchParams.get('utm_medium');
if (utmSource || utmMedium) {
sessionStorage.setItem('referrer', JSON.stringify({
source: utmSource || '',
medium: utmMedium || '',
timestamp: Date.now()
}));
}
</script>
- 后续任意页面（如结算页、成功页）均可安全读取：
const ref = sessionStorage.getItem('referrer');
若需上报，建议在提交订单前解析并拼入请求体，例如：{ order_id: 'xxx', referrer: JSON.parse(ref) }
配合 UTM 参数使用效果最佳
UTM 是行业通用标记规范，Google Analytics、Adobe Analytics 等都默认识别。把 UTM 作为源头输入，再由 sessionStorage 承接，既兼容分析平台，又规避了 referrer 的断层问题。
- 广告投放时统一加 UTM：
?utm_source=weibo&utm_medium=cpc&utm_campaign=spring_sale - 落地页不只存 source，建议完整保留 utm_* 全套参数，方便后续做多维归因分析
- 避免覆盖：如果用户多次从不同广告点击进入，每次都会重写 sessionStorage，天然保留“最后一次触达”来源，符合主流归因模型（如末次点击）
注意事项与边界情况
sessionStorage 是同源的，跨子域（如 a.example.com → b.example.com）无法共享。如需跨子域追踪，应改用 document.domain + iframe 或服务端透传（如通过 URL query 带参跳转）。
- 不要依赖它做长期留存归因（比如 7 天后回访下单），sessionStorage 不持久
- 用户新开标签页访问，即使来自同一广告，也属于新 session，需重新捕获
- 如需支持 PWA 或部分安卓 WebView 场景，建议加兜底逻辑：同时写入
localStorage并设短时效（如 2 小时），但需明确告知用户用途并获取同意
