一. 數(shù)據(jù)分析平臺(tái)的架構(gòu)倒推
僅限于神策的數(shù)據(jù)分析平臺(tái)?；谌脚_(tái)的SDK埋點(diǎn)（全埋點(diǎn)+可視化埋點(diǎn)+自定義事件埋點(diǎn)等）的數(shù)據(jù)采集上報(bào)，經(jīng)平臺(tái)數(shù)據(jù)加工（多類型的模型分析），形成數(shù)據(jù)概覽及業(yè)務(wù)系統(tǒng)的BI數(shù)據(jù)報(bào)表。
二.核心的events-users事件模型
直接看圖吧。基礎(chǔ)事件除了在神策數(shù)據(jù)分析平臺(tái)加工展示外，同樣可通過(guò)API同步至業(yè)務(wù)系統(tǒng)內(nèi)作處理。
三.埋點(diǎn)模式的對(duì)比
1.頁(yè)面可視化埋點(diǎn)模式。
（1）優(yōu)勢(shì)：此方式開(kāi)發(fā)量最小，僅需僅需在待埋點(diǎn)平臺(tái)（APP、公眾號(hào)、小程序、后端等）初始化神策SDK，并開(kāi)啟可視化埋點(diǎn)功能，即可在神策后臺(tái)頁(yè)面內(nèi)可視化操作埋點(diǎn)。
（2）劣勢(shì)：僅支持頁(yè)面點(diǎn)擊與頁(yè)面瀏覽類型，且僅支持默認(rèn)屬性，不可自定義參數(shù)，用于業(yè)務(wù)分析局限性大。
（3）適合場(chǎng)景：相對(duì)不重要的功能，僅需關(guān)注PV、UV。
2.全埋點(diǎn)模式。
（1）優(yōu)勢(shì)：此方式開(kāi)發(fā)量相對(duì)較小，僅需在待埋點(diǎn)平臺(tái)（APP、公眾號(hào)、后端邏輯等）初始化神策SDK即可自動(dòng)上報(bào)；全量事件均作采集上報(bào)。
（2）劣勢(shì)：準(zhǔn)確性、穩(wěn)定性、兼容性較代碼埋點(diǎn)而言，相對(duì)較低；屬于通用埋點(diǎn)方案，無(wú)法埋入自定義的參數(shù)。
（3）適合場(chǎng)景：適用于非關(guān)鍵的全量功能埋點(diǎn)，可用作粗略分析。
3.代碼埋點(diǎn)。
（1）優(yōu)勢(shì)：此方式可準(zhǔn)確穩(wěn)定的對(duì)關(guān)鍵事件做埋點(diǎn)，支持自定義參數(shù)。
（2）劣勢(shì)：此方式開(kāi)發(fā)量中等，需維護(hù)埋點(diǎn)管理表。
（3）適合場(chǎng)景：適用于關(guān)鍵功能的埋點(diǎn)，精準(zhǔn)分析。如核心功能（下單支付、客戶轉(zhuǎn)發(fā)等）。
4.寫(xiě)入業(yè)務(wù)系統(tǒng)自有埋點(diǎn)數(shù)據(jù)表。
（1）優(yōu)勢(shì)：埋點(diǎn)采集與數(shù)據(jù)分析展示完全由業(yè)務(wù)系統(tǒng)處理，可最大化實(shí)現(xiàn)復(fù)雜的數(shù)據(jù)分析。
（2）劣勢(shì)：此方式開(kāi)發(fā)量最大，且需開(kāi)發(fā)對(duì)應(yīng)報(bào)表或數(shù)據(jù)展示分析模塊；埋點(diǎn)管理成本高。
（3）適合場(chǎng)景：大型、數(shù)據(jù)口徑定義復(fù)雜的數(shù)據(jù)統(tǒng)計(jì)分析場(chǎng)景。
四.一些總結(jié)
相較于其他數(shù)據(jù)埋點(diǎn)分析平臺(tái)，神策的優(yōu)勢(shì)和劣勢(shì)都是比較明顯的。優(yōu)勢(shì)如：提供私有化部署模式、支持API形式的多項(xiàng)自定義導(dǎo)出方案、完善的系統(tǒng)數(shù)據(jù)治理規(guī)范、支持歷史數(shù)據(jù)的導(dǎo)入等。不足方面，則是不少朋友吐槽的過(guò)于技術(shù)化，對(duì)商務(wù)運(yùn)營(yíng)不太友好??。俺也是最近通讀了完整說(shuō)明文檔及SDK技術(shù)文檔，對(duì)其模式有個(gè)大概了解但仍有不少疑問(wèn)，最終還是自己上手寫(xiě)寫(xiě)代碼，通過(guò)觀察日志打印信息再來(lái)做假設(shè)驗(yàn)證，總算搞懂這套復(fù)雜模式。"紙上得來(lái)終覺(jué)淺，Build 、Debug &Run"
