如何回复 App Store 和 Google Play 评论

在两个商店中，开发者都可以公开回复带有正文的评论。

Apple App Store

• App Store Connect： 打开应用，进入评分与评论部分，逐条回复评论。拥有相应角色的团队成员可以撰写回复。
• App Store Connect API： App Store Connect API 提供客户评论和开发者回复，因此你可以在工具中列出评论，并以编程方式发布回复。API 密钥在 Users and Access → Integrations 中创建，.p8 私钥只能下载一次。

Google Play

• Play Console： 打开应用，在评分与评论下的评论部分阅读并回复评论。
• Google Play Developer API： Reply to Reviews API 可以列出评论并回复。需要注意：API 只返回大约最近一周内创建或更新、且带有正文的评论。更早的历史记录在 Play Console 可导出的月度评论报告中（参见 Google Play 评论历史指南）。

如果你在两个商店都上架了应用，就意味着有两个后台、两套权限设置、每天要查看两个地方。正是这种割裂，让团队把回复工作集中到一个工具里。

两个商店都公开了关于开发者回复的规则。在编写内部回复指南之前，请先阅读原文。下面的摘要只是起点，不能替代原文。

Apple

Apple 的 Ratings, Reviews, and Responses 页面鼓励开发者回复反馈、处理 bug 和功能请求，并让回复保持相关和礼貌。回复是公开的，Apple 说明回复发布后仍可编辑。

Google Play

Play Console 关于查看和回复评论的帮助中包含回复规则。概括来说，回复必须切题，不得包含个人信息、推广内容、激励措施或不当言论。Google 会更新规则，请以最新页面上的完整列表为准。

同时符合两边政策的实用规则

• 不要在公开回复中索要或重复个人信息（邮箱、电话、订单号）。请引导用户联系你的支持渠道。
• 不要为了让用户修改评论而提供奖励、折扣或好处。
• 不要争吵、不要嘲讽，也不要透露超出用户评论本身内容的信息。
• 避免推销式的措辞。提到某个版本已修复没有问题，但推广其他产品就不合适了。

Google Play 的上限写在 Reply to Reviews API 文档中。如果你在两个商店使用同一套回复模板，就把每个模板控制在 350 个字符以内。我们的回复模板遵循这条规则。

关于中文回复的补充：中文通常用比英文更少的字符表达同样的内容，所以 350 个字符的限制相对宽松。不过客套话叠加起来也会很长。请统计最终版本的字数，而不是草稿。

适用于大多数回复的可靠结构：

1. 点出具体问题。 复述用户写到的细节（“在结账页面应用会卡住”），表明有人真的读了。
2. 提供有用的信息。 临时解决办法、进展（“已在 4.2 中修复”），或明确的下一步。
3. 需要更多信息时，引导到非公开渠道： 例如支持邮箱或应用内帮助。不要在回复里索要个人信息。
4. 如果符合品牌风格，以个人或团队名义署名（“支持团队 小王”）。

会降低回复质量的做法：

• 把同一段文字粘贴到几十条评论下面。读者会注意到，看起来就像没人读过评论。
• 辩解、责怪用户（“你是不是用错了”），或冷嘲热讽。
• 做出无法兑现的承诺，比如为没有计划的功能给出日期。
• 只有客套话（“感谢你的宝贵意见”）而没有任何具体内容。

模板是很好的起点。至少第一句话和具体细节一定要针对每条评论改写。

中文回复建议使用亲切、礼貌的“你”，避免过于生硬的公文腔。即使品牌风格轻松，回复不满的用户时也最好保持礼貌。

很少有团队能在当天回复所有评论。定好一个简单的顺序，就不会漏掉最重要的评论：

1. 描述了可复现问题的 1 星和 2 星评论（崩溃、无法登录、支付问题）。修复后最有可能改变评分，也能帮你发现 bug。
2. 与钱有关的评论： 扣费、订阅、退款。尽快引导到正确的退款流程。
3. 关于最新版本的近期评论。 它们反映当前版本，也最显眼。
4. 带建议的 3 星和 4 星评论。 简短致谢并告知想法的进展，很容易赢得好感。
5. 5 星评论。 有时间时值得回复，一句简短而具体的感谢就够了。

有些评论不值得回复：垃圾信息、辱骂，或明显是在评论别的应用。与其回复，不如用商店的工具举报违规内容。

回复不是一次性的。两个商店都允许编辑已有回复，评论者之后也可以修改评论。Apple 说明，你回复后用户会收到通知，并且可以更新评论。Google Play 也在帮助文章中介绍了类似的机制。通知的具体方式因商店而异，也可能变化。

正因如此，跟进回复是最有效的做法之一：

• 有人报告 bug 时，回复说明已经确认，并在内部记录问题。
• 修复发布后，编辑或更新回复：“已在 4.3 版本中修复，感谢你的反馈。”
• 用户可能会回来更新评论。即使没有更新，之后的读者看到的也是已解决的问题，而不是悬而未决的抱怨。

要做到这一点，你需要知道哪条评论对应哪个 bug。把 bug 报告发送到问题跟踪工具会很有帮助。参见把应用评论变成 Linear issue。

两个数字就能看出回复流程是否健康：

• 回复率： 一段时间内获得开发者回复的评论（或带正文的评论）所占的比例。分别统计全部评论和 1–2 星评论。
• 平均回复时间： 从评论发布到回复所用的时间。少数很晚才处理的旧评论会拉高平均值，所以中位数也很有用。

为团队设定合适的目标，例如“带正文的 1–2 星评论必须在 2 个工作日内回复”，并每周检查一次。每次发布后都要看趋势：如果没有准备，评论激增时回复时间往往会变长。

Review Expert 把 App Store 和 Google Play 的评论集中到一个地方，团队无需在后台之间切换就能回复：

• 在 Apps & Businesses 中，用 App Store Connect API 密钥和 Google Play 服务账号连接应用。首先同步历史评论，之后大约每 5 分钟收到新评论。
• 按星级、平台和日期筛选评论列表，按优先级逐条处理。
• 在 Review Expert 中写好回复后，会通过官方 API 发布到商店。已有回复也可以用同样的方式更新。团队中的所有角色（所有者、管理员和审阅者）都可以回复。
• 仪表板会在评分趋势旁显示回复率和平均回复时间，让你知道团队是否跟得上。

还可以使用 AI 回复草稿和自动回复规则（审批步骤可选）。详见回复评论和仪表板。