一个做信息流投放的团队最近遇到个情况，广告后台的转化事件数量没怎么变，但落地页表单里的渠道标记字段开始大量出现空值。同一条跳转链路上的页面都能打开，跳转过程也没报错，可参数就是没有完整带到最终落地页。这种情况在跨域跳转里挺常见的，而且往往问题不在跳转本身挂掉，而是参数在某个中间环节被悄悄丢掉、改写或者重复拼接了。
参数透传异常值得单独拿出来处理，原因是它直接干扰两件事：一个是落地页上的业务判断，比如渠道来源、计划ID、设备类型这些；另一个是后续的转化归因，落地页拿不到关键参数，回传事件跟广告点击就对不上号了。排查这种问题最怕上来就改代码或者换跳转方式。先搞清楚参数在哪一层断掉，后面调整才有依据。
第一步：先确认参数在哪个跳转节点丢失
跨域跳转通常不是从广告链接触达最终落地页一步到位的，中间可能经过自有跳转服务、第三方监测平台、CDN边缘节点，甚至还有一次前端二次跳转。排查的时候先把链路画出来，标明每一跳的完整URL。可以从广告后台的点击链接开始，逐跳在浏览器地址栏或开发者工具里记录跳转后的地址。
判断条件其实很简单：如果参数在第一跳之后就不见了，问题出在跳转服务对URL的解析和重组；如果参数在中间某一跳还在，到最终落地页才丢，那问题更可能出在落地页自己的解析逻辑上，或者前面某次302响应里的Location头拼接有问题。关键操作是每一跳都要看原始响应头，别光看浏览器最终显示的地址，因为有些前端跳转会用history API把地址抹掉。
限制条件也得清楚。浏览器开发者工具的Network面板能看到302响应头，但如果是JS发起的跳转，参数可能在脚本里被拆分后重新拼接了。这时候需要在跳转脚本里加临时日志，把跳转前的href和即将跳转的目标地址都打出来。验证方法是在测试环境用带特殊标记的参数值走一遍链路，确认每个节点的输出是不是符合预期。
第二步：检查URL解析与重组的编码边界
参数丢失的一个高频原因是编码不对称。跳转服务从当前URL里取query string的时候，如果直接按原始字符串拼接到新地址，遇到参数值里含特殊字符就容易出问题。比如说某个参数值是a+b或者a b，在原始链接触达时可能被浏览器编码成a%2Bb或者a+b，跳转服务拿到后如果原样放进新URL，落地页解析时可能得到完全不同的值。
这一步要排查三个东西：原始链接里的参数有没有做百分号编码；跳转服务解析时是不是先解码再重新编码；最终落地页的解析函数跟跳转服务的编码方式是否一致。操作上可以用一个包含容易被混淆字符的测试参数走链路，比如同时带空格、加号、等号、中文字符的值。看每一跳的URL里这个参数变成了什么样子。
限制在于不同语言和框架对query string的解析默认行为不一样。PHP的parse_str会把加号转空格，Node.js的URLSearchParams则把加号当加号。如果跳转服务用一套规则编码，落地页用另一套规则解码，参数表面上有值，实际内容已经错了。验证方法是让落地页把收到的参数原样写进日志，跟跳转前发出的值做字节级对比。
第三步：核对参数映射表与中间页的字段裁剪逻辑
有些跳转服务不是简单透传所有参数，而是维护一张参数映射表。广告链路里的参数名可能是utm_source、utm_campaign，落地页业务系统需要的字段名可能是channel、campaign_id。映射表里少写一个字段，或者某个字段的取值规则在中间页被改写，落地页收到的参数自然不完整。
排查时把跳转服务里的映射配置导出来，和落地页期望接收的字段逐一对照。重点看几个容易出错的位置：一是映射表里有没有遗漏可选参数；二是中间页有没有根据业务规则对参数值做裁剪，比如只保留白名单里的渠道号；三是同一个参数在链路上是否被多次赋值，后面的值把前面的覆盖了。
这个环节的验证需要一条真实链路的日志。把跳转服务处理和转发参数前后的完整记录拿出来，对比落地页收到的值。如果中间页有裁剪逻辑，日志里必须能看到裁剪发生在哪个节点、依据什么条件。限制是有些第三方跳转服务的内部逻辑不透明，日志只能看到入参和出参，中间处理过程是黑盒。这种情况下可以换一条只经过自有跳转服务的链路做对照，判断问题是不是来自第三方。
第四步：区分前端二次跳转和服务端重定向的行为差异
跨域跳转里有一类是服务端302直接跳到最终落地页，还有一类是先返回一个中间HTML页面，再由页面里的JS执行跳转。两种方式对参数的影响完全不同。服务端302的Location头必须由跳转服务完整拼好，拼错了参数直接丢。前端二次跳转则多一次浏览器参与，参数可能被JS逻辑改动，也可能因为跳转脚本里只取了部分参数而丢失。
排查时先看跳转类型。如果Network里能看到302响应，就是服务端重定向，重点查服务端的URL拼接逻辑。如果看到的是200响应加一段跳转脚本，问题可能出在脚本里对location.href的赋值。操作上可以直接查看脚本源码，看它是从当前页面的query string里取参数，还是从某个JS变量里取。有的脚本会先取所有参数再拼一个全新地址，这个过程中漏掉某个字段很常见。
限制条件在于前端跳转脚本通常会被压缩或混淆，直接读源码成本高。验证方法是在浏览器控制台里手动执行脚本里的关键表达式，看取到的参数值是否符合预期。另外前端跳转还受浏览器安全策略影响，目标地址和当前页面跨域的话某些头部信息拿不到，但query string不受影响，所以参数丢失一般还是脚本逻辑问题。
第五步：检查落地页的接收位置与事件回传口径
参数到了最终落地页，不代表透传就成功了。有些落地页不是从URL里直接读参数，而是从Referer头里取，或者依赖服务端Session里存的值。跨域跳转后Referer可能被浏览器策略截断，只留下域名不带query string，如果落地页从Referer取参，参数就永远拿不到。
排查落地页接收逻辑时，先确认参数应该从哪个位置读。最稳妥的是从当前页面URL的query string里读，不依赖Referer或Cookie。如果落地页必须用Referer，需要检查跳转链路上有没有Referrer-Policy头把完整URL截掉。操作上可以用一条带参数的跨域跳转，看落地页服务器日志里记录的Referer值是否完整。
另一个容易被忽略的位置是事件回传。落地页可能成功拿到了参数，但回传事件给广告平台时参数映射又出了问题。比如说落地页把channel字段的值正确写入了表单，但回传时取的是另一个字段名，或者参数值在回传前被做了编码转换。验证方法是让落地页把回传事件的完整payload写日志，跟广告后台收到的转化事件字段做对比。
实战复盘：一个信息流渠道标记链路断掉的案例
有个做家居流量站的团队，日均点击量一千二三，投放渠道有三四个，落地页用自建系统接收渠道参数。他们的跳转链路是广告平台链接先到自有跳转服务，跳转服务做一次302再跳到一个CDN加速的落地页。某天运营发现落地页后台的channel字段空值率从百分之三左右升到百分之十几，但转化数量没有明显下降。
排查时先走了一遍链路，发现广告链接里的channel参数在跳转服务302之后还在，但到落地页就没了。CDN节点日志显示收到的URL里确实没有channel。往回看跳转服务日志，发现跳转服务拼Location头时，是从一个参数白名单数组里取字段再拼接，而channel不在这个白名单里。之前channel能透传，是因为跳转服务上一版代码是直接透传全部query string，后来为了做参数治理改成白名单模式，漏掉了channel。
调整过程不复杂，把channel加回白名单，再补了两个之前也没映射的字段。改完后在测试环境用带特殊字符的channel值走完整链路，确认落地页收到的值和广告链接里一致。上线后空值率回到个位数。这个案例的教训是，参数透传异常不一定来自复杂的编码问题，有时就是某次配置变更中一个白名单漏项。排查时先看链路日志，比直接改代码有效得多。
排查顺序的决策结论
参数透传异常的排查可以按以下顺序执行，每一步都有明确的判断条件：
- 先画跳转链路，逐跳记录URL，确定参数在哪个节点首次消失
- 检查每一跳的响应头，区分302和前端JS跳转，判断是服务端拼接问题还是脚本逻辑问题
- 核对跳转服务的参数白名单或映射表，找遗漏字段和值被改写的位置
- 确认落地页从URL、Referer还是Session取参，检查Referrer-Policy是否截断参数
- 最后核对事件回传的字段映射，确认落地页拿到的参数值是否正确回传
每一步的验证方法都依赖日志。没有全链路日志的团队，至少要在跳转服务和落地页服务器两端记录入参和出参。参数透传问题通常不是单点故障，而是多个环节的配置偏差叠加在一起。先定位断点，再判断是编码问题还是映射问题，最后才考虑改代码或调整架构。
