笔者前段时间了解到谷歌早在几年前便针对用户体验建立了名为 HEART 的追踪验证框架，好奇其内容是否对建立验证方案的方法论有助益，遂抽时间搜索了原外语文章，并进行了翻译和拆解。
01 摘要
越来越多的产品和服务被部署在 Web 上，这为大数据下评估用户体验带来了新的挑战和机遇。 Web 应用程序非常需要以用户为中心的度量指标，它可以用来度量关键目标的进展，并驱动产品决策。
在本文中，我们描述了以用户为中心的 HEART 框架指标，以及将产品目标映射到度量指标的过程。
我们还提供了 HEART 指标如何在兼顾数据驱动和以用户为中心的情况下帮助产品团队做出决策的实例。
框架和过程已经覆盖了足够多的我们公司产品，所以我们相信其他组织的团队也能使用或适应它们。 在大规模行为数据之下，我们也鼓励更多对度量指标的研究。
02 介绍
Web 技术的进步使更多的应用程序和服务基于 Web 打造，并愈加具备交互性质。
现在，用户可以“在云端”执行各种常见任务，包括那些以前仅限于本地客户端应用程序的任务(例如文字处理、编辑照片)。
对于用户体验专业人士来说，这种转变的一个关键意义是能够使用 Web服务器日志数据来大规模跟踪产品的使用情况。
通过附加的仪器，也可以通过不同的界面接口运行对照实验（ A/B 测试）。 但是，从以用户为中心的角度来看，它们（不同界面）应该根据什么标准进行比较评估呢? 我们应该如何扩展我们熟悉的用户体验度量指标，这里面存在哪些新的机会?
在 CHI 社区，已经存在一种既可以在小范围内（在实验室中）也可以在大范围内（通过调查）测量态度数据（例如满意度）的既定实践。
然而，就行为数据而言，已有的测量方法大多是小规模的，并且实验中有部分信息是通过秒表和检查表收集，如有效性（任务完成率、错误率）和效率（任务执行时间）[参考13]。
CHI 研究中缺失的一个关键部分是基于大规模行为数据的用户体验指标。
Web 分析社区一直致力于将关注点从简单的页面点击数转移到关键的性能指标。 然而，该社区的主要动机仍然以业务为中心，而不是以用户为中心。
Web 分析包（此处大意应是指性能分析类包体）提供现成的度量解决方案可能过于通用化，而无法考量用户体验如何，或者过于特定在电子商务背景下应用，而难以对 Web 上的其他大量应用程序和交互起到帮助。
我们已经创建了一个框架和过程来定义大数据下的以用户为中心的度量指标，包括态度上的和行为上的。
我们从在一家大公司工作的经验中总结了这些，该公司的产品涵盖了广泛的类别（面向消费者和面向业务），而且产品几乎都是基于 Web 的，每个都有数百万用户。 我们发现这个框架和过程已经适用于我们公司足够多的产品，并且非常有效，所以我们相信其他组织的团队将能够成功地使用和适应它们。 我们也非常鼓励更多基于大规模行为数据背景下对度量指标的研究。
03 相关工作
近年来出现了许多工具来帮助跟踪和分析web站点和应用程序的指标——
- 商业和免费的分析软件包[参考 5,11 ]提供现成的解决方案。
- 现代的分布式系统 [参考 4,8 ] 和专门的编程语言 [例如参考 12 ] 使得大规模日志数据的自定义分析变得更加容易，Web 应用挖掘技术可根据网页访问者的行为 [参考 3 ] 对其进行细分。
- 多个供应商支持用户调研的快速部署和分析，有些还提供用于大规模远程可用性测试或基准测试的软件 [例如参考 14 ]。
- 在合理设计 A/B 测试实验和此类实验分析上，存在着大量的工作。在 AB 测试中，两个相似的用户群体被给予不同的用户界面，他们的反应可以被严谨的测量和比较 [例如参考 10 ]。
尽管取得了这些进展，但有效地使用这些工具仍然具有挑战性——
标准的 Web 分析指标可能过于通用，不适用于特定的产品目标或研究问题。可用数据的绝对数量可能是巨大的，因此有必要确定究竟要查找什么，以及什么行为该被作为结果来看待。
一些专家建议，最好的做法是关注少量的关键业务或用户目标，并使用指标来帮助跟踪实现这些目标的进展[参考2,9,10]。
我们也认同这一理念，但却发现这个理念很难应用。 因为产品团队并非可以一直在他们的目标上达成一致或清晰地阐述他们的目标，这使得定义相关的度量指标变得困难。
可以确定的是，这些度量不应该是独立的。 它们应该结合其他来源的研究结果(如可用性研究和现场研究[参考6,9])去分析，从而得到更好的决策[参考15]。
此外，它们主要用于已发布产品的评估，而不能替代早期或形成性用户研究。 我们试图创建一个结合大规模的态度和行为数据的框架来补充现有在我们公司使用的的用户体验研究方法（补充而非替代）。
04 PULSE 指标
最常用的大数据下的度量指标专注于产品的业务或技术方面，许多组织广泛使用它们（或类似的变体）来跟踪产品的总体运行状况。
我们将这些指标称为 PULSE 指标：页面浏览量（Page Views），正常运行时间（Uptime），延迟（Latency），七天活跃用户（Seven-day active users）（即上周至少使用一次该产品的独立用户数）和收入（Earnings）。
这些指标都非常重要，并且与用户体验有关。
例如，奔溃很多（正常运行时间短）或速度很慢（高延迟）的产品不太可能吸引用户。 一个电子商务网站，其购买流程太多，可能会减少收入。 具有出色用户体验的产品更有可能看到页面浏览量和独立用户增加。
但是，这些是非常底层的或间接的用户体验指标，因此在用于评估用户界面更改的影响时，它们是存在问题的。它们的解释也可能不准确。
例如，特定功能的页面浏览量增加既有可能是因为该功能是真正受欢迎的功能，也可能是因为界面设计得令人困惑不知如何使用，用户胡乱点击时产生的数据。短期内带来更多收入的修改可能会导致较差的用户体验，从长远来看会流失用户。
给定时间段内的独立用户数量（例如7天活跃用户）通常用作衡量用户体验的指标。 它可以衡量用户群的总体数量，但无法深入了解用户对产品的忠诚度，例如不知他们每个人在 7 天内的访问频率如何。 它也不能区分新用户和老用户。 从理论上讲，在最坏的情况下，如果用户群的周流失率达到 100％ ，它的 7 天活跃用户数仍会增加。
05 HEART 指标
基于 PULSE 在度量用户体验质量和提供可操作的数据方面的缺陷，我们创建了一个名为 HEART 互补的度量框架： Happiness（幸福感）、Engagement（参与度）、Adoption（接受度）、Retention（留存率）和 Task success（任务完成率）。
这些是指标分类，团队可以从中定义特定的指标，用于跟踪目标实现的进度。
幸福感和任务成功的类别是从现有的用户体验度量中概括出来的：幸福包含满意度，任务成功包含有效性和效率。参与度、接受度和留存率是新的类别，大规模的行为数据让追踪这些新类别指标成为可能。
该框架源于我们与团队合作为他们的产品创建和跟踪以用户为中心的指标的经验。我们开始在我们所使用或建议的度量指标类型中看到通用性规律，并意识到将这些归纳到一个框架中会使这些原则更容易被其他团队记住和使用。
并不是所有场景都适合使用所有类别去度量，但是引用框架有助于明确地决定是否包含或排除特定的类别。
例如，对于面向企业端的产品来说，用户如果将产品作为其工作的一部分，参与度可能意义不大。在这种情况下，团队可能会选择更关注愉悦感或任务完成率。但是，在功能级别而不是整个产品级别上考虑用户参与率可能仍然是有意义的。
06 幸福感
用“幸福感”来描述的度量指标，本质上是一种态度指标。这些都与用户体验的主观方面有关，比如满意度、视觉吸引力、推荐意愿和易用性。使用一个通用的、设计良好的调查，可以随着时间的推移跟踪相同的度量指标，以查看所做更改的带来的变化。
例如，我们的网站有一个个性化的主页——iGoogle。团队通过每周产品内调查来跟踪许多指标，以了解更改和新特性的影响。在进行了一次重大的重新设计之后，他们发现他们的用户满意度指标在最初出现了下降。
(以7分李克特量表去调研。这里7分李克特量表层级对应完全同意，非常同意，同意，不一定，不同意，非常不同意，完全不同意，分别对应7、5、4、3、2、1分)
然而，随着时间的推移，这个指标恢复了，这表明用户厌恶改变可能是导致下降的原因，而一旦用户习惯了新的设计，他们就会喜欢它。有了这些信息，团队能够做出更有信心的决定来保持新的设计。
07 参与度
参与度是指用户对产品的投入程度。在度量环境中，这个术语通常是行为代指，例如在一段时间内交互的频率、强度或深度。
例如，每个用户每周访问的次数，或者每个用户每天上传的照片的数量。一般来说，每个用户的数据平均值作为一个参与度指标去评估会比取总数去评估更有用，因为总数的增加可能是更多用户参与的结果，而不是更多行为使用量导致的结果。
例如，与7天活跃用户数的PULSE指标（仅计算上一周内至少有多少用户访问过该产品的数量）相比，Gmail团队希望更多地了解其用户的参与程度。
考虑到日常工作中，用户会应定期检查其电子邮件帐户，因此我们选择的指标是在过去一周内访问该产品不少于五天的活跃用户的比率。 我们还发现，该比率的人群更可能长期留存下来，因此可以用作参与度的具体度量指标。
08 接受度和留存率
接受度和留存率指标可用于更深入地了解给定时间段内（例如，为期7天的活跃用户）独立用户的数量，从而解决将新用户与现有用户区分开的问题。接受度指标跟踪给定时间段内有多少新用户开始使用产品（例如，最近7天创建的帐户数），留存率指标跟踪给定时间段内存在的用户在一些时间段后仍存在（例如，给定一周中7天活跃用户在 3 个月后仍处于7天活跃用户的比率）。
怎么才算是“使用”产品会随着产品的性质和目标不同而有所不同。在某些情况下，仅访问其网站可能就算是“使用”。在其他情况下，您可能会仅在访问者成功完成关键任务（例如创建帐户）时才算是使用了产品。像参与度一样，留存率也可以在不同的时间段内测量。对于某些产品，您可能希望查看周留存率，而对于其他产品，月留存率或 90 天可能更合适。
接受度和留存率对于新产品和功能或正在重设计的产品特别有用。对于较成熟的产品，除季节性变化或外部事件外，它们趋于稳定。例如，在 2008 年 9 月股市崩溃期间，Google 财经浏览量和7天活跃用户数均激增。
但是，这些指标并未表明激增是由对危机感兴趣的新用户驱动还是现有用户对投资进行了恐慌检查。 不知道谁在进行更多访问，就很难知道是否或如何更改站点。 我们研究了接受度和留存率指标，以区分这些用户类型，并研究了新用户选择继续使用该网站的比率。 该团队能够使用此信息更好地了解由事件驱动的流量高峰带来的机会。
09 任务成功率
最后，“任务成功”类别涵盖了用户体验的几种传统行为指标，例如效率（例如完成任务的时间），有效性（例如完成任务的百分比）和错误率。大规模测量这些数据的一种方法是通过远程可用性或基准研究来为用户分配特定任务。基于网站的特性，使用 Web 服务器日志文件数据，可能很难知道用户试图完成哪个任务。如果存在用于特定任务的最佳路径（例如，多步骤注册过程），则可以衡量用户对其的跟踪程度[参考7]。
例如，Google Maps曾经有两种不同类型的搜索框：一个是用于本地搜索的双盒，用户可以在其中分别输入“ what”和“ where”方面（例如[pizza] [nyc]），另一个是搜索框处理各种搜索（包括本地搜索，例如[pizza nyc]或[nyc pizza]）。
团队认为单盒方法最简单，最有效，因此，在 A/B 测试中，他们尝试了仅提供单盒的版本。他们比较了两种版本的错误率，发现处于单框状态的用户能够成功地调整其搜索策略。这向团队证明，他们可以为所有用户移除双框。
10 目标–信号–指标
无论以用户为中心的度量指标如何，除非它与目标明确相关，否则在实践中不太可能有用，并且可用于跟踪实现该目标的进度。 我们开发了一个简单的过程，该过程使团队逐步阐明产品或功能的目标，然后识别表明成功的信号，最后构建要在仪表板上跟踪的特定指标。
目标
第一步是确定产品或功能的目标，尤其是在用户体验方面。 用户需要完成哪些任务？ 重新设计试图实现什么？ 使用 HEART 框架来提示目标（例如，吸引新用户还是鼓励现有用户更深入参与更重要？）。 以下是我们给的一些较为有益的建议：
- 不同的团队成员可能会对项目目标有分歧。 这个过程提供了一个很好的机会来收集所有不同的想法并努力达成共识（并为选定的指标提供支持）。
- 特定项目或功能成功的目标可能与整个产品的目标不同。
- 在此阶段，不用为能否可以找到相关的信号或指标而担忧分心。
信号
接下来，考虑目标的成功或失败如何在用户行为或态度中体现出来。 哪些动作将表明目标已实现？ 什么样的感觉或感知与成功或失败相关？
在此阶段，您应该考虑这些信号的数据表现是什么， 例如，对于基于日志的行为信号，当前是否记录了相关操作，或者是否可能记录? 你要如何收集态度反馈，可以定期部署调查吗？ 日志和调查是我们最常使用的两个信号源，但还有其他可能性（例如，使用评审团来进行评级）。 以下是我们的一些建议：
- 选择对目标敏感且特定服务于目标的信号——这个信号仅在用户体验更好或更差时会随着变化，而不因其他无关的原因而改变。
- 有时候，失败比成功更容易识别（例如，放弃任务，“撤消”事件[参考1]，沮丧）。
指标
最后，考虑如何将这些信号转换为特定指标，以适合随时间推移在数据板上进行跟踪。 以下是一些建议：
- 原始数据将随着用户群的增长而增加，需要进行规范化； 单用户的比率，百分比或平均值通常会更有用。
- 在确保基于Web日志的度量指标的准确性方面存在许多挑战，例如从自动来源（例如，爬网程序，垃圾邮件发送者）中过滤流量，以及确保记录所有重要的用户操作（在默认情况下可能不会发生，特别是在AJAX或基于flash的应用程序中。）
- 若能将您的产品与其他产品进行比较（竞品分析），则可能需要追踪那些产品建立的标准所使用的额外指标。
11 结语
我们已经花费了数年的时间来研究大数据背景下以用户为中心的产品指标的问题。 这导致我们开发了 HEART 框架和目标-信号-指标流程，我们将其应用于 Google 各个领域的 20 多种不同的产品和项目。
我们在本文中描述了几个示例，这些示例说明了所得指标如何帮助产品团队做出以数据为驱动力和以用户为中心的决策。
我们还发现框架和流程对团队讨论的聚焦更加有帮助。 它们已经推广到我们公司自己的产品中，足以使我们相信其他组织中的团队将能够成功地使用或适应它们。
我们已经对框架和流程进行了一年多的微调，但每个框架的核心都保持稳定，并且框架的类别足够全面，可便可以适应新的指标概念。
由于大规模行为指标相对较新，因此我们希望看到更多有关此主题的 CHI 研究，例如，确定每个类别中的哪些指标能够最准确地反映用户体验质量。
12 快速总结
（1）本文旨在通过建立 HEART 框架，并成立目标—信号—指标的映射方式来解决设计决策迭代科学性的问题。这个框架的成立基础是大数据+自定义指标+周期性追踪。
（2）HEART 的框架主要分别是 Happyness（幸福感）、Adoption（接受度）、Engagement（参与度）、Retention（留存率）和 Task Sussess（任务成功率）。其中简易区别如下：
- Happyness 和 Task sussess 是贯穿所有产品时期的数据指标；
- Engagement 是成长期、成熟期更应该追踪的可以用于区分核心用户的指标；
- Adoption 和 Retention 主要是探索期和成长期还有转型期/重设计时期主要追踪的指标（这两个指标在成熟期会倾向于维稳）。
（3）HEART 的数据指标的关键点是大数据周期性的迭代追踪，部分指标在目前市场情况下稍显理想化。
（4）框架应用关键点在于目标——信号——指标的映射，也就是以终为始的思维。其中信号主要围绕什么样的用户态度或行为会表明目标成败的角度去构思，并且该态度或行为变化应仅受目标成败的影响。
致谢
感谢 Aaron Sedley，Geoff Davis 和 Melanie Kellar 为 HEART 做出的贡献，以及 Patrick Patrick 的支持。
参考资料
（此部分翻译有些链接失灵，请直接谷歌关键词）
- Akers，D.等人 （2009）撤消和擦除事件作为可用性问题的指示器。 CHI 2009年，ACM出版社，第659-668页。
- Burby，J.和Atchison，S.（2007）. ActionableWebAnalytics. 印第安纳波利斯：威利出版公司
- Chi，E. 等人 （2002）. LumberJack：Web用户流量组成的智能发现和分析。 WebKDD 2002 Proc，ACM Press，第1-15页。
- Dean，J.和Ghemawat，S.（2008）. MapReduce：大型集群上的简化数据处理。 ACM的通讯，51（1），第107-113页。
- GoogleAnalytics：https://www.google.com/analytics
- Grimes，C.etal（2007）. 仅查询日志还不够， WWW 07查询日志分析研讨会的程序：https://querylogs2007.webir.org
- Gwizdka，J. ＆Spence，I. （2007年）Web导航中损失和成功的隐式度量。 与计算机进行交互19（3），第357-369页。
- Hadoop：https://hadoop.apache.org/core
- Kaushik，A.（2007）. WebAnalytics：AnHouraDay. 印第安纳波利斯：威利出版公司
- Kohavi，R.等 （2007）. 网络上的受控实验实用指南。 KDD 07，ACM Press，第959-967页。
- Omniture：https://www.omniture.com
- Pike，R.等 （2005）. 解释数据：使用Sawzall进行并行分析。 科学程序设计（13），第277-298页。
- Tullis，T.＆Albert，W.（2008年）. 衡量用户体验。 伯灵顿：摩根考夫曼。
- UserZoom：https://www.userzoom.com
- Weischedel，B.和Huizingh，E.（2006年）. 使用Web指标进行网站优化：一个案例研究。 ICEC 06，ACM Press，第463-470页。
注：
（1）翻译目的是共享学习，有疑惑或翻译错误请联系 Dreamy 的邮箱 1163940428@qq.com 。键盘侠勿扰，和谐生活。
（2）局部翻译结合原文与中式术语修改表述，让其更易于理解。
（3）若侵权请联系译者删除文章。若想转发也请附上译者信息（便于甄误）。
原文作者：克里·罗登，希拉里·哈金森，辛孚（原Kerry Rodden, Hilary Hutchinson, and Xin Fu）
原文标题：《大数据下评估用户体验: Web 应用程序中以用户为中心的指标》
原文地址： https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/36299.pdf、
编译作者：水水；博客（搁置 1.5 年重新捡起，没啥几篇破文章）：https://my.cgsdream.org/
本文由 @水水 翻译发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。