本文從一個(gè)不太常見有十分重要的角度切入——數(shù)據(jù)模型，也就是講解一些知名的數(shù)據(jù)分析平臺(tái)究竟收集了哪些數(shù)據(jù)，以及為什么要收集它們。將這類內(nèi)容成為：數(shù)據(jù)分析平臺(tái)的世界觀。

GrowingIO、神策、諸葛IO、TalkingData、友盟、Google Analytics for Firebase是數(shù)據(jù)分析領(lǐng)域廣為人知的幾家綜合性平臺(tái)，他們?cè)谟脩粜袨檠芯颗c驅(qū)動(dòng)業(yè)務(wù)增長(zhǎng)等多個(gè)方面，都提供了豐富的分析工具和技術(shù)支持，成為許多知名企業(yè)的數(shù)據(jù)平臺(tái)首選。

另一個(gè)特點(diǎn)是，我們都將移動(dòng)場(chǎng)景下的用戶行為分析作為重點(diǎn)之一，而非Web時(shí)代的行為分析（這也是Google Analytics for Firebase入選了，而沒有選擇Google Analytics 360的原因）。

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

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

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

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

• 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/

如果你對(duì)其他平臺(tái)感興趣，也歡迎在評(píng)論里告訴我，它會(huì)加入我的to-do list。

一、這個(gè)世界是怎樣的 for 數(shù)據(jù)分析平臺(tái)

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

首先，要對(duì)GrowingIO、神策和諸葛IO這三位同學(xué)加粗標(biāo)紅地提出表揚(yáng)?。?！

是因?yàn)樗麄冐矶己苜N心地在文檔中提供了一個(gè)叫做“數(shù)據(jù)模型”的部分，極大的減少了爬API文檔了解邏輯的時(shí)間。文檔地址如下：

• 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

另外三家就提供的比較隱晦了，不過多多少少還是能找到相關(guān)信息的——這6家平臺(tái)都采用了“事件模型”來收集數(shù)據(jù)。（部分?jǐn)?shù)據(jù)是自動(dòng)收集的，沒有特別明確的數(shù)據(jù)模型，后邊會(huì)詳細(xì)列舉。）

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

這三層之間的關(guān)系，是這樣定義的：

• 統(tǒng)計(jì)模型基于事件模型
• 事件模型基于用戶模型

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

二、事件（Event）

對(duì)于事件模型，理解事件（Event）這個(gè)概念當(dāng)然是最重要的。那么什么叫一個(gè)事件呢？

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

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

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

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

其中自定義事件是需要在收集之前，先在平臺(tái)上“注冊(cè)”這些事件的，這也是為了方便對(duì)事件進(jìn)行管理。

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

• 時(shí)間信息：這將是時(shí)間序列分析中的關(guān)鍵，這個(gè)信息代表了這個(gè)事件是什么時(shí)候發(fā)生的；
• 用戶信息：這部分主要是為了關(guān)聯(lián)事情的發(fā)動(dòng)者是誰，以便支持后續(xù)從用戶角度開展的分析；
• 事件類型：這也是每個(gè)事件的一個(gè)基本屬性，比如：App啟動(dòng)是一個(gè)類型，用戶登陸也是一個(gè)類型。
• 事件屬性：這部分的定義比較寬泛，所以也留了較大的自由度。比如：我們前面講到的兩個(gè)例子，如果是創(chuàng)建訂單的事件，則會(huì)包括訂單號(hào)、訂單金額、商品編號(hào)等等；如果是UGC類型的事件，則可能包括內(nèi)容發(fā)布的板塊、是否原創(chuàng)、引用鏈接等等。

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

三、用戶模型

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

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

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

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

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

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

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

這個(gè)時(shí)候，ta就是一位訪問用戶了。

那么訪問用戶又是誰呢？

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

在應(yīng)用中主要是這兩方面具體問題：

1. 歷史數(shù)據(jù)關(guān)聯(lián)問題，特別是與業(yè)務(wù)有關(guān)的數(shù)據(jù)（比如：訂單），一般都是與注冊(cè)賬號(hào)ID關(guān)聯(lián)的，而這個(gè)訪問用戶的ID很不穩(wěn)定，會(huì)頻繁變動(dòng)。
2. 訪問用戶ID的產(chǎn)生依賴于平臺(tái)。也就是說，用戶使用同一家的App，在沒登錄的情況下，在iOS、Android和其他平臺(tái)上上會(huì)被當(dāng)做是兩個(gè)人，這對(duì)于數(shù)據(jù)分析顯然是個(gè)災(zāi)難。

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

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

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

至此，簡(jiǎn)單理解，登錄用戶=認(rèn)識(shí)，訪問用戶=不認(rèn)識(shí)。

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

1. 基本固定不變的屬性，典型是人口統(tǒng)計(jì)學(xué)屬性，如性別、年齡段、地理位置等。
2. 通過一定的業(yè)務(wù)含義加工出來的用戶屬性，典型是用戶分群、用戶標(biāo)簽屬性。

四、分析

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

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

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

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

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

1. 統(tǒng)計(jì)分析

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

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

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

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

2. 歸因分析

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

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

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

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

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

修改之后的邏輯如下圖：

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

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

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

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

那么，這次轉(zhuǎn)化究竟應(yīng)當(dāng)歸屬于哪些頁面或按鈕呢？

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

關(guān)于歸因的問題會(huì)單獨(dú)整理一部分內(nèi)容。這部分整理還會(huì)衍生出一些其它的思考，比如：你的業(yè)務(wù)增長(zhǎng)，真的應(yīng)該歸因給社群裂變嗎？

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

經(jīng)評(píng)論的同學(xué)提醒，關(guān)于 GrowingIO 平臺(tái)的歸因，這里補(bǔ)充一些詳細(xì)信息：

登錄用戶的歸因模型：

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

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

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

轉(zhuǎn)化歸因方式：

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

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

• 使用最初歸因模型，某個(gè)內(nèi)部活動(dòng)帶來了多少注冊(cè)，多少訂單。
• 使用線性歸因模型，內(nèi)部搜索的效果怎樣，某個(gè)具體的搜索詞帶來了多少訂單，營業(yè)收入。
• 使用最近歸因模型，同一個(gè)內(nèi)部活動(dòng)的不同入口分別帶來了多少內(nèi)部活動(dòng)詳情頁面的瀏覽。

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

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

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

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

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

歸因是什么？在這篇中我們繼續(xù)探討《數(shù)據(jù)產(chǎn)品經(jīng)理：從歸因模型延伸到轉(zhuǎn)化漏斗》?。

本文由 @御豪同學(xué) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議