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

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

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

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

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

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

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

1

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

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

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

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

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

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

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

2

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

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

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

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

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

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

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

3

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

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

（1）Event Model VS Page View

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

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

（2）客戶端 vs 后端

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

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

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

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

（3）Event 5 要素

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

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

WHO：用戶身份，ID 識別；

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

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

HOW：維度特征。

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

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

• 盡量復(fù)用已使用過的字段，不改變原字段含義，減少數(shù)據(jù)庫的資源的損耗。

（5）字段記錄在 E/U

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

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

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

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

1

各端 SDK 能力

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

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

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

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

2

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

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

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

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

• 激活

• App 啟動（$AppStart）

• App 退出（$AppEnd）

• App 頁面瀏覽（$AppViewScreen）

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

• 曝光

• Crash

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

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

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

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

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

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

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

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

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

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

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

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

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

• 傳輸?shù)臄?shù)據(jù)量太大、浪費(fèi)資源。因為用戶的任意行為都會被采集上報，從經(jīng)濟(jì)上考量，數(shù)據(jù)量成本可能過大；

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

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

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

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

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

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

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

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

• 埋點(diǎn)代價比較大，在排期緊張的時候，代碼埋點(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ǔ)之上，通過可視化的方式對 $AppClick 事件進(jìn)行一些配置或者自定義操作。比如說，一旦應(yīng)用端的集成好 SDK 和配置好數(shù)據(jù)接受地址后就可以直接掃描頁面上的二維碼，同步 App 端和網(wǎng)頁端的動作。

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

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

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

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

3

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

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

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

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

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

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

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

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

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

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

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

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

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

這時存在兩種情況：

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

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

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

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

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

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

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

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

• App 退出嘗試同步；

• 本地緩存太多事件時的處理。

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

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

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

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

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

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

數(shù)據(jù)采集后，非常重要的一步是數(shù)據(jù)管理。因為隨著產(chǎn)品的迭代、人員的流動、KPI 等的變化，我們關(guān)心的數(shù)據(jù)內(nèi)容也會發(fā)生變化。那這時候再不斷上報無用數(shù)據(jù)的埋點(diǎn)，也就沒有必要了。

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

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

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

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

總結(jié)

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

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