神策數(shù)據(jù)技術(shù)VP付力力親述產(chǎn)品架構(gòu)演變：變與不變的背后思考

　 域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

本文作者：付力力，神策數(shù)據(jù)聯(lián)合創(chuàng)始人&技術(shù)VP

付力力畢業(yè)于北京理工大學(xué)軟件工程專(zhuān)業(yè)，2008年至2013年期間歷任百度新產(chǎn)品研發(fā)部、網(wǎng)頁(yè)搜索部、基礎(chǔ)架構(gòu)部工程師。2013年9月年至2014年8月?lián)瓮愣骨v數(shù)據(jù)部門(mén)資深研發(fā)工程師。2014年9月至2015年4月?lián)吸S金錢(qián)包技術(shù)合伙人。2018年8月，榮登“2018福布斯中國(guó)30歲以下精英榜”。

2015年9月神策數(shù)據(jù)正式發(fā)布了神策分析1.0版本，在隨后的3年里，我們的產(chǎn)品研發(fā)團(tuán)隊(duì)一直在不斷地進(jìn)行版本迭代，到目前為止一共發(fā)布了12個(gè)大版本。

相比于最初的1.0版本，現(xiàn)在的神策分析無(wú)論是在產(chǎn)品體驗(yàn)還是在底層架構(gòu)上都已經(jīng)發(fā)生了很大的變化：

從最初只能使用3個(gè)單薄的基礎(chǔ)分析功能，到現(xiàn)在支持10個(gè)分析模型聯(lián)合構(gòu)建的場(chǎng)景化分析能力;從最初只能支持每天數(shù)萬(wàn)日活的小App，到現(xiàn)在可以輕松應(yīng)對(duì)一天產(chǎn)生數(shù)百億的數(shù)據(jù)量巨型App。

而另一方面，3年內(nèi)，神策分析里也有很多地方?jīng)]有改變：

例如，從第一版的設(shè)計(jì)里就確定了模型的Event-User，該模型現(xiàn)在依然是整個(gè)神策分析里最基礎(chǔ)和重要的概念。

在這篇文章里，我給大家介紹神策分析最近在底層架構(gòu)上一些比較大的設(shè)計(jì)改進(jìn)，同時(shí)也會(huì)分享我們?cè)谶@些架構(gòu)設(shè)計(jì)中關(guān)于“變”與“不變”的思考。

一、從SQL查詢(xún)引擎到用戶(hù)行為分析引擎

我們之前在很多場(chǎng)合都對(duì)神策分析的底層架構(gòu)做過(guò)詳細(xì)的介紹，這個(gè)架構(gòu)的主要特點(diǎn)之一是：

神策所有的分析結(jié)果都是從明細(xì)數(shù)據(jù)實(shí)時(shí)查詢(xún)得出，而不是基于大多數(shù)分析系統(tǒng)所使用的預(yù)計(jì)算技術(shù)，之所以這么設(shè)計(jì)，因?yàn)槲覀兿Ｍ到y(tǒng)數(shù)據(jù)分析能力的上限在于數(shù)據(jù)本身。

換句話(huà)說(shuō)，我們期望只要是從已經(jīng)采集的數(shù)據(jù)里可以分析得到的結(jié)論，神策都希望可以幫助我們的客戶(hù)很容易的實(shí)現(xiàn)。

從結(jié)果看來(lái)，這種架構(gòu)設(shè)計(jì)的好處是非常顯著的：

它大大簡(jiǎn)化了整個(gè)系統(tǒng)的數(shù)據(jù)流，我們不需要為不同的分析模型來(lái)維護(hù)復(fù)雜的聚合表，并在數(shù)據(jù)回溯的時(shí)候保持這些數(shù)據(jù)之間的一致性(大多數(shù)類(lèi)似的數(shù)據(jù)系統(tǒng)里要么拋棄數(shù)據(jù)回溯的能力，要么放棄數(shù)據(jù)一致性)。

受益于這種架構(gòu)，我們?cè)诤芏痰臅r(shí)間內(nèi)推出眾多靈活的分析模型，并且這些分析模型之間可以通過(guò)分群等方式來(lái)進(jìn)行自由的組合查詢(xún)。

同時(shí)，配合我們開(kāi)發(fā)的查詢(xún)緩存機(jī)制，這套架構(gòu)也可以在報(bào)表等相對(duì)固定的數(shù)據(jù)分析需求上得到比較好的使用體驗(yàn)。

當(dāng)然，這種設(shè)計(jì)的另外一個(gè)結(jié)果是，神策分析很明確地拋棄了對(duì)高QPS查詢(xún)需求的直接支持(例如不應(yīng)該嘗試在商品詳情頁(yè)里直接從神策分析獲取這個(gè)商品本周的銷(xiāo)量)。

不過(guò)，整體上我們認(rèn)為，犧牲一個(gè)非必要的特性來(lái)?yè)Q取數(shù)倍的分析靈活性以及一個(gè)簡(jiǎn)單可維護(hù)的架構(gòu)，是一個(gè)非常劃算的選擇。

在這套架構(gòu)里，Impala作為我們使用的數(shù)據(jù)查詢(xún)引擎，可以說(shuō)是一個(gè)非常核心的模塊。

在最初的設(shè)計(jì)選型上我們選擇Impala，一方面是因?yàn)镮mpala已經(jīng)是一個(gè)相對(duì)比較成熟的MPP架構(gòu)的查詢(xún)引擎，而且對(duì)SQL有著比較良好的支持。另外一方面則是因?yàn)槲覀兊难邪l(fā)團(tuán)隊(duì)在Impala的使用和二次開(kāi)發(fā)上有著比較多的經(jīng)驗(yàn)。

其中，是否支持SQL是一個(gè)很重要的選型依據(jù)。雖然SQL是一種有著幾十年歷史、至今也沒(méi)有太多變化的古老工具，但是到目前為止它依然是對(duì)表格數(shù)據(jù)進(jìn)行操作的最佳選擇，在易用性和靈活性之間做到了比較好的平衡。

更重要的是，我們當(dāng)初經(jīng)過(guò)簡(jiǎn)單的調(diào)研發(fā)現(xiàn)，只使用SQL就可以很好的實(shí)現(xiàn)一個(gè)用戶(hù)行為分析系統(tǒng)的大部分需求，除此之外，還可以通過(guò)UDF/UDAF/UDAnF等增加擴(kuò)展能力，則幾乎可以滿(mǎn)足所有常見(jiàn)需求。

事實(shí)上，在神策分析比較早期的版本里，所有的分析模型都是用標(biāo)準(zhǔn)SQL直接實(shí)現(xiàn)的。

隨著我們產(chǎn)品功能的增加，我們?yōu)榱藵M(mǎn)足越來(lái)越復(fù)雜的分析模型和更高的性能指標(biāo)，也對(duì)Impala做了很多改造。

不過(guò)，在這個(gè)過(guò)程中，SQL自身的描述能力和Impala執(zhí)行架構(gòu)的局限性也逐漸暴露出來(lái)，例如我們很難像Spark的DAG模型一樣來(lái)靈活的控制SQL的查詢(xún)計(jì)劃，導(dǎo)致一些復(fù)雜查詢(xún)的性能不佳，以及在一些組合分析的場(chǎng)景下沒(méi)有辦法很容易的復(fù)用查詢(xún)的中間結(jié)果。

因此，我們開(kāi)始基于Impala構(gòu)建一個(gè)全新的查詢(xún)引擎。通過(guò)對(duì)已有的各種分析模型計(jì)算過(guò)程的理解，我們發(fā)現(xiàn)它們幾乎都可以被抽象為如下的計(jì)算過(guò)程：

1.篩選出特定時(shí)間范圍內(nèi)的特定Event數(shù)據(jù)，如果查詢(xún)還涉及到User/Item，那么還需要再次進(jìn)行Join操作，最終得到：List;

2.對(duì)List按照Event中的用戶(hù)ID進(jìn)行Shuffle，并按時(shí)間排序，最終得到每個(gè)用戶(hù)ID的有序Event序列：(User Id,List);

3.對(duì)(User Id,List)中的每個(gè)UserId的List應(yīng)用具體的分析模型規(guī)則，例如漏斗、留存等，得出每個(gè)用戶(hù)ID的中間計(jì)算結(jié)果，如下：(User Id,IntermediateResult);

4.對(duì)(User Id,IntermediateResult)進(jìn)行最后一次聚合，得到最終的結(jié)果。

不難看出，上述計(jì)算過(guò)程中最核心的難點(diǎn)在于如何快速的得到(User Id,List)，這中間可能涉及重排序和大數(shù)據(jù)量的Shuffle等操作。對(duì)于需要Join User/Item表的查詢(xún)，Join本身的性能也可能會(huì)成為瓶頸。

我們基于Impala原有的執(zhí)行框架，在底層存儲(chǔ)和查詢(xún)邏輯上做了一系列的優(yōu)化，最終實(shí)現(xiàn)的分析引擎相比于原有的方式在復(fù)雜查詢(xún)的執(zhí)行性能上有10x的提升，同時(shí)由于開(kāi)發(fā)方式的簡(jiǎn)化，也直接加速了我們對(duì)各種復(fù)雜分析模型的迭代速度。

在后續(xù)的文章中，我們會(huì)詳細(xì)介紹這個(gè)面向用戶(hù)行為分析的查詢(xún)引擎的具體優(yōu)化細(xì)節(jié)。

二、模型擴(kuò)展：從Event-User到Event-Item-User

在神策分析最初的設(shè)計(jì)階段，我們就確定了以Event-User為核心的邏輯數(shù)據(jù)模型，可以說(shuō)，Event-User模型是整個(gè)神策分析架構(gòu)的基礎(chǔ)。

3年以來(lái)，神策分析在數(shù)百家不同行業(yè)的客戶(hù)的實(shí)踐結(jié)果也充分證明了這個(gè)模型的適應(yīng)能力。

所有的數(shù)據(jù)模型本質(zhì)上都是對(duì)現(xiàn)實(shí)世界的抽象，而在抽象之后必然會(huì)損失一些對(duì)現(xiàn)實(shí)世界的還原能力。

所以Event-User模型雖然在電商、金融、在線(xiàn)教育、互聯(lián)網(wǎng)娛樂(lè)、企業(yè)服務(wù)等不同的行業(yè)上都發(fā)揮了很好的價(jià)值，但是隨著客戶(hù)需求的不斷深入，尤其是在和具體行業(yè)業(yè)務(wù)的深入融合中，我們也逐漸發(fā)現(xiàn)了這個(gè)模型的一些缺點(diǎn)。

例如在Event-User模型中，出于性能和可解釋性等各方面的考慮，Event是被設(shè)計(jì)為不可變的。從邏輯上看似乎沒(méi)有問(wèn)題，因?yàn)镋vent代表的是歷史上已經(jīng)發(fā)生過(guò)的事件，一般來(lái)說(shuō)不應(yīng)該需要進(jìn)行更新。

但是，在實(shí)際的應(yīng)用過(guò)程中，并不一定是這么理想的狀態(tài)。

例如，在很多客戶(hù)進(jìn)行埋點(diǎn)采集的過(guò)程中，他們會(huì)發(fā)現(xiàn)某些Event在最初的階段并不能很容易的采集到完整的數(shù)據(jù)。

比如一個(gè)電商客戶(hù)，在客戶(hù)端App里采集“商品加入購(gòu)物車(chē)”事件時(shí)，只能采集到商品的ID、名稱(chēng)等基本信息，而對(duì)于后續(xù)分析需要的更多維度，例如商品的分類(lèi)、促銷(xiāo)的活動(dòng)信息等等，則不一定能很容易的采集到(通常這些信息都是客戶(hù)端在業(yè)務(wù)中沒(méi)有使用到的，如果想要采集，則需要對(duì)服務(wù)端API、客戶(hù)端內(nèi)部的信息傳遞都做比較大的修改)。

又或者是等到真正需要分析的時(shí)候，才發(fā)現(xiàn)當(dāng)初的采集是不完備的，這個(gè)時(shí)候想再把歷史數(shù)據(jù)補(bǔ)上就是一件非常困難的事情。

還有另外一種比較常見(jiàn)的場(chǎng)景。某個(gè)在線(xiàn)教育的App中會(huì)有很多和課程相關(guān)的事件，例如對(duì)課程的瀏覽、購(gòu)買(mǎi)、學(xué)習(xí)等，而關(guān)于課程的一些基本信息中會(huì)有許多是不斷變化的，如課程的分類(lèi)、定價(jià)等等。

在Event里記錄的，應(yīng)當(dāng)是Event發(fā)生的時(shí)刻這個(gè)課程的狀態(tài)，例如一個(gè)購(gòu)買(mǎi)課程的事件，我們可以記錄下來(lái)當(dāng)時(shí)課程的分類(lèi)、價(jià)格屬性，作為Event的一部分。而課程的分類(lèi)、定價(jià)后續(xù)可能會(huì)隨著業(yè)務(wù)的需要隨時(shí)調(diào)整，如果業(yè)務(wù)方希望按照最新的(或者某個(gè)特定階段的)課程分類(lèi)或者定價(jià)來(lái)分析用戶(hù)的歷史行為，則是一個(gè)難以完成的需求。

從技術(shù)上來(lái)看，解決上述問(wèn)題的方案并不復(fù)雜。很多熟悉數(shù)據(jù)倉(cāng)庫(kù)的朋友可能會(huì)發(fā)現(xiàn)，這些其實(shí)是在傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)里比較典型的維度表的問(wèn)題，可以使用經(jīng)典的雪花模型或者星型模型來(lái)輕松解決。

但是，我們并不希望引入這么復(fù)雜的模型，畢竟神策分析的設(shè)計(jì)目標(biāo)并不是一個(gè)通用的數(shù)據(jù)倉(cāng)庫(kù)。雖然靈活性是神策分析最核心的設(shè)計(jì)目標(biāo)之一，但也是建立在"用戶(hù)行為分析"這個(gè)目標(biāo)的基礎(chǔ)之上的。

我們期望的一個(gè)理想方式是：對(duì)數(shù)據(jù)模型增加一點(diǎn)有限的復(fù)雜性，但是可以給整個(gè)系統(tǒng)帶來(lái)十倍甚至百倍的靈活性提升。

為了滿(mǎn)足上述需求，我們?cè)谛掳娴纳癫叻治鲋袑?duì)Event-User模型進(jìn)行了擴(kuò)展，引入了Item的概念。這里的所謂Item，在嚴(yán)格意義上是指一個(gè)和用戶(hù)行為相關(guān)聯(lián)的實(shí)體，可能是一個(gè)商品、一個(gè)視頻劇集、一部小說(shuō)等等。

如果不嚴(yán)格約束的話(huà)，理論上它也可以存儲(chǔ)其它任意的擴(kuò)展維度信息。

在具體的技術(shù)實(shí)現(xiàn)上，我們?cè)试S客戶(hù)定義多個(gè)不同的Item實(shí)體，例如電商有商品、配送點(diǎn)等不同的實(shí)體。

在使用前，客戶(hù)要定義這些實(shí)體，并且把這些實(shí)體的數(shù)據(jù)通SDK發(fā)送到神策分析系統(tǒng)中，自動(dòng)建立起一個(gè)或者多個(gè)Item表。然后，出于不同性能要求和業(yè)務(wù)需求的考慮，對(duì)于Item表的使用我們提供了不同的兩種方式。

第一種方式，客戶(hù)在進(jìn)行Event埋點(diǎn)時(shí)，可以選擇要進(jìn)行關(guān)聯(lián)導(dǎo)入的Item信息。

例如有一個(gè)“商品加入購(gòu)物車(chē)”的事件，這個(gè)事件里只采集了“商品ID”，但是同時(shí)因?yàn)槲覀兪孪纫呀?jīng)定義好了“商品Item”，那么通過(guò)“商品ID”則直接可以先把Event和“商品Item”進(jìn)行關(guān)聯(lián)，再把“商品Item”的某一些屬性作為Event的一部分進(jìn)行直接導(dǎo)入。

使用這種方式，可以在最大程度滿(mǎn)足業(yè)務(wù)分析的情況下簡(jiǎn)化客戶(hù)端對(duì)數(shù)據(jù)采集的工作，同時(shí)在查詢(xún)性能方面也不會(huì)有任何下降。

第二種方式，更類(lèi)似于傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)的維度表。

我們?cè)诼顸c(diǎn)時(shí)不做任何變動(dòng)，而是在需要進(jìn)行查詢(xún)的時(shí)候，把Item表加入進(jìn)來(lái)。

這種方式會(huì)有更好的靈活性，因?yàn)榭梢栽贓vent發(fā)生之后對(duì)數(shù)據(jù)進(jìn)行擴(kuò)展，也可以支持隨時(shí)使用最新的Item數(shù)據(jù)進(jìn)行分析，但是另外一方面，這么做并不能很好的保留事件發(fā)生當(dāng)時(shí)的某些狀態(tài)，而且由于需要在查詢(xún)的時(shí)候進(jìn)行實(shí)時(shí)的數(shù)據(jù)Join，也不可避免的會(huì)降低查詢(xún)性能。

在把Event-User模型擴(kuò)展為Event-Item-User模型之后，神策分析對(duì)復(fù)雜業(yè)務(wù)場(chǎng)景有了更好的支持，無(wú)論是在埋點(diǎn)工作的簡(jiǎn)化還是在分析能力的提升上都有非常直接的幫助。

后續(xù)我們也將繼續(xù)在簡(jiǎn)化Item數(shù)據(jù)的接入和使用上做出更多的改進(jìn)。

三、用戶(hù)分群的進(jìn)化

從2年前的神策分析1.4版本開(kāi)始，我們引入了用戶(hù)分群功能。從架構(gòu)層面，我們主要做了兩件事情：一是把分群的概念引入了我們的數(shù)據(jù)模型中，二是提供靈活、便利的定義分群規(guī)則的方式。

對(duì)于第一點(diǎn)，我們把分群看作是用戶(hù)屬性的一部分，只不過(guò)這個(gè)屬性是根據(jù)用戶(hù)已有的行為特征計(jì)算出來(lái)的，是一個(gè)衍生屬性。所以在數(shù)據(jù)模型上，分群其實(shí)是對(duì)Event-User模型中User部分的一個(gè)擴(kuò)展。

當(dāng)然，在物理存儲(chǔ)上，由于分群具有頻繁更新、整體刪除等特點(diǎn)，因此并不會(huì)直接和原有的用戶(hù)屬性信息存儲(chǔ)在一起，而是采用獨(dú)立存儲(chǔ)的方式。

對(duì)于第二點(diǎn)，一方面，我們提供了一套描述規(guī)則，允許客戶(hù)直接從UI上定義比較復(fù)雜的分群：在某段時(shí)間做過(guò)某個(gè)Event幾次，或者完成了某個(gè)連續(xù)的Event序列等。

更重要的是，我們把所有已有分析模型的用戶(hù)列表功能都看作為是分群規(guī)則定義的一部分，這種方式使得客戶(hù)可以很容易的把各個(gè)分析模型的結(jié)果進(jìn)行組合，產(chǎn)生1+1>2的效果。

整體上來(lái)看，神策分析1.4在引入分群的概念之后，架構(gòu)上幾乎沒(méi)有做任何大的改動(dòng)，就可以讓所有的分群和普通的用戶(hù)屬性一樣在任何的分析模型里直接使用。

這個(gè)也是完全得益于前文提到的實(shí)時(shí)分析架構(gòu)，以及具有良好擴(kuò)展能力的Event-User模型。

隨著客戶(hù)對(duì)神策分析的使用場(chǎng)景越來(lái)越復(fù)雜，我們的客戶(hù)對(duì)分群功能也提出了更多的需求。

一個(gè)比較顯著的問(wèn)題是：現(xiàn)在的神策的每個(gè)分群只能保存一個(gè)最新的結(jié)果，而不能查看歷史的狀態(tài)。

比如在一個(gè)電商產(chǎn)品里，我們可以很容易的建立一個(gè)"日購(gòu)買(mǎi)金額>=300"的用戶(hù)分群，但是這個(gè)分群每天都會(huì)自動(dòng)刷新，并且會(huì)丟掉前一天的狀態(tài)。

如果我們想分析這個(gè)用戶(hù)分群在時(shí)間軸上的變化趨勢(shì)，或者考慮一個(gè)更復(fù)雜的場(chǎng)景，想分析“日購(gòu)買(mǎi)金額>=300”的這個(gè)用戶(hù)群體在當(dāng)天購(gòu)買(mǎi)的商品品類(lèi)的分布情況，用現(xiàn)在的分群功能都是沒(méi)辦法直接實(shí)現(xiàn)的。

為了實(shí)現(xiàn)上述功能，我們?cè)诩磳l(fā)布的1.13版本也對(duì)用戶(hù)分群功能做了一次大的改進(jìn)。

首先在數(shù)據(jù)模型上，我們擴(kuò)展了分群的模型定義，加入了時(shí)間維度。即每個(gè)分群不只是代表這個(gè)分群的群體在某一時(shí)刻的狀態(tài)，而是可以保存每天、每周等不同時(shí)間點(diǎn)下的狀態(tài)。

其次，我們也進(jìn)一步增強(qiáng)了分群的描述能力，除了增強(qiáng)了在UI上進(jìn)行定義的功能之外，還允許用戶(hù)直接上傳分群好的結(jié)果(例如某個(gè)線(xiàn)下活動(dòng)的用戶(hù)列表)，或者是從一個(gè)SQL結(jié)果導(dǎo)出成一個(gè)分群，避免讓分群的能力受限于已有的規(guī)則定義。

另外，在分群的計(jì)算執(zhí)行層面，我們也不再使用獨(dú)立的MapReduce程序來(lái)進(jìn)行，而是復(fù)用了上面提到的基于Impala的用戶(hù)行為分析引擎。

因?yàn)榉秩旱倪^(guò)程，其實(shí)也是一個(gè)很典型的用戶(hù)行為分析的計(jì)算邏輯，這樣就很自然的把整個(gè)神策系統(tǒng)內(nèi)對(duì)于用戶(hù)行為的分析都統(tǒng)一到了一個(gè)計(jì)算模塊上來(lái)完成。

四、更精確的用戶(hù)標(biāo)識(shí)體系

如何準(zhǔn)確地標(biāo)識(shí)用戶(hù)一直是用戶(hù)行為數(shù)據(jù)系統(tǒng)中的一大難題。在過(guò)去的3年里，我們?cè)诳蛻?hù)端SDK、服務(wù)端架構(gòu)、數(shù)據(jù)接入的解決方案支持上做了持續(xù)的優(yōu)化，解決了很多普遍的問(wèn)題。

傳統(tǒng)的網(wǎng)站或者App分析工具，通常以Cookie或設(shè)備號(hào)作為用戶(hù)(其實(shí)是設(shè)備)的標(biāo)識(shí)，同時(shí)這些分析工具大部分也并不支持跨端的分析，所以關(guān)于用戶(hù)標(biāo)識(shí)導(dǎo)致的各類(lèi)問(wèn)題并不突出。

但是在今天的用戶(hù)行為分析場(chǎng)景中，準(zhǔn)確的跨端標(biāo)識(shí)用戶(hù)變成了一個(gè)非常迫切的需求。尤其是在微信生態(tài)的情況下，一個(gè)自然人用戶(hù)在App、小程序、H5、公眾號(hào)之間反復(fù)跳轉(zhuǎn)，完成一系列行為是非常常見(jiàn)的場(chǎng)景，如果不能做到準(zhǔn)確的標(biāo)識(shí)用戶(hù)，很多數(shù)據(jù)分析的需求將會(huì)無(wú)法準(zhǔn)確完成。

在神策分析1.13版本之前，為了解決跨端標(biāo)識(shí)用戶(hù)的問(wèn)題，我們提供了有限度的多設(shè)備用戶(hù)關(guān)聯(lián)體系。

這里的“有限”主要體現(xiàn)在一個(gè)注冊(cè)用戶(hù)在未登錄狀態(tài)下只能跟一個(gè)設(shè)備進(jìn)行綁定。很顯然，在很多場(chǎng)景下這種關(guān)聯(lián)并不能很好的滿(mǎn)足需求。

最典型的場(chǎng)景是，如果一個(gè)老用戶(hù)更換了新的設(shè)備，那么他在這個(gè)新設(shè)備上未登錄狀態(tài)下的操作將會(huì)被識(shí)別為一個(gè)全新的用戶(hù)，從而對(duì)某些分析結(jié)果的準(zhǔn)確性產(chǎn)生影響。

因此，我們?cè)谧罱?.13版本提供了一個(gè)注冊(cè)用戶(hù)跟任意多個(gè)設(shè)備進(jìn)行關(guān)聯(lián)的機(jī)制。在這個(gè)新的機(jī)制下，一個(gè)注冊(cè)用戶(hù)可以使用多個(gè)設(shè)備進(jìn)行登錄，并且他在這些設(shè)備上注冊(cè)/登錄前后的行為都會(huì)被準(zhǔn)確的識(shí)別到同一個(gè)用戶(hù)身上，從而能在神策分析里更準(zhǔn)確的還原一個(gè)用戶(hù)的行為序列。

當(dāng)然，這個(gè)在新的關(guān)聯(lián)機(jī)制也并不是提供無(wú)限的靈活性。考慮這樣一個(gè)場(chǎng)景：一個(gè)設(shè)備先后被多個(gè)注冊(cè)用戶(hù)登錄使用，那這個(gè)設(shè)備上產(chǎn)生的匿名行為(即非登錄狀態(tài)下產(chǎn)生的行為)只會(huì)被關(guān)聯(lián)到第一個(gè)在這個(gè)設(shè)備上登錄的注冊(cè)用戶(hù)。

雖然在技術(shù)上我們也可以很容易的實(shí)現(xiàn)用戶(hù)和設(shè)備之間的多重綁定，但是考慮到實(shí)際的應(yīng)用場(chǎng)景并不常見(jiàn)，而且提供這種機(jī)制之后一定會(huì)給客戶(hù)帶來(lái)的更多理解上的復(fù)雜性，我們還是決定把新的關(guān)聯(lián)機(jī)制限定在一個(gè)注冊(cè)用戶(hù)多個(gè)設(shè)備的場(chǎng)景下。

全新的用戶(hù)標(biāo)識(shí)體系雖然可以更準(zhǔn)確地標(biāo)識(shí)用戶(hù)，但是同時(shí)也會(huì)引入一個(gè)新的問(wèn)題：允許一個(gè)注冊(cè)用戶(hù)和多個(gè)設(shè)備進(jìn)行關(guān)聯(lián)，會(huì)導(dǎo)致歷史數(shù)據(jù)的分析結(jié)果是不斷變化的。我們可以看一個(gè)具體的例子，假設(shè)一個(gè)用戶(hù)X進(jìn)行了一系列操作：

7月1日之前在設(shè)備A上注冊(cè)、登錄并使用App

7月2日開(kāi)始在設(shè)備B上使用App

7月5日在設(shè)備B上使用之前的帳號(hào)進(jìn)行登錄，并繼續(xù)使用

我們可以看到，在7月5日之前，神策分析并不知道使用設(shè)備B跟設(shè)備A背后都是用戶(hù)X在操作，也就是說(shuō)在這之前計(jì)算用戶(hù)數(shù)都會(huì)是2，同時(shí)在計(jì)算留存、漏斗等數(shù)據(jù)時(shí)也都會(huì)當(dāng)作兩個(gè)不同的用戶(hù)。

而一旦到7月5日用戶(hù)X登錄了，神策分析可以知道之前的行為其實(shí)都是同一個(gè)人X產(chǎn)生的，那么這個(gè)時(shí)候再看7月5日之前的用戶(hù)數(shù)也會(huì)變成了1。

這種數(shù)據(jù)的變化在某些場(chǎng)景下可能會(huì)變得更加難以理解，我們假設(shè)一個(gè)比較極端的情況，如果上面的用戶(hù)X是在一年之后才在設(shè)備B上進(jìn)行登錄，那么這一年內(nèi)設(shè)備B所產(chǎn)生的行為是否都應(yīng)該視作用戶(hù)X產(chǎn)生的?現(xiàn)實(shí)情況下可能是，也可能不是，只憑借這些信息很難做出準(zhǔn)確的判斷。

本質(zhì)上，新的用戶(hù)標(biāo)識(shí)體系是實(shí)現(xiàn)了對(duì)歷史數(shù)據(jù)的修正，同時(shí)由于神策分析又是一個(gè)完全基于明細(xì)數(shù)據(jù)進(jìn)行實(shí)時(shí)查詢(xún)的分析系統(tǒng)，因此數(shù)據(jù)分析的結(jié)果跟著發(fā)生變化也是很自然的事情。

正如我們?cè)谏衔牡腅vent-User模型擴(kuò)展中提到的，雖然Event代表的是已經(jīng)發(fā)生的事件，但是依然會(huì)有一些信息在Event發(fā)生的當(dāng)時(shí)是無(wú)法得到的。

比如在上面的例子中，7月2日當(dāng)天我們并不知道在設(shè)備B上使用的也是用戶(hù)X，只能在3天之后再對(duì)這個(gè)數(shù)據(jù)進(jìn)行修正。我們?cè)谝欢ǔ潭壬掀茐牧薊vent的不變性，但是也帶來(lái)了更高的數(shù)據(jù)準(zhǔn)確性。

不過(guò)，除了技術(shù)上的難點(diǎn)，歷史數(shù)據(jù)的變化還會(huì)給數(shù)據(jù)的可解釋性造成比較大的影響：很多人都會(huì)對(duì)昨天甚至更早的數(shù)據(jù)報(bào)表會(huì)發(fā)生變化產(chǎn)生困惑。

因此，如何在提高數(shù)據(jù)準(zhǔn)確性的同時(shí)降低客戶(hù)對(duì)數(shù)據(jù)的理解難度，會(huì)是我們后面的重點(diǎn)方向。

關(guān)于神策數(shù)據(jù)

神策數(shù)據(jù)(https://www.sensorsdata.cn)，是一家專(zhuān)業(yè)的大數(shù)據(jù)分析服務(wù)公司，致力于幫助客戶(hù)實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)。公司推出深度用戶(hù)行為分析平臺(tái)神策分析(Sensors Analytics)，支持私有化部署、基礎(chǔ)數(shù)據(jù)采集與建模，并作為PaaS平臺(tái)支持二次開(kāi)發(fā);同時(shí)推出基于行為數(shù)據(jù)的客戶(hù)全生命周期分析平臺(tái)神策客景(Sensors Journey)，創(chuàng)造性將用戶(hù)行為數(shù)據(jù)融入客戶(hù)全生命周期的管理與分析，實(shí)現(xiàn)客群健康度分析，流失預(yù)警等重要價(jià)值，并應(yīng)用到企業(yè)服務(wù)、工具軟件等多個(gè)領(lǐng)域。

此外，還提供大數(shù)據(jù)相關(guān)咨詢(xún)和完整解決方案。神策數(shù)據(jù)積累了中國(guó)銀聯(lián)、中國(guó)電信、百度視頻、百聯(lián)、萬(wàn)達(dá)、小米、中郵消費(fèi)金融、廣發(fā)證券、中原銀行、百信銀行、聚美優(yōu)品、中商惠民、紛享銷(xiāo)客、Keep、36氪、中青旅、太平洋保險(xiǎn)、平安壽險(xiǎn)、鏈家、四川航空等500余家付費(fèi)企業(yè)用戶(hù)的服務(wù)和客戶(hù)成功經(jīng)驗(yàn)，為客戶(hù)全面提供指標(biāo)梳理、數(shù)據(jù)模型搭建等專(zhuān)業(yè)的咨詢(xún)、實(shí)施、和技術(shù)支持服務(wù)。希望更深入了解神策數(shù)據(jù)或有數(shù)據(jù)驅(qū)動(dòng)相關(guān)問(wèn)題，請(qǐng)撥打4006509827電話(huà)咨詢(xún)，會(huì)有專(zhuān)業(yè)的工作人員為您解答。

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！