你花在买量上的每一块钱，聪明与否，只取决于判断它的那条归因数据。投错了渠道，你损失的不是这一块钱本身——你还会把更糟的信号喂给算法，于是它替你找到更多同款。所以衡量层从来不是后台的琐事，它是整个增长引擎的仪表盘。

而这，恰恰是「WebView 优先」的做法悄悄崩坏的地方。

裂缝就在原生 App 与 Web 相遇的地方

当流量 App 把核心链路——注册、下单、转介——跑在一个指向远端文档的 WebView 里时，分析数据并不是从一根干净的管道流过，而是掉进了两个世界之间的缝里。

Google Analytics 4 把这个毛病讲得很具体。原生 App 和 App 内 WebView 走的是两条不同的数据流：App Data Stream 和 Web Data Stream。默认情况下，GA4 不会跨数据流统一会话或用户。用户从原生界面一步跨进 WebView 再退回来的那一瞬间，会话就裂开了。原生 App 用 App Instance ID 认人，WebView 用 Client ID 认人。除非人人都登录并接好 User-ID，否则同一个真人会被算成两个人。处于漏斗最上层的匿名流量——大多数——从设计上就被重复计数。

在通向外部世界的边界上，情况更糟。每一个 App 内浏览器本质上都是一个「关掉就忘」的全新无痕窗口；第三方 cookie 通常被直接屏蔽；发起跳转的 App 常常在页面加载前就把 HTTP referrer 剥掉。分析师们记录得很清楚：相当大比例的 App 内 WebView 流量，在报表里显示为「(direct) / (none)」——仿佛那些用户是把你的网址背下来的。你的直接流量那一行被悄悄虚高，而真正把他们送过来的社交或邮件活动，一分功劳都没捞着。

为什么失真会爬到利润表上

这不是报表上的小花絮，它会爬到预算决策上。

末次点击归因本来就已经给「最后那一下点击」过多信用，而欠下「真正制造意图的那个渠道」应得的功劳。AppsFlyer 自己的 CEO 把末次点击称作「一个弥天大谎」；而行业调查仍发现 45%–75% 的营销者依赖它。再叠一个会丢 referrer、会裂会话的 WebView，失真就复利式放大：带来便宜安装的渠道看着高效，带来昂贵安装却高终身价值的渠道看着浪费，预算于是精准地错配到反方向。

浪费不是假设。2024 年第一季度，23% 的程序化移动 App 内流量被判定为无效——单个季度估计就有 14 亿美元被白白花掉。你自己的仪表盘都看不见的东西，你无从防御。

还有第二种更安静的成本：实验。A/B 测试、转介链追踪、队列分析，全都假定每个用户有稳定的身份。当同一个人变成两个人，你的对照组就被污染，你的病毒系数就成了不可知。你在对着噪声做优化。

宿主自有 runtime 改了什么

解法不是往漏水的管子上再拧一个更好的仪表，而是把链路移出不可治理的 WebView，搬进宿主能控制的 runtime。

宿主自有 runtime 把小程序当作 App 内的第一方组件来跑，而不是浏览器外壳里的一份远端文档。埋点处在同一个可信边界内：事件不会丢在「原生↔Web」的缝里，会话不会因数据流错位而裂开，referrer 也不会被一个你并不运营的浏览器剥掉。宿主保留属于自己的第一方事件日志——干净、完整、能与后端营收对账——而不是去信任一个第三方容器来汇报它里面发生了什么。

这一处改变，找回了增长团队最紧缺的三样东西：每个用户稳定的身份、贯穿整段旅程不断裂的会话、以及对发生在你自己产品内部的行为的数据主权。

WebView 衡量 vs. runtime 衡量

失效模式WebView / H5宿主自有 runtime
会话身份App Instance ID ≠ WebView Client ID；匿名用户被重复计数整段旅程统一的单一第一方身份
referrer 与 cookie在 App 内浏览器边界被剥离；流量落为 (direct)/(none)在宿主自身边界内被保留
事件丢失事件丢在「原生↔Web」缝里；自动事件可能不触发事件在单一可信埋点路径中被捕获
数据主权行为由一个你控制不了的第三方容器汇报第一方事件日志由宿主持有并可对账
实验完整性对照组被污染，病毒系数不可知稳定身份支撑干净的 A/B 与队列分析

重点不是 WebView 有多邪恶，而是你控制不了的每一层，都可能是你的衡量悄悄说谎的一层。对一个把「高效买量、留住用户」当作全部战略的流量 App 来说，把核心链路跑在别人家的浏览器外壳里，等于把仪表盘交给了黑盒。

拥有 runtime，你才拥有「增长引擎到底有没有用」这件事的真相。

参考来源