最近在给自己的小说站跑 Facebook 广告，一个不起眼的配置让我琢磨了很久：设备定向要不要排除 iOS？

直觉上觉得应该不排，覆盖更多用户嘛。但实际想清楚之后，我做了一个反直觉的决定：只投 Android，最低 Android 9，iOS 暂时全排除。

这个决策背后有技术原因，不是玄学。

一句话总结

iOS 14.5+ 的 ATT 政策让 Meta Pixel 无法回传事件，广告系列的优化方向会跑偏；在没有 CAPI（Conversions API）的情况下，投 iOS 等于把预算喂给算法噪音。

iOS 信号丢失：不只是归因问题

先讲技术机制。

iOS 14.5 之后 Apple 推出了 ATT（App Tracking Transparency），要求所有应用在追踪用户行为前必须显式获得授权。绝大多数用户选择「不允许追踪」。

这对 Meta Pixel 的影响是致命的：

  1. 用户在 FB 上看到广告，点击进入小说站
  2. 小说站的 Pixel 代码触发 ViewContent 事件，准备回传给 FB
  3. iOS 系统层面直接拦截，事件永远到不了 Meta 服务器

结果是：FB 的广告系列认为这批 iOS 用户点了广告之后「什么都没发生」。算法会把这批流量标记为低质量，调整投放方向——但这个调整方向是错的，因为信息本身就是残缺的。

更严重的问题是：这不只是归因断裂，而是优化方向整体跑偏。

你以为广告系列在学习「哪些人喜欢看小说」，实际上它在学习「哪些 Android 用户点击了广告」（因为 Android 的 Pixel 信号是完整的）混合「哪些 iOS 用户不知道为什么点了」（信号丢失的噪音）。两个群体混在一起喂给算法，学习效率会被拉低。

为什么选 Android 9 作为最低版本

排除 iOS 之后，还需要设一个 Android 的最低系统版本。我选了 Android 9（Pie），原因很具体：

技术侧：我的小说站用 Next.js 静态导出，前端依赖了几个关键的现代 Web API：

  • IntersectionObserver：AdSense 懒加载和 ChapterPixel 的章节完成检测都依赖这个 API，Android 8 以上才稳定支持
  • CSS Grid / Gap / Aspect-ratio：Android 9 以上渲染稳定，Android 8 的 WebView 有已知 bug

运营侧：Android 8 发布于 2017 年，2026 年在用 Android 8 的用户基本是 5 年以上没换机的存量，购买力和活跃度都很低。排除掉这批人不影响核心受众覆盖，还能减少无效曝光。

实际覆盖：最低 Android 9 能覆盖 约 98% 的活跃 Android 用户。

只投 Android 对费用的影响

信号质量之外，设备选择还直接影响投放成本。

CPM（千次曝光成本）：iOS 广告主竞争密度更高，因为多数广告主默认认为 iOS 用户消费力强。实际测下来，仅投 Android 的 CPM 通常低 15–40%，同预算能买到更多曝光。

单次成效费用（CPR）：这个才是核心指标。CPR 低不只因为 CPM 低，更因为归因完整——算法清楚知道哪次点击带来了 ViewContent，出价越来越精准。iOS 混进来后，算法收到的是残缺信号，出价逻辑会变得保守且不稳定。

学习期：Facebook 广告系列需要积累 50 次转化事件才能脱离学习期。Android 信号完整，50 次的门槛更快达到；iOS 混进来后，部分转化事件丢失，学习期被拉长，预算在不确定状态下消耗更多。

什么时候 Android 反而更贵：如果落地页在 Android 低端机上加载慢（碎片化严重），跳出率高会把 CPR 拉上去。这也是为什么要设最低 Android 9——过滤低端慢机，间接保住落地页体验。

操作路径

在 FB 广告管理工具里，广告组层级配置：

1
2
3
4
5
广告组 → 版位 → 手动版位

设备类型：仅限移动设备
操作系统：仅限 Android（选移动设备后出现）
操作系统版本：最低 Android 9 / 最高：无

注意：这个设置在「手动版位」里，先切换到手动版位才能看到 OS 筛选项。「进阶赋能型版位（推荐）」模式下无法手动指定 OS。

什么时候回开 iOS

当前排除 iOS 是因为没有 CAPI，信号丢失没有补救手段。有两个条件满足任意一个，就可以考虑回开：

条件一：CAPI 上线。Conversions API 是服务端事件回传，绕过 iOS 的浏览器层拦截，直接从服务器把事件推给 Meta。上了 CAPI 之后，iOS 用户的 ViewContent 等核心事件可以正常回传，算法能重新学习这批用户。

实现门槛不低——静态站（Next.js output: ‘export’）没有运行中的 Node.js 服务器，需要额外部署一个 API 服务（Vercel Function / Cloudflare Worker / AWS Lambda 都可以）。当前日耗 <$50，性价比不足，等规模上来再搞。

条件二：GA4 数据证明 iOS 质量更高。接入 GA4 后，可以按操作系统分组看读者质量指标：人均阅读章节数、平均停留时长、跳出率。如果 iOS 用户这些指标显著优于 Android，那即使信号丢失，从流量质量角度也值得回开——只是归因会不准，但读者是真实的。

我的判断框架

场景建议
日耗 < $50，没有 CAPI，没有 GA4 数据只投 Android（当前），先把算法喂干净的信号
GA4 数据显示 iOS 读者质量 ≥ Android考虑回开 iOS，接受归因不准的代价换流量
CAPI 上线，信号丢失消除回开 iOS，此时投全量设备效益最大
日耗 > $100，CAPI 还没上重点关注，Signal Loss 警告会出现，CAPI ROI 开始合算

当前我的判断：可以再等。先把 GA4 接进来，有了读者质量数据之后再决定 iOS 是否值得回开。

这个决策不是永久的，是阶段性的——在信号不完整的情况下，优先喂给算法干净的数据，比追求覆盖面更重要。