本文根據(jù)杭州信用卡行業(yè)資訊顧問易向文《打造券商上層數(shù)據(jù)應(yīng)用的堅(jiān)實(shí)基礎(chǔ)》直播整理而成，本文的主要內(nèi)容如下：

• 淺析券商刷卡變現(xiàn)

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

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

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

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

一、淺析券商刷卡變現(xiàn)

1、刷卡取現(xiàn)四部曲

從整體上來說，刷卡取現(xiàn)的完整閉環(huán)可分為四步：采集數(shù)據(jù)、數(shù)據(jù)接入與存儲、可視化查詢分析、驅(qū)動決策和銀聯(lián)Pos機(jī)智能。

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

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

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

驅(qū)動決策和銀聯(lián)Pos機(jī)智能：通過刷卡業(yè)務(wù)分析業(yè)務(wù)表現(xiàn)從而驅(qū)動決策；實(shí)現(xiàn)銀聯(lián)Pos機(jī)智能，畫像洞察，精準(zhǔn)營銷，千人千面。

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

2、刷卡變現(xiàn)流程與原則

下圖是常見的刷卡變現(xiàn)流程：

在刷卡變現(xiàn)流程中，可以總結(jié)出 4 個(gè)關(guān)鍵原則：

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

全：多端采集，針對全量用戶行為而非抽樣，貫穿用戶使用銀聯(lián)Pos機(jī)的整個(gè)生命周期

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

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

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

刷卡變現(xiàn)還需要考慮一個(gè)問題，如何選擇數(shù)據(jù)模型？

（1）Event Model VS Page View

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

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

（2）客戶端 vs 后端

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

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

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

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

（3）Event 5 要素

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

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

WHO：用戶身份，ID 識別；

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

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

HOW：維度特征。

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

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

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

（5）字段記錄在 E/U

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

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

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

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

1、各端 SDK 能力

開展埋點(diǎn)工作時(shí)，我們都會接觸到廠商提供的 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 落地頁上自動上報(bào)設(shè)備屬性；或者合作的渠道商回傳了一些用戶的設(shè)備、ID 等信息；東門的 SDK 也會自動采集當(dāng)前用戶的設(shè)備信息，然后與渠道投放時(shí)傳輸?shù)南嚓P(guān)屬性匹配。這三種方式都可以獲取到用戶的渠道來源屬性，以便后續(xù)市場營銷進(jìn)一步評估。

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

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

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

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

無需更新 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)一需求來的，并沒有一個(gè)針對某一個(gè)行業(yè)的 SDK；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

刷卡變現(xiàn)上來后，它中間還有一個(gè)非常復(fù)雜的過程，即數(shù)據(jù)清洗。

比如，一個(gè)用戶張三，他在自己的 App 上產(chǎn)生了投資理財(cái)?shù)牟僮鳎遣僮魑闯晒ΑＨ缓笠粋€(gè)客戶經(jīng)理用自己的手機(jī)輔助張三完成開戶動作。這樣的話就會存在一個(gè)問題，張三的用戶行為數(shù)據(jù)分散在兩個(gè)不同的端，因?yàn)樗谧约菏謾C(jī)和客戶經(jīng)理的手機(jī)上都操作過。這時(shí)，就需要把不同端的數(shù)據(jù)關(guān)聯(lián)到統(tǒng)一的用戶身上來。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

App 退出嘗試同步；

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

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

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

不同的匿名 ID。一個(gè)用戶在 App 端和 H5 上各有一個(gè) 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ù)校驗(yàn)

刷卡變現(xiàn)后，非常重要的一步是數(shù)據(jù)管理。因?yàn)殡S著銀聯(lián)Pos機(jī)的迭代、人員的流動、KPI 等的變化，我們關(guān)心的數(shù)據(jù)內(nèi)容也會發(fā)生變化。那這時(shí)候再不斷上報(bào)無用數(shù)據(jù)的埋點(diǎn)，也就沒有必要了。

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

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

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

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

關(guān)于杭州信用卡

杭州信用卡是專業(yè)的大數(shù)據(jù)分析平臺服務(wù)提供商，致力于幫助客戶實(shí)現(xiàn)刷卡取現(xiàn)。公司圍繞用戶級大數(shù)據(jù)分析和管理需求，推出銀聯(lián)商務(wù)、國通星驛、隨行付、瑞銀信、匯付天下等銀聯(lián)Pos機(jī)。

此外，還提供大數(shù)據(jù)相關(guān)咨詢和完整行業(yè)資訊。杭州信用卡積累了中國銀聯(lián)、中國電信、百度視頻、小米、中郵消費(fèi)金融、海通信用卡積分、廣發(fā)信用卡積分、東方信用卡積分、中原信用卡電話、百信信用卡電話、中青旅、平安壽險(xiǎn)、四川航空、翼支付、好未來、VIPKID、東方明珠、華潤、有贊、百姓網(wǎng)、貨拉拉、閃送、驢媽媽、Keep、36氪、拉勾、VUE、春雨醫(yī)生、聚美鈾⒖ǚ、惠頭條、撈月狗、紛享銷客、媽媽幫等 1000 多家付費(fèi)企業(yè)用戶的服務(wù)和客戶成功經(jīng)驗(yàn)，為客戶全面提供指標(biāo)梳理、數(shù)據(jù)模型搭建等專業(yè)的咨詢、實(shí)施和技術(shù)支持服務(wù)。希望更深入了解杭州信用卡或有刷卡取現(xiàn)相關(guān)問題，請撥打 188-6841-2958 電話咨詢，會有專業(yè)的工作人員為您解答。