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

　 域名預(yù)訂/競價，好“米”不錯過

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

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

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

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

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

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

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

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

一、從SQL查詢引擎到用戶行為分析引擎

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

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

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

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

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

受益于這種架構(gòu)，我們在很短的時間內(nèi)推出眾多靈活的分析模型，并且這些分析模型之間可以通過分群等方式來進(jìn)行自由的組合查詢。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了滿足上述需求，我們在新版的神策分析中對Event-User模型進(jìn)行了擴(kuò)展，引入了Item的概念。這里的所謂Item，在嚴(yán)格意義上是指一個和用戶行為相關(guān)聯(lián)的實體，可能是一個商品、一個視頻劇集、一部小說等等。

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

在具體的技術(shù)實現(xiàn)上，我們允許客戶定義多個不同的Item實體，例如電商有商品、配送點等不同的實體。

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

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

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

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

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

我們在埋點時不做任何變動，而是在需要進(jìn)行查詢的時候，把Item表加入進(jìn)來。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了實現(xiàn)上述功能，我們在即將發(fā)布的1.13版本也對用戶分群功能做了一次大的改進(jìn)。

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

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

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

因為分群的過程，其實也是一個很典型的用戶行為分析的計算邏輯，這樣就很自然的把整個神策系統(tǒng)內(nèi)對于用戶行為的分析都統(tǒng)一到了一個計算模塊上來完成。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正如我們在上文的Event-User模型擴(kuò)展中提到的，雖然Event代表的是已經(jīng)發(fā)生的事件，但是依然會有一些信息在Event發(fā)生的當(dāng)時是無法得到的。

比如在上面的例子中，7月2日當(dāng)天我們并不知道在設(shè)備B上使用的也是用戶X，只能在3天之后再對這個數(shù)據(jù)進(jìn)行修正。我們在一定程度上破壞了Event的不變性，但是也帶來了更高的數(shù)據(jù)準(zhǔn)確性。

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

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

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

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

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

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