跳转插件是本文的核心主题。查询参数到底该透传还是该去掉，这事儿没有标准答案。我一般会先问一句：这个字段往下走，有没有人真的会读它？如果下游有消费方、字段本身又不敏感，那就透传；反过来，没人用、或者涉及合规风险、或者会把缓存键撑碎，那就在跳转规则里干脆去掉。真正坑人的地方在于，很多字段是"顺手带过去"或者"顺手删掉"的——两边都没想明白为什么这么干。
上个月有个做家居流量的客户来找我聊这个问题。他们日均点击量四千上下，跳转插件里配了一条通用规则，所有入站参数原样拼到目标链接上。跑了三周，落地页的渠道归因报告里冒出一堆没见过的来源字段，同时部分页面的缓存命中率从七八成直接掉到四成左右。后来一查，就是透传规则把上游一些临时参数、跟踪参数、甚至用户输入框回填的内容一起带了过去，缓存键被撑开了，归因口径也跟着被污染。这个案例后面我会细说。先把判断的四个维度讲清楚。
维度一：参数有没有下游消费方
这是第一道边界，也是最硬的一道。跳转规则里处理一个参数之前，先回答一个问题：目标页面、落地的后端服务、或者后续的统计脚本，有没有任何一处会读取这个字段？ 有消费方的典型例子是渠道标识、投放计划号、素材编号、活动 ID 这些。它们通常要一路传到落地页，再由页面上的统计代码或后端接口读取，用于归因和拆分。这类参数必须透传，而且在多级跳转链路里要保证每一跳都不丢。
至于没有消费方的，典型的是上游系统内部用的临时追踪串、调试标记、会话临时 ID。它们只在发起跳转的那一侧有意义，到了目标页就是死重量。这类字段应该去除——跟它有没有害关系不大，主要是它没有任何收益，却增加了缓存维度和日志噪音。 操作上，我建议在跳转规则里建一张白名单，明确列出允许透传的字段名，其余一律不进目标链接。这比建黑名单稳妥，因为上游随时可能加新参数，黑名单永远补不全。限制条件是白名单需要维护，渠道方新增跟踪字段时要同步更新，否则会出现"参数没丢但也没被识别"的情况。验证方法是跳转后在目标页读取一次 location.search，和白名单逐项比对。
维度二：参数是否含敏感或可识别信息
第二道边界是合规。查询参数里经常混进不该出现在 URL 里的东西：用户填写的手机号后四位、邮箱前缀、订单片段、内部用户 ID、带签名的令牌。这些字段一旦透传到目标地址，就会留在浏览器历史、服务器访问日志、以及可能被第三方脚本读取的 referrer 里。
判断标准其实可以简化成一句话：这个字段如果出现在一封邮件里被转发出去，会不会有问题。会，就必须在跳转规则里去除或改写。
去除的操作有两种。一种是直接从链接里删掉，适合那些下游根本不需要的字段。另一种是替换成不可逆的短标识，适合下游确实需要区分用户但不该拿到原始值的场景，比如把手机号替换成内部哈希后的短串，下游只用它做去重和分组。第二种方式需要在跳转规则里接一个改写步骤，配置复杂度会高一些。
限制条件是改写要保证一致性，同一次会话里同一个用户改写出的短串必须相同，否则下游的去重逻辑会失效。验证方法是构造几组相同输入，观察改写结果是否稳定，以及原始值是否确实没有出现在任何一跳的完整 URL 里。
维度三：参数对缓存命中的影响
第三个维度最容易被忽略。跳转的目标页如果走了 CDN 缓存，那么查询字符串通常参与缓存键计算。透传的参数字段越多、取值越分散，缓存键就越碎，命中率越低。
这就解释了前面那个家居流量站的问题。他们的目标页缓存本来是按路径加少数几个归因字段来切的，命中率能到七八成。透传规则把所有上游参数都带过去之后，缓存键里多出十几个维度，同样的页面被拆成大量不同的缓存对象，命中率掉到四成左右，源站回源压力明显上升。
边界在这里很清晰：透传的字段里，只有真正参与归因或分组的维度才应该进入缓存键，其余字段要么去除，要么在跳转规则里做归一化处理，比如把取值映射到有限几个枚举值。
操作上可以和缓存策略配合。一种做法是在跳转规则里把非归因参数统一剥离，只保留白名单字段。另一种做法是保留参数但调整缓存键规则，把不参与内容差异的字段排除在缓存键之外。前者改的是跳转插件配置，后者改的是 CDN 配置，两者要协同，否则会出现"跳转层去掉了、缓存层还在按完整 URL 切"的错位。
验证方法比较直接：对比调整前后的缓存命中率曲线，同时确认归因报告里的字段没有缺失。这两者是拉扯关系，调整时两边都要看。
维度四：参数是否参与归因口径对齐
归因是透传最主要的正当理由，但也是最容易出错的环节。广告平台回传的跟踪参数、跳转插件自己加的标记、落地页统计脚本读取的字段，这三者必须对齐同一套命名和含义，否则数据会在链路里错位。
常见的问题是同一含义用了不同字段名。比如投放侧叫 plan_id，落地页统计脚本读的是 utm_campaign，中间又有人加了个 campaign_code。透传规则如果只透传其中一部分，归因报告里就会有一段是空的。
边界在于：参与归因的字段必须透传且命名统一，不参与归因的字段不要为了"以后可能有用"而保留。判断方式是拿一张字段映射表，把投放侧、跳转侧、落地页侧三处的字段名列出来，逐行对齐。对不上的要么统一改名，要么在跳转规则里做字段重命名。
限制条件是字段重命名会增加跳转规则的可读性负担，字段一多容易配错。建议把重命名集中在一处，不要在多条规则里分散处理。验证方法是跳转后用抓包或者日志回放，确认目标 URL 里的字段名和落地页脚本读取的字段名完全一致。
四类场景的边界归纳
把上面四个维度合起来，可以归纳成四类典型场景，每类的处理方式不同。
- 第一类：有消费方、不敏感、不进缓存键。这类字段透传，且要保证多级链路不丢。典型是渠道标识和活动 ID。
- 第二类： 有消费方、不敏感、进缓存键。透传，但取值要做归一化，避免缓存键过度分散。典型是分组维度。
- 第三类： 有消费方、敏感。改写后再传，或者只传哈希标识。典型是用户标识类字段。
- 第四类： 无消费方。一律去除，不论敏感与否。典型是内部临时参数和调试标记。
这个分类的价值在于，它把"透传还是去除"从一道全局选择题，变成了一组逐字段的判断题。配跳转规则时，一个个字段过一遍，落到哪一类就按哪一类处理。
实战复盘：一个家居流量站的参数治理过程
回到开头那个客户。背景是家居流量站，日均点击四千上下，服务器是常规的双核四 G 配置，目标页走了 CDN，跳转插件用的是通用透传规则。
踩的坑有三个。第一，透传规则没有白名单，上游所有参数原样带过去，包括一些临时追踪串和页面回填字段。第二，其中一部分字段含用户输入的片段，虽然不完整但足以定位到具体咨询记录。第三，缓存键按完整 URL 计算，参数一多命中率就塌了。
调整过程分三步走。先把上游参数做了全量梳理，列出每个字段的来源和可能的消费方，梳理出大概二十来个字段。然后按上面四类场景分类，最后只保留了七个字段进白名单，其中两个做了归一化处理，一个敏感字段改成哈希短串。剩下的全部在跳转规则里去除。 同时和 CDN 侧确认了缓存键规则，把非归因字段从缓存键里排除。这一步不能只改跳转层，否则会出现参数去掉了但缓存行为没变的情况。
调整后的状态是：缓存命中率回到七成多，归因报告里的字段比之前少但每一项都有明确来源，敏感片段不再出现在任何一跳的完整 URL 里。归因数据的总量没有下降，只是字段收敛了。
上线前的逐字段检查项
把上面的内容收束成一份可以照着走的检查清单。配跳转规则时，对每一个查询参数问下面几个问题，任何一个答不上来就别急着上线。
- 这个字段的下游消费方是谁，具体在哪一段代码或哪一份报告里被读取。
- 如果不去除，它会不会出现在访问日志、浏览器历史或 referrer 里，是否会带来合规风险。
- 它是否参与缓存键计算，取值是否分散，会不会显著拉低命中率。
- 它在投放侧、跳转侧、落地页侧的字段名是否一致，不一致时在哪里做重命名。
- 多级跳转链路上，它在每一跳是否都被完整保留，有没有中间环节静默丢弃。
- 去除或改写之后，归因报告里对应的指标是否仍然可读。
这六项里，前三项决定字段该不该传，后三项决定传了之后链路和口径对不对。配规则时逐项过一遍，比上线后回头排查省事得多。
关于默认策略的一点结论
跳转插件的默认参数处理策略，建议设成"白名单透传加其余去除"，而不是"全量透传加事后清理"。原因很实际：全量透传在初期看不出问题，等到缓存命中率下滑或归因口径混乱时，排查成本已经很高；白名单模式虽然需要事先梳理字段，但边界清晰，新增字段时也有明确的加入流程。
例外情况是上游参数极少且都明确有消费方的小项目，这时全量透传的维护成本确实更低。但只要链路里出现了第三方跟踪、用户输入回填、或者多级跳转，就应该切到白名单模式。这个切换点，本质上就是"参数数量和来源是否已经超出你能一一说清楚的范围"。
参数处理没有一劳永逸的配置，它跟着投放链路一起变。每次渠道方新增跟踪字段、每次落地页统计脚本改字段名，跳转规则里的白名单和重命名都要跟着动。把这份检查项沉淀成配置文档的一部分，比记在某个人的脑子里可靠。
