本篇主要介紹了一些在使用者行為分析平臺中應用最廣的產品功能和分析方法，包括：使用者分群、留存分析、轉化分析、行為路徑分析和事件分析，與大家分享，供大家一同參考和學習。
相比於傳統行業，使用者行為分析平臺可能是網際網路企業的一個特有的資料分析工具。能夠對使用者行為進行分析，進而展開精細化運營，可能也是網際網路行業發展迅速的原因之一。隨著傳統行業逐步網際網路化，使用者行為分析的應用場景也越來越廣，該平臺在企業內扮演的角色也愈發重要。
得益於使用者所使用的硬體和軟體，我們可以記錄到大量的行為資料。使用者行為分析平臺便是對這類資料進行深度地分析，從中挖掘有價值的資訊，例如不同群體對產品的偏好，使用習慣等。這些資訊最終能指導產品和運營等方向的最佳化。可以說，使用者行為分析平臺是資料驅動業務的代表產品。
典型的行為分析包括了留存分析、轉化分析、路徑分析等，以及基礎的使用者分群
，這些功能若都能沉澱並在平臺上產品化，將能大大提高企業對行為資料分析的效率和覆蓋使用者的廣度，不具備專業資料分析技能的人員在簡單接受產品培訓後也可以完成相關分析。本文也會主要關注以上幾個模組。
一、使用者分群
使用者分群的操作，本身其實不會直接產生價值，但卻可以說是後續一切分析的基礎。
如果不進行分群，所有的分析都只基於彙總資料，很多細節在彙總時都丟失了。引用資深資料專家、Google Analytics的推廣人之一Avinash Kaushik的名言：所有聚合的資料都是垃圾，要麼分組，要麼去死。（All data in aggregate is crap。 Segment or die。）可見分組、分群的重要性。我們常見的分群例如：使用者獲取渠道來源，裝置終端，新老使用者等屬性，以及是否有過具體某類行為等。對使用者根據需求分群后，再進行留存、轉化等分析，通常會事半功倍，也能發掘真正有價值的資訊。
使用者畫像也可以被理解為使用者分群的一種，使用者畫像會根據一系列使用者標籤和演算法對使用者進行畫像描繪和分群。這裡介紹的使用者分群產品，可以看作是使用者畫像的消費方，在使用者分群產品中可以根據已有的畫像進行分群。具體的畫像產品或許會在另一篇裡講述。
不論是根據使用者所具備的自然屬性，還是在產品使用過程中所表現的行為特徵進行分群，都要求產品能做到足夠廣度和深度的資料記錄，也就是我們在第一篇埋點篇中要下的功夫。
在使用者分群模組中，我們可以根據已有的資料，配置分群規則，建立新的群組。分群的操作，其實類似SQL中的條件查詢。透過將程式碼功能產品化，降低了使用門檻。
如下圖，是神策產品中的針對某直播業務的使用者分群功能展示。
使用者分群功能
該分群結果為使用者屬性滿足使用者等級大於10且使用者型別為普通使用者，且在2017-4-17至2017-5-16之間有過至少5次送禮物行為且禮物型別為付費禮物，且在2017-4-17至2017-5-16之間有過留言和點贊行為的使用者。我們視其為高粘性且高頻消費使用者，在平臺上完成篩選後對該使用者群命名並儲存。運營人員可以檢視該使用者群的明細列表，更重要的是可以透過其他行為分析工具來觀察這部分使用者的行為表現，以及和其他使用者的區別。這類分析對於我們在使用者增長工作中定義目標人群、魔法數字、尋找增長機會、進行增長實驗等環節都有非常大的幫助。
可以看到，使用者分群本質上是一種條件篩選器，在每個篩選器中篩選出符合特定要求的使用者群。
篩選器中首先需要定義篩選的欄位（具體的使用者屬性、行為特徵等），再透過大小等於不等於、是否在之間、是否在其中等關鍵字完成條件的設定。若篩選的欄位是數字，自然篩選範圍也是數字，若篩選的欄位是字串，可以提供相應欄位的列表進行篩選。篩選器間可以巢狀，可以透過AND、OR（表示並且、或者）等關鍵字連線。
二、留存分析
留存分析是透過對使用者使用產品的情況、活躍程度等進行分析以判斷使用者是否仍留存在產品內的分析模型。
使用者留存在產品運營週期中的重要性無需多言，由於本文重點關注完成分析的資料產品，因此不會涉及過多具體分析的內容。
要進行留存分析，首先需要定義留存和流失的標準。
不同型別的產品可能有不同的定義方式，有些公司會把留存簡單定義為使用者在一定時間後仍有開啟產品。但有些公司可能需要更嚴格的定義，例如某電商公司可能將留存定義為使用者在一定時間內有再次消費的行為。
因此，在留存分析模組內，要可以對留存進行定義，即支援自定義起始和回訪事件，同時還可分別設定過濾條件。例如對於一款短影片app，我們可將起始事件設計為開啟app，回訪事件設計為播放影片。當然，此時我們已經可以應用在使用者分群模組中設定的使用者群，進行對特定群體的分析了。下圖展示了Growing IO定義留存的頁面。
定義使用者留存
衡量留存，我們通常會計算同一使用者群不同時間段的留存率，並以此繪製留存曲線，這便是我們常說的同期群分析（Cohort Analysis）。
在同期群分析中，我們會把同一時期加入的使用者放入模型，橫向追蹤他們在未來一段時間內是否仍然留存或流失，流失的時間和比例。例如常見的次日留存、7日留存，以及更長時間段更粗粒度的周留存、月留存等。使用者起始事件的日期和回訪事件的日期間隔N，便是該使用者的留存日期，即N日的留存使用者。
留存率的計算公式為：
具體某天的N日留存率=該天起始使用者在N日留存的使用者數/該天的起始使用者數
。當然也可以選擇周、月、甚至年等其他統計週期。
在明確留存事件、留存週期和統計時長後，就可以統計出每個週期的留存率和繪製留存曲線了，這些功能都可以由留存分析模組自動輸出。例如下圖，是Growing IO對過去180天使用者的月留存進行的分析。更精細的分析還可以同時繪製出多條不同統計週期下起始使用者的留存曲線，從而解讀每個週期下不同留存表現背後的不同動作。
使用者留存曲線
詳細資料可以檢視如下的留存表格，表格中記錄了每個統計週期內起始使用者在後續每個留存週期內的留存表現，並透過單元格顏色深淺表示留存程度。
留存詳情表
若想從整體上了解使用者留存的情況是否越來越好，還可以檢視特定週期留存率隨時間變化的趨勢。如下圖反映了過去30天，使用者次日留存、7日留存和14日留存的趨勢情況。
特定週期留存率的變化趨勢
針對特定週期下的留存使用者，我們還可以檢視詳細的留存使用者列表，做更細緻的分析，更可以將該使用者群儲存為新的使用者分群。
三、轉化分析
轉化分析是對完成關鍵行為的每一個環節建立轉化漏斗，瞭解最終及每一步具體轉化情況的分析模型。
轉化分析能讓我們清晰認識到目前轉化上的問題節點，並展開最佳化工作。
要進行轉化分析，首先自然要定義轉化漏斗。
轉化分析模組可以新建任意的轉化漏斗，在新建過程中正確選擇每個步驟的事件或指標即可。例如，下圖是Growing IO中新建轉化漏斗的頁面。左側是可選擇的具體事件或指標，根據勾選順序會在右側構建漏斗。定義轉化漏斗時，我們同樣可以選擇特定的使用者分群進行分析。
新建轉化漏斗
需要注意的點是，使用者完成整個轉化鏈條不一定是連續的。例如使用者在某電商網站購物，可能在第一天完成了商品的加購，但三天後才會完成下單支付。
因此在轉化分析模組，需要設定轉化的視窗期，即使用者完成整個轉化鏈條的總時長。
而轉化分析的統計時間範圍，通常是指轉化步驟的第一步發生在該統計範圍內，後續步驟不一定在此範圍內。例如，下圖是Growing IO中模擬的某電商網站簡易購買轉化漏斗。統計範圍是過去14天，意味著統計瀏覽商品詳情頁（第一步）發生在過去14天的所有記錄。轉化週期是3天，意味著只統計在3天內完成了整個轉化鏈條的記錄。
購買轉化漏斗
轉化漏斗中，可以瞭解整體的總轉化率，每一步的絕對數量和階段轉化率。以上圖資料為例，可以明顯定位問題在於大量使用者瀏覽商品後卻沒有加購，導致最終沒有成單。
與留存分析一樣，我們還可以檢視轉化率隨時間變化的趨勢圖，以定位轉化問題與特定時間點之間的關聯。下圖是該舉例資料的轉化趨勢表現，可發現在統計週期最後3天，轉化率下降明顯。但由於我們選擇的統計範圍是最近14天且轉化週期是3天，可能因為這個原因，導致部分最後3天進入漏斗的使用者還未完成整個鏈路，影響了當天的轉化率。
轉化率趨勢圖
簡單的轉化漏斗分析可能還不能滿足精細化運營的需求，更理想的做法是對不同維度或使用者群進行細分和對比分析，以瞭解不同群體間的轉化區別，進而指導我們的運營方向（是的，使用者分群又派上用場了）。例如，下圖根據使用者等級進行了漏斗對比，發現鑽石使用者的轉化率居然還不如普通使用者，這很可能意味著會員體系設計上的bug，相關產品人員可能需要好好反思總結下了。
轉化漏斗對比
四、行為路徑分析
轉化分析能告訴我們最終有多少使用者成功轉化，多少使用者流失了。可這些流失的使用者都去了哪？他們在流失前都有什麼行為？甚至他們為什麼會流失？這些問題轉化分析都無法告訴我們，因此我們需要對使用者的行為路徑進行分析，以幫助我們更深入的瞭解流失背後的原因。
行為路徑分析是用來追蹤使用者從某個事件開始到某個事件結束過程中的全部動線的分析方法。聽上去和轉化分析有點類似，但行為路徑分析記錄的資訊要更廣，記錄的時長通常更短。
轉化漏斗是人為定義的，而對於使用者的行為路徑，我們雖然可以透過產品設計進行引導，但卻無法控制。因此我們分析使用者的行為路徑不光是為了作為使用者轉化分析的補充，更可以瞭解使用者的實際動線、操作行為，讓產品順應使用者，找到使用者的願望線。
願望線的概念來源於設計心理學，它反映了人們最希望行走的路徑。
最典型的例子便是我們在小區、公園等地都會發現除去修築好的道路，總有一些人為踩踏草坪走出來的路，這便是使用者真實希望的路徑。在產品設計時，我們其實更多的應該是順應使用者的行為，而不是規劃使用者的行為。
要完成行為路徑分析，需要先定義Session。
Session即會話，是指在一段時間內，使用者在產品中的行為總和。一次Session可能包含了多個頁面訪問、圖片瀏覽、社互動動、支付交易等行為，以及會有在多個頁面間來回流轉的重複行為。我們會根據時長和具體事件完成Session的切分。行為路徑分析和轉化分析的另一個不同便是，行為路徑一般會被定義一串連續的行為，因此不會像轉化分析一樣設定以天為單位的統計週期。比如對於Web產品，Session的切割時間可能就是30分鐘，而對於App產品，可能切割時間只有1-5分鐘。透過Session我們可以瞭解使用者的實際使用時長和互動深度，但時長越長和互動事件越多並不一定代表產品對使用者價值越大，需要具體問題具體分析。也有可能是因為動線設計不合理，導致使用者增加了大量無效的操作。
其次需要挖掘在Session中使用者的最大前驅路徑。
最大前驅路徑的意思是，使用者在產品內可以完成的所有行為路徑的集合。例如使用者訪問Session有如下的路徑{A，B，C，D，C，B，E，G，H，G，W，A，O，U，O，V}，這裡每個字母代表一個訪問節點。尋找最大前驅路徑的思路就是每當發生回退事件，則意味一條路徑結束，需要回到回退事件之前的節點，再繼續往下尋找。因此這裡得到的最大前驅路徑為{ABCD，ABEGH，ABEGW，AOV，AOU}，一共5條路徑，畫成樹如下：
最大前驅路徑示例
尋找最大前驅路徑的工作，有特定的演算法可以解決，我們更需要關心的是在完成這些準備工作後的行為路徑分析產品化。在行為路徑分析模組中，我們可以設定路徑的開始和結束節點，以及統計的時間範圍。如果是配合轉化分析，可以設定為轉化漏斗的第一步和最後一步。該模組同樣也可以支援屬性和使用者分群的篩選。最終的分析結果以桑基圖的形式呈現。例如下圖是神策中對使用者行為路徑的分析。每一條串聯起的流向都是一條使用者路徑，直至節點最多的使用者路徑為止。
使用者行為路徑示例
使用者行為路徑分析能讓我們更深入的瞭解使用者的實際行為動向，發現更深層次的問題。在上圖中大量使用者在開啟App後成功被Banner位活動所吸引，但最後只有30%使用者透過活動落地頁提交訂單（假設是一個開通付費會員的活動），大量使用者選擇跳轉到商品詳情頁。這說明活動落地頁的設計存在問題，不足以直接轉化使用者開通付費會員，使用者仍需要透過瀏覽實際商品瞭解付費會員的價值。
五、事件分析
事件分析是指對具體的事件或指標進行查詢分析。
事件分析是最基礎的使用者行為分析，但也可以說是最細緻的分析，所以放到了最後來講解。透過對預先設計的埋點事件進行不同維度和時間範圍的篩選，可以簡單快捷的查詢我們想要的資料，本質上就類似於我們透過SQL完成取數工作。
要完成事件分析，首先要明確事件的定義。
由於在資料埋點篇中已做了詳細介紹，這裡就不再贅述了。只需瞭解事件是透過埋點記錄，一個產品中會包含大量的事件。一個事件內可能包含多個事件屬性，以key-value的形式記錄。例如埋點篇中的活動訪問事件，包含了活動ID、訪問來源等屬性。而有一些所有事件都具有的屬性，可以單獨作為公共屬性記錄，例如裝置終端、作業系統、app版本等。
事件分析模組的一個重要功能是需要支援自定義事件或指標。
埋點是最細節的統計資料，同時有一定的開發成本，不會頻繁變動。因此有些有分析需求的事件或指標不會直接由埋點一一記錄，而需要人為的在事後定義。例如統計同時訪問過A、B兩個活動的使用者數，需要定義一個新事件：既有A活動訪問事件，又有B活動訪問事件，對於這種由多個原始事件組合、過濾得出的新事件，通常被稱為虛擬事件。以及在資料指標篇中提到的計算指標，例如某商品詳情頁的點選率，需要透過自定義詳情頁點選次數/商品展現次數得出。
在進行事件分析時，只需選擇具體的事件或指標，以及指標的統計方式，通常包括求和/平均/人均等方式，在選擇統計的時間範圍就可以完成基礎分析了。更細緻的需求，還可以透過新增拆分維度和使用者分群進行深度分析。如下圖統計了商品點選和加購行為在過去七天的次數變化趨勢，並按照男裝/女裝的類目進行了拆分。
事件分析示例
由於留存分析、轉化分析、路徑分析其實都是對事件進行定義和組合後進行的分析，所以可以認為事件分析是其他各類分析的基礎。在基礎的事件分析中，我們一般會配置一些常用的分析指標，比如PV、UV、DAU等。而作為最原始和最基礎的分析工具，事件分析的粒度也是最細的，因此除了瞭解常規的事件和指標的表現，我們有必要藉助事件分析挖掘更細節的資料。
本篇主要介紹了一些在使用者行為分析平臺中應用最廣的產品功能和分析方法，除此之外還有諸如使用者行為細查、熱圖分析等相關功能。隨著技術本身和從業人員分析水平的進步，未來必然會有更豐富更科學的分析工具和方式出現，例如藉助AI能力幫助企業智慧定位魔法數字和願望線的功能。我們能做的只有不斷進步，跟上行業發展的趨勢，保證自己處在領域前沿。越早掌握新工具，越能獲得先發優勢。
使用者行為分析平臺篇到此結束。
本文由 @Rowan 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議