上一篇文章寫了埋點以及基礎技術，本篇介紹埋點時常使用的事件模型。

一、事件模型

在傳統的web時代，我們經使用pv、uv來統計某個頁面/某個按鍵的使用情況（如：umeng）。

但隨著數據精細化，產品迭代&數據分析更期望深度分析用戶行為（新老用戶的行為差異、各渠道用戶轉化率、使用app時的行為路徑），另一方面推薦也需要用戶粒度的行為數據以實現精準化，但這些是“基于頁面、按鈕的計數統計”無法得到，因而事件模型由此出現。

簡單來說，事件模型非常像5w2h，它通過（who、when、where、how、what）記錄了誰在某個時間點、某個地方、用某種方式、做了某一件事情（某個行為）。who、when、where、how、what即是事件模型的五個要素。

1. Who：即誰參與了這個事件，唯一標識（設備/用戶id），可以是 匿名的設備id（idfa\idfv\android_id\imei\cookie）、也可以是后臺生成的賬戶id（user_id,uid）、也可以是其他【唯一標識】?，F在很多公司都有自己的唯一設備id（基于某個策略產生的唯一標識），e.g.阿里有OneId。
2. When：即這個事件發生的實際時間。該時間點盡可能精確，有利于行為路徑分析行為排序，像神策會精確到毫秒。
3. Where：即事件發生的地點?？梢酝ㄟ^ip地址解析國家、省份、城市；如果期望更細致的數據，如果住宅、商業區等，需要額外地理信息數據庫來做匹配。
4. How：即用戶用某種方式做了這個事件，也可以理解為事件發生時的狀態。這個包括的就比較多，可以是進入的渠道、跳轉進來的上級頁面、網絡狀態（wifi\4g\3g）、攝像頭信息、屏幕信息（長x寬）等。而如使用的瀏覽器/使用的App，版本、操作系統類型、操作系統版本、進入的渠道等 經常設置為“預設字段”。
5. What：即用戶做了什么，也是event模型的主題。這里應該盡可能詳細的描述清楚行為，如搜索（搜索關鍵字、搜索類型）、觀看（觀看類型、觀看時長/進度、觀看對象（視頻id））、購買（商品名稱、商品類型、購買數量、購買金額、 付款方式）等等。

二、事件模型對應埋點文檔

事件模型反映在埋點上報，即觸發一個事件時上報對應日志，記錄who、when、where、how、what。對應的統計文檔，即埋點文檔，在小型創業公司通常是excel來傳遞，有數據平臺部門的公司通常會有專門的維護后臺——埋點管理后臺，以同步埋點的增刪改查看。

上述所說的事件模型的埋點文檔通常會包括：

1. 事件類型，像“停/啟動”、“退出app”這種常規事件會設置為預設事件，將自動采集，而非預設事件則可以支持各種業務需求。
2. 事件名稱（英文/中文），能夠準確描述事件，區別與其他事件，中文名可以用戶數據后臺顯示。
3. 事件參數（英文/中文），能夠準確定義參數，區別與其他事件，不同事件的相同參數盡量保持一致，中文名可以用戶數據后臺顯示。
4. 參數值，備注合理參數的范圍，例舉參數的值。
5. 類型，參數值記錄的類型。由于不同類型支持數據分析后臺查詢方式不同，比如文本類型可以選擇單個值，數值類型使用區間（大于、小于等），定義參數類型時切記考慮通用性、以及分析后臺的便利性。
6. 新增時間（版本），新增該埋點的時間點。
7. 刪除時間（版本），刪除該埋點的時間點。

三、日志上報

剛有提到“事件模型反映在埋點上報，即觸發一個事件時上報對應日志，記錄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功能、有多大比例進入了分類頁面。結合不同屬性的用戶在路徑分析模型上的差異點、待優化點。

此外，基于“事件模型”采集的數據，也更好的服務于：

1. 可視化/報表展示；
2. 數據分析；
3. 實時推薦；
4. ab測試等。

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

題圖來自 Pexels，基于 CC0 協議