研发协作
应用评分下降或差评增多时:分析并回复评论…
当需要分析、回复或改善应用评论与评分,尤其是差评增多、评分下降或想获取更多好评时,使用本技能。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 38/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15
适用场景
应用评分下降或差评增多时:分析并回复评论特定
解决思路
- 初始评估:检查并读取 `app-marketing-context.md`,获取上下文。
- 初始评估:向用户询问 App ID,以便抓取当前评论。
- 初始评估:向用户询问目标国家/地区,默认 US。
- 初始评估:向用户询问当前评分和趋势(上升还是下降)。
- 初始评估:向用户询问当前是否回复评论。
- 情绪分析:把评论归类为 Bugs & Crashes;对这类技术问题,修复并回复修复时间线。
- 情绪分析:把评论归类为 Feature Requests;对这类新功能需求,跟踪提及频率并考虑加入路线图。
- 情绪分析:把评论归类为 UX Complaints;对这类困惑或挫败流程,优先改进 UX。
- 情绪分析:把评论归类为 Pricing Complaints;对太贵或 paywall 问题,审查变现策略。
- 情绪分析:把评论归类为 Love & Praise;对正面反馈,感谢用户并邀请分享。
- 情绪分析:把评论归类为 Competitor Mentions;对用户比较替代品的内容,理解竞争差距。
- 追踪指标:平均评分目标为 4.5+ 星;低于 4.0 会显著伤害转化。
- 追踪指标:评分趋势应稳定或改善;下降趋势是问题信号。
- 追踪指标:评论速度应一致;突然下降可能说明评分提示有问题。
- 追踪指标:差评回复率目标为 100%;这能表明你在意,并可能改变评分。
- 追踪指标:回复时间目标为 < 24 小时;快速回复能建立信任。
- 优化应用内评分提示:在积极体验后显示,例如完成一项任务或达成一个目标。
- 优化应用内评分提示:在用户已使用 App 3+ 次后显示。
- 优化应用内评分提示:在至少使用 7 天后显示。
- 优化应用内评分提示:绝不在崩溃、错误或令人沮丧的时刻后显示。
- 优化应用内评分提示:绝不在 onboarding 或首次 session 中显示。
- 遵守 Apple 的 SKStoreReviewController 规则:每台设备每 365 天最多只能调用 3 次。
- 遵守 Apple 的 SKStoreReviewController 规则:Apple 控制对话框实际出现的时间。
- 遵守 Apple 的 SKStoreReviewController 规则:不能自定义该对话框。
- 遵守 Apple 的 SKStoreReviewController 规则:可以控制调用它的时机,时机至关重要。
- 使用智能触发模式:成就触发——用户完成一个里程碑。
- 使用智能触发模式:连续触发——用户连续 N 天回来使用。
- 使用智能触发模式:价值触发——用户省钱、省时或达成结果。
- 使用智能触发模式:惊喜触发——在惊喜或愉悦时刻后。
- 处理差评:使用 HEAR 框架,Hear——承认用户提到的具体问题。
- 处理差评:使用 HEAR 框架,Empathize——表达你理解他们的挫败。
- 处理差评:使用 HEAR 框架,Act——说明你正在做什么或已经做了什么。
- 处理差评:使用 HEAR 框架,Resolve——邀请他们联系支持以获得直接帮助。
- 回复 Bug report 模板:感谢 [name] 报告;说明问题已定位,并已在 version [X.X] 中修复,将于 [date] 发布;请用户更新后反馈是否解决。
- 回复 Feature request 模板:感谢好建议;说明已加入路线图;表示会持续根据用户反馈改进,并请关注后续更新。
- 回复 Vague negative(例如“This app sucks”)模板:表示抱歉;说明希望了解具体问题以便改进;请用户通过 [support email] 提供细节联系支持。
- 不要防御或争论。
- 不要对每条评论复制粘贴同一回复。
- 不要忽略差评。
- 不要要求用户改变评分(违反指南)。
- 不要提供奖励换取评论。
- 把批评者转化为拥护者:修复他们报告的问题。
- 把批评者转化为拥护者:回复并确认已修复。
- 把批评者转化为拥护者:如果他们联系过你,通过支持渠道跟进。
- 把批评者转化为拥护者:许多用户会在问题得到积极解决后更新评论。
- 竞品评论分析:阅读竞品评论,找出未满足需求——用户希望竞品有什么。
- 竞品评论分析:阅读竞品评论,找出常见抱怨——用户为什么沮丧,这是你的机会。
- 竞品评论分析:阅读竞品评论,找出切换触发因素——用户为什么离开竞品。
- 竞品评论分析:阅读竞品评论,找出功能期望——该类别的必备功能是什么。
- 自身评论模式分析:分析评论,找出最常提及的功能(正面和负面)。
- 自身评论模式分析:分析评论,找出常见用户群体(谁在使用你的 App)。
- 自身评论模式分析:分析评论,找出情绪化语言(App 唤起什么感受)。
- 自身评论模式分析:分析评论,找出比较提及(用户提到哪些竞品)。
- 输出 Review Health Report:包含 Rating: [X.X] ★ ([trend: ↑/↓/→])。
- 输出 Review Health Report:包含 Total Reviews: [N]。
- 输出 Review Health Report:包含 Last 30 Days: [N] reviews, [X.X] avg rating。
- 输出 Review Health Report:包含 Response Rate: [X]%。
- 输出 Review Health Report:包含 Top Issues 1-3,格式为 [issue] — mentioned [N] times。
- 输出 Review Health Report:包含 Top Praise 1-2,格式为 [praise] — mentioned [N] times。
- 输出 Action Plan:Immediate——使用模板回复 X 条差评。
- 输出 Action Plan:This week——修复最常报告的 bug,优化评分提示时机。
- 输出 Action Plan:This month——实现最热门功能请求,分析竞品评论。
- 输出 Response Drafts:为影响最大的差评提供具体回复草稿。
- 相关技能:更广泛的 ASO 审计使用 aso-audit。
- 相关技能:修复导致差评的留存问题使用 retention-optimization。
- 相关技能:挖掘竞品评论洞察使用 competitor-analysis。
- 相关技能:随时间追踪评论指标使用 app-analytics。
适用边界 · 注意事项
- 没有已发布应用或可抓取评论数据时不适用。
- 需要更广泛的 ASO 审计时,应使用 aso-audit,而不是只做评论管理。
- 差评主要由留存问题导致时,应使用 retention-optimization。