3 种收集应用内反馈的方法：Webview、SDK 和 API 2018 年 1 月 25 日
已发表: 2018-01-25收集和分析应用内反馈可能非常简单——前提是您拥有合适的工具和方法来执行此操作。 在之前的文章中，我们概述了收集应用内反馈对移动用户体验很重要的几个原因。 下一步是演示如何收集这些反馈。 在应用内收集反馈时，有三个选项可供选择——所有这些选项都有各自的优点和缺点。 这些方法包括： Webviews、SDK 和 API 。
本文将定义和分析每种方法，让您（作为移动营销人员）更清楚地了解这些方法可以做什么和不能做什么，以及为了实施这些方法对您的期望。
让我们从第一种方法开始： webviews 。
什么是 Web 视图？
根据定义，webview 是一种已打包到移动应用程序（产生所谓的“混合应用程序”）中的浏览器。 Webview 允许使用 Web 技术（例如 HTML、CSS 或 JavaScript）构建移动应用程序，并且仍将其打包为用户可以在应用程序商店中找到的本机应用程序。 
通过 webview 收集反馈时，用户需要做的就是使用他们的反馈软件提供商将反馈表单加载到 webview 中。 这样做的过程基本上与将反馈表（作为网页）加载到移动应用程序的外壳中相同。 一个很好的例子是电子商务或体育应用程序。
注意：网页视图与移动响应式网站不同。 当网站具有响应性时，布局和/或内容会根据它们所呈现的屏幕大小做出响应或调整。 响应式网站会自动更改以适合您使用的设备。 通常，响应式设计面向大约四种屏幕尺寸：宽屏桌面显示器、较小的台式机（或笔记本电脑）、平板电脑和手机。 随着屏幕变小，内容会移动并更改为每个屏幕的最佳显示。
免费白皮书：良好反馈策略的重要性
了解如何在在线反馈表中提出正确的问题，以充分利用它。
通过 Webview 的应用内反馈
以下是通过 webview 收集应用内反馈可以提供什么以及不足之处的详细介绍：
优点：
- 快速且易于实施。 您需要做的就是通过 web 视图将运行反馈表单的 URL 链接到应用程序中。 更高级的反馈工具有一个唯一的 URL，反馈表单在该 URL 中独立运行。 这意味着它不在页面上的滑入或模式中，而是可以使用唯一的 URL 来处理表单。
- 轻松发布/更改反馈表。 这可以在不发布移动应用程序的新版本的情况下完成。
缺点：
- 可能会干扰用户的应用内体验。 Webviews 有时会让用户感觉好像他们在应用程序之外（取决于设计），即使理论上用户仍然在应用程序内。 因此，将 webview 很好地集成到您的应用程序中是非常重要的。 但是，要做到这一点，可能会花费您一些额外的精力、时间和定制。
- 无法使用某些本机/移动功能。 因为您正在通过 webview 加载网页，所以某些功能将不可用，包括截屏（例如视觉反馈）、GPS（通过定位服务）或添加图片（使用相机）。
- 始终需要互联网连接。 完全本机运行的移动应用程序可以在没有有效互联网连接的情况下运行。 但是，webview 需要持续连接。 如果没有连接，则您的应用程序中没有反馈表。
什么是 API？
API 或应用程序编程接口是一组用于构建应用程序软件的定义、协议和工具。 大多数大公司都在某个时候为他们的客户或内部使用构建了 API。
开发团队经常将他们的应用程序分解为多个可以使用 API 相互通信的服务器。 支持主应用服务器的服务器称为“微服务”。 一家向其客户提供 API 的公司是另一种说法，他们构建了一系列专用 URL，这些 URL 提供纯数据响应（或“原始”响应），您不会在网站的用户界面中看到这些响应。 
两种类型的反馈 API
关于客户反馈系统，有两种类型的 API。 一个 API 用于将反馈引导至平台。 这方面的一些示例是来自网站的帖子或将反馈从移动应用程序传输到反馈收集系统。
第二个 API 是一个将从反馈系统中检索和导出反馈的 API。 例如，它可以从系统中提取反馈并将其添加到 JIRA 或 Trello 等项目管理工具中。
通过 API 进行应用内反馈
以下是使用 API 收集应用内反馈的优缺点：
优点：
- 如何构建和实施的自由和灵活性。 使用 API，您无需遵循任何规则。 换句话说，您可以完全控制如何实施您的反馈表。 您自己构建它，决定您的反馈表单的外观并选择它们将在您的应用程序中出现的时间/位置。
- 所有移动设备功能均可用。 尽管您需要自己开发它，但您将能够使用诸如 GPS、相机照片或屏幕截图等移动功能——而使用 web 视图则不能。
- 反馈表可以在没有互联网连接的情况下运行。 反馈响应可以被缓存，这意味着只要用户有连接就提交它。 这很重要，因为某些移动应用程序可以在没有互联网连接的情况下完全运行。 例如，用于在地点提出保险索赔的旅行保险应用程序。 假设您在国外发生了事故，但您无法访问互联网。 该应用程序会缓存您的保险索赔，以便当您回到 WIFI 区域时，它可以将您的所有数据提交给保险公司。
缺点：
- 如果不发布新版本的移动应用程序，就无法轻松更改反馈表。 例如，当您想在反馈表单中添加或更改问题时，您需要更改界面和 API 帖子并发布用户需要下载/更新的应用程序的新版本。
- 您必须自己设计应用内反馈表。 然而，许多移动开发框架都有预先构建的模块，使您能够快速构建界面。
- 学习曲线更长。 了解反馈软件供应商的 API 很重要。 这将包括依靠所有文档和指南来解决任何错误或混淆。 这就是为什么如果有一个可以提问的社区是理想的。 它还可能需要更多的时间来开发，因为你自己构建了所有东西。
什么是 SDK？
对于不熟悉的人，缩写词 SDK 代表软件开发工具包。 SDK 是一个可下载的软件包，其中包括在平台上构建所需的工具。 
根据 Twilio 的说法，“单个 SDK 通常针对其平台进行大量定制，但典型的 SDK 可能包含以下内容”：
- 库或 API：这些是预定义的代码片段，可帮助您在平台上执行常见的编程任务。
- 集成开发环境 (IDE)：一种编辑器，使用户能够设计图形元素，例如按钮或文本框。 IDE 在移动 SDK 上非常常见。
- 附加工具：这些工具通常用于执行调试、构建、运行和测试应用程序等任务。
立即试用 Mopinion 的任何移动 SDK！
使用这些灵活且易于安装的 SDK 开始从您的本机应用程序收集强大的反馈，以获得应用内反馈。
SDK 与 API
SDK 是一套完整的 API，使用户能够执行创建应用程序所需的任何操作。 另一方面，API 只是一系列可能适用于特定目的的相关方法。 
为了更好地理解，让我们举个例子。
Java 开发工具包 (JDK) 不仅包含 API，还包含编译器、运行时系统和其他杂项工具。 Java API 只是构成您可以开箱即用的核心语言的所有库。
在应用内反馈软件方面，有多种解决方案可以在使用特定平台的 SDK 的同时在移动应用内收集反馈。 示例包括适用于 iOS 的 Swift SDK 或适用于 Android 的 JAVA SDK。
根据您的编程语言、您正在开发的平台以及您需要的通信解决方案类型（例如向您的反馈软件提供商发布反馈），您可以使用各种 SDK。
通过 SDK 的应用内反馈
以下是 SDK 在应用内反馈收集方面可以提供和不可以提供的功能：
优点：
- SDK 允许您快速启动和运行。 很容易将新功能集成到您的应用程序中（例如收集反馈）。 已经处理了很多事情，例如身份验证、向反馈供应商发布反馈以及验证输入字段。
- 无需发布移动应用程序的新版本即可轻松更改反馈表。 这意味着您可以从反馈工具中添加/更改问题或设计，而不必将其编程到应用程序中。
缺点：
- 比使用 webview 更长的学习曲线。 与 API 类似，您需要熟悉 SDK。 有一些 SDK 有很好的文档记录并拥有活跃的用户群。 Github 就是一个很好的例子。 但是，如果情况并非如此，那么选择提供出色客户服务的应用内反馈供应商可能是明智之举。
- 您依赖于应用软件的质量以及 SDK。 使用 SDK，您实际上是在一个软件中运行一个软件。 因此，即使您的移动应用程序和您使用的 SDK 都是根据所有软件开发约定开发的，仍然可能会出现问题。 同样重要的是要知道，SDK 很容易降低应用程序的性能，并可能给用户体验带来缺陷。 例如，您可能正在加载您不使用或干扰应用程序其他功能的模块。
评估哪种方法最适合您的业务……
如您所见，每种方法都有其优缺点，包括实施要求、技术诀窍和实施后的性能。
我们对你的建议？ 事先定义您的目标，并评估您拥有哪些资源以及需要哪些资源——尤其是从技术角度来看。 显然，并非所有这些方法都适合每家公司，因此通过列出您的目标和能力，决定哪种方法适合您会容易得多。
想了解更多关于应用内反馈的信息？
立即免费获取我们的白皮书！
下载白皮书