背景

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

圖片來源：富力環(huán)球商品貿易港公眾號

剛入公司時，公司的數(shù)據(jù)埋點這塊是和百度合作，用的百度移動統(tǒng)計。運營反饋百度的流量分析做的很強大，但是最大的問題是不能結合電商的業(yè)務數(shù)據(jù)。比如只有坑位的流量數(shù)據(jù)卻拿不到坑位的交易額、轉化率（交易額/PV）這些數(shù)據(jù)，另外電商的主路徑 訪問>商品詳情>商品列表>加購>下單>支付整個流程的轉化率是取不到的。此時就拉上我們的開發(fā)，叫上了億訂產品經(jīng)理和運營負責人，一起溝通目前的問題。

圖片來源：百度移動統(tǒng)計，  百度的移動分析看不到任何業(yè)務數(shù)據(jù)。

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

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

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

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

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

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

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

基于以上問題，我們數(shù)據(jù)中臺內部開始設計產品方案和技術方案。

關于技術方案

埋點技術選型

要解決以上問題，就要對億訂的H5端、APP端（IOS/安卓）進行全面的埋點，如果采用手工埋點的方式，工作量是比較大的，而且依賴各個產品線的前端開發(fā)（JS/安卓/IOS）。我們的技術負責人研究了市面上各個數(shù)據(jù)公司的埋點方式，從是否開源，SDK是否支持H5、安卓、IOS。部署方式是私有化，還是saas化（采集到的用戶數(shù)據(jù)是公司比較重要的數(shù)據(jù)，出于安全考慮，需要本地化部署）這幾個方面入手決定用神策開源埋點SDK，這樣節(jié)省了大部分的工作量，SDK一旦部署基礎信息比如（時間、地點、瀏覽器、硬件設備）都會自動化的采集。

基礎信息采集

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

瀏覽頁面事件采集

接下來是用戶瀏覽頁面數(shù)據(jù)埋點，這個協(xié)調了億訂的產品經(jīng)理梳理了億訂的所有網(wǎng)頁地址和按鈕名稱（為了后文的觸點埋點）包括上文提到的入口頁面推廣頁、首頁、商品列表頁、商品詳情頁、加購頁、下單頁、支付頁等關鍵頁面進行了全方位的埋點。拿電商最關鍵的商品詳情頁舉個例子，他有可能是從坑位來的，有可能是從搜索來的、有可能是從推薦來的，要記錄他的來源信息，才能對以后的分析有作用。比如上文問題三提到的轉化率是涉及到坑位產生的交易額和PV兩個指標，那每次進入商品詳情頁，要記錄坑位的信息才能進一步計算出坑位的總的銷售額和轉化率。數(shù)據(jù)中臺是數(shù)據(jù)貪婪的應用，埋點收集到的信息當然是越詳細越好，不過過多的埋點也會影響前端的性能，所以所有的埋點都是基于問題指向的。

觸點事件采集

基于億訂業(yè)務線提供的按鈕列表，讓億訂的前端開發(fā)工程師對關鍵按鈕點擊進行了埋點開發(fā)。有兩方面的作用，一方面如電商主路徑中的加購是按鈕點擊不是頁面點擊這時就要通過觸點事件的方式先收集數(shù)據(jù)后期格式化為頁面瀏覽事件來處理。另一方面如要看關鍵按鈕的點擊次數(shù)，關鍵頁面的轉化率（如登錄、注冊頁轉化率等）都需要統(tǒng)計按鈕的點擊。

關于產品方案

問題一

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

1.訪問到到商品列表頁的轉化率 訪問用戶數(shù)最好是訪問了首頁+訪問了商品列表頁+訪問商品詳情頁的人數(shù)去重后的UV，因為也有人直接 從商品列表頁或商品詳情頁進入產品。這樣算才能更精準

2.加購>下單的轉化率可能大于100%，比如今天加購的用戶可能在后天下單。

3.加購是一個按鈕不是頁面要格式化為頁面處理。

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

問題二

運營用了一段時間就提出另外一個問題，天天看這些結果，但是就算發(fā)現(xiàn)了轉化率比較低，也很難找出轉化率低的原因。為了解決這個問題我們基于百度的歷史數(shù)據(jù)發(fā)現(xiàn)億訂的訪問入口（用戶第一次進入的頁面）只有這幾個 推廣頁、首頁、活動頁、還有用戶直接從商品列表頁、商品詳情頁進入（大部分是朋友圈的推廣），如果能知道這些入口主路徑的轉化率，那問題范圍就縮小了。于是就有了入口分析功能，和其他數(shù)據(jù)產品的路徑分析不太同，我們不但把入口主路徑的轉化率清晰顯示出來，還可以看每個路徑每天的變化趨勢。這樣就可以更加直觀的觀察出路轉化率低那條路徑。計算的方法要在這里講下，第一步把所有的用戶訪問分為N個會話（我們會話的間隔時間定義為20分鐘，也就是訪問一個頁面后如果超過20分鐘才訪問下一個頁面，那下一個頁面就算另外一個會話）。第二步找出用戶首次訪問包含這些入口的會話。第三步把用戶的訪問路徑打橫，遍歷用戶的訪問路徑如果滿足我們定義的路徑，這條路徑就會算一個UV。 計算時商品列表頁它是從搜索來的，還是從分類來的，還是直接從首頁來的已經(jīng)提前打好標識。

問題三

坑位轉化率涉及坑位交易額，但是埋點數(shù)據(jù)有5%左右的丟失率，比如用戶操作時的網(wǎng)絡不好，此時用戶的埋點數(shù)據(jù)就無法正常上傳到埋點服務器。我們需要做到100%的精準。另外就是電商的加購是有一個斷層的，比如用戶今天加購，沒有購買，過了2天直接進入購物車買商品，此時如果通過普通的數(shù)據(jù)埋點是很難得到購物車商品的來源的。和億訂的前端開發(fā)工程師商量后，就決定采用后端埋點的方式。用戶加購時將坑位的ID信息傳至數(shù)據(jù)庫，每次從購物車取出商品支付時再從數(shù)據(jù)空中取出商品的所屬坑位ID，下單時將坑位ID保存至訂單中，這樣從訂單中就能直接分析出這個商品來源于那個坑位。

以上就是本次分享有關數(shù)據(jù)中臺-數(shù)據(jù)埋點的所有內容，接下來會持續(xù)更新有關數(shù)據(jù)中臺的產品設計、標簽平臺的搭建、推薦系統(tǒng)的搭建等更多干貨。全部基于實戰(zhàn)，歡迎持續(xù)關注。