半分钟跳转二十多次，适老化要治的是跳转链路而不是字号
一、二十多次跳转其实是三类不同的东西
据公开报道，一位老人想用手机拍一段表演，打开应用后广告接连弹出，半分钟内跳转了二十多次。数字本身不是我们要用的结论，值得用的是它的形状：一次打开能堆出二十几次跳转，说明这不是一次失误，而是三条各自独立运转的机制在同一段时间里同时生效。
治理这类问题，第一步是把“广告太多”这个模糊抱怨拆成三类可归因的跳转，因为三类的责任主体完全不同，改法也完全不同。
| 类型 | 发生位置 | 一次手势引发的跳转数 | 责任主体 | 能改的地方在哪 |
|---|---|---|---|---|
| 开屏阶段连点 | 启动页与首屏广告层 | 一次误触可串出多跳 | 应用自身与开屏接入方 | 首屏布局、跳过控件热区、开屏时长 |
| 插屏与激励视频误触唤起 | 任务中途弹出的全屏层 | 一次弹层可带一次外跳 | 广告接入方为主 | 弹出时机白名单、关闭热区尺寸 |
| 页面内广告位多层重定向 | 内容流里的原生广告位 | 一次点击可重定向多次 | 广告网络与落地页链条 | 重定向次数预算、落地页归属登记 |
三类里最难看的往往是第三类，因为用户以为自己点的是内容，实际点了广告位；而前两类至少看得出是广告。把三类混在一个投诉标题下讨论，最后所有改动都会落到“少放点广告”这种没人能验收的话上。
二、跳转链路在自家客户端里是测不出来的
有人会问：跳转这么多次，我们的自动化测试怎么从来没抓到过？原因是跳转发生在广告 SDK 内部。业务代码这一侧只知道自己收到了一个事件“用户点击了广告位”，之后发生的是 SDK 自己发起的连续重定向：换域名、换协议、唤起外部容器、再落地到某个页面。这一整段都在业务代码的视野之外，直到用户已经不在应用里。
这带来两个后果。第一，客户端的性能测试、崩溃测试、UI 走查都不可能发现它，因为被测应用确实只做了一次跳转动作，后面是第三方在做。第二，出问题后我方拿不出证据——日志里只有一条点击记录，用户说的是二十几次，两边对不上，讨论就变成了“是不是用户在撒谎”。
所以链路必须用另一种方式测：把整段过程录下来，而不是把代码跑一遍。可行的做法是在真机上做一次链路录制，记录每一次页面切换、每一次外部容器唤起、每一次返回落点，形成一份带时间序列的跳转记录表。这份表是唯一能拿去和广告接入方对质的东西，也是唯一能证明“这一跳不是我们发起的”的东西。
三、跳转预算要写成接入约束，不是事后投诉
真正能落地的规则只有一句：一次用户手势最多引发一次跳转。这句话听起来像诉求，但它完全可以写成技术约束，而且能测。
一条可执行的跳转预算至少要含三个字段：
- 重定向预算：一次用户手势从点击到最终落地，允许的 HTTP 重定向与页面替换次数上限，超过即中断并落回应用内兜底页。
- 出容器预算：一次任务过程中允许离开本应用容器（唤起外部页面、外部应用、系统浏览器）的次数上限。离开一次要有可见提示，第二次直接拦下。
- 回不来时的兜底：跳转链中断、外部页面打不开、返回按钮失效这三种情况的统一落点页。兜底页必须给出“回到我原来的任务”这一个动作，而不是再放一次推荐内容。
关键是这段约束写在哪里。写在自家代码里管不住第三方 SDK，写在投诉话术里没有约束力。它应该出现在广告 SDK 的接入协议与接入清单里，作为准入条款：不承诺重定向预算的素材位不接，接入后超预算的按条款下线。这才是它能被执行的位置。
四、误触在老年用户身上成本更高，对应三条界面约束
同样的误触，在不同人群身上的代价不一样，原因有三条：触屏手势的容错窗口不同，手指按压与滑动的边界判定对老年用户更苛刻；对“跳过”按钮位置的行业先验不同，年轻人凭经验知道跳过在右上角且字很小，老年用户不知道，于是会去点中间那个明显的图；误触之后的退出路径不认识，不知道返回键、外部页面、系统导航之间是什么关系，只能反复点，于是每次反复又触发一跳。
对应到界面上，三条约束可以写死进验收标准：
- 关闭与跳过的热区尺寸要有下限，而且热区要明显大于可视图标本身。判定方式是量出来的，不是感觉出来的。
- 跳过按钮不允许被缩略图、动效或“跳过”以外的任何装饰遮住，也不允许在倒计时间里移动位置。位置会变，用户的先验就作废。
- 离开应用之后必须有明确的回退入口和文案，文案要写成动作而不是名词，例如“回到之前拍视频的地方”，而不是一个返回箭头。
这三条不是“适老化”的加分项，它们直接决定一次误触是花两秒还是花二十几次跳转。
五、埋点要补的四个字段和一张归属表
出事后要回答的第一个问题是“这二十几次是谁发起的”。现有埋点结构通常回答不了，因为它记录的是页面访问，不是跳转链。要补的字段有四个：
- 触发来源广告位标识：这一次跳转由哪一个广告位实例引发，而不是“广告位”这个大类。
- 每一跳的目标域：按跳转次序记录目标域名或协议头，形成有序序列。
- 是否离开应用容器：这一跳是应用内路由，还是跳到了外部。
- 用户是否有主动返回动作：链上有没有一次真实的人工返回，用来区分“用户自己在逛”和“链子在带着用户走”。
有这四个字段，一段争议就能被还原成一张时序表；没有这四个字段，任何讨论都是各说各话。
配套的是一张广告位归属表，按位置登记每一个可点击广告位：所在页面与位置、接入方、素材类型、是否会引发外跳、末次链路录制里的实际跳转次数、负责人。这张表的作用是把“这块地方是谁的”变成有主的事项。绝大多数跳转失控问题之所以拖着不改，不是没人知道，是因为没人能说出该谁改。
六、首屏禁则、老年模式的裁剪与会上怎么摆平
一条最省事的规则：任务型入口的首屏不允许放会重定向的广告位。拍摄、扫码、付款、乘车码、健康码这一类入口，用户带着明确目的来，路径上任何一次重定向都不是干扰而是打断。规则可以具体到“从启动到进入拍摄取景框的界面里，不出现任何可外跳元素”，这条能被自动化检查，因为入口路径是固定的。
老年模式不能只是一个字号开关。真正的裁剪至少有三项：关掉全部可重定向广告位；只保留不跳出的信息流类型；把任务路径最短化，常用功能直接给入口卡片，不做二级嵌套。字号是显示层的事，跳转是链路层的事，一个开关管不了两层。
至于商业目标和合规在会上怎么摆平，靠道德劝说没有用，靠改指标口径有用。把跳转次数做成一个产品健康度指标，和收入指标并排在同一张表上按广告位维度出数，让“某个位置贡献了多少收入、平均引发几跳”同时可见。一旦只有投诉量落在运营侧，而收入落在商业侧，改跳转的人永远在亏钱；两个数放在一起，讨论才有共同语言。
洹拓给客户做客户端时，能在合同范围内把住的就三件事：接入清单里写明跳转预算与超预算的下线条件；每次上线前跑一次真机链路录制并把时序表随版本存档；给广告位建归属表并指定负责人。三件事的共同点是都不要求第三方改变商业模式，只要求把这条链变成可测量、可归因、可回退的工程对象。一个客户端如果连“一次手势几跳”都测不出来，它对用户做出的任何适老化承诺都只是文字。