從數據產品經理視角,聊聊事件模型
上一篇文章寫了埋點以及基礎技術,本篇介紹埋點時常使用的事件模型。
一、事件模型
在傳統的web時代,我們經使用pv、uv來統計某個頁面/某個按鍵的使用情況(如:umeng)。
但隨著數據精細化,產品迭代&數據分析更期望深度分析用戶行為(新老用戶的行為差異、各渠道用戶轉化率、使用app時的行為路徑),另一方面推薦也需要用戶粒度的行為數據以實現精準化,但這些是“基于頁面、按鈕的計數統計”無法得到,因而事件模型由此出現。
簡單來說,事件模型非常像5w2h,它通過(who、when、where、how、what)記錄了誰在某個時間點、某個地方、用某種方式、做了某一件事情(某個行為)。who、when、where、how、what即是事件模型的五個要素。
- Who:即誰參與了這個事件,唯一標識(設備/用戶id),可以是 匿名的設備id(idfa\idfv\android_id\imei\cookie)、也可以是后臺生成的賬戶id(user_id,uid)、也可以是其他【唯一標識】。現在很多公司都有自己的唯一設備id(基于某個策略產生的唯一標識),e.g.阿里有OneId。
- When:即這個事件發生的實際時間。該時間點盡可能精確,有利于行為路徑分析行為排序,像神策會精確到毫秒。
- Where:即事件發生的地點??梢酝ㄟ^ip地址解析國家、省份、城市;如果期望更細致的數據,如果住宅、商業區等,需要額外地理信息數據庫來做匹配。
- How:即用戶用某種方式做了這個事件,也可以理解為事件發生時的狀態。這個包括的就比較多,可以是進入的渠道、跳轉進來的上級頁面、網絡狀態(wifi\4g\3g)、攝像頭信息、屏幕信息(長x寬)等。而如使用的瀏覽器/使用的App,版本、操作系統類型、操作系統版本、進入的渠道等 經常設置為“預設字段”。
- What:即用戶做了什么,也是event模型的主題。這里應該盡可能詳細的描述清楚行為,如搜索(搜索關鍵字、搜索類型)、觀看(觀看類型、觀看時長/進度、觀看對象(視頻id))、購買(商品名稱、商品類型、購買數量、購買金額、 付款方式)等等。
二、事件模型對應埋點文檔
事件模型反映在埋點上報,即觸發一個事件時上報對應日志,記錄who、when、where、how、what。對應的統計文檔,即埋點文檔,在小型創業公司通常是excel來傳遞,有數據平臺部門的公司通常會有專門的維護后臺——埋點管理后臺,以同步埋點的增刪改查看。
上述所說的事件模型的埋點文檔通常會包括:
- 事件類型,像“停/啟動”、“退出app”這種常規事件會設置為預設事件,將自動采集,而非預設事件則可以支持各種業務需求。
- 事件名稱(英文/中文),能夠準確描述事件,區別與其他事件,中文名可以用戶數據后臺顯示。
- 事件參數(英文/中文),能夠準確定義參數,區別與其他事件,不同事件的相同參數盡量保持一致,中文名可以用戶數據后臺顯示。
- 參數值,備注合理參數的范圍,例舉參數的值。
- 類型,參數值記錄的類型。由于不同類型支持數據分析后臺查詢方式不同,比如文本類型可以選擇單個值,數值類型使用區間(大于、小于等),定義參數類型時切記考慮通用性、以及分析后臺的便利性。
- 新增時間(版本),新增該埋點的時間點。
- 刪除時間(版本),刪除該埋點的時間點。
三、日志上報
剛有提到“事件模型反映在埋點上報,即觸發一個事件時上報對應日志,記錄who、when、where、how、what?!?相比行為打包上報(非實時數據),有效減少數據延遲/丟失比例。
非實時的日志上報sdk中,因上報策略不同,即使是同一指標,基于不同的sdk統計到的數據會有差異,常見問題:延遲上報、數據丟失。
上報策略將會影響數據展示,使業務方懷疑數據可信度,如:延遲上報的數據,再次處理后會引起數據回流(e.g.第一天上報90%的行為,相應報表則會基于這90%統計展示;第二天再次上報5%前一天的數據,相應報表則會基于95%統計展示,引起兩個時間點看到的數據不一樣。)
- 實時:用戶行為發生后立即上報;
- 非實時:當一系列的行為都發生后,打包上報、最常見的app退出/下次啟動時上報當次/上一次用戶行為。
當前的事件模型上報日志示例:
{
“uid”:”1234566″ ? ? ? ? ? ? ? ?##唯一標識
“time”:”1534065122″ ? ? ? ?##時間
“type”:”pre” ?????????????????? ???##預設事件
“event”:”start_up” ????????????##事件名稱
parameters:{
“$app_version”:”1.0″? ? ? ? ##預設參數
“$wifi”:”wifi”?????????????? ???##預設參數
“$ip”:”108.66.35.65″? ? ? ?##預設參數
“masterid”:”12345″? ? ? ? ?##事件參數
“masterrate”:”666″? ? ? ? ?##事件參數
“videoid”:”987654321″? ? ##事件參數
“videotype”:”美食”? ? ? ? ? ##事件參數
“videotime”:”100s”? ? ? ##事件參數
“playtime”:”60s” ? ? ? ??? ?##事件參數
}
}
三、事件模型的分析應用
事件模型結合其主體(用戶/設備)的屬性信息可以支持各種分析模型(漏斗分析模型、留存分析模型、路徑分析模型、用戶分群模型)。
用戶屬性常記錄年齡、性別、職業、喜好等不易發生變化的。
(1)事件分析&用戶分群模型:任一事件可以結合預設字段和用戶屬性來統計分析,如 18歲以下的女生在這個事件上的表現,反之也可以得到任一時間在 屬性維度上的分布,如:這個事件觸發用戶的年齡分布、地域分布、機型分布等。
(2)漏斗分析模型&用戶分群模型:分析一個多步驟過程中每一步的轉化與流失情況。結合用戶屬性,可以分析各維度的漏斗,以找到轉化低的瓶頸。例如:不同渠道的注冊漏斗,是否存在某個渠道在某個轉化過程中表現異常。
(3)留存分析模型&用戶分群模型:進行初始行為的用戶中,有多少人還會進行該行為。結合用戶屬性,可以細分群體優化增長、精細化運營活動。
- 新用戶留存:第一次訪問后繼續訪問的用戶占比。
- xxx行為留存率:進行xxx行為的用戶中,有多少人還會進行xxx行為,通常來衡量某個功能的用戶粘度
- xxx行為后,做yyy行為:進行xxx行為的用戶中,有多少人會進行yyy行為。eg.第一天加入購物車的用戶中,在第二天付款的占比。
(4)路徑分析模型&用戶分群模型:則可以清晰的看到訪問當前頁面的所有用戶中,緊接著有多少進入了詳情頁、有多大比例使用了xx/yy功能、有多大比例進入了分類頁面。結合不同屬性的用戶在路徑分析模型上的差異點、待優化點。
此外,基于“事件模型”采集的數據,也更好的服務于:
- 可視化/報表展示;
- 數據分析;
- 實時推薦;
- ab測試等。
本文由 @?cecil 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Pexels,基于 CC0 協議
加個微信可以?
數據產品經理主要做什么呢
“二、事件模型對應埋點文檔”中第五條類型中提到的文本類型和表格中提到的字符類型是同一個概念嗎?
是相同的
寫的非常好,最近讀者我,在做公司APP埋點方案、日志格式,事件模型很有啟發意義……
埋點文檔是數據產品出?
可以加個微信嗎?
可以
看到“事件模型非常像5w2h,它通過(who、when、where、how、what)”,百科一下5W2H分別是what why who when where how howmuch,個人認為嚴謹總是沒錯的
是的,所以是非常像5w2h~
?
好像樓主并沒有按照5W2H來分析啊,少了why ,howmuch ,樓主可以加上在分析下嗎?