字節跳動楊震原：抖音電商是如何實現數據驅動的？

7 月 20 日，火山引擎原動力大會在京舉辦。會上，火山引擎發佈了全新 Slogan“雲上增長新動力”。並推出了以云爲底座的一系列產品解決方案。

字節跳動副總裁楊震原以抖音電商爲例，分享了火山引擎是如何支持公司內部業務做好數據驅動的。他表示，“數據驅動理念在抖音電商上的實踐，這些經驗、這些技術能力，都已經沉澱到了火山引擎數據產品上。我希望火山引擎也能夠幫助企業客戶獲得增長的新動力。”

以下爲楊震原演講全文：

大家好，我叫楊震原，很高興大家有時間來參加火山引擎的發佈會。

大家都知道，火山引擎是字節跳動技術中臺能力的對外輸出。剛纔譚待（火山引擎總裁）講了火山引擎更新了 Slogan，要爲更多企業提供 “雲上增長新動力”，數據驅動是增長動力中非常重要的一個因素。接下來，我會爲大家分享字節跳動內部業務是怎麼做到數據驅動的。

首先要說的是，數據驅動並不是有數據就能驅動，而是要從解決一個一個的業務問題運轉起來：我們需要明確業務的目標是什麼，這個目標要能夠量化，因爲有了量化，才能優化；優化的效果一定不是憑感覺，而是要用 A/B 測試等客觀的分析評估方法；業務過程的數字化也是非常重要的，數字化越充分，對業務的描述就越精準；還有數字化的協同工作，包括數據治理等手段讓底層數據得到規範、統一的表達，通過數據可視化等工具讓更多的業務角色使用起來。

在圍繞業務目標持續的優化和評估過程中，數據驅動會成爲內部協同的日常習慣，最終使產品得到更有效的改進，這就是數據驅動基本的方法。這裏我分享下抖音電商在數據驅動上的一些實踐經驗。

簡單介紹一下抖音電商，大概是在 2020 年的 6 月份成立的。大家可以看到，我們數據產品對抖音電商支持的一些重要節點，還有電商業務給數據產品的 NPS（淨推薦值）打分情況。2020 年 11 月，數據產品已經能夠支持抖音電商裏面的核心業務，獲得了一個比較好的 NPS 反饋， 到今天 NPS 值應該已經達到 70% 左右了，這中間我們也做了各種各樣的工作，很多的改進，也可以說是跟着抖音電商一路成長過來。

生意轉化以秒計算，

如何提供高效實時反饋

支持一項全新的業務，數據產品會面臨各種各樣的挑戰。第一大挑戰是，實時。

抖音電商轉化路徑很短，轉化時間常常以分甚至以秒來計算。大家可以想象，在直播賣貨的過程中，不管是主播還是運營，他們對數據實時性的要求是非常高的。今天主播講一件商品，可能在接下來的 5 秒鐘，就有幾萬單甚至幾十萬單的訂單產生，所以需要有非常實時的數據反饋，能夠讓主播、讓運營人員更快更準確地做選品調整，或者及時制定一些營銷策略，這樣才能夠讓業務更好地發展。

這和很多傳統的貨架電商模式是不一樣的。實時需求場景非常多，業務活動的頻次又很高。如何在這樣不斷爆發的需求之下，還能夠保證數據支持能夠很實時地完成，我們的做法是實時數倉。

實時數倉看起來並不是一個新的概念，很多公司都在做實時數倉，想做出來也並不很難，但是真的去業務裏應用實時數倉的時候，遇到的挑戰還是非常多的。我舉一個例子，比如說數據的一致性問題，今天直播可以很快收到數據實時的分析。但是當過了兩三天之後，當你去看一些統計數據，發現前後不一致怎麼辦？這就是很大的問題。

再比如在非常快的需求迭代過程中，整個鏈路的全流程管理是不是能做好。數據的發佈，是不是有合適的工具，測試是不是有合適的工具，以及數據監控是不是能夠到位？實時數據一旦出問題，它修復的代價是很大的。它不像離線的數據，大不了重跑一遍就可以了。

所以從整個流程來看，做好實時還是很有挑戰的。我們的數據產品經過了很多業務、很長時間的迭代，實時數倉已經做得比較完善了。對抖音電商來說，我們現在已經能夠提供比較全套的實時數據。

實時大屏，可以給運營人員、主播實時反饋各項核心指標；實時分析，是指如果現有的實時指標不夠，可以在實時分析的平臺臨時性地做一些分析查詢，比如說你突然想分析某一個目標人羣，或者你想做一個臨時的漏斗分析等等，這裏提供了非常靈活的 SQL 的查詢，並且對實時數據流做處理；實時預警可以配置各種規則，當業務情況發生變化，比如當前的流量突然下滑，它就可以提供報警的功能，或者配置自動觸發一些操作；實時營銷也給運營人員提供了工具，比如運營發現 “創單到成功購買” 的轉化低，可以分析出未成功購買的人羣是不是對價格敏感，或者是其他因素影響，從而制定一些對應的營銷策略，讓業務有更好的轉化。

大促頻率高、新玩法多，

如何敏捷支持各項業務訴求

第二大挑戰是敏捷的需求。

如今電商大促的頻率很高，電商這個業務又有個特點，新玩法多。要做好敏捷支持，有很多技術的方法。我今天想給大家分享一個組織模式，就是數據 BP。

數據 BP 實際上是一種分工的方法。我們有做公共產品的團隊，叫做數據平臺，就是去做一些通用的功能，做通用的數據產品，能夠在基礎上提供支持。數據 BP 則是嵌入到每一個業務裏面去的，比如說抖音電商就有一個數據 BP 團隊，他們完全和抖音電商的業務目標去對齊，爲抖音電商的目標而努力。同時他們也對數據平臺內部非常瞭解，能夠充分地利用數據平臺的產品。同時，抖音電商的數據 BP 還會把業務需求引入到數據平臺，幫助數據平臺成長，這個機制我們認爲是成功有效的。

我們總結了幾個數字說明數據 BP 的服務標準，叫 0987。

0 是做到零數據事故。這看起來是一個很基本的要求，但是在業務複雜多變的情況下，實現零數據事故並不容易，它對技術的能力、對運維、對治理都提出了很高的要求。

第二個數字是 9，指的是 90% 的需求滿足。從這個數字中，大家也可以看到數據 BP 是一個服務型團隊，它要能把業務的需求轉化出來，滿足好。這要求團隊對業務很熟悉，能夠和產品、和業務的人員有深入的互動，能夠一起討論需求，去幫助業務修改甚至提出需求，這樣才能真正實現 90% 的需求滿足。

第三個數字是 8，指的是 80% 的分析，要能夠通過主題表、中間表的方式來覆蓋，這對中間數據的建設提出了一個很高的要求。80% 這個尺度我們自己衡量了很久，認爲是一個合適的值。當這個數字很大，比如說希望所有數據都能夠通過中間表覆蓋，其實是不必要的，因爲可能過度抽象很多中間數據，也許需求剛剛提完，中間數據表剛建設完，業務就變了。但這個數字太低的時候，也就意味着有大量的分析是直接基於原始數據來做的，這就會帶來很多問題，比如一些指標相似而不相同，口徑不一致，一些分析跑得很慢等等。從大量業務實踐來看，80% 的分析覆蓋是一個相對合理的目標。

最後這個 7，指的是 70% 的 NPS，這在行業裏是一個很高的標準，代表業務滿意度的一個評價。我們要能夠通過這個指標，去發現數據服務環節中的各個問題，來提高業務的滿意度。

數據 BP 的機制在字節內部是很有效的。我舉一個例子，不久前抖音電商的 618 大促活動，業務提了很多玩法需求，都需要定製的數據支持。這裏面有 10 個需求在 5 月 17 日才完成數據詳評，上線開發時間非常緊急。但因爲有之前沉澱的模型，數據 BP 判斷可以複用 4 個，部分可複用 3 個，10 個工作日內就做了 100% 的交付，並沉澱新的玩法模型，可以應用到下次的大促中。我覺得如果沒有數據 BP 的組織模式，想支持好這樣緊迫的活動是很難做到的。

如何在滿足實時、

敏捷的同時確保穩定

電商業務與錢相關，數據一定要算對，容錯率極低。同時，業務運營重度依賴數據，每天都需要根據數據來做決策，數據必須準時產出。這就帶來了第三大挑戰，就是穩定。

要想穩，實際上有一些基礎的工作，比如監控、運維質量等。我這裏想講的一點是數據治理，在實時、敏捷的同時保證穩定，治理是一個特別重要的問題。因爲如果不做好數據治理這件事，業務的複雜度，其中冗餘的問題以及一些混亂的因素，是沒有辦法通過監控和運維機制就能解決的。

我們提到幾個做法，一個叫分佈式治理，一個叫經驗複用，一個叫經驗沉澱到工具（DataLeap）。

爲什麼提分佈式治理呢？我們早期實際上並不是分佈式治理，而是專職團隊治理，就負責數據治理工作。但是當我們作爲數據團隊去支持衆多業務的時候，這個模式就難以爲繼了，我不可能讓一個專門的治理團隊去治理各個業務。

所以我們提出了分佈式治理，就是要有治理委員會去制定各種標準，這些標準也都是從業務上傳，在每個業務中也會有專人負責治理工作，讓治理工作自下而上產生出來。

經驗複用，就是我們在一個成熟產品積累了很多經驗，當我們再去支持一個新的產品，能夠快速地把成熟產品的經驗借鑑起來，不要再走一遍先污染後治理的老路。除了經驗複用之外，還要把經驗沉澱在工具中去，這纔是能進一步擴大槓桿的方法。

DataLeap 數據產品提供了一整套的數據治理工具。這源於在長期以來的數據處理中，我們會把一些通用的能力沉澱到工具中，當新業務直接使用這些工具時，就不會在初期挖很多坑，可以直接達到一個比較高的數據治理水準。

讓數據驅動成爲習慣

剛纔聊了抖音電商在數據驅動實踐過程中的三個挑戰。接下來我再簡單介紹一下業務不同角色如何做好數據化的運營和決策。

數據產品絕對不是隻給管理者用的，它要能夠給公司各個角色各個層級的人去用，幫助每個人都能夠有更好的決策。但是不同的角色需要有不同的數據產品，這樣才能夠提高效率，更有針對性。

比如說對管理層，我們提供了管理駕駛艙，管理者能夠直接看到一些宏觀的指標，看到一些趨勢的變化，輔助管理者做出更及時有效的決策。對於一線 Leader，對運營和風控等一線人員，他們可能需要看業務數據，比如羅盤，同時他們也可能需要 BI（敏捷分析平臺），可能需要人羣畫像、行爲分析等等能夠指導一線工作的工具。因此我們針對不同的業務角色，也會去專門地定製不同的產品來滿足各個角色的需要。

在字節跳動內部，每月有超過 10 萬員工直接使用 BI 產品，可以說數據驅動已經成爲大家日常工作的一種習慣，深入人心。

這是字節跳動整個數據產品體系的架構圖，上面是各種業務，我們通過數據 BP 的機制支持不同業務。然後是一些是數據應用產品，直接給公司的不同角色使用。底下有一些偏基礎的產品，比如說數據建設、數據引擎等，能夠支持我們上層的應用。這樣一套體系，既能夠支持不同業務個性化的需求，也能夠經驗複用，把一些底層能力複用。這些能力和工具也都在火山引擎上形成了對應的產品，提供給外部客戶使用。

技術與業務互相塑造、共同成長

我一直有一個理念，技術和業務是一個互構的關係，互相折騰，製造麻煩，共同成長。就像剛纔我分享的抖音電商的例子，這個業務在成長過程中對技術部門提出了很多需求，給數據產品造成了很多 “麻煩”。正是因爲這些 “麻煩”，數據產品才能更好地改進。反過來說，優秀的數據產品也讓抖音電商的效率提高。技術和業務互構，互相塑造、共同成長。

以上就是我的分享。字節跳動技術中臺支持公司業務的這些經驗、這些技術能力，都已經沉澱到了火山引擎上。我希望火山引擎也能夠幫助我們的客戶提升業務價值，獲得新的增長動力。謝謝大家。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8mG6FkzrCUugvXIdVt-z5A