1. 數據模型簡介

在神策分析中，我們使用事件模型（Event 模型）來描述用戶在產品上的各種行為，這也是神策分析所有的介面和功能設計的核心依據。

簡單來說，事件模型包括事件（Event）和用戶（User）兩個核心實體，同時配合物品（Item）實體可以做各種維度分析，在神策分析中，分別提供了介面供使用者上傳和修改這兩類相應的數據，在使用產品的各個功能時，這兩類數據也可以分別或者貫通起來參與具體的分析和查詢。對這兩個概念，我們會在後文做具體的描述。

1.1. Event Model Vs. Page View

在傳統的 Web 時代，通常使用 PV（Page View 的簡寫，也即頁面訪問量）來衡量和分析一個產品的好壞，然後，到了移動互聯網以及 O2O 電商時代，PV 已經遠遠不能滿足產品和營運人員的分析需求了。

在這個年代，每個產品都有著獨一無二的核心指標用來衡量產品是否成功，這個指標可能是發文數量、影片播放數量、訂單量或者其它的可以體現產品核心價值的指標，這些都是一個簡單的 PV 無法衡量的。

除此之外，PV 模型也無法滿足一些更加細節的、更加精細化的分析。例如，我們想分析哪類產品銷量最好，訪問網站的用戶的年齡和性別構成，每個管道過來的用戶的轉化率、留存和重複購買率分別如何，新老用戶的客單價、流水、補貼比例分別是多少等等。這些問題，都是以 PV 為核心的傳統統計分析沒辦法解答的問題。

因此，神策分析採用事件模型作為基本的數據模型。事件模型可以給我們更多的資訊，讓我們知道用戶用我們的產品具體做了什麼事情。事件模型給予我們更全面且更具體的視野，指導我們做出更好的決策。

當然，採用神策分析的事件模型，依然是可以完成 PV 統計的，並且實現起來也很簡單，使用 SDK 或者匯入工具上傳一個類似的介面即可：

{
    "distinct_id": "2b0a6f51a3cd6775",
    "time": 1434556935000,
    "type": "track",
    "event": "PageView",
    "properties": {
        "$ip" : "180.79.35.65",
        "user_agent" : "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.）",
        "page_name" : "網站首頁",
        "url" : "www.demo.com",
        "referer" : "www.referer.com"
    }
}
CODE

1.2. Event 實體

1.2.1. Event 的五要素

簡單來說，一個 Event 就是描述了：一個用戶在某個時間點、某個地方，以某種方式完成了某個具體的事情。從這可以看出，一個完整的 Event，包含如下的幾個關鍵因素：

  • Who：即參與這個事件的用戶是誰。在我們的數據介面中，使用 distinct_id 來設定用戶的唯一 ID：對於未登入用戶，這個 ID 可以是 cookie_id、裝置 ID 等匿名 ID；對於登入用戶，則建議使用後台分配的實際用戶 ID。同時，我們也提供了 track_signup 這個介面，在用戶註冊的時候呼叫，用來將同一個用戶註冊之前的匿名 ID 和註冊之後的實際 ID 貫通起來進行分析。
  • When：即這個事件發生的實際時間。在我們的數據介面中，使用 time 欄位來記錄精確到毫秒的事件發生時間。如果呼叫者不主動設定，則各個 SDK 會自動獲取當前時間作為 time 欄位的取值。
  • Where：即事件發生的地點。使用者可以設定 properties 中的 $ip 屬性，這樣系統會自動根據 ip 來解析相應的省份和城市，當然，使用者也可以根據應用的 GPS 定位結果，或者其它方式來獲取地理位置資訊，然後手動設定 $city 和 $province。除了 $city 和 $province 這兩個預設欄位以外，也可以自己設定一些其它地域相關的欄位。例如，某個從事社區 O2O 的產品，可能需要關心每個小區的情況，則可以增加自定義欄位 “HousingEstate”；或者某個從事跨國業務的產品，需要關心不同國家的情況，則可以增加自定義欄位 “Country”。

  • How：即用戶從事這個事件的方式。這個概念就比較廣了，包括用戶使用的裝置、使用的瀏覽器、使用的 App 版本、操作系統版本、進入的管道、跳轉過來時的 referer 等，目前，神策分析預設了如下欄位用來描述這類資訊，使用者也可以根據自己的需要來增加相應的自定義欄位。

    $app_version：應用版本
$city： 城市
$manufacturer： 裝置製造商，字串型別，如"Apple"
$model： 裝置型號，字串型別，如"iphone6"
$os： 作業系統，字串型別，如"iOS"
$os_version： 作業系統版本，字串型別，如"8.1.1"
$screen_height： 螢幕高度，數值型別，如1920
$screen_width： 螢幕寬度，數值型別，如1080
$wifi： 是否 WIFI，BOOL型別，如true
    CODE
  •  What：描述用戶所做的這個事件的具體內容。在我們的數據介面中，首先是使用 event 這個事件名稱，來對用戶所做的內容做初步的分類。event 的劃分和設計也有一定的指導原則，我們會在後文詳細描述。除了 event 這個至關重要的欄位以外，我們並沒有設定太多預設欄位，而是請使用者根據每個產品以及每個事件的實際情況和分析的需求，來進行具體的設定，下面給出一些典型的例子：
    - 對於一個“購買”類型的事件，則可能需要記錄的欄位有：商品名稱、商品類型、購買數量、購買金額、 付款方式等；
    - 對於一個“搜尋”類型的事件，則可能需要記錄的欄位有：搜尋關鍵詞、搜尋類型等；
    - 對於一個“點擊”類型的事件，則可能需要記錄的欄位有：點擊 URL、點擊 title、點擊位置等；
    - 對於一個“用戶註冊”類型的事件，則可能需要記錄的欄位有：註冊管道、註冊邀請碼等；
    - 對於一個“用戶投訴”類型的事件，則可能需要記錄的欄位有：投訴內容、投訴對象、投訴管道、投訴方式等；
    - 對於一個“申請退貨”類型的事件，則可能需要記錄的欄位有：退貨金額、退貨原因、退貨方式等。

1.2.2. Event 的劃分和欄位設計原則

為了更好地使用神策分析提供的強大、便捷的分析功能，我們強烈建議使用者花費一定的時間，梳理自己的數據使用需求，並據此做好 Event 的劃分和欄位設計。

在 Event 的劃分和設計過程中，神策分析團隊也會提供相應的技術支援和服務，除此之外，我們將一些基本的原則也在這裡整理出來，期望對使用者有所幫助。

1.2.2.1. 用戶端埋點 Vs. 在後端記錄 Event

友盟、百度統計等傳統分析工具，都是在用戶端嵌入 SDK 進行埋點，但是，我們強烈推薦 在後端記錄 Event，這是出於以下一些考慮：

  1. 很多行為，如下單等，他們的很多欄位在前端（App 和 Web 界面）是拿不到的。甚至有些行為，如用戶線下消費等，前端根本就沒有提供相應的功能，就更拿不到對應的數據。
  2. 後端修改程序更加方便便捷，如果是在 App 端記錄數據，則每次修改都需要等待 App 的發版和用戶更新；
  3. App 端收集數據會有丟失的風險，並且上傳數據也不及時。App 端為了避免浪費用戶的流量，一般情況下，都是將多條數據打包，並且等待網絡狀況良好以及應用處於前台時才壓縮上傳，因此，自然會造成上傳數據不及時，很有可能某一天的數據會等待好幾天才傳到伺服器端，這自然會導致每天的指標都計算有偏差。同時，由於 App 端可以快取的內容有限，用戶裝置的網絡連接等問題，App 端收集的數據目前也沒有太好的手段保證 100% 不丟失。 

基於以上幾點考慮，除非某個行為只在前端發生，對後端沒有任何請求，否則，我們建議永遠只在後端收集數據。

1.2.2.2. Event 的劃分原則

對產品劃分 Event，我們有如下的一些建議：

  1. 為了節約使用成本，應該從需求出發，只記錄那些會分析到的 Event，這一點是與傳統的 PV 分析產品一個很大的不同。記錄 Event 是為了詳細地了解用戶是如何使用產品的，對於暫時不會分析到的那些使用情況，可以暫時先不記錄。
  2. Event 的數量不應過多，對於一個典型的用戶產品，Event 的數量以不超過 20 個為宜。當然，這個只是我們對事件設計的一些原則性的建議，系統本身並沒有這方面的限制。一些類似的用戶操作，可以合併成一個 Event。例如，假設某個產品比較關心對一系列商品分類頁的訪問情況，那麼，並不意味著每個商品分類頁點擊就應該劃分成一個單獨的 Event，而是可以劃分出一個單獨的商品分類頁訪問 Event，然後再將不同的分類以欄位的形式進行記錄。
  3. Event 不僅侷限於用戶在 App、Web 界面等前端的操作和使用，一些其它類型的用戶行為，例如用戶的電話投訴、用戶在線下接收服務、用戶在線下商家進行消費等，如果能夠獲取到相應的數據，並且數據分析也會用到，則也可以作為相應的 Event。

1.2.2.3. 欄位設計原則

為每個 Event 進行欄位設計，我們有如下的一些建議：

  1. 先根據需求梳理分析的指標和維度，然後再從指標和維度倒推需要在每個 Event 記錄的欄位。
  2. 神策分析是一個數據分析工具，並不是一個日誌儲存和備份系統，所以，一些用不到的欄位，例如 Cookie 的完整內容、後端請求傳回碼等，就沒有必要作為一個 Event 的欄位來進行記錄和收集了。
  3. 預設欄位中已經有的欄位，則建議儘量複用預設欄位。對所有預設欄位的說明，可以參看 數據格式 中的相應說明。
  4. 某個 Event 的某個欄位的設計一旦確定，則不要再修改它的型別和取值含義。例如，一開始對於"Buy"這個 Event，我們設計了一個數值型別的欄位 Money，描述這個購買行為對應的購買金額是多少元，然而後面我們期望把它改成分，那麼我們建議不如廢棄掉 Money 欄位並且增加一個新的欄位叫 MoneyByCents，而不是去改變 Money的含義。

1.3. User 實體

1.3.1. 記錄和收集 User Profile

每個 User 實體對應一個真實的用戶，用 distinct_id 進行標識，描述用戶的長期屬性（也即 Profile），並且透過 distinct_id 與這個用戶所從事的行為，也即 Event 進行關聯。

神策分析提供了一系列 profile_xxx 類型的介面，用來對某個 user 的 Profile 進行記錄和修改。

一般記錄 User Profile 的場所，是用戶進行註冊、完善個人資料、修改個人資料等幾種有限的場合，與 Event 類似，我們也強烈建議 在後端記錄和收集 User Profile。

應該收集哪些欄位作為 User Profile，也完全取決於產品形態以及分析需求。簡單來說，就是在能夠拿到的那些用戶屬性中，哪些對於分析有幫助，則作為 Profile 進行收集。

1.3.2. 欄位記錄在 Profile 還是 Event 的取捨

有些時候，我們可能會糾結，某個與用戶相關的欄位是應該記錄在 Profile 還是記錄在 Event，一個基本的原則就是，Profile 記錄的是用戶的基本固定不變的屬性，例如性別、出生年份（請注意，記錄的不是年齡而是出生年份）、註冊時間、註冊地域、註冊管道等。而還有一些欄位，例如用戶級別、裝置類型、地域、是否是 Vip 等，雖然也是用戶相關的欄位，但是可能是會經常變化的，則應該在用戶的某個 Event 發生的時候，作為 Event 的一個欄位來進行記錄。

1.4. Item 實體

神策 1.14 開始支援 Item 實體。

在 Event-User 模型中，出於性能和可解釋性等各方面的考慮，Event 是被設計為不可變的。從邏輯上看似乎沒有問題，因為 Event 代表的是歷史上已經發生過的事件，一般來說不應該需要進行更新。

但是，在實際的應用過程中，並不一定是這麼理想的狀態。

如，在採集和分析中會發現：

  • Event 實體中一些基本資訊中會有許多是不斷變化的
  • 埋點採集中，發現某些 Event 在最初的階段採集到的數據不完善。  

這時，可透過 Item 實體對 Event-User 模型進行補充。

這裡的所謂 Item，在嚴格意義上是指一個和用戶行為相關聯的實體，可能是一個商品、一個影片劇集、一部小說等等。Item 的應用場景有很多，下面介紹兩個最常見的應用場景。

1.4.1. 神策分析系統中的 Item 應用

Item 模型的一個典型場景是用作神策分析的維度表，具體的使用請參考文件 虛擬屬性和維度表

1.4.2. 神策推薦系統中的 Item 應用

想了解神策推薦服務的更多細節，請聯繫神策技術支援。

神策推薦核心價值是計算用戶最有可能消費的物品（即 Item），並以推薦結果傳回到產品前端供用戶消費。神策推薦系統會以 Item 數據為基礎構建推薦物品的畫像（高維向量），計算用戶最有可能消費的物品或者相似物品。

在對接神策推薦系統時，開發者需要透過 SDK 的 itemSet 系列介面來上傳數據，同時神策也提供了管理後台對 Item 表進行直接的管理，例如管理員可以對某條待推薦的 Item 進行封鎖或者調整權重以優化推薦效果。