本文根據神策數據解決方案顧問易向文《打造券商上層數據應用的堅實基礎》直播整理而成，本文的主要內容如下：

• 淺析券商數據采集

• 常見的埋點方式介紹

• 如何做好用戶數據關聯

• 數據管理與數據校驗

注：圖中數據均為虛擬數據。

一、淺析券商數據采集

1

數據驅動四部曲

從整體上來說，數據驅動的完整閉環可分為四步：采集數據、數據接入與存儲、可視化查詢分析、驅動決策和產品智能。

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

數據接入與儲存：通過多種數據接入方案，確保提供適合業務需求的數據接入手段，便捷將各不同源數據入庫，保證格式的統一性。

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

驅動決策和產品智能：通過業務指標分析業務表現從而驅動決策；實現產品智能，畫像洞察，精準營銷，千人千面。

這個框架的重點在于數據采集，引用神策數據咨詢師徐美玲的一句話：“不可用的數據不是資產，而是負資產。”我們甚至會非常頭痛如何提升數據質量，讓它變得可用起來。

2

數據采集流程與原則

下圖是常見的數據采集流程：

在數據采集流程中，可以總結出 4 個關鍵原則：

大 ：做好長期的數據建設，要充分考慮用戶規模與數據規模的增長，做好數據資產的積累

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

細：盡可能采集足夠全面的屬性與維度，盡量保存數據細節，讓積累的數據資產更加優質。例如，從 （5W） 這 5 個角度來采集用戶行為數據

時：在技術條件與成本允許的情況下，盡可能地提高數據采集的時效性，從而提高后續數據應用的時效性

3

數據模型選擇

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

（1）Event Model VS Page View

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

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

（2）客戶端 vs 后端

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

• 前端拿不到部分數據。比如說在做理財產品的申購時，一般情況下需要等后端確認后才能得到購買成功的結果。所以，從后端傳輸結構數據更加符合業務邏輯。

• 前端采集存在數據傳輸丟失的風險。而從后端采集數據，可有效避免。

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

（3）Event 5 要素

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

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

WHO：用戶身份，ID 識別；

WHEN：用戶當前時間；

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

HOW：維度特征。

（4）字段設計原則

• 從業務需求出發，通過指標需求，倒推需要哪些字段；

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

（5）字段記錄在 E/U

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

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

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

二、常見的埋點方式介紹

1

各端 SDK 能力

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

• SDK 核心是通過埋點來采集數據；

• 在 SDK 配置 Schema 將采集的數據傳輸到指定的服務器端；

• SDK 支持我們去定義相關的策略，最大限度的保證數據的準確性和完整性，如：緩存策略、同步策略、網絡策略等。

2

常見埋點方式
?

（1）全埋點（無埋點）

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

全埋點支持的事件類型 ：

• 激活

• App 啟動（$AppStart）

• App 退出（$AppEnd）

• App 頁面瀏覽（$AppViewScreen）

• App 控件點擊（$AppClick）

• 曝光

• Crash

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

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

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

全埋點的優點在于：

• 周期短，埋點代價比較小；

• 無需更新 App，便于后續優化迭代；

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

• 網頁的點擊熱力圖強烈依賴全埋點，需要它去支撐相關內容。

當然，全埋點也有應用缺陷：

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

• 無法自動采集業務相關的數據。數據廠商提供的 SDK 是按照滿足市場的統一需求來的，并沒有一個針對某一個行業的 SDK；

• 無法滿足更精細化的分析需求。SDK 僅能采集一些相對比較統一的事件，無法滿足行業繼續下鉆、細分的訴求；

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

• 傳輸的數據量太大、浪費資源。因為用戶的任意行為都會被采集上報，從經濟上考量，數據量成本可能過大；

（2）代碼埋點

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

• 顯而易見，代碼埋點的優點如下：

• 精準控制埋點；

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

• 采集數據豐富；

• 可以滿足更精細化的分析需求。

當然，代碼埋點也有兩個缺點：

• 埋點代價比較大，在排期緊張的時候，代碼埋點不易推進；

• 埋點的更新和新增需要伴隨著 App 發版。

（3）可視化全埋點

全埋點和代碼埋點各有優劣，那可視化全埋點就是結合了兩者的優點，在全埋點的基礎之上，通過可視化的方式對 $AppClick 事件進行一些配置或者自定義操作。比如說，一旦應用端的集成好 SDK 和配置好數據接受地址后就可以直接掃描頁面上的二維碼，同步 App 端和網頁端的動作。

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

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

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

下方表格是對幾種不同的埋點方式的總結：

3

如何選擇埋點方案？
?

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

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

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

三、數據關聯

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

比如，一個用戶張三，他在自己的 App 上產生了投資理財的操作，但是操作未成功。然后一個客戶經理用自己的手機輔助張三完成開戶動作。這樣的話就會存在一個問題，張三的用戶行為數據分散在兩個不同的端，因為他在自己手機和客戶經理的手機上都操作過。這時，就需要把不同端的數據關聯到統一的用戶身上來。

場景一：用戶在多家公司產生開戶行為

某個券商公司，在用戶開戶時會分配給用戶一個客戶號以及一個相關的資金賬號。同時，用戶在開戶前也會在券商 App 端注冊留下手機號碼和設備信息。采集該用戶的數據后發現，該用戶在不同的券商公司做過多次開戶，而用戶的客戶號可以統一關聯到一個類似一碼通的證券賬戶上。

這時做用戶數據關聯就比較復雜，神策的建議如下：

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

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

場景二：券商希望單獨分析注冊開戶流程，引入互聯網運營經驗，對沒有開戶但平臺認為有價值的用戶進行運營，促進用戶轉化。

這時存在兩種情況：

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

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

下面簡單介紹下如何保證埋點數據的完整性和準確性

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

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

• 本地緩存一定條數量的事件會同步（默認 100 條）；

• 固定時間間隔同步（默認 15 秒）；

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

• App 退出嘗試同步；

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

此處強調下 App 與 H5 打通的必要性：

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

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

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

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

四、數據管理與數據校驗

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

在此，我們推薦一個相對比較成熟的數據管理功能——數據入庫強校驗模式。在該模式下，一旦用戶做了某個行為被采集上報后，系統會進行自動化檢測，看這個數據符不符合我們的規范。如果不符合，就可以直接拒絕數據入庫，進而最大程度上保證數據的純凈性和準確性。

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

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

本文主要從埋點方式上分享了券商行業如何做好數據建設，打好上層數據應用的堅實基礎，感謝大家的聆聽。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。