量化設計價值(三):如何建立體系化的監控系統

編輯導語:在使用者體驗設計中,資料也是一個十分重要的衡量因素。透過資料指標的建立,設計師可以更好地觀察到使用者行為、使用者特徵等資訊。本篇文章裡,作者結合其實際工作案例,總結、分享了量化設計中的資料型別與後續的資料視覺化等環節流程,一起來看一下。

量化設計價值(三):如何建立體系化的監控系統

隨著使用者體驗設計的發展,我們已經過了僅依賴需求和直覺就可以完成產品設計決策的階段了。

資料對使用者體驗設計師的價值可以總結為兩點

資料可以在「產品設計決策階段」提供了更多元的參考意見;

資料可以在「產品設計覆盤階段」提供更客觀的評價標準。

一、資料使用的場景

無論所處哪一種設計階段,總的來說,設計師的資料需求主要可以分為兩大類。

量化設計價值(三):如何建立體系化的監控系統

1. 探索事物間關係的“內因/外因”

是什麼東西影響了使用者的購買決策 ?我的新版網站首頁的改版是否為產品提升了註冊的轉化率 ?

這類需求的本質是探究一種事物間的歡喜和因果性,常用「推論性統計」、「相關&非引數校驗」進行分析。對於這類需求,往往會有專業的資料分析師,使用者研究設計師,資料產品經理承接。

2. 發現數據中的“模式/異常”

在一天之中隨著時間的變化,使用者的訪問量有什麼規律 ?這類需求的本質是在對已經發生的事物規律做一種總結 ,使用的統計方法更多的是「描述性統計」。對於絕大多數設計師而言,能夠做到發現數據中的 “模式/異常” 基本可以覆蓋絕大多數日常工作的需求。

本文主要關注解決設計師的第二類使用場景——發現數據中的“模式/異常”。目前各大網際網路企業內部都會提供自研或者第三方的BI工具,因此筆者建議設計師可以透過建立一個包含關鍵的體驗指標的資料看板系統,對自己負責的業務進行系統的總結和覆盤。

以我曾經的工作內容為例。

我們的產品是服務商家進行“前後端對接生產”的訂單稽核系統。【

效率】

是製造業至關重要的關注面,在一個企業使用者的付費決策中也起到了相當重要的分量,客戶使用我們的工具進行訂單稽核和流轉的效率是整個使用者體驗模型中的重要部分。

因此我們需要構建一系列合理的指標來判斷訂單系統的處理效率。除【

效率】

外,【

使用者行為

】【

使用者特徵

】等都是設計師關係的資訊。以【

效率

】為起點,最終我們構建了一個籠統的包含設計師所有要監測的資訊看板系統。

量化設計價值(三):如何建立體系化的監控系統

二、關鍵概念

本質上網際網路產品中的看板(kanban)與自然科學領域研究人員的用 R 或者 Seaborn 繪製的精美圖表沒有本質上的區別,差異點可能在於看板更加關注時效性,同時更加具備可互動性。

隨著儀表盤工具和各種BI軟體產品在人群中的普及,人們對儀表盤,指標(

Metric

)和關鍵績效指標(

KPI

)的組成有不同的理解。為了確保我們都說相同的語言,我將定義一組術語,這些術語將構成我們討論的基礎:

度量(Measure)

:度量是一段數字上可量化的資料。銷售額、利潤、留存率,都是具體衡量的例子。

維度(Dimension

):維度表示給定指標的不同方面屬性。例如,時間通常被用作分析不同度量的維度。其他一些常見的維度包括地區、產品、部門、細分市場等。

層次結構(Hierarchy)

:維度可以進一步分解為層次結構。例如,時間維度還可以形成層次結構,例如,年>季度>月>日。

粒度(Grain)

:層次結構中的每個級別都稱為維度的粒度。例如,年 > 季度 > 月 > 日 ,中的“年”是一個特定的粒度。

指標(Metric)

:指標是我們經常在儀表板中顯示的資料型別,它表示一個

度量

Measure

)的資料段與一個或多個特定

維度

(Dimension

)和相關

粒度

(Grain)

的關係。

量化設計價值(三):如何建立體系化的監控系統

上圖是在Tableau中一個標準的指標示例-

“每週銷售總額”

的構建方式。

在這個指標中,我們需要量化的“

”是美元——即總銷售額,用來觀察量化資料的“

維度

”——即時間,而時間維度可以被進一步分解為“年>季度>周”的

層級結構

“每週銷售總額”

需要關聯的維度中的特定“

粒度

——

即周。

看板(Cards or KanBan)

: 觀察一個或多個

指標(Metric)

執行情況的圖表。

儀表板(Dashboard)

: 儀表板是多個圖形、圖表、量表或其他直觀表示的集合。多個看板可組成一個儀表板。

報告(Report)

: 報告可以是對應圖表和其他視覺化的表示,也可以是可能直接相關或不直接相關的大量圖表和視覺化。多個儀表盤可組成一個報告。

量化設計價值(三):如何建立體系化的監控系統

“實時、受眾群體、流量獲取、行為……”

上圖為Google Analytics 中提供的多種型別的資料分析報告,報告可以非常廣泛地涵蓋廣泛的相關資訊。每一種特定報告內包含了若干個回答特定問題的dashboard,一個dashboard內可以包含多個相互關聯的指標的看板。

一個可分析、可追蹤的資料系統中,最原子的構成單位理解成一個“看板”。如何從0-1構建一個客觀有效的資料看板系統?我們可以類比【一個人學習做菜】的過程,做菜的過程可以總結為三個階段:

學習菜譜&列一個採購清單;

採購食材&烹飪食材;

擺盤料理&品嚐美食。

對應到資料看板系統的建立,我們亦可以總結為三個階段:

瞭解資料的特性、明確自己需要哪些資料;

透過技術手段獲取資料、將粗資料加工成意義明確的指標;

將指標資料視覺化,觀察資料並嘗試分析現象。

量化設計價值(三):如何建立體系化的監控系統

三、度量 Measure & 維度 Dimension

“ Data is more than numbers, and to visualize it, you must know what it represents。 ”資料不僅僅是數字,數字、陣列、表格、都可以被稱之為資料。要將資料形象化,你必須知道它代表什麼。

為了構建有效的效率指標,第一步是:明確為了解決當前的問題,要觀察的【

度量

】是哪些,以及這些度量又需要從哪些【

維度

】進行觀察。

1. 瞭解資料型別

一個線上的專案每天都在收集成百上千種資料,怎樣確定自己需要什麼資料作為

度量(Measure)

呢?首先值得注意的是,不是所有型別的資料都適合作為

度量

Measure

)被加工成指標。

不同學科、不同課程、不同領域,對於資料型別的定義基本一樣,但稱呼並不完全一樣。

統計學中,資料型別分為四種:定類,定序,定距,和定比。這四種類型是從低到高的遞進關係,高階的型別可以用低階型別的分析方法來分析,而反過來卻不行。

量化設計價值(三):如何建立體系化的監控系統

定性資料與定量資料

從宏觀角度分析,資料型別分為

定性

定量

兩種。

一個通俗的例子,以自身為例:例如衣服的顏色,頭髮的型別和鼻子的形狀這些標識標識的是定性資料;例如身高、體重、年齡和鞋子的尺碼,這些可測量的是定量資料。

1)定量資料

定量資料是統計資料,通常具有自然結構性,意味著它更加嚴格和明確,可再細分為連續/離散兩種。

此類資料使用數字和值進行測量,這使其更適合進行資料分析。可以透過以下方式獲取定量資料:

2)定性資料

定性資料是非統計資料,本質上通常是非結構化或半結構化的。

定性資料可以用來問“為什麼”的問題。它是調查性的,在進行進一步研究之前通常是開放性的。從定性研究中生成的資料用於理論化、解釋、發展假設和初步理解。

可以透過以下方法獲取定性資料:

文字和檔案;

音訊和影片記錄;

圖片和符號;

訪談筆錄和焦點小組;

……

想要了解訂單流轉的效率是怎樣,最簡單的方法是透過和我們的客戶進行面聊一下使用情況、並記錄一下反饋,但這樣的產物並不方便進行統計分析和展示。

儘管有一些對定性資料“結構化”的方法,比如對定類資料進行的非引數校驗,但實施起來成本較高。定量資料因為本身結構化的特點更適合分析,因此在這裡建議設計師在構建自己的dashboard系統時,需要跟蹤分析的資料儘量選擇

定量資料

2. 確定需要觀察的度量&維度

明確需要觀察的度量有哪些,首先需要從要解決的問題出發。

但是沒有一個整體的分析模型,往往會導致我們的分析遺漏很多資訊和細節,導致資料分析師無法理解彼此的需求,最終導致最後產出的看板難產或答非所問。

3. 使用的問題分析工具——KPI wheel

在這裡介紹一種名為KPI Wheel的簡單工具,可用於收集將用於定義和視覺化指標的前期必備資訊。您可以將

KPI wheel

的圖片列印在紙上,然後開始嘗試依次思考這四個方面:

“ 要解決的問題是什麼?”

“誰在關心這個問題?”

“我需要去哪裡獲取這些資料?”

“為什麼這個資料很重要?”

在解答的上述的幾個問題的過程中隨手記錄:

可能引發什麼進一步的疑問;

使用此資訊可以採取什麼行動或決定。

不斷地提出問題並進行進一步分析,這麼做的目的是讓使用者不斷分解問題,直到他們有足夠的資訊來採取行動或做出決定。

經過幾輪完整的分析後,使用者就可以大致確定指標的「度量」和 所需要的「維度」。

量化設計價值(三):如何建立體系化的監控系統

以我曾經的工作內容為例:我們的產品是服務商家進行“前後端對接生產”的訂單稽核系統,我們需要構建一系列合理的指標來判斷訂單系統的處理效率。

以下是與產品經理討論過程中的具體流程。

第一輪 KPI Wheel ——

Answer KPI Wheel:“ WHAT?WHO? WHERE? WHY?

1)what:我們需要一種途徑,瞭解使用者進行訂單稽核的效率如何。

針對這個問題我們聯想到:

想要了解訂單處理效率,首先需要定義什麼叫訂單的效率;在行業中有一種叫做「訂單生命週期」的專有名詞來表示訂單從建立到結束的時長,是一個可借鑑的概念。

針對我們的業務,一個工單的生命週期經歷了從建立——流轉&稽核——透過,一個工單從建立到透過所經歷的時間是我們需要記錄的【度量】。

2)who:產品/運營/設計 三個業務方都關注訂單的效率

針對這個問題我們聯想到:

對於不同的角色,在檢測資料的時候都關注哪些維度?

訂單型別分稽核單&生產單這兩種,兩種型別的訂單,訂單型別是一個必要維度。

時間是上述三個相關方都需要關注的維度,一個訂單在透過稽核時的時間,是一種重要的分析維度;而“時間”維度,我們可以繼續拆分為:年——月——周——日的層次結構。

對於運營,瞭解不同行業的商家的訂單效率,對進行深入運營是必要的。而“行業”維度根據分類方式的不同,又可以歸類為一級行業(軟裝設計/板式傢俱/……),二級行業(整木定製/辦公傢俱定製/暖通/地板/瓷磚……)。

對於產品,為了更好地維護客情,對於特定的大客戶的資料需要重點關注。因此商家賬號的ID,也是重要的分析維度。

3)where:我們需要的資料要在哪裡獲取?

針對這個問題我們聯想到:

與一般的使用者行為資料不同,訂單的資料都儲存在後臺的操作日誌中。

需要的“行業”維度,可以複用其它團隊已經制定好的標籤。

4)why:效率是企業的生命,製造業中存在各種效率指標,如“人效”/“屏效”等。糟糕的使用效率會造成我們的產品在根本上是不可接受的,因此效率指標非常重要。

針對這個問題我們聯想到:

透過【訂單生命週期】統計的時間,可以在整體上評估訂單系統的流轉效率。但是僅僅依靠一個這樣的指標,缺少一些更細緻的視角。可以增加對方案(訂單的載體)的停留時長的統計,來計算稽核在整個生命週期中所耗時間的佔比。

The Rising Questions & Action:

根據問題1的答案,這還會引發什麼其他問題,或者您將採取什麼行動?”

在回答上面的4W的過程中,會引發其它衍生問題,例如 “訂單稽核週期的時間的最小單位是什麼?” 等等。

針對上述的其中衍生問題,可以再進行一輪kpi wheel的自問自答。比較簡單的衍生問題,不需要4個方面都進行問題分析。

4. 最終

在多次重複上述的兩個過程後,最終我們確定了要在產品中量化哪些

度量(Measure),

以及這些度量需要哪些分析維度,並將所有需要的度量和相關的維度都用表格的形式記錄下來。

例如,“

訂單從建立到最終透過的時長(h)”

,是一個需要被量化的度量。它需要關聯的

維度(Dimension

)有時間、商家ID、一級行業、二級行業。

量化設計價值(三):如何建立體系化的監控系統

四、指標 Metric

研究完成菜譜,記錄✍️採購清單後,接下來的帶班過程就是準備食材並進行烹飪。

當你已經明確了要觀察的

度量(Measure)、

和需要關聯的

維度

(Dimension

),下一步就是透過資料建設獲取這些度量,然後將度量加工成指標。

1. 建設埋點

獲取度量的過程就是“

取數”

的過程。想要建立看板,資料分析師需要透過各種方式獲取一張包含所有你需要的資訊的寬表。

如何獲得這張包含一切關鍵資訊的表格?我們需要藉助埋點獲取資料。

所謂埋點就是在應用中特定的流程收集一些資訊,用來跟蹤應用使用的狀況。

您可以把使用者在與您的網站或應用互動時觸發互動行為理解為一個“

事件”

,一個時間存在一個觸發的條件,當達到這個觸發條件後就會上傳請求,請求中會攜帶需要的“

引數

”。

例如“使用者點選按鈕將商品加購到購物車”這個行為,每次使用者觸發這個行為後都會發送一個請求,而這個請求中會記錄:加購商品的金額/加購商品的型別/加購商品的商品ID……等資訊。這些結構化的資訊構成了我們需要的

度量(Measure)

維度

(Dimension

)。

在完成了最基礎的埋點後,我們就獲得了最基礎的資料。

量化設計價值(三):如何建立體系化的監控系統

2. 如何建立有效指標建議

“指標”是量化衡量標準,未經加工的資料不具備可觀察的價值。

透過埋點,我們單純只是得到了若干張包含所有使用者資訊的巨型表格,我們是分析不出什麼有用資訊的。為了更有效地去觀察和分析作為

度量

Measure

)的資料,就需要對埋點資料進行一定的加工,變得更加易於理解和表達。

當一個

度量

Measure

)的資料段與一個或多個特定

維度

(Dimension

)之間互相聯絡了起來,度量就成為了指標。

例如,同樣的一份關於【

訪問使用者人數

】這一度量,可以根據關聯的時間維度的不同,建立

DUV

MUV

等多個不同的指標。

如何建立一個有效的指標,結合筆者的工作經驗,下面給出三點建議。

1)為一個指標設想一個高階概念

首先指標的名稱需要客觀,要讓人乍一聽就能大概會意,例如:「加購商品操作每日點選次數」。

而如果您定義的是類似:“軟體上手度”,這種概念比較晦澀、在業內又沒有約定俗成的定義的指標,可能需要重新考慮概念是否恰當。

每週訪問站點的使用者總數/ 每日訪問站點的使用者數/ 每日訪問站點的新手使用者數……這些指標既相互獨立,但反應的又是同一件事的客觀熟悉的時候,我們可以把這些詳細的指標統一用一個高階的指標概念來做一個歸納,例如“站點訪問使用者數”。

量化設計價值(三):如何建立體系化的監控系統

2)檢查並確定定義指標的細節

確定了指標的基礎概念後,需要檢查一遍指標的細節。

例如,“訂單生命週期”這個指標的定義中,生命週期是指一個訂單從建立到最後透過稽核耗時,而與其關聯的維度有時間、訂單型別等。

需要強調的是,一個訂單可能會存在:建立時間、透過時間,這兩種不同的時間戳。而在“訂單生命週期”這個指標我們需要關聯的時間維度是【透過時間】。如果關聯是【建立時間】,則會得到另外一種完全不同的生命週期計算方式。

量化設計價值(三):如何建立體系化的監控系統

3)將測量到的度量資料,透過計算總結為一個指標

透過埋點收集到的是大量的資料,是一個巨大的整體,而指標則是描述總體特性的引數。

而把原始資料組織並總結成更易處理的形式的技術叫做描述性統計,一種最常見的方法是透過計算平均數的方法總結一組資料。

這些描述總體特性的引數中又存在不同的用途,有的用來描述頻數分佈,有的用來描述集中趨勢:平均數,眾數、中位數,有的用來描述變異性:四分衛距、方差。我們需要根據自己的用途選擇合適的統計方式來構建指標。

量化設計價值(三):如何建立體系化的監控系統

根據統計方法的不同,常見的指標型別有以下幾種,他們擁有不同的分佈型別和方差的計算公式

【 計數 Count 】

【 機率

Probability

【 平均數

Average

【 中位數(或其它位數)

Percentile

【 比率 Rate 】

【 一般比例 Ratio 】

量化設計價值(三):如何建立體系化的監控系統

五、視覺化 Visualize

烹飪好食材之後,接下來的工作就是擺盤與上菜。優秀的擺盤可以讓料理更加精緻和高階,優秀的資料視覺化可以幫助我們更好地觀察與分析資料,反之糟糕的資料視覺化可能會讓我們丟失很多重要資訊。

1. Why visual ?

為什麼一定要使用看板(圖表)來觀察和分析資料?僅關注幾個關鍵指標的資料是否就已經足夠?

使用看板對指標進行觀察和分析的意義在於:相比單純的數字,圖表可以攜帶更多的展示維度(大小、長度、顏色、面積……),能幫助我們多維度地觀察資料、避免疏漏。

例如,安斯庫姆四重奏

(Anscombe’s quartet)是四組基本的統計特性一致的資料,但由它們繪製出的圖表則截然不同。如果僅依靠基本的統計特性來觀察資料,我們很容易忽略一些重要資訊。

量化設計價值(三):如何建立體系化的監控系統

選擇合適的圖表型別

BI工具中支援多種圖表型別,比如展示瀏覽路徑的“桑基圖”、展示轉化率的“漏斗圖”、甘特圖、散點圖等。

如何選擇合適的圖表來展示並分析你的資料可以參考下圖:

量化設計價值(三):如何建立體系化的監控系統

圖表種類繁多,但只要掌握其中的一小部分就能滿足絕大多數需求。對於大部分設計師,以下3種最基礎的圖表型別是最常用的:

條形圖:條形圖是最常用的圖表型別。條形圖易於閱讀,我們用眼睛比較條形圖的末端,很容易快速得出結論:哪一類最大、哪一類最小以及類別之間的增減區別。

線圖:線圖最常用於繪製連續的資料。因為線連線了點,這就暗示了點與點之間存在著離散資料(一系列資料分隔成不同的類別)間沒有的聯絡。通常,連續性資料都以時間為單位:天、月、季度和年度。

餅圖:餅圖在總量間各部分的佔比時比較高效。

最後,當我們建立了許多看板後如何進行歸納?

我們可以將關注相同的問題的看板歸納在一起,就形成了一個關注同一類問題的Dashboard;對不同的 Dashboard 提取共性,將同一個業務的不同Dashboard組織起來,就形成了一個Report。一個Report內可以籠統的包含當前業務需要關注的所有資訊。

量化設計價值(三):如何建立體系化的監控系統

例如:【訂單生命週期】關注的是企業的訂單效率問題,但並不是唯一關注效率的指標。

另外還有諸如:“審單員平均稽核時長”這樣的人效指標的看板,這些看板同樣反饋的是訂單的效率。我們將關注相同的問題的看板歸納在一起,就形成了一個Dashboard,Dashboard內的看板與指標都有關注同樣的問題—效率。

除了效率,身為設計師的我們還需要關注很多其他的問題:比如使用的使用者的特徵、流量的來源、使用者發起的行為等等,這些問題都可以擁有自己獨立的Dashboard。

最後這些Dashboard組織在一起,就成為了一個支援系統的觀察分析當前業務的體驗指標的完整報告。

2. 觀察與分析資料

“我們需要的不是資料,而是資料告訴我們的實事”。透過建立一個系統的監測體系的目的主要是為了從資料中探索:模式/異常。不管圖表的形式是什麼,我們都需要留心觀察這兩者。

1)何為「模式」

模式即資料中的某項規律。

比如機場每月的旅客人數,雖然隨著時間推移變化不定,但是通過幾年的資料對比,我們可能發現旅客人數存在著季節性或週期性的變化,某些月份的旅客數量一致偏低,某些月份則一直偏高。

量化設計價值(三):如何建立體系化的監控系統

根據資料畫像我們可得知,某個產品的成熟期使用者佔絕對多數的現狀,瞭解了這個「模式」,就可以更好地制定符合絕大多數使用者心智的設計策略

2)何為「異常」

異常即問題資料。

異常資料並非是錯誤資料,也有可能是裝置記錄或人工錄入資料時出現的問題。我們透過異常異常分析,一方面可以分析異常原因;一方面可以發現現有系統的漏洞。

量化設計價值(三):如何建立體系化的監控系統

蘋果公司透過監控異常值、發現了位於深圳的AppleCare灰色產業,進而改善了AppleCare的產品策略,避免了巨大的損失

最後在觀察分析資料的過程中,有三個需要特別關注的資料的特性不要忘記。

① 資料具有可變性(VARIABILITY)

資料的可變性這一重要的特性讓我們可以從資料中獲取規律和關係。如果您構建的指標本身並不具備可變性了,那您很可能需要嘗試其他指標進行跟蹤和分析。

② 資料具有不確定性(UNCERTAINTY )

很多資料都是隻能提供一個估計而不是絕對準確的數量。例如:分析人員通常會透過樣本的資料,進而對整體的資料分佈進行進行猜測。

③ 資料需要聯絡上下文( CONTEXT )

資料分析離不開情境。我們知道,資料的產生必然是有其情境的,不過統計資料時,我們通常都要剝離情境;而當我們進一步分析資料時,又必須回到具體的情境中去。

例如:某個羽絨服經銷商發現某一年冬季的銷售額產生了明顯的下降。

這本應該是一個異常的訊號,但我們不能簡單粗暴地定義這是一個糟糕的資料。因為實際上,銷售額下滑的哪一年是一個暖冬,且和同類的競品相比自己的產品銷售額下滑趨勢的更低。結合情景分析資料,往往能得到意想不到的結論。

本文參考文獻:

文章:Dashboard Design: Key Performance Indicators and Metrics —— Thomas Gonzalez

文章:【統計學】區分定類、定序、定距、定比變數——YYIverson

書籍:Tableau:資料視覺化之極速BI —— 沈浩

書籍:Which chart or graph is right for you?——Tableau圖表白皮書

書籍:Data Points:Visualization That Means Something —— Nathan Yau

書籍:Storytelling With Data —— Cole Nussbaumer Knaflic

作者:曉虎;公眾號:酷家樂使用者體驗設計

本文由 @酷家樂使用者體驗設計 原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

頂部