筆者前段時間瞭解到谷歌早在幾年前便針對用戶體驗建立了名為 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 的支持。

（此部分翻譯有些鏈接失靈，請直接谷歌關鍵詞）

1. Akers，D.等人 （2009）撤消和擦除事件作為可用性問題的指示器。 CHI 2009年，ACM出版社，第659-668頁。
2. Burby，J.和Atchison，S.（2007）. ActionableWebAnalytics. 印第安納波利斯：威利出版公司
3. Chi，E. 等人 （2002）. LumberJack：Web用戶流量組成的智能發現和分析。 WebKDD 2002 Proc，ACM Press，第1-15頁。
4. Dean，J.和Ghemawat，S.（2008）. MapReduce：大型集群上的簡化數據處理。 ACM的通訊，51（1），第107-113頁。
5. GoogleAnalytics：http://www.google.com/analytics
6. Grimes，C.etal（2007）. 僅查詢日誌還不夠， WWW 07查詢日誌分析研討會的程序：http://querylogs2007.webir.org
7. Gwizdka，J. ＆Spence，I. （2007年）Web導航中損失和成功的隱式度量。 與計算機進行交互19（3），第357-369頁。
8. Hadoop：http://hadoop.apache.org/core
9. Kaushik，A.（2007）. WebAnalytics：AnHouraDay. 印第安納波利斯：威利出版公司
10. Kohavi，R.等 （2007）. 網絡上的受控實驗實用指南。 KDD 07，ACM Press，第959-967頁。
11. Omniture：http://www.omniture.com
12. Pike，R.等 （2005）. 解釋數據：使用Sawzall進行並行分析。 科學程序設計（13），第277-298頁。
13. Tullis，T.＆Albert，W.（2008年）. 衡量用戶體驗。 伯靈頓：摩根考夫曼。
14. UserZoom：http://www.userzoom.com
15. Weischedel，B.和Huizingh，E.（2006年）. 使用Web指標進行網站優化：一個案例研究。 ICEC 06，ACM Press，第463-470頁。

注：

（1）翻譯目的是共享學習，有疑惑或翻譯錯誤請聯繫 Dreamy 的郵箱 [email protected] 。鍵盤俠勿擾，和諧生活。

（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 年重新撿起，沒啥幾篇破文章）：http://my.cgsdream.org/

本文由 @水水 翻譯發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

閱讀更多 人人都是產品經理 的文章

關鍵字: 大數據 設計 人生第一份工作