一个容易被忽略的症状：同一落地页在不同来源下的跳出率差了三倍
上个月有个做家居流量站的客户甩给我一份数据，看着挺闹心的。同一个落地页A，从信息流广告点进来的访客，跳出率干到了百分之六十几；从搜索品牌词进来的呢，只有百分之二十出头。他当时第一反应就是页面不行，急着要改结构。后来我把两个来源的访客行为单独拉出来看，发现压根不是一回事。搜索品牌词进来的人，本来就想买，意图很明确；信息流那边点进来的人，大部分还在到处比价、看款式，页面根本没接住他们想了解信息的需求。
你看，这个事其实暴露了一个特别常见的毛病：流量来源和落地页之间要是没拆开看，聚合数据会把不同来源用户的行为差异整个糊在一起。落地页实验要是跑在聚合流量上，分组结果就被来源结构给稀释了，你以为在测页面，实际上测的是流量配比。按流量来源拆分落地页，真不是把链接参数换一换就完事了。得想明白三个问题：哪些来源值得单独建组、拆完之后对照组怎么摆、拆出来的数据怎么判断靠不靠谱。
这篇文章就围着这三个问题来讲，聊的是实验分组和对照设置的边界条件。不碰任何平台审核规避或者差异化展示那些灰色技术，只讲流量管理、页面适配和数据归因的合规做法。
先定义拆分维度：不是所有来源都值得单独建组
按流量来源拆落地页，头一个要拍板的事，就是搞清楚哪些来源够格独立分组。来源这个维度可以切得很碎，搜索推广的字面词、信息流的兴趣标签、自然搜索的关键词、直接访问、合作渠道的引荐流量，全都能拆。拆得太粗吧，实验里看不出差别；拆得太细呢，每组样本量又不够，数据抖得厉害，今天高明天低，根本没法下判断。
从我们实际干活的角度看，一个来源要不要独立建组，得满足两个条件。头一个，这个来源的访客在落地页上的行为路径，跟整体均值有肉眼可见的差别。比如跳出率偏差超过一定幅度，或者转化之前的页面浏览深度明显不一样。第二个，这个来源的日点击量得撑得起独立分组做统计判断。要是日均就几十个点击，拆出来跑两个礼拜也攒不够可信的样本量，那拆组纯粹是给自己找麻烦，维护成本蹭蹭涨。
我们一般会用商业意图强度来分层，这个逻辑比较可操作。搜索品牌词、搜索核心词、搜索长尾词，放高意图层；信息流推荐、社交媒体内容页、内容推荐位，归到中低意图层。同一层里的用户行为差不太多，层跟层之间的决策路径区别就大了。这么切出来的组，统计上有意义，规则配置也不至于搞得太复杂。
还有一件事得提前想，就是页面模板数量。你要是每个来源都配一套完全独立的页面，维护成本是线性往上走的，来源越拆越多，最后团队扛不住。合理点的做法是页面模块化，把首屏文案、信任组件、转化钩子拆成可以自由组合的模块，按来源层去拼不同版本。这样实验调整的是模块组合，不是整个页面推倒重来。
对照组设置的三个条件：缺一个都会让结论失真
流量来源拆完之后，对照组的设置其实比实验组更关键。我见过不少团队，拆落地页的时候满脑子都是实验组怎么改，对照组随手拿个旧页面就顶上了。这要是对照组跟实验组不在同一个来源层里，跑出来的差异很可能反映的是来源本身的不同，跟页面改动半毛钱关系没有。
对照组要设得靠谱，得同时满足三个条件。头一个叫同源对照。实验组和对照组必须来自同一个流量来源层，或者来自结构相同的来源组合。打个比方，实验组是搜索长尾词分流到新落地页，那对照组就应该是搜索长尾词继续走旧页面。你拿信息流的旧页面数据来比，那算怎么回事，比出来的差距谁知道是页面造成的还是人群本身就不一样。
第二个条件是分流机制的一致性。实验组和对照组的分流得在同一个技术链路上完成，别搞成实验组走服务端重定向、对照组走前端跳转。这两个东西的加载时序不一样，会直接影响到跳出率，这个差异不该被算进页面改动的效果里。不然你测了半天，测的是跳转方式的差别。
第三个条件，转化口径得统一。拆了落地页之后，很多团队会把不同来源的转化事件分开回传。要是实验组回传的是深度转化事件，对照组只回传浅层事件，那比较出来的转化率就是个笑话。对照组的转化事件定义、归因窗口、去重逻辑，每一项都得跟实验组完全对齐，一点都不能差。
这三个条件缺一个，实验数据就会表现出一种很典型的状态：拆完之后实验组和对照组差异挺大，但波动也大得离谱，而且差异方向跟你页面改动的逻辑推演对不上。遇到这种情况，别急着下结论说页面行不行，先回去查对照组是不是同源、分流链路一致不一致、转化口径对齐没对齐。多半问题出在这几个地方。
分组之后的归因校验：先查数据有没有串组
按流量来源拆完落地页，数据串组是最容易踩的坑。串组是什么意思呢，就是本来该记到A来源组的点击，被算到B来源组里去了。一旦串组，实验组和对照组的数据全被污染，最后转化结论肯定跑偏，而且你还不一定马上能发现。
串组这事，通常出在三个环节。第一个环节是链接参数透传。落地页在跳转过程里要是把来源参数弄丢了，后面转化事件就没法正确归属。检查办法不复杂，取一段时间的点击日志，逐个核对每个点击的来源参数在落地页加载之后还在不在，以及转化事件回传的时候有没有带上同一个参数。
第二个环节是缓存。落地页要是被CDN缓存了，不同来源的用户可能看到同一个缓存版本，页面里的实验标记也跟着混在一起。查这个得去看CDN的缓存命中日志，确认带不同来源参数的请求有没有被正确区分开。动态模块比较多的落地页，一般需要针对来源参数设置缓存键，让不同来源的请求各走各的缓存条目。
第三个环节是归因窗口内的重复点击。同一个用户短时间之内从不同来源点进落地页，归因系统可能把转化记到第一次点击的来源头上。这种情况在跨设备或者跨渠道的用户路径里特别常见。处理方式是在归因逻辑里把首次点击和末次点击的优先级写清楚，同时在实验数据里单独标记那些多来源触达过的用户。
有个校验方法挺实用，就是做来源和转化的交叉分布表。把每个来源组的点击量、到达量、转化量全列出来，算算到达率和转化率的比值关系。要是某个来源组的到达率异常低，那这个来源的跳转链路十有八九有问题；要是转化量的分布跟点击量的分布差得特别远，就得去查归因环节是不是串组了。
决策阈值：什么情况下应该停止拆分或合并分组
按流量来源拆落地页，不是拆得越细就越好。拆分的收益来自更精准的页面适配，但成本也很实在：更多页面要维护、更多规则要配、数据校验越来越复杂。当拆分带来的那点边际收益已经低于维护成本的时候，就该停手了，甚至把已经拆出来的分组合并回去。
怎么判断要不要继续拆，可以盯着三个信号看。第一个信号，组间差异稳不稳定。如果拆分后的两个来源组连续两周转化率差异都维持在一个方向上，而且差异幅度超过了预设阈值，说明这个拆分是有信息量的，值得留。如果差异方向今天正明天负、来回横跳，那这个拆分就没抓住稳定的用户行为差异，再往下拆只会让数据波动更大。
第二个信号，规则维护成本的变化。每多一个来源分组，跳转规则、页面模板、转化事件配置全都得跟着调。要是一个来源组日均点击量小得可怜，维护它的时间成本却跟大组一样多，这个分组的性价比就太低了。通常日均点击量低于一定量级的来源，真没必要单独维护页面版本，合并到同一个意图层的大组里就得了。
第三个信号，转化数据的置信区间宽度。样本量越小的组，转化率的置信区间就越宽。当置信区间的下限已经低过了合并后的整体转化率，这个组独立决策的价值就很有限了。这种时候合并分组不会损失多少信息，反而能让数据稳下来。
停拆或者合并的决定，应该提前写进实验方案的预设规则里，别等数据出来了再临时拍脑袋。预设规则得包括样本量门槛、观察周期、差异阈值和置信水平。这么做能避免因为某一天数据异常就做出情绪化的调整，那种调整事后看基本都靠不住。
实战复盘：一个家居类广告投放项目的分组调整
这个客户做的是家居收纳类产品，投放渠道有搜索推广也有信息流。日均点击量一千二三的样子，搜索来源占四成左右，信息流占六成。落地页原来是一套通用模板，所有来源共用。客户的目标是提高咨询表单的提交量，但改了好几版页面，效果都不咋地。
我接手之后先把数据按来源拆开看。搜索来源的咨询提交率大概在百分之四点几，信息流只有百分之一点二。两个来源的访客在页面上的行为完全不一样：搜索用户平均浏览两到三个模块就提交表单了，信息流用户大部分在首屏之后就走了。这说明通用页面在信息流场景下根本没做好信息铺垫，用户连信任都还没建立起来，就被要求填表单，换谁都得走。
我们把实验分了两组。实验组A是搜索来源，页面保持原有结构，只调了表单位置和文案细节。实验组B是信息流来源，落地页改成先展示使用场景和用户反馈，表单入口往后放。对照组就是原来的通用页面，搜索和信息流各取一部分流量继续跑。 跑了两周，搜索组的咨询提交率从百分之四点几提到了百分之五点二，变化不算大。信息流组的提交率从百分之一点二提到了百分之二点六，翻了一倍多。但这时候冒出来一个数据串组的问题。信息流组的一部分点击在跳转过程里把来源参数搞丢了，导致大概百分之八的转化被记到了搜索组头上。这个串组比例看着不高，但已经足够让搜索组的数据虚高，信息流组的真实效果被压低了。
排查下来，发现是落地页里一个前端跳转脚本在处理参数的时候没把来源标识带过去。修复之后重新跑了一周，搜索组的真实提交率在百分之四点九左右，信息流组稳定在百分之二点四。最终客户拍板，把信息流来源单独建组，搜索来源维持通用页面的升级版。 回过头看，这个案例里最关键的调整真不是页面本身，而是拆组之后发现的那个数据串组问题。要是当时直接看聚合数据，信息流页面的改进会被搜索来源的高转化盖得严严实实，客户很可能继续在错误的方向上一版一版地改页面，越改越偏。
实施要点与检查项
按流量来源拆分落地页做实验，落地之前先把下面这几件事确认清楚。第一，拆分维度是不是基于可观察的行为差异，而不是凭感觉随便划的。第二，对照组和实验组是不是同源，分流链路一致不一致，转化口径统一没统一。第三，跳转链路里的来源参数有没有在到达页面和转化回传中完整保留下来。第四，CDN缓存策略有没有区分不同来源的请求。第五，归因逻辑里对多来源触达的用户有没有明确的处理规则。
实验跑起来之后，每周固定查一次交叉分布表，重点看到达率和转化量的分布跟点击量分布匹不匹配。发现偏离了，先查链路参数和缓存，再查归因逻辑，最后才去怀疑页面本身的问题。拆分从来不是目的，让不同来源的用户看到跟自己意图对得上的页面内容，同时保证数据归因干干净净，这套做法才算真正解决了问题。
