拆了 11 个出海短剧 App:没有一个在做 Web 自充
- 2026-10-04 15:44:55
三句话讲完这次拆包
●11 个包里，没有任何一个第三方支付 SDK。
Stripe、Adyen、PayerMax、Airwallex、Xsolla 全部零命中，收款 100% 还在苹果谷歌的计费通道里。所谓「短剧都在做 Web 自充」，至少在 App 内，样本里零人在走。
●归因是一家通吃，变现是全家桶。
AppsFlyer 10/11，Adjust 只有 1 个；而广告中介平均每个 App 同时接 9 家，最多的接了 14 家。同一批团队，在两件事上的策略完全相反。
●买量砸七成，留存工具投入是零。
Braze、CleverTap、OneSignal、MoEngage、Airship 这些 CRM，全部零命中。召回只剩下 Firebase 裸推送一条路。
报告告诉不了你的那部分
我写过短剧的成本结构，也写过渠道税和收款。这些文章有个共同的软肋：数据都来自公开报告。报告能告诉你市场多大，告诉不了你一件事——同行现在到底在用什么。
归因用谁、支付接谁、变现靠谁，厂商不会公布，也没有哪份报告统计。但它其实是公开的——就写在每个 App 的安装包里。
所以这次换个做法：把公开渠道能下载到的出海短剧 App 安装包解开，扫里面集成了哪些第三方 SDK，再做分布统计。
样本 11 个 App、11 家不同厂商、合计 1.1 GB 安装包；指纹库覆盖 12 类 119 个产品共 267 条特征。结论只出聚合分布，不点名单个 App。
三类证据，为抗混淆而设计
先讲清楚方法，这决定了后面的数字能信到什么程度。每个 SDK 用三类信号，任一命中即判定集成：
●类路径
DEX 里的类描述符前缀，比如 com/appsflyer。信号最强，但 R8/ProGuard 会把类名改掉。
●服务端域名
代码里硬编码的接口域名，比如 appsflyersdk.com。抗混淆——域名是字符串常量，混淆器不会改它。
●文件特征
so 库名、assets 文件名。同样抗混淆。
加入域名这一层是刻意的：只靠类路径会系统性低估重度混淆的 App，而出海应用恰恰是混淆最狠的一类。
但域名这层也带来一个陷阱，它差一点让本文的归因结论完全写反——第二条发现里专门讲。
11 个 App 的关键 SDK 覆盖
虚线框表示零命中。全员在用的是商店内购和广告聚合；零命中的是第三方支付和第三方 CRM——这两个「零」是本文的主线。
说好的 Web 自充，App 里一个都没有
先看最反常识的一条。这是 11 个包里所有支付类 SDK 的命中情况：
| Google Play Billing | 11/11 | |
每个点是一个 App。实心＝命中，虚线空心＝未命中。
翻遍 11 个包，没有任何一个第三方收银台。这意味着这些 App 的收入 100% 经过苹果和谷歌的计费通道，那 15%~30% 的渠道分成，一分没省下来。
行业里讲了一年短剧要靠 Web 自充绕开渠道税，头部产品的 Web 站也确实存在。但「在 App 里放一条自有支付通道」这件事，样本里零人在做。
答案在上一篇里：苹果外链给 7 天 归因窗口，谷歌 24 小时，而 App 内外链本身还要交 10%~20% 的「外链税」。真正 0 分成的只有「广告 → Web 落地页 → 支付」这条完全绕开 App 的漏斗——它跑在 App 外面，安装包里当然扫不到。
严谨地说：这说明 App 内没有第三方收银台，不排除厂商在 App 之外运营独立 Web 站。但这恰恰印证了渠道税那一篇的结论——平台把 App 内这条路堵死了，能走的只剩 App 外。
一家通吃，以及差点写反的结论
第二条是归因。结果非常集中：
AppsFlyer 10/11 近乎垄断 | Adjust 1/11 仅一家 | 其他 0/11 无类路径证据 |
归因在很多赛道是 AppsFlyer 和 Adjust 二分天下，在出海短剧里几乎是一家通吃。
差点写反的一条结论
第一轮的结果是错的：Kochava、Tenjin、Singular 各命中 2 次，看起来「平均每个 App 接了 4 家归因」。
查证后发现：这三家全部只匹配到域名，没有一条类路径。
原因：AppLovin、ironSource 这类聚合 SDK 内置了各家归因商的回传域名清单——接了聚合，就等于把所有 MMP 的域名一起打包进了安装包。
修正口径：归因与埋点类结论只认类路径证据，域名命中单独标注、不计入统计。
这是这类分析最容易翻车的地方：指纹匹配上了，不等于那个东西真的在。不区分证据类型，一篇看起来数据详实的文章就会把行业格局描述反。
平均每个 App 同时接 9 家广告中介
和归因的高度集中相反，广告变现这一端是彻底的「全家桶」：
| AppLovin MAX | 11/11 | |
| Google AdMob | 11/11 | |
App 编号已匿名，仅表示 11 个样本。广告中介占单个 App 全部 SDK 的 18%~52%，中位约四成。
单个 App 接入的广告中介家数：最少 4 家，最多 14 家，中位数 9 家。
没人敢只用一家，因为聚合层收益直接取决于竞价参与方的数量。同一次曝光，出价的中介越多，eCPM 越高，填充率也越稳。对一个毛利薄到个位数的生意，这几个点就是生死线。
代价是包体和稳定性：样本里最大的包 165 MB 接了 14 家，最小的 23 MB 只接 5 家。每多接一家，都是一次 SDK 冲突和崩溃率的赌博。
买量投到飞起，召回还在裸推送
第四条最值得说，因为它是个「空白」而不是「发现」。
Firebase FCM 11/11 裸推送 | 第三方 CRM 0/11 全部零命中 | 实验平台 7/11 仅 Remote Config |
Braze、CleverTap、OneSignal、MoEngage、Airship、Iterable、Insider——生命周期运营这个品类里能叫得上名字的产品，在 11 个包里一个都没有。
一个把七成以上流水砸进买量的赛道，前端投放精细到素材级别，后端留人的工具投入却是零。漏斗前端拼命灌水，后端连个阀门都没装。
这解释了买量成本为什么压不下来：召回只剩裸推送，用户流失后几乎没有第二次触达机会，增长只能靠继续买。LTV 提不上去，CAC 就永远降不下来。
也可能是这些团队把生命周期能力做进了自研后台。但即便如此，「零第三方 CRM」本身也说明这一环的优先级排得很后。
海外产品，中国底座
最后一条是结构性的：这些产品面向海外用户，底层却大量跑在中国云上。
播放器好理解：短剧的核心体验是「秒开 + 不卡」，国内云厂商在这件事上工程积累更深，转码、CDN、防盗链都是现成的。
但埋点是另一回事。火山 AppLog 5/11、神策 3/11，意味着相当一部分海外用户的行为数据回流到中国的数据平台。这在合规上是个需要主动管理的风险点，尤其在数据本地化立法收紧的市场。
短剧 App 里的人脸活体
还有一条不成体系但有意思的：11 个包里有 2 个集成了 FaceTec——人脸活体核验，通常用在金融开户和实名认证场景。
最可能的解释是分级内容的年龄验证，或创作者端实名。2/11 的样本量不足以下结论，但如果未来几个季度这个数字在涨，说明内容分级正在从政策压力变成产品必选项——值得盯着。
这份数据的边界
样本 11 个，不是全量。另有 9 个安装包在公开渠道反复下载不完整（含赛道头部之一），未纳入；红果海外版混淆过重（283 MB 只扫出 2 个 SDK），作为离群样本单列，不进百分比。
命中 ≠ 线上启用。包里有这段代码，不代表功能开着——可能是历史残留，也可能只在特定地区或版本生效。
只做只读解包 + 字符串匹配。不反编译、不修改、不运行任何安装包；包来自公开下载渠道，不涉及破解或绕过。
重度混淆会让数字偏低。三类证据已在对冲这一点，但对混淆最狠的产品仍会低估。所以横向比「谁接得多」没有意义，本文只做品类层面的分布。
「出海的钱怎么走」这条线
渠道税地图 · 平台怎么收这笔钱，以及为什么 App 内绕不开
成本结构 · 买量 65 + 分成 30，完整算一遍
收款地图 · 新兴市场收款的三层损失
你手上的产品，这几项是怎么选的？
留言区聊聊你的选型和踩过的坑。《出海 SDK 图谱》每季度重扫一版，下一版补齐短剧样本，并扩到新兴市场借贷赛道。
关注「智跃出海」· 每篇先说结论
