一. 數(shù)據(jù)分析平臺的架構(gòu)倒推

僅限于神策的數(shù)據(jù)分析平臺?；谌脚_的SDK埋點（全埋點+可視化埋點+自定義事件埋點等）的數(shù)據(jù)采集上報，經(jīng)平臺數(shù)據(jù)加工（多類型的模型分析），形成數(shù)據(jù)概覽及業(yè)務系統(tǒng)的BI數(shù)據(jù)報表。

二.核心的events-users事件模型

直接看圖吧?；A(chǔ)事件除了在神策數(shù)據(jù)分析平臺加工展示外，同樣可通過API同步至業(yè)務系統(tǒng)內(nèi)作處理。

三.埋點模式的對比

1.頁面可視化埋點模式。

（1）優(yōu)勢：此方式開發(fā)量最小，僅需僅需在待埋點平臺（APP、公眾號、小程序、后端等）初始化神策SDK，并開啟可視化埋點功能，即可在神策后臺頁面內(nèi)可視化操作埋點。

（2）劣勢：僅支持頁面點擊與頁面瀏覽類型，且僅支持默認屬性，不可自定義參數(shù)，用于業(yè)務分析局限性大。

（3）適合場景：相對不重要的功能，僅需關(guān)注PV、UV。

2.全埋點模式。

（1）優(yōu)勢：此方式開發(fā)量相對較小，僅需在待埋點平臺（APP、公眾號、后端邏輯等）初始化神策SDK即可自動上報；全量事件均作采集上報。

（2）劣勢：準確性、穩(wěn)定性、兼容性較代碼埋點而言，相對較低；屬于通用埋點方案，無法埋入自定義的參數(shù)。

（3）適合場景：適用于非關(guān)鍵的全量功能埋點，可用作粗略分析。

3.代碼埋點。

（1）優(yōu)勢：此方式可準確穩(wěn)定的對關(guān)鍵事件做埋點，支持自定義參數(shù)。

（2）劣勢：此方式開發(fā)量中等，需維護埋點管理表。

（3）適合場景：適用于關(guān)鍵功能的埋點，精準分析。如核心功能（下單支付、客戶轉(zhuǎn)發(fā)等）。

4.寫入業(yè)務系統(tǒng)自有埋點數(shù)據(jù)表。

（1）優(yōu)勢：埋點采集與數(shù)據(jù)分析展示完全由業(yè)務系統(tǒng)處理，可最大化實現(xiàn)復雜的數(shù)據(jù)分析。

（2）劣勢：此方式開發(fā)量最大，且需開發(fā)對應報表或數(shù)據(jù)展示分析模塊；埋點管理成本高。

（3）適合場景：大型、數(shù)據(jù)口徑定義復雜的數(shù)據(jù)統(tǒng)計分析場景。

四.一些總結(jié)

相較于其他數(shù)據(jù)埋點分析平臺，神策的優(yōu)勢和劣勢都是比較明顯的。優(yōu)勢如：提供私有化部署模式、支持API形式的多項自定義導出方案、完善的系統(tǒng)數(shù)據(jù)治理規(guī)范、支持歷史數(shù)據(jù)的導入等。不足方面，則是不少朋友吐槽的過于技術(shù)化，對商務運營不太友好??。俺也是最近通讀了完整說明文檔及SDK技術(shù)文檔，對其模式有個大概了解但仍有不少疑問，最終還是自己上手寫寫代碼，通過觀察日志打印信息再來做假設(shè)驗證，總算搞懂這套復雜模式。"紙上得來終覺淺，Build 、Debug &Run"