關于流量分析體系的那點事

2 評論 15425 瀏覽 59 收藏 17 分鐘

編輯導語:大家是否知道,什么是流量數據?為什么要做流量數據分析體系?又該怎樣做流量數據分析體系呢?本文作者圍繞這三個問題,為我們做出了詳細地解答,讓你知道關于流量分析體系的那點事。

1. 什么是流量數據

流量數據主要以用戶訪問產品/頁面時,從啟動到使用產品等一系列的過程都會產生許多流量數據。流量數據定義為用戶訪問產品時/頁面時產生的數據,需要企業通過數據采集來獲取數據。

2. 為什么要做流量數據分析體系

當前市面上居高不下的獲客成本,對于新用戶,可能僅打開一次app就流失。監測流量數據,診斷數據異常,改善業務邏輯,促進產品收益。

3. 怎樣做流量數據分析體系

用戶訪問產品/頁面時,從啟動到使用產品等一系列的過程都會產生許多流量數據。流量數據大 都通過埋點上報產生,通過數據處理與加工形成質量高、易于分析的數據資產,經過數據分析為決策提供數據支持與洞見。

3.1 數據生產

3.1.1 業務需求——埋點數據需求

組里的DA同學收到的業務訴求常常是“期望能這個功能的使用情況”等,而此時如果僅給出一個功能使用uv、pv,是不夠的,需要全方面的了解業務訴求,并將其抽象為埋點需求。

面對“期望能這個功能的使用情況”業務需求時,需要了解:

  1. 業務的短、中、長期戰略,e.g.中長期戰略為用戶下沉;
  2. 為什么上線這個功能;
  3. 這個功能可能會影響其他功能。

了解后,根據業務背景、需求、目的,將其抽象為“埋點需求”。

  1. 業務的短、中、長期戰略,e.g.中長期戰略為用戶下沉,用戶下沉使用城市等級、收入金額等來劃分;
  2. 為什么上線這個功能:了解到是為了提高用戶粘度,需要監測使用該功能的用戶留存、活躍天數。并通過對比分析得到與其他功能的差異表現;
  3. ?這個功能可能會影響其他功能: 獲得與該功能可能相斥的功能點,監測數據表現,避免“業務預期外”的侵蝕現象;獲取期望相輔的功能點,監測數據表現,避免“出乎意料”。

3.1.2 埋點設計

設計埋點需求前,需要了解下事件模型(who、when、where、how、what),基于事件模型全方面的刻畫埋點。

3.1.2.1 埋點要素

WHO:

即誰參與了這個事件,唯一標識(設備/用戶id),可以是匿名的設備id(idfa\idfv\android_id\imei\cookie)、也可以是后臺生成的賬戶id(user_id,uid)、也可以是其他【唯一標識】。

現在很多公司都有自己的唯一設備id(基于某個策略產生的唯一標識),e.g.阿里有OneId。埋點時,該參數通常使用 業務所用的唯一id;在埋點設計文檔中,如果沒有特殊處理,無需特別聲明。

WHEN:

即這個事件發生的實際時間。

該時間點盡可能精確,有利于行為路徑分析行為排序,像神策會精確到毫秒。如果公司內已有數據統計sdk且該埋點使用,則無需特別說明。

WHERE:

即事件發生的地點。

可以通過ip地址解析國家、省份、城市;如果期望更細致的數據,如果住宅、商業區等,需要額外地理信息數據庫來做匹配。地點信息和時間信息一樣,是每一個行為事件都需要上報的信息,基本上會是統計sdk的預設字段,也無需特別說明。

HOW:

即用戶用某種方式做了這個事件,也可以理解為事件發生時的狀態。

這個包括的就比較多,可以是進入的渠道、跳轉進來的上級頁面、網絡狀態(wifi\4g\3g)、攝像頭信息、屏幕信息(長x寬)等。

而如使用的瀏覽器/使用的App,版本、操作系統類型、操作系統版本、進入的渠道等 經常設置為“預設字段”,也無需特別說明。

WHAT:

即用戶做了什么,結合用戶行為/操作以及業務所需的數據粒度,需要通過埋點盡可能詳細的描述清楚行為,也是埋點設計文檔最為重要的部分。

如搜索(搜索關鍵字、搜索類型)、觀看(觀看類型、觀看時長/進度、觀看對象(視頻id))、購買(商品名稱、商品類型、購買數量、購買金額、 付款方式)等等。

3.2.2.2 埋點示例

以“啟動”事件、“播放”事件為例,設計埋點。

3.1.3 埋點開發

埋點在形式上,支持代碼埋點、可視化埋點、全埋點。代碼埋點時,可以客戶端埋點,也可以服務端埋點;統計SDK,APPSDK、webSDK、小程序SDK、H5SDK等。

可視化埋點、全埋點背后對應的是統計SDK針對“某些事件”的自動上報,埋點開發相關知識點可以查看歷史文章。

統計SDK是埋點開發提效的工具,填寫需要上報的參數即可,統計SDK的格式大都基于事件模型,較為通用的事件模型可以參考神策分析。

3.1.4 埋點測試驗收

埋點測試驗收,需要從邏輯、數據 兩方面測試驗收,以確保埋點的正確性、順序性、完整性。

  • 正確性:確認數據是否上發,并檢查上方數據內容格式是否與需求文檔一致;
  • 順序性:數據上報的順序正確,間接性驗證埋點代碼的正確性;
  • 完整性:針對各場景均需要測試,確保不同來源、不同場景下均有數據上報。

埋點平臺通常均有針對性測試的模塊,像umeng可以注冊測試設備后,查看埋點的測試數據,埋點上線后也需要進一步觀察數據是否有異常。

3.2 流量數據的加工

3.2.1 數據質量的保障

經過數據處理的埋點數據,需要保障 完整性、準確性、一致性、及時性。

  • 完整性:完整性是指數據的記錄和信息是否完整,是否存在數據缺失情況,是數據質量最基礎的保障;
  • 準確性:指數據中記錄的信息和數據是否準確、是否存在異?;蛘咤e誤的信息;
  • 一致性:指在多處數據記錄中,數據一致;
  • 及時性:保障數據的及時產出才能體現數據的價值。

3.2.2 數據模型

有了埋點數據,通過數據處理,該過程就不詳細講了。

數據標準化后,通常會存在于三張表:事件表;用戶屬性表;目標對象表(三張表僅是按照使用表的目的而言,為了提高查詢效率等,通常會將三張表按照事件過程再拆分)。

基于這三張表的查詢模型,將可以支持一般數據量級的各種分析模型,超大數據量下查詢速度會降低,如需提高查詢速度,則需要通過存儲換查詢,例如將高頻查詢結果進行緩存、設置數據加速等。

  • 事件表:每條記錄描述一個用戶在某個時間點、某個地方、以某種方式完成某個具體的事件;
  • 用戶屬性表:主體為用戶,每一個用戶有一條記錄,屬性包括了用戶屬性(包括平臺、網絡、服務商、手機型號、地域等等自然屬性;也包括用戶等級、是否為大V等非自然屬性),通過用戶可以關聯到事件表分析。
  • 目標對象表:主體為目標對象,目標對象通常是一個業務的主要載體,比如短視頻APP,目標對象為視頻(id),通過目標對象可以關聯事件表分析。

3.3 流量數據的應用

3.3.1 常用流量分析

3.3.1.1 事件分析

事件分析法常用語研究某行為事件的發生 對產品價值的影響以及影響程度,通過研究與事件相關的所有因素來分析用戶行為事件變化的原因。

在日常工作中,運營、市場、產品、數據分析師等不同角色的業務同學,常常根據實際工作情況關注不同的事件、以及事件對應的指標。

例如:上周來自北京的用戶拍攝視頻的去重用戶數是多少?

事件分析是圍繞事件表而來的。描述的是一個用戶在某個時間點、某個地方、以某種方式完成某個具體的事件。

3.3.1.2 漏斗分析

漏斗分析重在過程,現代營銷觀念也認為控制了過程就控制了結果。漏斗分析是流程分析,它能夠反應從起點至終點各階段用戶轉化情況。

狹義上是以用戶為單位將步驟串聯起來,進入后續步驟的用戶,一定是完成了該漏斗前序步驟。廣義上的漏斗分析,僅僅是用漏斗這種形態來描述,即將液體從大口導入,從小口漏出。

例如一款游戲產品 用戶從激活到購買皮膚:激活app、注冊賬號、進入游戲、玩游戲、購買皮膚。

漏斗分析應用:

(1)全流程監控轉化過程:對于業務流程相對規范、周期較長、環節較多的流程分析,能夠直觀地發現問題。

多維度切分找到低轉化的問題點——這里以廣告的點擊,因而關注“廣告的曝光->點擊”的漏斗分析。

(2)通過對比不同渠道的該漏斗過程,可以找到最佳投放廣告的渠道:如下圖展示可以看到baidu的總體轉化率高于全部 6個點,明顯優質。當然實際的場景中,還需要結合更多的價值衡量標準來篩選優質渠道。

(3)對比分析不同用戶群體的漏斗,從差異角度找優化點。這里以新增用戶的關鍵行為轉化過程為例,通過漏斗分析找到用戶群體的差異性,再根據差異性做更細粒度的引導。

關鍵行為的轉化漏斗如下“啟動app->登錄->進入直播間->直播互動->送禮物”,通過對比查看不同國家,發現中國與總體在后兩個轉化中差異大于1%,尤其是在進入直播間->直播互動,當然差異的背后還可以進一步的洞察,更好的利用這個差異點。

3.3.1.3 留存分析

留存分析是一種用來分析用戶參與情況的分析模型,考察進行初始行為的用戶中有多少人會進行后續行為,能有效衡量產品對用戶價值。

通過留存分析,延長用戶的生命周期,增加每一個用戶生命周期價值。針對新用戶,可以描述出由不文明的那個的用戶轉化為活躍用戶、穩定用戶、忠誠用戶的過程。

留存分析可以:

(1)了解新用戶的同期群

上周上線了新版本,目的是提升新用戶留存,通過對比上線前的同期群留存表現,發現新版本沒有明顯變好。

(2)找到目標用戶

長期留存的用戶是忠實度較高的用戶,反過來可以結合用戶屬性分析得到“什么樣”的用戶,自身留存較好。

(3)找到用戶視角的產品核心價值

同一批用戶,通過什么樣的行為后,留存提升了。

留存分析在衡量用戶粘度的時候,還需要結合用戶訪問天數(一定周期內),留存相同的工具型、內容型產品,通常工具型的用戶訪問天數低于內容型的。

3.3.1.4 路徑分析

app日志按照用戶的使用過程、使用頻率,可以呈現出“明確的”用戶現存路徑。通過路徑的指標表現,發現路徑問題,使用戶盡可能短路徑體驗到產品核心價值。

路徑分析可以:

(1)在路徑分析中,常常會發現產品/運營設計之外的使用路徑,尤其是發生在大型產品上。產品、運營均清楚自己負責的模塊,與其他模塊的配合協作過程較模糊,甚至不清晰。

此時的第一反應是“用戶的真實操作是這樣么?怎么會,超出了我當前自己產品的認知”?;谑录氖滦驍祿故?,將能夠解決這個問題。

(2)多維度切分找到關鍵路徑上的用戶群體:如上發生A->B路徑的用戶有誰?他們在對應時間點是如何使用產品的,是在怎樣的網絡條件下?

(3)此外,路徑分析還可以用來展示用戶流向,操作A行為的用戶中有多少流失了,又有多少操作了其他行為,其他行為的占比達致為多少?

3.3.2 報表

流量數據多以報表形式展示。清晰的展示展示關鍵數據,完整的描述數據故事,往往對看板制作有較高要求。

流量數據具有標準的數據結構,這有助于提高流量數據看板制作的效率——通過沉淀常用數據數據分析模型的圖表,快速形成看板。

3.3.3?行為標簽

行為標簽數據是用戶畫像、用戶分群的基礎數據,而流量數據是行為標簽的主要數據來源。行為標簽由于處理方式不同,分為以下幾種:

  • 事實標簽:通常也稱為規則標簽,是基于用戶行為數據和規則產生的標簽,e.g. 無效用戶—“APP啟動后沒有使用核心功能”;新增用戶—“7日內的新增”;
  • 模型標簽:是通過數據模型得到的標簽,e.g. 消費能力高;
  • 預測標簽:和模型標簽一樣,也是通過模型得到,但不同的是預測標簽是對未來的預估,e.g. 潛在流失用戶。

 

本文由 @cecil 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 產品l

    回復
  2. 現在收集用戶數據的工具 有多少是自己企業創建,多數是依靠第三方工具

    回復