Progressive Web Apps（PWA）：应用安装广告的 APK 替代方案

Progressive web apps 是什么，投手为何要关心

Progressive web apps（PWA，渐进式 Web 应用）是「行为像已安装原生 App 的网站」。它在浏览器里加载，但借助 Web App Manifest 和 Service Worker，可以被添加到主屏幕、以全屏方式脱离浏览器外壳启动、离线工作并发送推送通知。在用户看来，它的样子和手感就是一个原生 App，却没有 APK 下载、没有应用商店上架，也不用等审核。

对效果广告投手和应用安装营销人来说，最后这句话就是全部重点。如果你跑用户获取（UA）广告，你的转化漏斗通常是「广告点击 → 商店页 → 下载 → 安装 → 首次打开」，而每一步都在漏人。PWA 把漏斗中段压缩成一次点击，这正是 progressive web apps 悄然成为成本敏感、跨平台 UA 场景下首选 「应用安装广告的 APK 替代方案」 的原因。

本文写给买量投手，而非工程师。如果你想要开发者层面的搭建步骤，可阅读我们的配套文章 渐进式 Web 应用指南（英文）。这里我们聚焦广告经济学：PWA 与 APK、PWA 与原生 App 的对比，一个 PWA 安装活动到底怎么跑，iOS 与 Android 的安装差异，以及如何上线。

PWA、APK 与原生 App：对投手意味着什么

投手通常会比较三种分发形态：PWA、裸 APK（你自己在 Play 商店之外托管的可下载 Android 安装包），以及上架到应用商店的原生 App。三者在单次安装成本（CPI）、覆盖面和风险上各有取舍。

APK 路线省去了商店审核和商店抽成，但它逼用户走一条别扭的流程：下载文件、点掉「未知来源」安全警告、再安装。这些摩擦会直接体现在 CPI 上。原生上架路线带来信任和自然曝光，但你要付商店费用、等几天审核，而且一个政策标记就可能下架你的应用——把整个广告活动一起带走。

Progressive web apps 恰好在两者之间找到平衡：从落地页一键即可安装；没有商店，也就没有商店封禁；同一套构建在 Android 和 iOS 上都能跑。下面是投手真正在意的对比：

规律很清楚：APK 在速度和成本上胜过原生，但只覆盖 Android，而且仍要用户点掉一个吓人的警告。PWA 保留了速度与成本优势，去掉了安全警告，还补上了 iOS——于是你不必再并行维护两条漏斗。

为什么 progressive web apps 能拉低你的单次安装成本

CPI 本质是一道漏斗数学题。如果 100 个人点了你的广告，最终只有 12 个完成原生商店安装，那么你的实际 CPI 就是点击成本除以 0.12。把漏斗缩短，同样的点击预算就能买到更多安装。

Progressive web apps 从四个方面缩短它：

• 没有商店跳转。 用户不用离开你的落地页、再去导航一个商店页。主屏幕安装提示在上下文里直接弹出。

• 没有文件下载。 没有几十兆的 APK 要在移动数据下拉取，也没有「未知来源」警告要去说服用户绕过。

• 首次打开即时。 原生安装完成后，用户还得去找图标、再打开；PWA 可以直接把用户交接进体验本身。

• 一套构建，两端通吃。 你不必在 Android 的 APK 漏斗和 iOS 的商店漏斗之间拆分预算和素材测试。

这些叠加起来，就是点击到活跃用户之间的流失更少——而那正是安装预算流血的地方。要让这些收益落到实处，有两个运营要点。其一，保护好漏斗：付费应用安装流量会招来机器人和无效点击，广告平台也会审视落地体验，因此在流量到达安装提示之前，用 DeepClick 绿盾（Shield） 这类工具合规地分流与过滤。其二，把那些在安装前就划走的用户找回来：再触达（re-engagement） 流程能挽回相当一部分点击后流失——这些用户在一次性漏斗里会被白白丢掉。

一个 PWA 安装活动如何一步步运作

PWA 安装活动复用你已经在跑的整套 UA 机器——同样的广告平台、同样的像素、同样的归因——只换掉落点。

1. 构建或封装 PWA。 把现有站点转换，或用 PWA builder 生成 manifest、Service Worker、图标和安装逻辑。产出物是一个 URL，而不是一个二进制包。

2. 搭好落地页。 页面检测平台并展示对应的安装提示（见下文 iOS 与 Android 一节），首屏给出清晰的价值主张。

3. 接好追踪。 部署你的像素，并在应用被添加到主屏幕时触发一个安装事件，让安装像其他转化一样回传给广告平台。

4. 投放流量。 在你惯用的平台跑活动，点击落到落地页而不是商店页。

5. 过滤与分流。 对进来的点击做机器人与无效流量筛查，把真实用户导向安装提示。

6. 度量与挽回。 跟踪安装率、CPI 和安装后行为，并对安装前流失的用户做再触达。

因为整条流程都在服务端，你以小时为单位迭代，而不是以商店审核周期为单位。改文案、换提示、补漏点，改完即时上线。DeepClick 的 PWA 安装产品 把这一整条端到端打包——生成可安装的 PWA、托管安装落地页、把安装回传进你的广告栈——让买量投手无需立项做工程就能上线。

iOS 与 Android 的 PWA 安装：唯一要提前规划的差异

让 PWA 新手最容易栽跟头的，是安装手势因平台而异，所以你的落地页必须检测平台并据此给出引导。

Android（Chrome 及 Chromium 系浏览器）： 这是顺滑路径。浏览器会弹出原生安装提示，你的页面可以放一个「添加到主屏幕」按钮直接触发它。一键，图标就到了主屏幕。

iOS（Safari）： 苹果不会以同样方式暴露自动安装提示，所以用户要手动添加 PWA：点「分享」按钮，再选「添加到主屏幕」。这依然只是几次点击、没有下载，但你必须展示一个简短的视觉提示指向「分享」图标，因为用户不会自己猜到。一个给 iOS 用户展示两步图示的落地页，转化率会远高于一个到处都假设 Android 流程的页面。

从第一天起就为两端做规划：检测平台、渲染正确的提示，并在每条路径上埋一个安装事件，让你的 iOS 与 Android 报表都保持干净。

什么时候该选 PWA，什么时候不该

当你的目标是「在两端以低 CPI 拿安装量」、你的体验以内容 / 电商 / 互动驱动、且你希望绕开商店守门人快速上线和迭代时，progressive web apps 是很强的选择。当下架风险对你的广告活动构成真实运营威胁时，PWA 也是显而易见的一步。

当你确实需要深度的原生硬件集成、当商店自然曝光和商店评价本身就是你的核心获客渠道、或当你的变现依赖走特定商店通道的内购管线时，PWA 的契合度就较弱。很多投手两条都跑：付费 UA 走 PWA 安装漏斗，自然曝光走商店上架。两者并不互斥——而单就付费应用安装这一侧而言，PWA 在成本上通常更胜一筹。

核心要点

• Progressive web apps 是应用安装广告的 APK 替代方案： 一键安装、免商店审核、无 APK 下载摩擦。

• 更低的 CPI 来自更短的漏斗——没有商店跳转、没有文件下载、首次打开即时、一套构建覆盖两端。

• 无下架风险： 没有上架，政策标记就无法在一夜之间拿掉你的广告活动。

• 规划好 iOS 与 Android 的安装差异： Android 有原生提示；iOS 用户走「分享」添加，所以要给出视觉提示。

• 保护并挽回漏斗： 合规过滤付费流量、对点击后流失做再触达，才能让 CPI 收益落到实处。

常见问题（FAQ）

用大白话说，progressive web apps 是什么？

Progressive web apps 是能被安装到主屏幕、行为像原生 App 的网站——全屏启动、离线支持、推送通知——而不需要应用商店或 APK 下载。对投手而言，PWA 是一个可以拿来跑安装活动的 URL，用它替代商店上架页。

PWA 真的能替代 APK 文件来跑应用安装活动吗？

可以。两者都跳过应用商店审核，但 PWA 一键即可安装，没有文件下载、没有「未知来源」安全警告，而且能在 iOS 和 Android 上都跑。这去掉了裸 APK 路线最大的两个摩擦点，也正是 PWA 越来越成为成本敏感型 UA 默认 APK 替代方案的原因。

Progressive web apps 真能降低 CPI 吗？

它降低的是「广告点击到活跃用户」之间的流失，而这正决定了实际 CPI。通过去掉商店跳转和下载步骤、并用一套构建服务两端，PWA 安装漏斗在同样点击成本下，比原生商店漏斗转化更高比例的点击。

PWA 安装在 iPhone 和 Android 上分别怎么操作？

在 Android 上，浏览器会展示原生安装提示，你的落地页可以用「添加到主屏幕」按钮触发。在 iPhone（Safari）上，用户点「分享」、再选「添加到主屏幕」，所以你的页面应展示一个指向「分享」图标的简短视觉提示。两条路径都无需任何下载。

我需要 PWA builder，还是可以直接转换现有站点？

都行。PWA builder 会替你生成 manifest、Service Worker 和安装逻辑，但现有的移动站点也可以升级成可安装的 PWA。一个托管式 PWA 安装产品会包办构建、安装落地页和安装追踪，让买量投手无需立项做工程就能上线。