作者：李陽? 來源公眾號：數據有毒

GrowingIO、神策、諸葛IO、TalkingData、友盟、Google Analytics for Firebase是數據分析領域廣為人知的幾家綜合性平臺，他們在用戶行為研究與驅動業務增長等多個方面，都提供了豐富的分析工具和技術支持，成為許多知名企業的數據平臺首選。

另一個特點是，我們都將移動場景下的用戶行為分析作為重點之一，而非Web時代的行為分析（這也是Google Analytics for Firebase入選了，而沒有選擇Google Analytics 360的原因）。

在數據分析領域，“巧婦難為無米之炊”這句古話常被提起，用來比喻沒有高質量的數據，就無法進行高質量的分析、得出高質量的結論。而這6家平臺與單純的數據可視化平臺相比，其服務都覆蓋了數據采集的部分，也就是從源頭開始支撐整個數據分析。

因此，這個系列就從一個不太常見又十分重要的角度切入——數據模型，也就是講解一些知名的數據分析平臺究竟收集了哪些數據，以及為什么要收集它們。我將這類內容稱為：數據分析平臺的世界觀。

至于數據分析“出彩”部分，各家也都有自己的側重點——有偏重用戶行為與畫像的、有偏重廣告與商業變現的、也有偏重營銷工具的，各不相同。那么廢話不多說，加下來我們就來探討這幾個數據平臺的“世界觀”。

本文中介紹的所有內容，都來自于這幾家平臺的幫助文檔整理，鏈接如下：

• GrowingIO：https://docs.growingio.com/docs/

• 神策：https://www.sensorsdata.cn/manual/

• 諸葛IO：https://docs.zhugeio.com/

• TalkingData：http://doc.talkingdata.com/

• 友盟：https://developer.umeng.com/docs

• Google Firebase Analytics：https://firebase.google.com/docs/analytics/

如果你對其他平臺感興趣，也歡迎在評論里告訴我，它會加入我的to-do list。

一、這個世界是怎樣的 for 數據分析平臺

這是一個根本性的問題，直接決定了后續的所有內容。就像咱們中國古人，認為世界的基本就是陰和陽而已。陰陽的組合與生化，產生了世界萬物。對于數據分析平臺來說，也會有一些構成世界的基本元素。這些元素之間相互影響、相互作用，演化出了千變萬化的數據分析。

首先，要對GrowingIO、神策和諸葛IO這三位同學加粗標紅地提出表揚！！！

是因為他們仨都很貼心地在文檔中提供了一個叫做“數據模型”的部分，極大的減少了爬API文檔了解邏輯的時間。文檔地址如下：

• GrowingIO：https://docs.growingio.com/docs/data-model/

• 神策：https://www.sensorsdata.cn/manual/data_model.html

• 諸葛IO：https://docs.zhugeio.com/datamanager/data_model.html

另外三家就提供的比較隱晦了，不過多多少少還是能找到相關信息的——這6家平臺都采用了“事件模型”來收集數據。（部分數據是自動收集的，沒有特別明確的數據模型，后邊會詳細列舉。）

在這幾家平臺看來，這個世界就是一大堆錯綜復雜“事件”（Event）而已。用戶是事件的施動者，而每個事件有自己的一些獨有的信息。用一句話概括：有人搞了一些事情，我們來分析一下吧。

這三層之間的關系，是這樣定義的：

• 統計模型基于事件模型

• 事件模型基于用戶模型

其中事件和用戶，我們可以稱之為兩個“實體”（Entity）。他們之間的關系可以用E-R表示為：

二、事件（Event）

對于事件模型，理解事件（Event）這個概念當然是最重要的。那么什么叫一個事件呢？

那些在數據分析中耳熟能詳的用戶行為，都可以叫做一個事件。比如，啟動App、注冊、登陸、瀏覽、轉化（創建訂單、完成支付、發布內容等）、留存、分享、訂閱、收藏等等。

當然，這就存在一個問題了——不同的業務形態，會產生不同的用戶行為。有的關注交易，有的關注UGC內容，有的則只是看用戶的點點劃劃。那么對于這幾家第三方平臺來說，如何給出一套模型能覆蓋所有事件呢？

其實每家平臺會把這些事件分為兩類：那些已經確定的、不管什么業務類型都會需要的事件，當做了“預留事件”（每家的叫法略有差別，比如：在TalkingData指的就是“靈動分析”部分的數據）。比如：打開App、注冊、登陸、瀏覽（PV/UV）等。也就是說，只要接入了這個平臺（并將SDK進行了正確的初始化），就可以收集到這些事件的數據，進行監控和分析。

另一類，就是“自定義事件”（同樣每家的叫法略有差別）。這一類涵蓋的就是與不同的業務類型高度相關的那些事件了，比如：單純的UGC內容平臺，就沒有訂單和支付這些事件；而對于純粹的電商平臺，其關注的核心也不會是超大篇幅的內容產出。這些就應當作為自定義事件。

其中自定義事件是需要在收集之前，先在平臺上“注冊”這些事件的，這也是為了方便對事件進行管理。

但不管是預留事件還是自定義事件，都保留了基本的事件數據結構，一個事件主要包含四部分信息，稱作事件的屬性（E-R圖中與事件連線的橢圓形）：

• 時間信息：這將是時間序列分析中的關鍵，這個信息代表了這個事件是什么時候發生的；

• 用戶信息：這部分主要是為了關聯事情的發動者是誰，以便支持后續從用戶角度開展的分析；

• 事件類型：這也是每個事件的一個基本屬性，比如：App啟動是一個類型，用戶登陸也是一個類型。

• 事件屬性：這部分的定義比較寬泛，所以也留了較大的自由度。比如：我們前面講到的兩個例子，如果是創建訂單的事件，則會包括訂單號、訂單金額、商品編號等等；如果是UGC類型的事件，則可能包括內容發布的板塊、是否原創、引用鏈接等等。

至此，我們可以簡單的理解，所謂“事件”，其實可以就按表面意思理解，就是發生了一些事的概念。而后續在進行分析的時候，就得根據分析的需要，重新整理事件的數據。

三、用戶模型

用戶模型是第二大概念，也是最愛分析的第二大主題。上一段說到在數據收集之后，進行分析的時候，需要重新對數據進行整理，面向用戶的數據匯總就是主要方式之一。通過這樣的匯總，我們得到的是用戶畫像、用戶偏好等這些初步的結論，再進行深入分析。

下面先搞清楚兩類用戶：訪問用戶與登錄用戶。

在用戶模型中，用戶分為兩類：登錄用戶與訪問用戶。

所謂登錄用戶，就是已經注冊并取得了注冊賬號的用戶，比如：我們注冊了QQ就有QQ號，注冊了淘寶有淘寶賬號等等。對于這樣的用戶，正因為他們已經有了一個幾乎不可能改變的賬號，之后所有的行為和屬性信息，都會盡可能地與這個不變的賬號關聯起來。

這引出一個題外話——賬戶體系的重要性。在互聯網社交剛崛起的階段，有很多平臺致力于做統一賬戶。關鍵在于這個跨平臺的賬戶ID關聯了用戶的所有行為，這種方式對于渴望降低CAC、實現交叉引流的平臺有很大幫助。

但對于那些大平臺，就是流量的“凈輸出”方，而且那些初期需要引流的平臺，一定是把第三方賬號關聯到自己的賬戶體系上，這就凸顯了同一賬號的信息中介作用。在大廠開始外推自己的賬戶體系、信息逐漸開始“對稱”起來的時候，統一賬號就沒有存在空間了。

說到用戶注冊和登錄，這就產生了另一個問題：當用戶沒有登陸，甚至還未注冊，那怎么辦呢？

這個時候，ta就是一位訪問用戶了。

那么訪問用戶又是誰呢？

問題就在這——我們不知道TA是誰，TA沒有登陸，我們已經掌握的歷史數據卻都是與注冊賬號相關的。也就是說，這些數據都無法跟這個訪問用戶對應上。

在應用中主要是這兩方面具體問題：

歷史數據關聯問題，特別是與業務有關的數據（比如：訂單），一般都是與注冊賬號ID關聯的，而這個訪問用戶的ID很不穩定，會頻繁變動。

訪問用戶ID的產生依賴于平臺。也就是說，用戶使用同一家的App，在沒登錄的情況下，在iOS、Android和其他平臺上上會被當做是兩個人，這對于數據分析顯然是個災難。

這就好像，我們用身份證買了一張機票，如果你不出示身份證，人家自然不會給你辦理手續，即使用護照或者其他證件也不行。（慘痛的真實經歷…）

當然，在互聯網的領域中從不會“坐以待斃”。對于這樣的“無名氏”用戶，許多平臺已經開始支持記錄和管理歷史訪問設備，也就是你用的手機、平板電腦等設備有自己的ID（比如網卡的MAC地址）。如果某位訪問用戶使用同一部手機打開了App，我們也可以通過手機的設備號近似的關聯到登錄用戶身上。

這種從設備到人的映射關系，有些是在賬號體系中“強管理”的——關聯設備數量有限制，而且需要明確授權。比如：Apple ID。也有“弱管理”的，只是在App中展示一下。更低效的做法，是把關聯的工作放到數據分析階段，再耗費大量計算資源做這個層次的關聯。

至此，簡單理解，登錄用戶=認識，訪問用戶=不認識。

用戶也會有自己的屬性，這些是人們喜聞樂見，喜歡分析的內容。對于一位用戶，屬性包括以下兩種：

基本固定不變的屬性，典型是人口統計學屬性，如性別、年齡段、地理位置等。

通過一定的業務含義加工出來的用戶屬性，典型是用戶分群、用戶標簽屬性。

四、分析

上邊還剩一個“端”的實體，但是其自身的分析價值更偏向技術層面，我們暫時忽略。

分析這部分可能是整篇文章比較吸引人的地方，但其實，說完了前面幾方面的內容，才可以開始將分析。這個時候，能分析什么、怎么分析這類問題，才能落到具體的東西上。

我們回到前面的這張E-R圖：

圖中的實體（用矩形表示）和實體關系（用連線表示）概括了我們要分析的內容。這張圖里有三個主體：端、用戶和事件。這也就意味著，我們的分析過程有三個切入點：產品（內容）自身、用戶自身以及用戶行為。

當然，我們最常分析的，還是產品與用戶關系，以及用戶自身的行為這兩個大主題。而這兩個行為的數據，主要來源于“用戶觸發事件”這個過程。（下邊那些就不是正統的E-R圖了哈，能傳達含義就行。）

1. 統計分析

統計分析是最基本的分析手法了。

要做的基本就是指定一些屬性的值，然后對實體進行計數。比如：我們要求用戶的性別=男性，然后對滿足要求的實體計數。再或者，我們要求事件類型=新增，然后統計事件實體的數量，算出來的就是今日的新增用戶數DNU（隱含一個去重的過程）。

另一類統計分析是分析用戶的行為路徑，比如：用戶從打開App，到最終支付成功，經歷了怎樣的路徑呢？

這就是通過關聯事件實體，并對事件進行統計而得出的，比如下圖這個關系：

2. 歸因分析

?歸因分析需要給發生的事情找到原因，一般的最終目的是通過這種挖掘出來的因果關系，對未來進行預測。比如：如果我們發現了女性用戶更可能購買我們的產品，那么在資源有限的情況下，我們就應當著重向平臺上的女性用戶推廣我們的產品。

另一類例子，就是關于事件和事件之間的，比如經典的“LinkedIn 魔法數字”案例——1周內增加5個社交好友的用戶更容易留存。

針對第一類案例，我們實際上是通過關聯事件實體和用戶實體來實現的：

而對于第二類行為之間的歸因分析，使用過行為之間的交叉來過濾用戶，最終仍舊是通過統計用戶數量來得出結論的：

如果你經手過大數據量，可能已經想到了，這樣的事件統計計算量會非常非常大！在實戰中，更多情況是將這種行為的數量當做用戶的一種屬性，這也就是前面提到的第二類用戶屬性。

修改之后的邏輯如下圖：

但不管哪種分析，都會面臨一個問題——用戶屬性很不穩定，會改變的。比如：用戶的年齡段。在用戶第一次加好友的時候，其年齡段屬性為“21-25歲”，真實年齡為25歲，正處在年齡段交替的時間點；當再次加好友的時候，真實年齡已經變成了26歲，其年齡段屬性也隨之變成了“26-30歲”。

這就產生問題了：當用戶完成了5次社交好友之后，這5次的社交好友應當歸因到“21-25歲”呢？還是歸因到“26-30歲”年齡段呢？

這會直接對我們的分析結論產生影響。

類似的問題也出現在一些其他分析上，比如：用戶的瀏覽行為。當用戶啟動App之后，可能在所有內容之間穿梭很久，最終才決定購買或者其他轉化。

那么，這次轉化究竟應當歸屬于哪些頁面或按鈕呢？

為了避免這種問題，有些平臺（如：GrowingIO）在配置自定義事件時提供了明顯的配置項（稱為“埋點事件”的“歸因方式”）；也有的平臺講這件事的決定權交給了使用者，可以在代碼或者事件定義的過程中給出；更有如Google Analytics for Firebase這樣的平臺，會提供一套專門的“歸因模型”，來處理這類轉化歸因的問題。

關于歸因的問題會單獨整理一部分內容。這部分整理還會衍生出一些其它的思考，比如：你的業務增長，真的應該歸因給社群裂變嗎？

——–[UPDATE 2018-11-21]——–

經評論的同學提醒，關于?GrowingIO?平臺的歸因，這里補充一些詳細信息：

登錄用戶的歸因模型：

【歸因目的】隨著用戶行為的產生，用戶自身的屬性也會跟著改變（比如年齡、地域等），兩個時間段是無法嚴格對齊的，導致一個行為可能對應了多個屬性值（隨時間延續而產生），所以才需要用歸因模型來約定，每個行為具體對應哪個屬性值。官方例子是用戶從銀卡升級為金卡，那么從現在看，用戶在銀卡階段的交易應當歸屬銀卡階段還是金卡階段呢？

【備選方案】兩種方案：最近（只時間間隔最小，歸銀卡）；最終（歸金卡）；

【參考文檔】https://docs.growingio.com/docs/data-definition/user-variable/loginuserid#gui-yin-mo-xing

轉化歸因方式：

【歸因目的】當用戶實際轉化之后，我們會追溯促成轉化的原因。在這個分析過程中，用戶可能歷經了多個活動、多個按鈕和頁面、反復搜索了多個商品等。應當如何認定是哪個事物促成了用戶轉化呢？因此這里還有歸因的邏輯。一個重要的區別在于，“轉化”與單純的“事件”不同，“轉化”通常會對應價值的產生，比如用戶支付。所以這種歸因，不僅僅是建立關系，還要將這種產生的價值，按照一定的分配方式分給所有相關方。

【備選方案】最近（依然是時間間隔最小的含義）、最終和線性（平均分）歸因。同時，官方給出了三種備選方案的應用場景：

• 使用最初歸因模型，某個內部活動帶來了多少注冊，多少訂單。

• 使用線性歸因模型，內部搜索的效果怎樣，某個具體的搜索詞帶來了多少訂單，營業收入。

• 使用最近歸因模型，同一個內部活動的不同入口分別帶來了多少內部活動詳情頁面的瀏覽。

【參考文檔】https://docs.growingio.com/docs/data-definition/custom-event/convert-variable#gui-yin-fang-shi

廣告監測中的歸因邏輯：

【歸因目的】廣告投放與利益綁定的更緊密，但同樣面臨如前所說的“1對多”的困境，而且同樣需要有一定的規則來分配產生的價值。從GrowingIO平臺提供歸因方式判定，更偏重于比較獨立的純粹廣告，而不適用于與業務流程或產品形態深度結合的類推薦流程。如果是深度結合的流程，可以想象Last Click會直接忽略在轉化路徑上的其他影響因素，把轉化歸功于“立即支付”這樣的按鈕。

【備選方案】Last Click（最近點擊）規則 + 反作弊 + 15天時間窗

【參考文檔】https://docs.growingio.com/docs/ads-tracking/app-marketing#4-gui-yin-luo-ji

把此篇文章轉發到朋友圈或產品/運營微信群的小伙伴可以找微信：chanpin628 領取一份WMS原型素材。

此外我們的官方網站也上線了，每日分享高質量的文章、原型素材和行業報告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可點擊底部的閱讀原文直接查看，或者復制網址：www.dadaghp.com?打開。

更多干貨可關注微信公眾號：產品劉

想學習更多關于產品、職場、心理、認知等干貨，可長按右邊二維碼，關注我們。

··················END··················

RECOMMEND

推薦閱讀

我年輕的時候通過跳槽漲工資

面試題，你的興趣愛好是什么？

那些年我得到的職場教訓

線下實戰2.0

點擊“閱讀原文”

查看更多干貨

總結

以上是生活随笔為你收集整理的数据产品经理：6大数据分析平台的“世界观”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。