APP产品设计系列-意见反馈

Posted 2023-04-26

参考技术A 意见反馈是APP的基础功能，它是与用户互动、收集用户意见的重要渠道，其入口一般放置在关于页或设置页。

典型的意见反馈设计有两种：在线客服和反馈表单

在线客服

类似即时通讯功能，用户在下方输入文字，由人工或机器人进行回复，以便快速解决用户问题，多用于电商、SNS、游戏等领域。机器人回复，类似自动问答，根据提问关键字匹配问题库回复用户，比人工节约成本，回复相对生硬，不够人情味。

优点：快速响应，实时互动， 点对点，反馈高效，有趣。

缺点：问题过于零散，不便归纳整理分析，研发成本高。

建议采用第三方工具搭建即时通讯功能，节省开发成本。

反馈表单

简单点就一个内容输入框，或再加个上传附件、联系方式或反馈类型，这种设计略显机械。也有用选择题替代表问答题，或者选择题必填，问答题选填，让用户觉得填反馈花不了多长时间还很简单方便，发送反馈的几率会高得多。

相比在线客服，反馈表单形式固定化，方便归类整理分析反馈问题，研发成本低，大部分APP都采用这种。填写表单的设计要点：

1、表单不要太长，字段尽量少，减少用户输入；

2、不要让用户填写姓名、地址等信息；

3、反馈之后要有回复，不要杳无音讯，回复不要太官话和机械，要有人情味，让用户觉得他的反馈是有用的；

4、能查看反馈记录及回复结果，如APP中设置“我的反馈”、邮件回复结果；

4、附带相关信息，如token、账号信息、地区、运营商类型、操作系统版本、APP版本等信息，以便更准确分析需求、定位缺陷；

5、 归类整理，反馈较多的整理成常见问题。

6、输入框过滤！@~#￥%……&*等特殊字符，以防SQL注入，建议设置每天提交次数限制机制，以防止机器提交垃圾数据。

7、有些APP，意见反馈入口会放在主界面，或新版初装二次启动时引导用户反馈（吐槽）。这些都是为了得到更多反馈，优化完善产品。

#本文同步发布到 pm263.com ，pm263为你提供更多更全的产品经理干货，欢迎大家访问。

关于 Google App Engine 可用性的反馈

【中文标题】关于 Google App Engine 可用性的反馈

【英文标题】：Feedback on availability with Google App Engine

【发布时间】：2011-02-10 13:02:04

【问题描述】：

我们有一些在 Google App Engine 上构建应用程序的良好经验，第一个应用程序的目标受众是 Google Apps 用户，因此它托管在 Google 基础架构上没有问题。

我们非常喜欢它，因此我们想研究将它用于另一个应用程序，但是下一个项目是为一个对它所采用的技术并不真正感兴趣的客户而设计的，他们只是希望它能够正常工作一直都在。

在这种情况下，考虑到我们已经涵盖了技术适用性和功能方面，是否有任何担忧认为这些东西仍然相对较新，并且我们可能不像我们用传统方法完成它那样“可控”托管？

【参考方案1】：

您是对的：与传统托管相比，您没有那么多控制权。然而，希望收益超过负面影响。 App Engine 具有极强的可扩展性——它运行在与 Google 本身相同的硬件上。您多久访问一次http://google.com 并且该页面或搜索结果失败？

尽管您让 Google 运行您的代码，但代码仍由您自己来做。对于像 django-nonrel 这样的新项目，您可以直接在 App Engine 上创建和运行原生 Django 应用，如果它不能满足您的需求，将该应用程序带到托管 Django 应用程序的 ISP 是相当容易的（并且有很多这样的应用程序）。更多关于这个项目的信息如下。

您不必担心硬件、操作系统、提供机器映像、数据库、Web 服务器、前端负载平衡器、CDN/边缘缓存、软件/软件包升级、许可费用等。所有这些东西与您已经或将要创建以解决特定问题的 Web 或其他应用程序无关。无论您喜欢与否，所有这些额外的基础设施都是必需的；但是使用 App Engine，您只需要考虑您的应用/解决方案，而无需考虑这些额外的东西。

显然，您丢失的另一件事是您的一些执行环境。为确保您与您的云邻居（资源占用、安全问题等）很好地合作，您必须在沙箱中执行，这意味着您的应用无法创建本地文件、打开网络套接字等。但是，App Engine 提供了一个丰富的 API 和产品功能集，让您至少可以创建有意义的应用：

可扩展的分布式对象数据存储（见下文） 内存缓存 URLFetch 图片服务（调整大小、裁剪等） 用于后台处理的用户服务/身份验证任务队列 Django 网络模板 大文件的 blobstore 拒绝服务黑名单 事务性任务 数据存储游标 发送（和/或接收）电子邮件 通过 XMPP 发送（和/或接收）聊天/IM/即时消息

您还拥有一个完整的仪表板管理控制台，可让您监控应用的使用情况、计费设置和历史记录、配额使用情况的完整转储，甚至可以查看或下载您的应用程序日志。

从@Anurag 解决“主要痛点”：

1a。免费配额相当慷慨……足以为每月获得 5MM 浏览量的网站提供动力。此外，如果您相信 Google 会将您的信用卡提供给他们，他们会提高免费配额水平，甚至更高。查看 their quota page 并参考“免费默认配额”和“启用计费的默认配额”列中的数字...这里有一些示例：a)请求数：1.3MM 默认，43MM 启用计费 (wBE)，b) 数据存储 API 调用：10MM 默认，140MM wBE，c) URL 提取：657K 默认，46MM wBE

1b。请求最多 30 秒：这对您来说更安全，因为您的应用程序现在与其他人一起在操场上。谷歌必须确保所有的云邻居都能很好地相互配合，并且不会占用 CPU。但是，App Engine 团队正在研究一种允许更长时间运行后台任务的方法……目前还没有时间表，但 it is on the public roadmap。

1c。在 App Engine 上编写聊天服务器不仅可行，而且非常简单。这是使用 App Engine 的 XMPP API 创建的一个——它非常愚蠢，只是将他们发送给我们的内容回显给发件人（请注意，您必须已经邀请用户聊天）：

from google.appengine.api import xmpp
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

class XMPPHandler(webapp.RequestHandler):
    def post(self):
        msg = xmpp.Message(self.request.POST)
        msg.reply("I got your msg: '%s'" % msg.body)

application = webapp.WSGIApplication([
    ('/_ah/xmpp/message/chat/', XMPPHandler),
], debug=True)

def main():
    run_wsgi_app(application)

if __name__ == '__main__':
    main()

1d。 the public roadmap 上的另一个项目是未来“[支持] 浏览器推送（彗星）通信”，所以它也即将到来。

2a。 “不是 SQL”是 Google App Engine 的最大优势之一！关系数据库无法扩展，必须在某个时候进行分片以防止 RDBMS 崩溃。但是，是正确的，因为它不是传统的，所以移植起来稍微困难一些！基于 Google Bigtable，您可以将 App Engine 数据存储区视为可扩展的分布式对象数据库。 App Engine 允许您query the datastore using a Query object 模型，或者如果您坚持，他们还提供 SQL-like GqlQuery interface。

2b。对于像django-nonrel 这样的新先锋项目，如果您创建一个 Django 应用程序并使用它的 ORM，您可以使用一个纯 Django 应用程序并直接在 App Engine 上运行它。同样，您可以将其从 App Engine 中移出，并将其直接转移到托管 Django 应用程序的更传统的 ISP 供应商。查询保持完全相同，您不必关心它是否执行 SQL。

3a。上面的 1b 已经解决了长时间运行的进程。 Google 意识到了这一需求并正在努力解决。

3b。 TaskQueue API 支持 100k 次调用，但这已达到 1MM wBE...而且这是每天一次。

3c。 Google 强烈鼓励将任务分解为多个子任务。低延迟应用程序被认为不会“占用系统”，并且比那些速度慢且消耗更多云邻居资源的应用程序得到更好的处理。

【讨论】：

感谢您，尽管我已经了解技术限制/偏好/要求并且对它们非常满意。我最担心的是这样的事情 groups.google.com/group/google-appengine/browse_thread/thread/… 。尽管谷歌在解释问题方面可能比大多数人都好，而且就像你说的那样，它不太可能发生。但是如果这样的事情再次发生，在停机期间没有人可以打电话给你，你只需要坐下来等待。您对此有何看法？

您说得很好，我们还处于云计算的早期阶段。然而，我认为他们的事后分析非常全面，团队正在努力确保这些事情在未来很少（如果有的话）发生。当有停机时间时，您不需要打电话给某人，因为有人必须被寻呼......这样的系统不会在谷歌不知道的情况下发生故障。如果您确实需要联系 Google，可以在这里创建一个新的生产问题：code.google.com/p/googleappengine/issues/entry

【参考方案2】：

是的，您不会像使用传统托管那样拥有更多的控制权。 GAE的主要痛点是

配额等，请求最多 30 秒，因此彗星/反向 ajax 等超出窗口或非常困难。尝试在谷歌应用引擎上编写一个聊天服务器。

不是 Sql 数据库，如果需要的话很难移植到其他服务器，并且有时会受到谷歌数据库的限制，例如尝试对一个查询进行排序，该查询在除已排序的列之外的不同列上进行比较。

长时间运行的进程，有一个Task api但是如果你想做长时间运行的后台处理是不够的，否则你将不得不在子任务中中断你的任务，所以事情变得复杂，甚至每秒可以运行多少个任务的配额。

如果您的应用可以建模为请求-响应注册表，GAE 是很好的选择，几乎不需要后台处理。

也看到这个 Feedback on using Google App Engine?