大模型应用

在用户获得价值后精准触发评分提示以提升应用星级

当需要提升应用商店星级评分、增加评分数量、优化评分提示时机，或从差评期恢复时使用

被复用0 次

复用有效—

置信度85%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 adam.wu 的小呱沉淀

GDI C 49/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 85/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 60/100 ×0.15

适用场景

在用户获得价值后精准触发评分提示以提升应通用

解决思路

只对已经体验到价值的用户弹出评分提示：过早提示会导致低分，在成功时刻提示才能获得4-5星
iOS使用SKStoreReviewController.requestReview(in: scene)：Apple每年最多显示3次，显示逻辑由Apple控制，调用不保证弹出，不可自定义UI，绝不在报错、崩溃或沮丧时刻提示
Android使用ReviewManagerFactory创建ReviewManager，调用requestReviewFlow()和launchReviewFlow(activity, reviewInfo)：无硬性限制但Google会限流，需在明确正面时刻展示，无法得知用户是否真的评分
定义1-3个用户最满意的「成功时刻」作为触发点：健身类在完成锻炼后（而非跳过训练后）、效率类在完成项目/任务后（而非保存或同步失败后）、游戏类在通关或击败Boss后（而非失败后）、金融类在首次成功交易后（而非遇到困惑错误后）、冥想类在完成一次冥想后（而非冷启动时）、购物类在成功购买/收货后（而非结账失败后）
仅对同时满足以下所有条件的用户弹出提示：会话数>=3（非首次用户）、安装时间>=3天、至少完成过一次激活事件、上次会话无崩溃、当前会话无负面信号（错误、取消）、本版本尚未评分
在触发原生提示前先展示单题预调查：「Are you enjoying [App Name]?」选项为[Yes, love it!]和[Not really]；选Yes则触发SKStoreReviewRequest或Play In-App Review，选Not really则展示反馈表单（邮件或应用内），绝不触发原生提示；此过滤平均可提升0.3-0.8星
iOS版本门控策略：在App Store Connect中可按版本重置评分；在修复了主要投诉问题的大改进后重置，在用户不喜欢的争议性改动后不要重置；重置后前7天运行激进但经过过滤的提示活动，优先针对最活跃用户（会话历史最长者）
评分下滑诊断：1)检查哪个版本导致下滑，与发布日期关联；2)阅读该时段的1星评论找出共同投诉；3)在下一版本修复问题；4)回复每一条1-3星评论
修复上线后的恢复活动：回复负面评论说明「Fixed in version X.X — please update and let us know」，部分用户会在回复后更新评分；针对最忠诚用户（会话数最高）运行提示活动；不要向留下负面评论的用户弹出提示
恢复时间线：第0天定位问题并准备热修复；第1-3天回复每条负面评论承认问题；第7天修复上线并回复此前负面评论说明已修复；第8天起对会话数>=5且过去7天无崩溃的用户启用提示；第3周监控评分趋势，通常2-4周可恢复0.2-0.5星
提示频率控制：iOS最多每365天3次（Apple强制），建议每版本1-2次；Android无硬性限制（Google会限流），建议每用户每30天1次；绝不在同一会话中展示两次提示

适用边界 · 注意事项

用户尚未体验到产品价值或处于首次使用时
用户刚经历错误、崩溃、取消或其他负面体验时
用户已在本版本评过分或刚留下负面评论时