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

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

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

付力力畢業(yè)于北京理工大學(xué)軟件工程專業(yè)，2008年至2013年期間歷任百度新產(chǎn)品研發(fā)部、網(wǎng)頁(yè)搜索部、基礎(chǔ)架構(gòu)部工程師。2013年9月年至2014年8月?lián)瓮愣骨v數(shù)據(jù)部門資深研發(fā)工程師。2014年9月至2015年4月?lián)吸S金錢包技術(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查詢引擎到用戶行為分析引擎

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

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

換句話說，我們期望只要是從已經(jīng)采集的數(shù)據(jù)里可以分析得到的結(jié)論，神策都希望可以幫助我們的客戶很容易的實(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ù)類似的數(shù)據(jù)系統(tǒng)里要么拋棄數(shù)據(jù)回溯的能力，要么放棄數(shù)據(jù)一致性)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們?cè)诼顸c(diǎn)時(shí)不做任何變動(dòng)，而是在需要進(jì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)，而且由于需要在查詢的時(shí)候進(jìn)行實(shí)時(shí)的數(shù)據(jù)Join，也不可避免的會(huì)降低查詢性能。

在把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)。

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

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

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

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

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

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

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

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

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

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

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

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

為了實(shí)現(xiàn)上述功能，我們?cè)诩磳l(fā)布的1.13版本也對(duì)用戶分群功能做了一次大的改進(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)行定義的功能之外，還允許用戶直接上傳分群好的結(jié)果(例如某個(gè)線下活動(dòng)的用戶列表)，或者是從一個(gè)SQL結(jié)果導(dǎo)出成一個(gè)分群，避免讓分群的能力受限于已有的規(guī)則定義。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本質(zhì)上，新的用戶標(biāo)識(shí)體系是實(shí)現(xiàn)了對(duì)歷史數(shù)據(jù)的修正，同時(shí)由于神策分析又是一個(gè)完全基于明細(xì)數(shù)據(jù)進(jìn)行實(shí)時(shí)查詢的分析系統(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上使用的也是用戶X，只能在3天之后再對(duì)這個(gè)數(shù)據(jù)進(jìn)行修正。我們?cè)谝欢ǔ潭壬掀茐牧薊vent的不變性，但是也帶來(lái)了更高的數(shù)據(jù)準(zhǔn)確性。

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

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

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

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

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

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