作者：李陽? 來源公眾號：數(shù)據(jù)有毒

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

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

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

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

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

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

• 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 數(shù)據(jù)分析平臺

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

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

是因為他們仨都很貼心地在文檔中提供了一個叫做“數(shù)據(jù)模型”的部分，極大的減少了爬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家平臺都采用了“事件模型”來收集數(shù)據(jù)。（部分數(shù)據(jù)是自動收集的，沒有特別明確的數(shù)據(jù)模型，后邊會詳細列舉。）

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

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

• 統(tǒng)計模型基于事件模型

• 事件模型基于用戶模型

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

二、事件（Event）

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

那些在數(shù)據(jù)分析中耳熟能詳?shù)挠脩粜袨?#xff0c;都可以叫做一個事件。比如，啟動App、注冊、登陸、瀏覽、轉化（創(chuàng)建訂單、完成支付、發(fā)布內容等）、留存、分享、訂閱、收藏等等。

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

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

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

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

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

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

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

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

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

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

三、用戶模型

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

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

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

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

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

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

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

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

那么訪問用戶又是誰呢？

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

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

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

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

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

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

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

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

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

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

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

四、分析

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

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

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

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

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

1. 統(tǒng)計分析

統(tǒng)計分析是最基本的分析手法了。

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

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

這就是通過關聯(lián)事件實體，并對事件進行統(tǒng)計而得出的，比如下圖這個關系：

2. 歸因分析

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

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

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

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

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

修改之后的邏輯如下圖：

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

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

這會直接對我們的分析結論產(chǎn)生影響。

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

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

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

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

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

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

登錄用戶的歸因模型：

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

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

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

轉化歸因方式：

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

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

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

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

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

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

廣告監(jiān)測中的歸因邏輯：

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

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

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

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

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

更多干貨可關注微信公眾號：產(chǎn)品劉

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

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

RECOMMEND

推薦閱讀

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

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

那些年我得到的職場教訓

線下實戰(zhàn)2.0

點擊“閱讀原文”

查看更多干貨

總結

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

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