几乎每个消费类 App 团队在第一年都会犯一个安静的会计错误。后台显示一百万用户，本能上就把他们当一百万项资产。其实不是。如果这些用户是通过内嵌的第三方网页去触达一项服务，你拥有的只是一条走廊，不是走廊后面的房间。
让我把机制说具体，因为这种流失是技术性的，不是修辞。
当你把一个第三方 H5 塞进 webview，那个页面跑在服务商的源站（origin）上。它的 cookie、本地存储、会话——全部归属服务商，不归属你。用户在那个流程里建立的身份归服务商；交易数据落进服务商的 systems；售后关系——退款、二次触达、下一次推荐——也住在那里。你抓到了那次点击，但没抓到任何能复利的东西。
这就是「流量」和「资产」的区别，而且大多数团队直到第二次想激活这批受众、却发现激活不了时，才意识到。
你到底拥有什么，摆到桌面上
| 维度 | 内嵌第三方 H5 | 小程序 runtime（宿主自有） |
|---|---|---|
| 身份 | 服务商的源站拥有会话 | 宿主自有账户体系 |
| 数据归属 | 留在第三方 | 沉淀进宿主自己的库 |
| 二次触达 | 关掉标签页即断 | 宿主消息通道召回 |
| 关系图谱 | 属于被嵌入的服务 | 宿主拥有用户图谱 |
| 监管姿态 | 宿主可能不是数据控制者 | 宿主是第一方控制者 |
| 可移植性 | 锁死在第三方 | 宿主掌控、可迁移 |
代价在三处显现。
第一，二次触达。webview 会话在用户关掉时就结束。你没有一个能稳定回到那个人手里的通道，服务商有。下一次你想说「订单发货了」或「给你个权益」，你要么征得服务商同意，要么用已经付过一次获客费的广告把受众买回来。
第二，数据图谱。一个用户与一项服务之间的关系——买了什么、频次、弃了什么——是消费业务能产出的最值钱的数据集。在第三方 H5 里，这张图谱属于被嵌入的服务。你看到的是一份你无法掌控的聚合。宿主自有 runtime 把每个事件写进宿主自己的库，图谱就在你业务内复利。
第三，也是最被低估的一项，监管暴露。在欧盟 GDPR、巴西 LGPD、印度 2023 年《数字个人数据保护法》（DPDP）这类框架下，「谁是数据控制者或受托方」不是学术问题。当第三方在你 App 内处理用户数据，你可能不是控制者——这意味着你把最敏感环节的控制权和责任一并交了出去，同时一旦出事还要扛品牌风险。
这些都不代表 H5 没用。一次性活动——引流量、转化一次、忘掉——内嵌页面便宜也好用。错误的是把它当基础设施。基础设施是你拥有的东西，租来的门面不是。
这正是超级 App 十年前想明白的部分，值得直说，因为这是它们估值的真正来源。微信、支付宝、Grab、Gojek 做的不是「你能点的网站」。它们把身份、钱包、消息通道建成了自有基础设施，再让成千上万商户在 runtime 内运行。商业层是架在一个平台端到端掌控的关系之上的。眼球从来不是资产，被掌控的关系才是。
小程序 runtime 是把这套结构复现出来的机制，而且不用从零重建一个超级 App。当服务跑在宿主的 runtime 内，身份、钱包、通知都由宿主提供——所以每次交互都写进宿主自己的账户，而不是服务商的。用户变成你手里的一条记录，而不是服务商日志里的一位访客。
我想反驳一种浪漫化解读。掌控 runtime 不等于以榨取方式「拥有用户」、为锁定而锁定。持久的 advantage 更窄也更能站住脚：它把你原本在租、且随时可能因服务商改条款或被下架而失去的关系，变成一项能扛过这些冲击的资产，因为它活在你自己的 systems 里。你不再是一个把自己的受众租给别家服务的流量提供者，而开始成为一个拥有货架、收银台和客户名单的平台。
这才是真正的分界线。流量是租来的，资产是自己的。runtime 是你从一列移到另一列的方式。
