網易嚴選數據產品實踐
數據產品是個新興的產品分類，每個人眼裏都有一個自己的數據產品，儘管在絕大部分人的概念中都是一堆報表。在過去的3年裏，網易嚴選技術團隊在用戶需求的推動下，也藉助了網易易數的產品，一步步構建了網易嚴選數據產品體系，下文分享在構建過程中自己的一些思考和總結。
背景
本文內容來自我在2020產品經理大會上《網易嚴選數據產品實踐與方法論》分享的文字總結，由於篇幅原因，只包含了實踐部分。數據產品是個新興的產品分類，每個人眼裏都有一個自己的數據產品，儘管在絕大部分人的概念中都是一堆報表。在過去的3年裏，我們在用戶需求的推動下一步步構建了網易嚴選數據產品體系，在構建過程中也有一些自己的思考。
網易嚴選數據產品實踐主要分爲以下4個階段：「業務有數可看」、「數據質量保障」、「CXO有處看數」、「場景化數據產品」。這4個階段其實並沒有明顯的階段之分，各階段高度重疊，很多時候都同時在推進。接下來，我會從每個階段面臨的需求(問題)，以及我們採用的產品解決方案來詳述我們的實踐之路。
一、業務有數可看
2017年，我剛來嚴選的時候，是嚴選數據產品起步的階段，我們主要面臨事多、人少、工具差的三大問題(應該也是各個數據部門長期面臨的問題)。
「事多」主要是因爲業務方多且當時業務數據需求有一波激增。現代商業(特別是在線業務)數據重要性不言而喻，業務需要通過數據來了解業務現狀，發現業務的機會點和風險點。網易嚴選作爲品牌電商，業務鏈路特別長，相較於純互聯網業務主要有產品運營部門，品牌電商還有很重的供應鏈、商品、客服等部門，記得當時光二級部門就有30+，每個部門都有數據需求。當時還不斷有電商互聯網大廠的管理層加入嚴選，基於他們在原來公司比較先進的數據監控體系，提了大量數據需求，帶來一波業務數據需求的激增。「人少」是部門初建的常規問題，當時我們數據開發10個不到(還有2個實習生數據產品經理)，跟我們合作的數據分析師應該也就10個左右。當時使用的報表工具有BIEE、excel、自己開發的數據產品(報表集合)，數據開發主要寫MR加工數據，網易猛獁+網易有數儘管也已經引入，但是沒有用正確的姿勢大規模的使用起來。
面對「業務有數可看」的需求，我們通過構建數據倉庫+嚴選有數(敏捷BI平臺)的方案來解決。數據開發工程師在網易猛獁大數據開發平臺使用SQL高效地進行數據開發構建數據倉庫，數據分析師基於數據倉庫在網易猛獁上使用SQL高效地進行分析集市的開發，再使用網易有數通過拖拽和配置的方式快速進行報表開發。經過數據分析師和數據開發工程師的辛勤工作，嚴選有數目前有8w的圖表(加上其他數據產品一共10w+)，工作日PV 6K+，周UV900+，對於一個事業部級別的BI平臺，報表量和訪問量應該算是非常不錯了。那我們是如何做到這樣的規模呢？首先應該感謝數據分析師和數據開發工程師的辛勤開發，開發了大量的報表和數據模型。因爲本文主題是數據產品，接下來我主要從數據產品(嚴選有數)的角度展開講下我們方案的優勢。
嚴選有數是網易有數在嚴選的一個私有部署版本，在網易有數的版本上結合數倉做了性能優化，在開放協同上也做了一些功能擴展。
嚴選有數繼承了網易有數簡單易用的特性，只需要簡單拖拽即可進行可視化分析，支持分析師快速製作數據報表。PPT式的操作，讓分析師能夠快速進行報表佈局、圖層管理、圖表樣式優化，製作出業務人員友好的報表。
由於嚴選有數承載的報表數量大、大數據查詢引擎的併發性能差、業務人員集中在開始上班時間(9點多)併發查看報表，性能問題一直是影響業務人員高效閱覽報表的主要問題。在性能方面，我們優化查詢引擎(Imapla)的同時，通過數據產出驅動的緩存極大的提升了性能，支持業務人員快速閱覽報表。最早，嚴選有數採用常規的被動緩存，圖表首次訪問落庫查詢(並緩存)，後續訪問查詢緩存。業務人員上班後(9點多)集中訪問報表，大量圖表首次訪問進行落庫查詢，查詢引擎瞬間就崩了。那時候幾乎每天早上都被嚴選有數羣裏用戶對BI平臺崩了的抱怨，搞得焦頭爛額，儘管暫時通過限流排隊，解決崩的問題，但還是大量用戶排隊訪問不了報表。我們的第一次改進，是把被動緩存改成定時主動緩存，因爲報表數據絕大部分是T+1的，當日數據產出後不會變化，所以在每天7點數倉(及分析集市)產出後，集中進行主動緩存。
改進後70%以上的圖表訪問都能命中緩存，秒級影響，極大地提升了用戶的閱覽體驗。隨着圖表數量的快速增加，7點-9點多之間緩存的佔比越來越低，平臺的平均性能越來越差，用戶圖表平均訪問時間也不斷增長，每天早上嚴選有數羣裏各種用戶抱怨又開始出現。我們再次改進了我們的緩存方案，把定時主動緩存改成了數據產出驅動的緩存。通過監聽數倉表(及分析集市表)產出的消息，每次有表產出時遍歷依賴該表的所有圖表，如果相應的圖表依賴的表都已經產出就開始進行緩存。這樣我們就不用等到7點開始進行主動緩存，而是從0點開始只要圖表依賴的表已經產出就開始進行主動緩存，這樣從0到9點多，我們就能預先緩存大量圖表。我們的圖表緩存命中率達到80%以上(最近缺乏人力持續優化下跌到70%左右)，命中緩存的圖表都秒級響應。
在網易有數的基礎上，我們還增加了一些開放協同的功能點。我們根據業務人員所屬業務域，開放了儘量多的數據權限(能看到更多數據，才能產生更多分析的想法)。我們開發了維度/指標級搜索功能，讓業務人員通過搜索維度/指標名稱，快速從衆多的報表中找到他想要的報表。我們在報表右上角提供了聯繫作者的快速入口，當業務人員閱覽報表時，如有疑問可以快速喚起popo聯繫報表作者。通過一系列開放協同的產品功能，讓業務人員可以看到更多的數據，可以更快速的找到想要的數據報表，可以便捷的聯繫報表作者(分析師)，形成業務人員看更多數據->產生更多數據需求->聯繫分析師提進一步分析需求->分析師開發更多分析報表的分析閉環。
二、數據質量保障
由於數據源多、數據鏈路長、數據指標口徑複雜等原因，數據質量問題多、保障難度大。從用戶的角度看數據質量主要存在晚、錯、不一致的問題。
「晚」是指報表產出晚，實時數據延遲。由於報表數量大，對應的數據處理任務(數倉、數據集市)也很多，任務的出錯和運行超時都可能導致數據產出晚。18年時，嚴選有數用戶羣裏，用戶反映報表晚產出是常態。實時數據延遲主要會在大促時候出現，實時UV、在線人數常常會延時。「錯」主要指數據指標錯誤和用戶標籤錯誤。數據源裏一條記錄的丟失、一個字段的錯誤，數據處理任務鏈路上一個處理邏輯的錯誤、任務的延遲都可能導致數據指標、用戶標籤的錯誤。「不一致」主要指同一指標在不同的報表不一致，指標口徑業務理解不一致。因爲同一個指標會出現在不同的有數報表以及不同的數據產品中，經常會出現業務在不同的報表裏看到指標不一致的情況。同一個指標名稱在不同的上下文可能有多種口徑，光毛利相關的口徑就有5+個，業務人員對同一個指標的口徑理解可能會不一致。
數據質量保障是一個複雜而系統化的工程，展開講可以寫一本書，本文的主題是數據產品，下面主要從數據產品的角度講下我們的數據質量保障的解決方案。針對數據質量保障需求，我們設計開發了一系列中臺數據產品來保障數據的完整性、準確性和穩定性。
在剛開始構建數倉的時候，我們就形成了默認的規則，所有的業務數據庫、業務日誌都接入數倉，保障了在線化數據的完整性。儘管我們嚴選產技團隊，幾年來加班加點地不斷研發系統，但是嚴選依然有很多業務沒有線上化，進而數據不能通過業務系統、日誌進入數倉。一方面是因爲作爲品牌電商，業務鏈路長，對應的業務線上化的需求也多，另一方面業務不斷更精細化運營、不斷探索新的業務方向(這樣才互聯網)，進而不斷產生新的業務線上化需求。針對尚未線上化的業務過程，我們開發了數據填報系統，業務通過excel就可以快速把數據導入數倉。
數據產品經理結合業務需求通過指標管理系統先定義指標(口徑、描述等)，數據開發同學通過數倉設計系統根據指標定義進行數倉模型的設計，網易猛獁大數據開發平臺根據數倉設計系統的模型設計來新建表。通過需求->設計->開發的在線化協同，來保證指標開發的一致性。指標地圖，提供所有核心指標的定義，業務人員可以在指標地圖查看指標定義，來解決指標口徑理解問題。從數據源的角度看，業務DB的數據一方面有數據庫scheme的校驗，另一方面應用層也會進行校驗(業務DB的數據是通過應用層代碼寫入的)，出問題的概率很低。數據填報系統excel導入的數據，因爲在excel裏直接操作數據且操作非常靈活(約束少)，很容易出現導入的數據有問題。我們首先控制數據填報系統的建表權限(只有數據開發可以建表)，同時在系統裏提供了大量的校驗規則。業務人員需要導入數據到數倉時，先聯繫對應的數據開發提數據導入需求，數據開發根據需求設計表的結構，並配置對應的表級/字段級的校驗規則。業務人員導入excel的時候，相應的校驗規則就能提前發現不符合規則的數據，並要求業務人員修改後重新導入。埋點由於端多、涉及的開發人員多、沒有強scheme約束，也是數據源問題重災區。埋點管理系統提供了埋點的定義，埋點流程管理和埋點測試。埋點開發人員使用埋點管理系統的單元測試能力，在埋點開發完成後就能進行單元測試，檢查埋點數據是否符合埋點定義。測試人員可以使用埋點管理系統的迴歸測試能力，對核心埋點進行迴歸測試。通過埋點測試，可以保障埋點數據源的準確性。
由於數據任務量大(1W+任務節點)、大數據平臺本身穩定性相對較差，任務穩定性保障一直是個難題。我們跟杭研共建任務運維中心，提供任務治理、智能監控報警、任務影響分析等功能保障數據穩定產出。通過任務運維中心，發現高耗時、耗資源風險任務，及時進行任務優化。智能監控報警，在任務出錯、預測基線有破線風險時及時報警給數據開發值班人員，數據開發值班人員自己或組織對應的開發人員，及時進行問題的處理，保障任務的穩定(準時)產出。
三、CXO無處看數
看到「CXO無處看數」，大家可能覺得很奇怪。上文不是說了，在有數上已經制作了大量報表，怎麼CXO會無處看數。因爲CXO有不一樣的場景，進而產生不一樣的需求。儘管BI平臺（嚴選有數）上有大量報表，CXO依然面臨「難找」、「不能隨時看」的問題。CXO有整個BI平臺的權限，進入平臺後面對海量的報表，難以快速找到想看的數據(CXO的時間又很少)。CXO工作特性需要隨時隨地查看數據。CXO事情特別多，電商CXO尤甚，品牌電商CXO更甚，CXO不是在開會/出差，就是在開會/出差的路上(連我自己現在也差不多)。
針對CXO的看數場景和需求(痛點)，我們設計開發了VIPApp-移動數據工作臺。VIPApp爲CXO提供了隨時隨地監控KPI以及所見既所得商品、類目、流量數據。下圖中是VIPApp很早期版本的一些UI，因爲數據安全的原因數據部分打了碼。早期VIPApp主要爲CXO及少數中高層服務，現在已經逐漸發展成面向嚴選全員的移動數據工作臺了，承載了整個嚴選KPI體系監控及各業務運營的數據監控體系。VIPApp從技術角度看是以嚴選app爲容器，內嵌了一個wap(數據產品)網站；從用戶角度看依託嚴選app提供了所見既所得的交互入口。用戶可以長按類目喚起類目數據頁，長按商品喚起商品數據頁，長按流量位置喚起流量數據頁。移動化讓用戶隨時隨地可以查看數據，所見既所得的入口讓用戶可以快速找到對應的數據模塊。好的用戶體驗一定會帶來高頻訪問的回報(每個產品人都應該信仰)，VIPApp也不另外，是我們最成功的數據產品。
四、場景化數據產品
在日常接到的用戶數據需求中，我們發現的一些數據需求場景，相對於作爲整個嚴選業務數據監控體系的一部分，作爲一個垂直場景的數據解決方案會是一種更好的表達，比如大促、市場投放、用戶體驗等數據需求場景。大促是電商最重要的節日，要渲染大促氛圍，要實時追蹤大促的爆發效果，以進行運營動作的及時調整。市場投放要及時追蹤市場拉新KPI，及時評估渠道ROI來決策放量/停投，要測試/挑選拉新的新品等。互聯網產品都是以用戶爲中心，網易更是極度重視用戶體驗，如何量化評估用戶體驗，如何從用戶視角改進業務。
針對電商大促場景化數據需求，我們設計開發了電商數據大屏和客服數據大屏。在17年雙11之前，我們開發了第一版嚴選電商雙11數據大屏。跟業界雙11數據大屏類似，數據大屏通過主動的實時數據呈現，讓業務實時追蹤大促爆發。通過炫酷的視覺樣式和動畫來渲染大促氛圍。在電商雙11大屏上線後，我們客服部門負責人找到我們，希望幫他們在下一次大促前做個客服數據大屏。由於沒找到mock數據的客服數據大屏(下圖的大促數據大屏數據是mock的)，且客服數據大屏上數據太多打碼難度太大，大家根據大促數據大屏自行腦補下UI吧。客服數據大屏包含實時的會話、排隊、坐席數據，還有滿意度、CPD、滿意度報警、超30分鐘會話等排行榜。我們發現電商數據大屏只在雙11、週年慶等極少數電商大促節日的正點時段使用，但是客服數據大屏在我們兩地的客服部門長期放了好幾塊。這種現象讓我想到在房產中介看到的月度榜單牆，客服大屏是一種更實時的可視化的勞動競賽榜。
針對用戶體驗場景化需求，我們設計開發了諦聽-輿情洞察中心。用戶體驗的難點在於難以定量的衡量和分析。除了復購、退貨量這些間接的量化指標外，我們能收集到的用戶直接的聲音是用戶評論、客服諮詢等非結構化、定性的數據。用戶在嚴選的消費鏈路(訪問->瀏覽->諮詢->...)的每個節點，在嚴選內部都有對應的業務部門/業務環節爲用戶提供服務。我們根據業務環節建立輿情的分類體系，通過算法+規則將輿情分到對應分類中。將歸屬到具體分類的輿情數量求和，就完成了輿情從定性到定量的過程，輿情類別就是輿情分析的維度。因爲我們建立了用戶輿情->輿情分類->業務環節(部門)的映射關係，就可以通過分析對應業務部門所屬分類的數據來評估對應部門的用戶體驗，進而可以將對應的負面輿情分發到對應的部門進行改進。質量相關的輿情我們早已完成線上評估->分類->分發->改進的線上化閉環，當前我們也正在推進其他分類的線上化閉環。
針對市場拉新的場景化需求，我們設計開發了刑天-推廣渠道管理系統。整體的思路和邏輯類似，這裏就不展開敘述了。
總結&後記
3年多的不斷建設，經過以上4個階段，我們基本完成了嚴選數據產品體系，並伴隨業務的精細化與創新進行相應的開發與迭代。從用戶(嚴選業務人員)角度看，自上而下是場景化數據產品、敏捷BI平臺和數據管理數據產品(又可以叫中臺數據產品)，分別應對業務場景化數據需求(CXO看數也可以理解爲一種場景化數據需求)、大規模的看數需求和高效高質量的數據管理需求。
在寫文章的過程中，我發現文章信息密度還是很大，包含了很多數據產品和解決方案，難以在一篇文章中全部展開來講。如果大家對數據產品感興趣，想了解具體的產品或解決方案，請在評論區留言，我們會根據反饋發表對應的解決方案或數據產品的文章。當然我也會視本文的熱度，決定後續是不是把方法論部分再寫一篇文章發表出來。
作者簡介
魏文慶，現任網易嚴選數據技術及產品部總監。2007年浙江大學計算機碩士畢業後入職網易杭州研究院，從事前端開發，後歷任技術主管、技術經理、技術總監。曾負責網易攝影、網易企業郵箱、易信公衆號等產品開發，以及網易前端微專業課程開發。2015年開始內部創業，孵化敏捷BI平臺-網易有數，任網易有數總經理，負責產品研發和商業化。2017年開始負責網易嚴選數據技術及產品部，從0到1搭建網易嚴選數據中臺和數據產品體系。
本文由嚴選技術團隊授權發佈