不少团队在配AB页跳转的时候，脑子里都有个默认前提：源页面URL上挂了UTM，落地页那边肯定能收到。真到动手的时候，这个前提十有八九不成立。上个月一个做家居内容的客户就来找我们复盘，说同一批投放链接，后台看点击量挺正常，可分析工具里将近三成的访问被扔进了直接流量。查了一圈，毛病不在投放侧，出在跨域跳转这段路上——Referrer被裁了，UTM参数在中转页被重写。下面我把这类问题拆成六个环节，每个环节就回答一件事：这会儿该盯什么信号，看到什么情况就该停下来处理。
环节一：先确认Referrer-Policy是不是参数衰减的起点
跨域跳转丢Referrer，大部分时候真不是服务器配错了，是浏览器默认策略在那起作用。现在浏览器对跨域请求的默认Referrer策略已经收得很紧，HTTPS页面往HTTP页面跳，Referrer直接给你省掉；就算是HTTPS到HTTPS，响应头里没明确声明的话，浏览器也可能只发源站域名，路径和查询串都不带。
- 打开浏览器开发者工具的Network面板，把跳转请求抓出来，看Request Headers里那个Referer字段——是完整URL，还是只剩域名，还是压根没有。
- 翻源页面响应头里的Referrer-Policy字段。常见的几个取值里，no-referrer-when-downgrade碰到协议降级就把Referrer丢了，strict-origin-when-cross-origin跨域时只留域名，origin则只发源站。
- 源页面要是SPA，还得确认meta标签里的referrer策略跟HTTP头打不打架，两边不一致的时候，以更严格的那一方为准。
停止条件
抓包一看，Referer字段只到域名层级、查询参数一个没有，那就说明策略层已经在裁剪了。这时候还蹲在落地页翻UTM纯属浪费时间，得先回源页面把Referrer-Policy调了。话说回来，把策略放宽到unsafe-url确实能拿到完整URL，但路径和参数就暴露给所有下游域名了，接不接受看你的合规要求，别为了归因把整个站点的策略一刀切放开。
环节二：核对UTM拼接位置，别让中转页吃掉参数
AB页跳转一般都有个中间层——短链服务、跳转网关，或者一个独立跳转页。这层要是做了URL重写、参数白名单过滤，或者干脆把目标地址写死在配置里，UTM就在这一跳没了。
常见触发条件
中间层只透传固定那几个参数名，比如只放target和token过去，其他查询串一律扔掉。；中间层做了参数去重或者排序，把utm_source和utm_medium合并了、覆盖了。；中间层配的是301永久重定向，浏览器把跳转结果缓存下来，后面请求直接命中缓存，参数形态就固化了。。
把跳转链路每一跳单独拎出来，用curl或者浏览器直接访问，逐跳记录URL的完整查询串。重点盯三个位置：源页面发起跳转时的URL、中间层返回的Location头、落地页最终收到的URL。中间层的Location头里UTM已经不见了，问题就锁死在这一层，后头的不用查了。至于301和302怎么选，参数需要动态变化的话优先用302，免得浏览器缓存旧的重定向结果。
环节三：服务端透传校验，确认参数没有在Header转换中丢失
有些跳转链路不是浏览器发起的，是服务端收到请求后返回重定向。这种场景下UTM参数可能以Cookie、自定义Header或者Session的形式在服务端传来传去，哪一环类型转换出问题或者字段被截断，都会造成衰减。
操作与限制
- 在服务端日志里把接收到的完整查询串和最终拼出的重定向URL都打出来，两者做字符串比对，确认参数数量和值对得上。
- 参数走Cookie传递的话，检查Cookie的Domain和Path设置，跨子域跳转时Domain范围不对，Cookie就不会被带上。
- 参数走Header传递的话，注意部分CDN或反向代理会过滤非标准Header，自定义字段名建议用X-前缀，并且确认中间设备不做清洗。
验证方式上，我一般建议在测试环境构造一条带完整UTM的请求，在跳转的每个服务节点打日志，确认参数进入下一跳之前仍然完整。这动作看着笨，但比事后在分析工具里猜归因快得多。
环节四：落地页接收端核对，区分“没收到”和“收到了没上报”
参数衰减有时候是个假象：落地页其实收到UTM了，但页面的分析脚本在上报前做了处理，比如读了错误的参数名、大小写没匹配上，或者脚本加载时机晚于参数解析。
检查项
- 在落地页控制台直接读location.search，确认原始查询串里UTM在不在，这一步先排除“参数根本没到”的可能。
- 检查分析工具的初始化配置，看它读的是标准utm_参数名还是自定义映射。很多团队跳转时改用了自定义参数名，接收端却没同步更新映射表。
- 检查脚本加载顺序，如果分析脚本在DOMContentLoaded之后才执行，而页面在这期间发生了二次跳转或者History替换，参数可能已经被覆盖了。
这一环节的价值在于把问题范围缩小。location.search里有完整UTM，可上报数据里没有，问题就在接收端映射或者上报时机；location.search里就没有，那就回到前三个环节继续查。
环节五：用一条可控链路做端到端核对，而不是逐段猜
排查参数衰减，最容易犯的错是分散验证：在A工具里看Referrer，在B日志里看UTM，最后靠推理拼结论。更靠谱的做法是构造一条可控链路，从源页面到中间层到落地页，每个节点打上时间戳和参数快照，一次走完。
实施要点
- 源页面加一个临时参数，比如debug_check=1，方便在日志里定位这次特定请求。
- 中间层记录接收到的查询串和发出的Location头，落地页记录location.search和分析工具实际读取到的值。
- 三个节点的记录用同一个请求ID串起来，避免并发请求混淆。
这条链路跑通一次，参数在哪个节点开始衰减就一目了然。后续再遇到类似问题，可以复用这套核对流程，不用每次从头猜。
环节六：实战复盘——一个家居流量团队的参数修复过程
回到开头提到的那个客户。团队做家居内容站，日均访问量在几千到一万之间，跳转链路是源页面到自建短链服务，再到落地页，服务器用的是普通云主机，没有复杂的边缘计算层。
他们最初的表现是：分析工具里直接流量占比偏高，部分渠道的转化数据对不上。团队先怀疑是分析工具的归因窗口问题，调整了窗口设置，没有改善。后来按上面的环节逐个核对，发现两个叠加问题。
第一个问题在Referrer-Policy。源页面没有显式设置策略，浏览器默认按strict-origin-when-cross-origin处理，跨域跳转时Referrer只保留域名。第二个问题在短链服务，它只透传了目标URL参数，没有把原始查询串拼接到Location头里。两个问题叠加，导致落地页既拿不到Referrer，也拿不到UTM，自然被归到直接流量。
调整过程分两步。先在源页面显式声明了Referrer-Policy，在合规允许的范围内保留了完整URL作为Referrer；然后修改短链服务的跳转逻辑，把原始查询串做白名单过滤后拼接到目标地址上，白名单只保留UTM相关参数和必要的追踪字段，其他参数不传递。改完之后重新用可控链路核对，落地页能稳定收到完整UTM，分析工具里的直接流量占比回落到正常水平。整个修复前后花了大概三个工作日，其中大部分时间用在确认哪些参数可以透传、哪些必须过滤，而不是改代码本身。
这个案例里没有复杂的对抗场景，问题都出在基础配置上。但它说明一件事：参数衰减往往不是单一原因，而是浏览器策略和中间层逻辑同时出问题，只查一个环节容易漏掉另一个。
收束：一份可以照着走的核对结论
把上面的环节压缩成一份可执行的核对顺序，遇到跨域跳转参数衰减时按这个顺序走：
- 先抓包看Referer字段的实际形态，判断是否在策略层被裁剪。
- 再逐跳记录URL，定位UTM在哪一跳开始消失。
- 检查服务端透传逻辑，确认参数在Header或Cookie转换中没有丢失。
- 在落地页读取location.search，区分“没收到”和“收到没上报”。
- 用带请求ID的可控链路做一次端到端核对，避免分散验证。
- 修复后重新跑一次同样的核对流程，确认参数在每一跳都完整。
有件事得提前定好：排查超过两个环节还定位不到衰减点，就别继续在单个环节里深挖了，应该把链路完整记录拉出来做一次端到端比对。参数问题通常不是靠猜能猜出来的，靠的是每个节点留下可核对的记录。另外，透传参数时要同步考虑合规边界，不是所有查询参数都适合原样传递，白名单机制比全量透传更可控。
总结：本文详细介绍了AB页跳转的相关内容，包括AB页跳转的原理、配置方法和优化技巧，包括AB页跳转的原理、配置方法和优化技巧，包括AB页跳转的原理、配置方法和优化技巧。希望这些AB页跳转内容对您有帮助。
