本文根據(jù)神策數(shù)據(jù)解決方案顧問(wèn)易向文《打造券商上層數(shù)據(jù)應(yīng)用的堅(jiān)實(shí)基礎(chǔ)》直播整理而成，本文的主要內(nèi)容如下：

• 淺析券商數(shù)據(jù)采集

• 常見(jiàn)的埋點(diǎn)方式介紹

• 如何做好用戶數(shù)據(jù)關(guān)聯(lián)

• 數(shù)據(jù)管理與數(shù)據(jù)校驗(yàn)

注：圖中數(shù)據(jù)均為虛擬數(shù)據(jù)。

一、淺析券商數(shù)據(jù)采集

1

數(shù)據(jù)驅(qū)動(dòng)四部曲

從整體上來(lái)說(shuō)，數(shù)據(jù)驅(qū)動(dòng)的完整閉環(huán)可分為四步：采集數(shù)據(jù)、數(shù)據(jù)接入與存儲(chǔ)、可視化查詢分析、驅(qū)動(dòng)決策和產(chǎn)品智能。

采集數(shù)據(jù)：業(yè)務(wù)中有多種數(shù)據(jù)來(lái)源，包含終端「web、App、H5 等」，后端服務(wù)器日志「Log」和業(yè)務(wù)數(shù)據(jù)「Database」。首先就要將全端的數(shù)據(jù)采集、匯總。

數(shù)據(jù)接入與儲(chǔ)存：通過(guò)多種數(shù)據(jù)接入方案，確保提供適合業(yè)務(wù)需求的數(shù)據(jù)接入手段，便捷將各不同源數(shù)據(jù)入庫(kù)，保證格式的統(tǒng)一性。

可視化查詢與分析：結(jié)合分析模型，配置具體維度與指標(biāo)，獲取分析結(jié)果，保證實(shí)時(shí)性需求

驅(qū)動(dòng)決策和產(chǎn)品智能：通過(guò)業(yè)務(wù)指標(biāo)分析業(yè)務(wù)表現(xiàn)從而驅(qū)動(dòng)決策；實(shí)現(xiàn)產(chǎn)品智能，畫(huà)像洞察，精準(zhǔn)營(yíng)銷，千人千面。

這個(gè)框架的重點(diǎn)在于數(shù)據(jù)采集，引用神策數(shù)據(jù)咨詢師徐美玲的一句話：“不可用的數(shù)據(jù)不是資產(chǎn)，而是負(fù)資產(chǎn)。”我們甚至?xí)浅ｎ^痛如何提升數(shù)據(jù)質(zhì)量，讓它變得可用起來(lái)。

2

數(shù)據(jù)采集流程與原則

下圖是常見(jiàn)的數(shù)據(jù)采集流程：

在數(shù)據(jù)采集流程中，可以總結(jié)出 4 個(gè)關(guān)鍵原則：

大 ：做好長(zhǎng)期的數(shù)據(jù)建設(shè)，要充分考慮用戶規(guī)模與數(shù)據(jù)規(guī)模的增長(zhǎng)，做好數(shù)據(jù)資產(chǎn)的積累

全：多端采集，針對(duì)全量用戶行為而非抽樣，貫穿用戶使用產(chǎn)品的整個(gè)生命周期

細(xì)：盡可能采集足夠全面的屬性與維度，盡量保存數(shù)據(jù)細(xì)節(jié)，讓積累的數(shù)據(jù)資產(chǎn)更加優(yōu)質(zhì)。例如，從 （5W） 這 5 個(gè)角度來(lái)采集用戶行為數(shù)據(jù)

時(shí)：在技術(shù)條件與成本允許的情況下，盡可能地提高數(shù)據(jù)采集的時(shí)效性，從而提高后續(xù)數(shù)據(jù)應(yīng)用的時(shí)效性

3

數(shù)據(jù)模型選擇

數(shù)據(jù)采集還需要考慮一個(gè)問(wèn)題，如何選擇數(shù)據(jù)模型？

（1）Event Model VS Page View

首要考慮，是選擇事件模型，還是頁(yè)面瀏覽模型。Web 時(shí)代，流行使用 PV 分析頁(yè)面的流量。但移動(dòng)互聯(lián)網(wǎng)及 O2O 時(shí)代，PV 已經(jīng)無(wú)法滿足分析需求。

比如，采集同一個(gè)頁(yè)面瀏覽事件，一個(gè)用戶在券商 App 上瀏覽了某一基金。頁(yè)面瀏覽模型僅能簡(jiǎn)單記錄“用戶有一次瀏覽行為”。但用戶到底瀏覽了哪個(gè)頁(yè)面就受限于代碼的規(guī)范程度。而事件模型可以靈活編輯需要采集的屬性，如基金名稱、基金代碼、基金收益率、基金經(jīng)理等。

（2）客戶端 vs 后端

從客戶端還是后端采集數(shù)據(jù)也是需要考量的問(wèn)題，神策更加建議從后端采集數(shù)據(jù)，主要原因如下：

• 前端拿不到部分?jǐn)?shù)據(jù)。比如說(shuō)在做理財(cái)產(chǎn)品的申購(gòu)時(shí)，一般情況下需要等后端確認(rèn)后才能得到購(gòu)買(mǎi)成功的結(jié)果。所以，從后端傳輸結(jié)構(gòu)數(shù)據(jù)更加符合業(yè)務(wù)邏輯。

• 前端采集存在數(shù)據(jù)傳輸丟失的風(fēng)險(xiǎn)。而從后端采集數(shù)據(jù)，可有效避免。

理想情況下，在前端新增埋點(diǎn)，需要將 App 更新到最新的版本，才可以真正發(fā)揮埋點(diǎn)的作用；而后端，僅需改動(dòng)代碼。但因?yàn)樘厥庑袠I(yè)限制，考慮到風(fēng)險(xiǎn)問(wèn)題，大多數(shù)金融公司都是在必須情況下才會(huì)改動(dòng)后端代碼。

（3）Event 5 要素

采集事件后，可用 5 要素定義：

WHERE：位置環(huán)境場(chǎng)景。神策的 SDK 可以解析用戶 IP，分析出當(dāng)前用戶的位置。自有 APP 也可以獲取用戶定位，并上報(bào)到事件中。當(dāng)然，這就需要去做一定的自定義開(kāi)發(fā)；

WHO：用戶身份，ID 識(shí)別；

WHEN：用戶當(dāng)前時(shí)間；

WHAT：做了什么事情，是什么；

HOW：維度特征。

（4）字段設(shè)計(jì)原則

• 從業(yè)務(wù)需求出發(fā)，通過(guò)指標(biāo)需求，倒推需要哪些字段；

• 盡量復(fù)用已使用過(guò)的字段，不改變?cè)侄魏x，減少數(shù)據(jù)庫(kù)的資源的損耗。

（5）字段記錄在 E/U

字段到底是記錄在用戶表還是事件表里面呢？建議如下：

• 易變化數(shù)據(jù)，如用戶級(jí)別、設(shè)備類型、地域、是否是 Vip 可以直接記錄在事件表里面；

• 固定數(shù)據(jù)，如用戶的性別、出生年份記錄在用戶表里。

二、常見(jiàn)的埋點(diǎn)方式介紹

1

各端 SDK 能力

開(kāi)展埋點(diǎn)工作時(shí)，我們都會(huì)接觸到廠商提供的 SDK。那 SDK 有什么作用呢？

• SDK 核心是通過(guò)埋點(diǎn)來(lái)采集數(shù)據(jù)；

• 在 SDK 配置 Schema 將采集的數(shù)據(jù)傳輸?shù)街付ǖ姆?wù)器端；

• SDK 支持我們?nèi)ザx相關(guān)的策略，最大限度的保證數(shù)據(jù)的準(zhǔn)確性和完整性，如：緩存策略、同步策略、網(wǎng)絡(luò)策略等。

2

常見(jiàn)埋點(diǎn)方式
?

（1）全埋點(diǎn)（無(wú)埋點(diǎn)）

全埋點(diǎn)，也叫無(wú)埋點(diǎn)、無(wú)碼埋點(diǎn)、無(wú)痕埋點(diǎn)、自動(dòng)埋點(diǎn)。它可以直接把 SDK 集成到不同的應(yīng)用端，而無(wú)需開(kāi)發(fā)工程師寫(xiě)代碼或者只寫(xiě)少量的代碼，就能預(yù)先自動(dòng)收集用戶的所有行為數(shù)據(jù)。

全埋點(diǎn)支持的事件類型 ：

• 激活

• App 啟動(dòng)（$AppStart）

• App 退出（$AppEnd）

• App 頁(yè)面瀏覽（$AppViewScreen）

• App 控件點(diǎn)擊（$AppClick）

• 曝光

• Crash

上述 7 類事件，各有用途。激活事件普遍應(yīng)用于渠道追蹤，比如 H5 的落地投放，用戶在 H5 落地頁(yè)上自動(dòng)上報(bào)設(shè)備屬性；或者合作的渠道商回傳了一些用戶的設(shè)備、ID 等信息；神策的 SDK 也會(huì)自動(dòng)采集當(dāng)前用戶的設(shè)備信息，然后與渠道投放時(shí)傳輸?shù)南嚓P(guān)屬性匹配。這三種方式都可以獲取到用戶的渠道來(lái)源屬性，以便后續(xù)市場(chǎng)營(yíng)銷進(jìn)一步評(píng)估。

App 啟動(dòng)可以對(duì)用戶屬性進(jìn)一步細(xì)化、下鉆，比如說(shuō)用戶是主動(dòng)啟動(dòng) App，還是從后臺(tái)或者第三方平臺(tái)喚醒 App；App 退出會(huì)有一些內(nèi)容做相關(guān)的限制；頁(yè)面瀏覽和控件點(diǎn)擊，就是用戶對(duì)每一個(gè)頁(yè)面的瀏覽和每一個(gè)控件的點(diǎn)擊都會(huì)自動(dòng)上報(bào)一條數(shù)據(jù)內(nèi)容。

券商的科技部門(mén)比較關(guān)心平臺(tái)的崩潰率，通過(guò) Crash 事件的自動(dòng)化采集，就可以知道各端的崩潰率情況，便于后續(xù)分析崩潰的原因以及針對(duì)性的去優(yōu)化平臺(tái)。

全埋點(diǎn)的優(yōu)點(diǎn)在于：

• 周期短，埋點(diǎn)代價(jià)比較小；

• 無(wú)需更新 App，便于后續(xù)優(yōu)化迭代；

• 自動(dòng)化上傳數(shù)據(jù)，解決了數(shù)據(jù)“回溯”的問(wèn)題；

• 網(wǎng)頁(yè)的點(diǎn)擊熱力圖強(qiáng)烈依賴全埋點(diǎn)，需要它去支撐相關(guān)內(nèi)容。

當(dāng)然，全埋點(diǎn)也有應(yīng)用缺陷：

• 覆蓋的功能有限，僅有上述 7 類事件是能夠通過(guò)全埋點(diǎn)自動(dòng)采集；

• 無(wú)法自動(dòng)采集業(yè)務(wù)相關(guān)的數(shù)據(jù)。數(shù)據(jù)廠商提供的 SDK 是按照滿足市場(chǎng)的統(tǒng)一需求來(lái)的，并沒(méi)有一個(gè)針對(duì)某一個(gè)行業(yè)的 SDK；

• 無(wú)法滿足更精細(xì)化的分析需求。SDK 僅能采集一些相對(duì)比較統(tǒng)一的事件，無(wú)法滿足行業(yè)繼續(xù)下鉆、細(xì)分的訴求；

• 各家的開(kāi)發(fā)框架不一樣，SDK 的兼容性可能會(huì)存在問(wèn)題；

• 傳輸?shù)臄?shù)據(jù)量太大、浪費(fèi)資源。因?yàn)橛脩舻娜我庑袨槎紩?huì)被采集上報(bào)，從經(jīng)濟(jì)上考量，數(shù)據(jù)量成本可能過(guò)大；

（2）代碼埋點(diǎn)

代碼埋點(diǎn)的前提是需要集成 SDK，在 App 啟動(dòng)的時(shí)候初始化 SDK，然后在某個(gè)事件發(fā)生時(shí)調(diào)用 SDK 的接口觸發(fā)（track）事件。

• 顯而易見(jiàn)，代碼埋點(diǎn)的優(yōu)點(diǎn)如下：

• 精準(zhǔn)控制埋點(diǎn)；

• 方便、靈活自定義事件、自定義屬性；

• 采集數(shù)據(jù)豐富；

• 可以滿足更精細(xì)化的分析需求。

當(dāng)然，代碼埋點(diǎn)也有兩個(gè)缺點(diǎn)：

• 埋點(diǎn)代價(jià)比較大，在排期緊張的時(shí)候，代碼埋點(diǎn)不易推進(jìn)；

• 埋點(diǎn)的更新和新增需要伴隨著 App 發(fā)版。

（3）可視化全埋點(diǎn)

全埋點(diǎn)和代碼埋點(diǎn)各有優(yōu)劣，那可視化全埋點(diǎn)就是結(jié)合了兩者的優(yōu)點(diǎn)，在全埋點(diǎn)的基礎(chǔ)之上，通過(guò)可視化的方式對(duì) $AppClick 事件進(jìn)行一些配置或者自定義操作。比如說(shuō)，一旦應(yīng)用端的集成好 SDK 和配置好數(shù)據(jù)接受地址后就可以直接掃描頁(yè)面上的二維碼，同步 App 端和網(wǎng)頁(yè)端的動(dòng)作。

圖中是一個(gè)已經(jīng)集成好 SDK 電商 App，可以看到 App 首頁(yè)有不同的 icon 位和推薦位等相關(guān)內(nèi)容。手機(jī)上任意可以點(diǎn)擊的位置都會(huì)自動(dòng)命中一個(gè)埋點(diǎn)的點(diǎn)位，我們可以自定義一個(gè)相關(guān)的事件名，比如說(shuō)首頁(yè)數(shù)碼電器 icon 的點(diǎn)擊。另外也可以根據(jù)條件進(jìn)行篩選，比如需要的內(nèi)容文本中，是數(shù)碼電器需要埋點(diǎn)，還是首頁(yè)第一個(gè)推薦位需要埋點(diǎn)？

頁(yè)面上所有可點(diǎn)擊的元素，只要有價(jià)值去做分析的都可以通過(guò)簡(jiǎn)單操作將埋點(diǎn)細(xì)分下鉆，而不是像全埋點(diǎn)一樣，所有的 icon 點(diǎn)擊都定義為一個(gè)事件。因此，可視化全埋點(diǎn)不用再去區(qū)分每一個(gè)元素的內(nèi)容，業(yè)務(wù)人員也可以自主定義埋點(diǎn)動(dòng)作。

下一步，就需要設(shè)置頁(yè)面瀏覽事件相關(guān)的埋點(diǎn)。如下圖，在可視化頁(yè)面的右上角直接點(diǎn)擊【創(chuàng)建頁(yè)面瀏覽事件】，我們可以直接靈活定義一個(gè)事件的名稱，其次還可以標(biāo)記出當(dāng)前頁(yè)面的唯一標(biāo)志，即在代碼中可以找到一個(gè)類似 screen name 的參數(shù)。

下方表格是對(duì)幾種不同的埋點(diǎn)方式的總結(jié)：

3

如何選擇埋點(diǎn)方案？
?

一般情況下，所有行業(yè)內(nèi)并沒(méi)有一個(gè)普適的、完美的埋點(diǎn)方案。因?yàn)楦骷业脑V求不一樣，其次還要考慮自己科技部門(mén)或者專門(mén)負(fù)責(zé)埋點(diǎn)的人員的排期以及平臺(tái)的發(fā)展情況。

因此，建議的做法是針對(duì)不同的應(yīng)用場(chǎng)景，選擇最合適的數(shù)據(jù)采集方案。比如說(shuō)，如果平臺(tái)重視 UV、PV、點(diǎn)擊量等基本指標(biāo)，通過(guò)全埋點(diǎn)就可以直接采集；如果要做精細(xì)化分析，那代碼埋點(diǎn)會(huì)更加清楚、更加精確地還原用戶行為數(shù)據(jù)。

當(dāng)然，我們更加推薦全埋點(diǎn)和代碼埋點(diǎn)相結(jié)合的方案。舉例而言，一般在項(xiàng)目一期上線時(shí)，主要采用全埋點(diǎn)；之后再結(jié)合業(yè)務(wù)的分析情況和最核心的應(yīng)用場(chǎng)景采用代碼埋點(diǎn)，比如說(shuō)注冊(cè)開(kāi)戶的流程、客戶入金的流程、客戶投資的流程等。

三、數(shù)據(jù)關(guān)聯(lián)

數(shù)據(jù)采集上來(lái)后，它中間還有一個(gè)非常復(fù)雜的過(guò)程，即數(shù)據(jù)清洗。

比如，一個(gè)用戶張三，他在自己的 App 上產(chǎn)生了投資理財(cái)?shù)牟僮?#xff0c;但是操作未成功。然后一個(gè)客戶經(jīng)理用自己的手機(jī)輔助張三完成開(kāi)戶動(dòng)作。這樣的話就會(huì)存在一個(gè)問(wèn)題，張三的用戶行為數(shù)據(jù)分散在兩個(gè)不同的端，因?yàn)樗谧约菏謾C(jī)和客戶經(jīng)理的手機(jī)上都操作過(guò)。這時(shí)，就需要把不同端的數(shù)據(jù)關(guān)聯(lián)到統(tǒng)一的用戶身上來(lái)。

場(chǎng)景一：用戶在多家公司產(chǎn)生開(kāi)戶行為

某個(gè)券商公司，在用戶開(kāi)戶時(shí)會(huì)分配給用戶一個(gè)客戶號(hào)以及一個(gè)相關(guān)的資金賬號(hào)。同時(shí)，用戶在開(kāi)戶前也會(huì)在券商 App 端注冊(cè)留下手機(jī)號(hào)碼和設(shè)備信息。采集該用戶的數(shù)據(jù)后發(fā)現(xiàn)，該用戶在不同的券商公司做過(guò)多次開(kāi)戶，而用戶的客戶號(hào)可以統(tǒng)一關(guān)聯(lián)到一個(gè)類似一碼通的證券賬戶上。

這時(shí)做用戶數(shù)據(jù)關(guān)聯(lián)就比較復(fù)雜，神策的建議如下：

第一點(diǎn)，券商比較關(guān)心的是投資行為的全流程的分析，所以建議使用唯一的客戶號(hào)。客戶號(hào)的好處在于可以從自然人的視角去判定客戶在全生命周期里的行為路徑。

第二點(diǎn)，同時(shí)上報(bào)用戶的其它屬性，保證數(shù)據(jù)的完整性，例如用戶 ID、注冊(cè)手機(jī)號(hào)、主資金賬號(hào)、輔助資金賬號(hào)等。

場(chǎng)景二：券商希望單獨(dú)分析注冊(cè)開(kāi)戶流程，引入互聯(lián)網(wǎng)運(yùn)營(yíng)經(jīng)驗(yàn)，對(duì)沒(méi)有開(kāi)戶但平臺(tái)認(rèn)為有價(jià)值的用戶進(jìn)行運(yùn)營(yíng)，促進(jìn)用戶轉(zhuǎn)化。

這時(shí)存在兩種情況：

第一種，用戶所有行為都是在自己的手機(jī)端完成，那可以直接以匿名 ID 將其開(kāi)戶前所有行為進(jìn)行關(guān)聯(lián)。后續(xù)用戶開(kāi)戶成功后，就可將開(kāi)戶獲得到的客戶號(hào)作為用戶的唯一 ID 與匿名 ID 關(guān)聯(lián)；

第二種，用戶在自己的手機(jī)端、在客戶經(jīng)理的手機(jī)端、在自己親朋好友的手機(jī)端等都有相關(guān)操作。面對(duì)這種情況，神策的建議是直接用手機(jī)號(hào)作為用戶的一個(gè)動(dòng)作 ID 進(jìn)行關(guān)聯(lián)起來(lái)。后續(xù)再將客戶號(hào)、資金賬號(hào)等補(bǔ)充到用戶表里。

下面簡(jiǎn)單介紹下如何保證埋點(diǎn)數(shù)據(jù)的完整性和準(zhǔn)確性

首要說(shuō)明，一個(gè)成熟的 SDK 必須能夠支持同步策略的配置。SDK 并不是每采集到一條信息就立即與服務(wù)端通信，而是先緩存到本地經(jīng)過(guò)壓縮后才會(huì)進(jìn)行數(shù)據(jù)上報(bào)。

因此神策建議幾種不同的等待同步機(jī)制：

• 本地緩存一定條數(shù)量的事件會(huì)同步（默認(rèn) 100 條）；

• 固定時(shí)間間隔同步（默認(rèn) 15 秒）；

• 核心事件同步（trackInstallation、login 等）；

• App 退出嘗試同步；

• 本地緩存太多事件時(shí)的處理。

此處強(qiáng)調(diào)下 App 與 H5 打通的必要性：

目前平臺(tái)的一個(gè)普遍應(yīng)用場(chǎng)景是 App 上有內(nèi)嵌聯(lián)儲(chǔ)的頁(yè)面，比如證券類 App 的基金產(chǎn)品和理財(cái)產(chǎn)品的介紹頁(yè)。用戶點(diǎn)進(jìn)介紹后，會(huì)進(jìn)入到 H5 的落地頁(yè)。如果不打通 App 與 H5，就會(huì)存在以下問(wèn)題：

• 不同的匿名 ID。一個(gè)用戶在 App 端和 H5 上各有一個(gè) ID，如果沒(méi)有打通，那用戶的行為數(shù)據(jù)就是割裂的。

• 數(shù)據(jù)的準(zhǔn)確性。H5 的頁(yè)面是無(wú)法直接獲取到設(shè)備相關(guān)信息的，它只能夠通過(guò)解析 UA 的值去獲取一些相對(duì)來(lái)說(shuō)比較有限的信息，而且 UA 值解析也存在問(wèn)題，可能采集的內(nèi)容不全甚至有些事件根本無(wú)法采集到。而打通后，APP 端和 H5 就可以互補(bǔ)共同完善數(shù)據(jù)的采集。

• H5 無(wú)緩存，數(shù)據(jù)易丟失。一般而言，H5 頁(yè)面采集的流失率可能在 5% 左右，而將 App 與 H5 打通，流失率可以降到 2%，甚至 1%。

四、數(shù)據(jù)管理與數(shù)據(jù)校驗(yàn)

數(shù)據(jù)采集后，非常重要的一步是數(shù)據(jù)管理。因?yàn)殡S著產(chǎn)品的迭代、人員的流動(dòng)、KPI 等的變化，我們關(guān)心的數(shù)據(jù)內(nèi)容也會(huì)發(fā)生變化。那這時(shí)候再不斷上報(bào)無(wú)用數(shù)據(jù)的埋點(diǎn)，也就沒(méi)有必要了。

在此，我們推薦一個(gè)相對(duì)比較成熟的數(shù)據(jù)管理功能——數(shù)據(jù)入庫(kù)強(qiáng)校驗(yàn)?zāi)Ｊ健Ｔ谠撃Ｊ较?#xff0c;一旦用戶做了某個(gè)行為被采集上報(bào)后，系統(tǒng)會(huì)進(jìn)行自動(dòng)化檢測(cè)，看這個(gè)數(shù)據(jù)符不符合我們的規(guī)范。如果不符合，就可以直接拒絕數(shù)據(jù)入庫(kù)，進(jìn)而最大程度上保證數(shù)據(jù)的純凈性和準(zhǔn)確性。

數(shù)據(jù)入庫(kù)后，我們希望能夠回溯數(shù)據(jù)是否存在報(bào)錯(cuò)情況，并且明確報(bào)錯(cuò)原因，針對(duì)性處理解決。如下圖，共有 3748 條數(shù)據(jù)報(bào)錯(cuò)。在明細(xì)中，我們可以直接查看錯(cuò)誤原因。圖中模擬的是時(shí)間戳的報(bào)錯(cuò)情況，可能因?yàn)閿?shù)據(jù)錯(cuò)過(guò)時(shí)間，與服務(wù)端不匹配，而無(wú)法入庫(kù)。下一步，就可以定位問(wèn)題，比如說(shuō)，是否平臺(tái)端的數(shù)據(jù)上報(bào)能力存在異常。

數(shù)據(jù)校驗(yàn)也是數(shù)據(jù)采集過(guò)程中非常核心、非常必要的一個(gè)環(huán)節(jié)。很多時(shí)候并不是沒(méi)有采集數(shù)據(jù)，而是采集的數(shù)據(jù)無(wú)法滿足訴求，以及其準(zhǔn)確性也欠考慮。神策分析的埋點(diǎn)管理有實(shí)時(shí)導(dǎo)入數(shù)據(jù)查詢功能，可對(duì)用戶的每一個(gè)動(dòng)作進(jìn)行判斷，其是否入庫(kù)準(zhǔn)確數(shù)據(jù)。其次，還可以通過(guò)用戶行為序列查看最終入庫(kù)數(shù)據(jù)是否準(zhǔn)確。

本文主要從埋點(diǎn)方式上分享了券商行業(yè)如何做好數(shù)據(jù)建設(shè)，打好上層數(shù)據(jù)應(yīng)用的堅(jiān)實(shí)基礎(chǔ)，感謝大家的聆聽(tīng)。

總結(jié)

以上是生活随笔為你收集整理的神策数据易向文：打造券商上层数据应用的坚实基础的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。