haiming-app-monetization

移动应用付费转化

将海明Dev的移动端实践转化为贴合当前产品的判断：先让用户感知价值，再解释购买权益，最后验证真实付费结果。目标是给出开发者可以执行的方案，不承诺收入或转化提升。

这是Meoo「AI Builder Growth Kit｜从 Vibe Coding 作品到真实收益」共创项目中的一项实践内容。 它将海明 Dev 的移动端经验，转化为适配当前产品阶段的增长判断与行动路径：先让用户直观感知价值，再清晰说明购买权益，最后通过真实付费验证方案是否有效。内容旨在帮助开发者制定可执行的方案，不承诺收入或转化率提升。 本项目采用 MIT 许可证。

选择工作范围

• 在 App 目录调用：读取项目，完成评估及方案；默认不修改产品代码。
• 提供截图、录屏、链接或产品说明：依据可见信息评估，明确无法观察的路径。
• 只问 onboarding、付费墙或定价：聚焦对应部分，不强制执行完整流程。
• 明确要求评估并实现：完成必要分析后在授权范围内实现、验证，不重复询问已确定事项。发布、改商店价格或实际购买不因调用本 Skill 自动获得授权。

1. 从真实实现建立产品理解

遵守项目规则，保留用户已有修改。先读项目说明、依赖和入口，再按调用关系定位 onboarding、核心体验、套餐、权益门槛、购买及恢复路径、分析事件。只读相关文件，不无差别读取密钥、用户数据或整个仓库。

识别目标用户、核心用途、平台、地区、收费模式和价值首次出现的位置。区分入口正在调用的页面与旧文档、注释、未挂载文件、Preview。说明代码证据的文件及行号。

形成当前路径：首次打开 → 价值体验 → 付费墙 → 商品选择 → 购买/跳过 → 权益到账或后续体验。检查 Debug 会员覆盖、已完成引导标记、设备能力及新老用户条件；运行前先确认测试状态。

代码无法证明线上价格、用户意愿、转化率或实际视觉效果。明确区分：代码事实、公开来源、运行观察、主理人经验、待验证假设。静态推导故障不得写成已复现故障。

只集中追问影响方案的关键缺口：目标用户与地区/币种、当前实际套餐、主要使用周期、持续服务成本；有数据再问漏斗和流量。其他缺口注明假设继续。已有产品优先保留可用结构，不为了套方法增加订阅周期或问卷。

2. 诊断 onboarding：问题与亮点相连

主理人的参考流程是互动提问 → 对应功能演示 → 相关亮点 → 付费墙。根据产品可合并或省略步骤，不预设越短或越长越好。

• 许诺：围绕用户实际困扰说明能获得什么改善，必须由产品真实能力支持。
• 价值唤醒：展示通过什么方式达成改善，优先真实预览、结果或可体验操作。
• 每个问题的答案应改变后续价值文案、演示、配置或推荐。可以共用页面骨架，不让所有答案进入同一套介绍。
• 只提出能够影响后续设计的问题，允许合理跳过。不要为普通用途选择收集诊断或其他无关敏感信息。
• 优先复用项目已有演示和配置组件；未实现能力标为待开发，模拟效果标为预览。
• 按用户目的和设备决定是否展示 Watch、壁纸等辅助亮点。付费或跳过后接上实际使用步骤，避免重复配置。

设计输出具体到：页面目的、问题与选项、答案对应的用户诉求、关联亮点、演示、标题/正文/按钮、下一步与退出路径、复用位置或新增工作。

3. 诊断付费墙、套餐和权益

先区分全应用门槛与单功能门槛。主理人不默认推荐硬付费墙；流量大小不是采用硬墙的充分依据。结合用户购买意图、价值证据和体验需求判断。

检查免费、免订阅限时体验、订阅试用与正式会员各自能做什么。读取具体权益门槛，不把某项功能的试用扩写成全功能试用。

• 展示关键权益差异，完整对比可展开；明确用户买到什么。
• 套餐可为月、年、周、终身，但不必全部提供。突出适合产品和用户周期的主推项；有必要才提供其他选项入口。
• 轻量工具如照片转换可优先考虑免费体验；复杂 AI/Agent 产品可讨论周订阅，但不是必选。功能复杂程度不等于成本，按实际使用周期与调用成本判断。
• 终身方案核算持续云端/AI 成本；付费周期不能与产品提供的价值脱节。
• 按所选商品切换购买按钮、计费周期、试用及续费说明。终身买断不显示订阅续费文案。
• 试用资格、模式、时长、结束后价格依据运行时商品和平台规则，不仅检查存在优惠就宣布免费。
• 徽章、社区、分享卡片仅在产品适用时建议；区分购买前可感知价值与购买后的留存、传播价值，不强行添加社区。

优惠可以使用真实的新用户价、价格对比、到期时间和退出挽回。划线价须有真实依据；计划中的未来标准价不冒充历史成交价。活动到期要实际执行，不能不断重置截止时间。推荐项可以标“推荐”，不能无依据写“最受欢迎”。退出挽回设适当频次，用户再次拒绝后能够退出。“用户会自己取消”不是自动续费设计的依据。

不要仅因存在退出按钮就认定免费体验完整，也不要仅因存在购买方法就认定交易可靠。对影响转化的路径检查：商品加载、部分商品缺失、选中项、按钮可用性、用户取消、pending、验证失败、成功后权益刷新、适用时的恢复购买。专项范围限于影响购买和权益体验的问题，不扩张成全面代码审计。

4. 竞品与定价

需要定价研究时，搜索少量同用途、同目标用户的应用，优先官方价格页和对应地区应用商店。搜索只使用公开产品描述，不发送私有源码、密钥或用户数据。

记录产品、可比原因、地区/币种、计费周期、价格、权益、试用、来源链接及查询日期。对照本地测试配置、公开商店条目、运行时商品与后台信息，遇到冲突明确记录。

• 同名商品多个价格可能是旧档位或不同优惠，不能作为独立样本取中位数，也不能推断全部可购买。
• 未知计费周期写未知，不擅自将 Pro 价格标成月费或年费。
• 竞品中间水平只能作为初始参考，再结合权益、用户价值、服务成本与现有收入选择候选价。
• 先解释是否需要改价；已有合理套餐时允许建议保持。输出币种/周期、主推理由、套餐标签和验证方式。
• 不将简单汇率换算等同区域差异定价；缺少地区数据时给出待验证假设。
• 无联网能力则说明价格未核实，仍完成代码与设计部分，不伪造来源。涉及平台订阅、试用或支付接入实现时查证相应官方文档。

5. 输出可接续实施的方案

默认写一份中文 Markdown 报告到当前任务的合适位置；遵循用户指定输出位置，案例评估时不擅自把报告写进被评估项目。用户只要口头讨论则直接回复。结构按任务裁剪：

1. 结论与范围：优先改什么，已有优点，事实依据和观察限制。
2. 优先问题：证据 → 用户影响 → 建议 → 对应代码/页面；先处理购买阻断。
3. 竞品与候选定价：来源、差异、未知项、价格和标签文案。
4. Onboarding 与付费墙：分支、逐页文案、权益、商品选择、购买与跳过后的下一步。
5. 实施和验证：复用位置、新工作、测试场景、首轮实验。

不使用无依据的评分、收入预测或提升百分比。没有运行就标注未运行；有屏幕尺寸相关判断时优先实际观察，否则列为待验证。优先提供少量高价值改动，不堆砌所有技巧。

6. 衡量真实效果

先定义主指标及分母、去重方式、地区/用户分组、观察窗口。区分付费墙购买率、新用户实际付费率、试用开启率、试用转付费率和续费率。

免费试用开启不算实际付费，等待完整观察期后比较。同步观察每用户收入、退款、取消和留存。教程查看不等于安装组件，预览不等于使用成功。

优先验证一个清晰假设。比较 onboarding 时尽量保持价格和权益一致，购买可靠性修复作为共同基线。流量足够时稳定随机分组；小样本可做可用性观察，但不冒充统计结论。未知基线和流量时不随意给出保证足够的样本量或实验天数。

评估本 Skill 本身时，使用 行为验收场景，分别说明流程完成度、实际运行验证和商业效果；三者不能互相替代。