數據中臺實戰（一）：以B2B電商億訂為例，談談產品經理視角下的數據埋點

電子商務 B2B 產品經理百度統計 iOS 百度移動統計百度 Android 技術設計師時尚工程師硬件瀏覽器人人都是產品經理 2019-05-15

本文以B2B電商產品“億訂”為實例，與大家一同談談數據中臺的數據埋點。

筆者所在公司為富力環球商品貿易港，是富力集團旗下匯聚原創設計師品牌及時尚買手/採購商兩大社群，通過億訂B2B電商、RFSHOWROOM、環貿快版、環貿映像、富運通、富貿通等子品牌為時尚行業提供一站式產業＋渠道服務的平臺。

筆者所在部門為數據中臺，職責就是為公司搭建數據中臺，支撐各產品線數據化運營，通過數據中臺打通各條產品線的數據，更精準的為產業的上下游客戶服務。本文以B2B電商產品億訂為實戰，談數據中臺的數據埋點。

圖片來源：富力環球商品貿易港公眾號

剛入公司時，公司的數據埋點這塊是和百度合作，用的百度移動統計。

運營反饋百度的流量分析做的很強大，但是最大的問題是不能結合電商的業務數據，比如：只有坑位的流量數據卻拿不到坑位的交易額、轉化率（交易額/PV）這些數據，另外電商的主路徑訪問>商品詳情>商品列表>加購>下單>支付整個流程的轉化率是取不到的。

此時，就拉上我們的開發，叫上了億訂產品經理和運營負責人，一起溝通目前的問題。

圖片來源：百度移動統計，百度的移動分析看不到任何業務數據。

溝通後確定主要確定解決以下問題：

問題一：要知道億訂B2B電商產品每天的主路徑訪問用戶數>商品列表頁>商品詳情頁>加購>下單>支付主路徑每天的人數及每個步驟之間的轉化率。目的是長期監測每步的轉化率如果有明顯異常，運營同事會進一步分析轉化率低的原因。

圖片來源：億訂電商，從左到右以此為：首頁、商品列表、商品詳情、加購、結算頁

問題二：因為問題一隻能解決總體轉化率，要想定位到底是那裡的轉化率低導致整體轉化率低的原因，還得看用戶每個入口路徑各環節的轉化率。

問題三：要解決坑位的轉化率問題，因為評價坑位好壞的因素不止有PV/UV百度統計的兩個指標，運營同事定義了坑位的轉化率為（pv/坑位交易額）來綜合判定坑位的性價比，如果坑位的放在很明顯的位置，那他的轉化率還是很低，那就要分析原因，改變運營策略。比如圖片的調整、商品的調整、位置的調整等。

問題四：要打通用戶的行為數據和用戶的交易數據，用戶運營的同事需要更加了解他們的用戶比如什麼時候訪問，訪問了那些商品、什麼時候加購，加購了那些商品，什麼時候買了那些商品。這些百度是做不到的。通過用戶的訪問行為，運營同事會進行鍼對性的運營型。

問題五：要看到用戶的留存情況，留存的定義分為兩種，第一種是訪問留存率，新用戶第一次訪問看他接下來7天后、14天后、一個月後是否再次訪問。第二種是購買留存率，用戶第一次支付後看接下來的7天后、14天后、一個月後是否再次支付。這樣就能直接看出平臺的用戶粘性。

基於以上問題，我們數據中臺內部開始設計產品方案和技術方案。

關於技術方案

埋點技術選型

要解決以上問題，就要對億訂的H5端、APP端（IOS/安卓）進行全面的埋點，如果採用手工埋點的方式，工作量是比較大的，而且依賴各個產品線的前端開發（JS/安卓/IOS）。

我們的技術負責人研究了市面上各個數據公司的埋點方式，從是否開源，SDK是否支持H5、安卓、IOS。部署方式是私有化，還是saas化（採集到的用戶數據是公司比較重要的數據，出於安全考慮，需要本地化部署）這幾個方面入手決定用神策開源埋點SDK。

這樣節省了大部分的工作量，SDK一旦部署基礎信息比如（時間、地點、瀏覽器、硬件設備）都會自動化的採集。

基礎信息採集

接下來，就要進行埋點接口的定義。

首先，是公共字段的定義，這些都封裝在SDK中，只要前端工程師基於SDK的開發文檔進行工程部署，程序就是自動收集用戶的這些基礎信息。這樣用戶在那裡，用戶使用的什麼設備，用戶什麼時間訪問了我們的產品，就解決了。

瀏覽頁面事件採集

接下來，是用戶瀏覽頁面數據埋點，這個協調了億訂的產品經理梳理了億訂的所有網頁地址和按鈕名稱（為了後文的觸點埋點）包括上文提到的入口頁面推廣頁、首頁、商品列表頁、商品詳情頁、加購頁、下單頁、支付頁等關鍵頁面進行了全方位的埋點。

拿電商最關鍵的商品詳情頁舉個例子：他有可能是從坑位來的，有可能是從搜索來的、有可能是從推薦來的，要記錄他的來源信息，才能對以後的分析有作用。

比如：上文問題三提到的轉化率是涉及到坑位產生的交易額和PV兩個指標，那每次進入商品詳情頁，要記錄坑位的信息才能進一步計算出坑位的總的銷售額和轉化率。數據中臺是數據貪婪的應用，埋點收集到的信息當然是越詳細越好，不過過多的埋點也會影響前端的性能，所以所有的埋點都是基於問題指向的。

觸點事件採集

基於億訂業務線提供的按鈕列表，讓億訂的前端開發工程師對關鍵按鈕點擊進行了埋點開發。

有兩方面的作用：一方面如電商主路徑中的加購是按鈕點擊，而不是頁面點擊。這時就要通過觸點事件的方式，先收集數據，後期格式化為頁面瀏覽事件來處理；另一方面，如要看關鍵按鈕的點擊次數，關鍵頁面的轉化率（如登錄、註冊頁轉化率等）都需要統計按鈕的點擊。

關於產品方案

問題一

關於問題一的電商產品的主路徑：訪問用戶數>商品列表頁>商品詳情頁>加購>下單>支付，只用取這些頁面的UV就可以了，不過有幾個個問題需要注意。

訪問到到商品列表頁的轉化率：訪問用戶數最好是訪問了首頁+訪問了商品列表頁+訪問商品詳情頁的人數去重後的UV，因為也有人直接從商品列表頁或商品詳情頁進入產品。這樣算才能更精準。
加購>下單的轉化率可能大於100%，比如：今天加購的用戶可能在後天下單。
加購是一個按鈕不是頁面要格式化為頁面處理。

基於這些問題設計出了電商主路徑的頁面，主要可以看出每天的訪問用戶數、瀏覽商品列表頁用戶數、瀏覽商品詳情頁用戶數、加購用戶數、下單用戶數、收藏用戶數、分享用戶數和他們之間的轉化率。每天的轉化率我們以漏斗的形式展現，這樣更能直觀的看出轉化率的變化情況。點擊數字後可以查看用戶明細信息，可以直接導出這些結果，做針對性運營，這樣主路徑的問題就解決了。

問題二

運營用了一段時間就提出另外一個問題，天天看這些結果，但是就算髮現了轉化率比較低，也很難找出轉化率低的原因。

為了解決這個問題，我們基於百度的歷史數據發現：億訂的訪問入口（用戶第一次進入的頁面）只有這幾個推廣頁、首頁、活動頁、還有用戶直接從商品列表頁、商品詳情頁進入（大部分是朋友圈的推廣）。

如果能知道這些入口主路徑的轉化率，那問題範圍就縮小了。於是，就有了入口分析功能，和其他數據產品的路徑分析不太同，我們不但把入口主路徑的轉化率清晰顯示出來，還可以看每個路徑每天的變化趨勢。

這樣就可以更加直觀的觀察出路轉化率低那條路徑，計算的方法要在這裡講下：

第一步把所有的用戶訪問分為N個會話（我們會話的間隔時間定義為20分鐘，也就是訪問一個頁面後如果超過20分鐘才訪問下一個頁面，那下一個頁面就算另外一個會話）。
第二步找出用戶首次訪問包含這些入口的會話。
第三步把用戶的訪問路徑打橫，遍歷用戶的訪問路徑如果滿足我們定義的路徑，這條路徑就會算一個UV。計算時商品列表頁它是從搜索來的，還是從分類來的，還是直接從首頁來的已經提前打好標識。

問題三

坑位轉化率涉及坑位交易額，但是埋點數據有5%左右的丟失率，比如：用戶操作時的網絡不好，此時用戶的埋點數據就無法正常上傳到埋點服務器。

我們需要做到100%的精準，另外就是電商的加購是有一個斷層的，比如：用戶今天加購，沒有購買，過了2天直接進入購物車買商品。

此時，如果通過普通的數據埋點是很難得到購物車商品的來源的。和億訂的前端開發工程師商量後，就決定採用後端埋點的方式。用戶加購時將坑位的ID信息傳至數據庫，每次從購物車取出商品支付時再從數據空中取出商品的所屬坑位ID，下單時將坑位ID保存至訂單中，這樣從訂單中就能直接分析出這個商品來源於那個坑位。

問題四

採、存、通、用是對數據中臺價值最好的解釋。

採就是採集要採集用戶行為數據和業務數據；存就是通過三層建模的方式對數據進行更科學的存儲；通是打通，第一要打通用戶用戶行為數據和用戶業務數據，比如能綜合看到埋點採集到的數據像時間、地理位置、硬件設備和用戶的購買行為像瀏覽、訪問、加購、購買、收藏、分享等。

打通的第二層含義就是要打通公司內各個產品線的數據，比如：筆者公司要做產業的上下游，就要打通生產數據、銷售數據、供應鏈數據，形成更加立體的用戶畫像。產品線之前的數據打通會在《數據中臺實戰-基於多條產品線的標籤平臺》中介紹。

問題五

留存率的概念每種產品都不同，一般來說就是鎖定一批發生了某種行為的用戶，看接下來的7天或者14天等等是不是又發生了這種行為。

電商產品的留存率是電商產品的北極星指標，是這樣定義的：一個新用戶在第一次來到產品後的一週內，如果一週內能讓他購買1-2次，那接下來他的復購率會非常高。

但是，不同電商產品的消費頻次是不同的所以基於我們產品的特性。我們做了7日留存率、14日留存率、30日留存率這幾個數據指標來監控平臺的用戶粘性。另外就是電商產品初期用戶量和交易量是比較小的，所以我們還特別定義了一個訪問留存率的指標，看新用戶訪問後，7日後的留存情況、14日後的留存情況來綜合監測用戶的黏性。