DataPipeline | 享物說產品負責人夏凱：數據驅動的用戶增加實戰

夏凱，卡內基梅隆大學計算機系畢業，曾供職於Evernote數據團隊和微軟Bing.com搜索引擎廣告部門。回國後做爲早期成員加入小紅書，前後從事大數據，用戶增加，項目和團隊管理等工做。

我最初是在美國作搜索型廣告。回國以後，加入小紅書，作基礎的數據服務、數據平臺。做爲創業團隊，最開始想作數據挖掘、數據統計、增加，可是沒數據，因此先得把數據的採集、管理、計算、儲存的技術架構搭起來，有了技術架構以後，再作進一步的數據分析，基於分析與決策，而後再作增加，進而推進產品的迭代和公司各個層面的決策。所以，我將從技術架構、到分析、增加、產品的路徑進行分享。

1、享物說是什麼

先介紹一下如今作的一個事情，享物說是一個小程序，也有APP，主要是作用戶與用戶之間物品互換社區，有一點像閒置交易。因爲免費，用戶與用戶之間，經過咱們定義的小紅花積分互相換東西，用戶黏性與興趣很是高，增加率也很是快，同時藉着小程序傳播很是快的特色，在過去10個月內，咱們從0作到3000萬的節奏。B端商業/企業端能夠在平臺上送東西作推廣、回饋粉絲活動。除此以外，咱們也會作一些公益，如捐贈圖書館等。

2、數據平臺的從0到1

1.數據團隊的創業故事

隨着數據增加的速度，會對數據團隊提出很大的挑戰。對咱們來講，最初的挑戰是業務在10個月內以很是快的速度增加，咱們內部從零到一搭建一個完善的數據平臺，支撐高速發展的業務是比較困難的。所以，基於業務，咱們首要考慮的是須要支持什麼樣的業務數據分析需求；第二是如何在短時間內迭代一個MVP的產品支撐這些需求，基於以上思考，咱們利用雲計算工具和第三方服務，加上咱們團隊工程師的努力，再根據產品反饋、業務部門使用數據的反饋，咱們對數據平臺進行了迭代。

2.數據的需求

第一點：提升產品和改善用戶體驗。在對產品功能設計、流通佈局、頁面設計等方面進行決策的時候，咱們更可能是但願依賴數據，而不是經驗。然而經過數據分析支持決策，就須要採集、計算、存儲與分析工具。有這樣一個場景，咱們曾經很強烈的爭論過，在產品設計與業務設計之間，到底應該用單列瀑布流的形式，仍是用雙列的形式？

單列圖文並茂，能夠沉浸式的瀏覽，可是一次只能看見一個；雙列的佈局是一屏能夠看到多個，點進去再退回來，可是可能會打斷用戶瀏覽。今天看來相似抖音與快手的佈局，在當時尚未快手讓咱們作參考。當時，咱們把這兩個佈局分別分配10%的流量，過一段時間後，經過看使用時長、用戶黏性詳情，咱們依靠數據決策採用了雙列布局。因爲抖音的出現，咱們從新設計了單列布局，讓用戶體驗變的更直接、更沉浸、交互性更強。

第二點：IF U CAN'T MEASURE IT, CAN'T MANAGE IT。在公司管理或者決策分析時，在沒有數據支持狀況下，你們很容易陷入主觀討論和爭議。所以，咱們在進行產品流程/功能的迭代，經過藉助數據分析工具，根據數據分析結果制定完善的迭代方案，避免陷入無心義的爭論中。

最後一點，上升到文化層面：主動意識+智商+理智環境+信息透明 = RELIABLE DECISION MAKING。我我的認爲幫助整個公司/組織作可信賴的決策支持，有四個因素：主動意識、足夠自驅以及智商，後面兩個因素和數據息息相關，分別是理智環境和信息透明。在相對理智的環境，讓每一個人均可以發聲，讓每一個人的意見均可以被尊重，經過數據進行決策。另一個因素就是信息透明，每一個作決策/參與決策的人，基於足夠多的數據信息，進行有效的判斷。

3.對數據平臺的需求

對於一家企業而言，對數據需求強烈的部門如市場部、運營部、銷售部等，市場部每一年推廣費用巨大，經過數據分析進行ROI計算，所以市場部對於數據質量、渠道流量質量有極高的要求；運營部門對數據靈活性有很高的要求，好比說今天運營部作一個活動，如何衡量活動對拉新的效果以及對老用戶促銷效果，經過分層對不一樣用戶的召回效果進行評判活動的質量。而這在數據靈活性、指標靈活性上面須要進行多維分析。

4.方案的迭代

研發團隊更可能是支持線上業務，所以對數據平臺的高可用有很強的依賴，若是他的推薦用到你的數據結果，無論是計算用戶中短時間的用戶畫像，或者直接經過數據結果作推測或者對搜索排名作決策的時候，須要數據保持高可用，而且提供可編程可直接對接的接口。產品這塊提出的需求，一是基於本身的KPI指標體系，二是不一樣的產品經理會看不一樣的指標。大的產品經理，會看GMV，小的產品經理會看註冊、轉化、點擊、測試結果等，這些要支持各類不一樣力度下鑽，以及指標分析。

最初，咱們是經過在業務數據庫裏面跑數據，工程師須要寫腳本，以及經過跑數據填到Excel裏面，再給到業務部門。這種方式很是不靈活，以及會影響線上的業務訪問，即便將數據同步到其餘數據庫裏面，依舊會出現只有最終業務數據結果，沒有過程問題。例如訂單數據，要想知道這個訂單從簽收、流轉、發貨的狀態流轉上是比較困難的，由於只有當前的用戶狀態、交易狀態、支付狀態等最終結果。

在迭代過程當中，咱們須要的是用戶行爲日誌，經過狀態變動日誌這樣的方式，把一些結果的數據落到日誌裏面，最後再作分析。這樣就提出來對日誌的採集、同步計算與結構化的需求。

5.數據平臺設計方案

當時一部分業務在騰訊雲，後來咱們採用了混合雲方式。咱們的數據平臺架構隨着業務量的升級，通過幾回迭代，下面和你們分享一下咱們在迭代過程當中是如何思考的，以及爲何作這樣的決策。

最初的業務分析需求比較簡單，當時對數據分析需求較急的是業務部門，如對某些接口的訪問數、某些功能的瀏覽量、點擊量分析這些需求，工程師一天就能夠完成。然而隨着業務量上升，接下來各類各樣的靈活性數據分析需求撲面而來，沒法應對。

前端、客戶端、小程序、移動平臺、PC等來的流量，這些數據會最終會落到兩個地方，用戶行爲數據會落在用戶的訪問日誌上，這些日誌被進一步收集採集；業務數據會經過定時同步的方式，把業務數據定時同步到文件儲存上，最終這些數據會落到AWS，基於數據倉庫，咱們直接落到數據倉庫，這個數據倉庫能夠結構化，實現速度較快，須要維護與搭建的成本相對較低。

當時遇到兩個問題：一個是這套系統的靈活性比較有限，當有實時、大量的數據需求，以及須要快速拿到分析結果時，會產生計算跟不上展現問題。另外，當時的AWS只有線下庫的專區，數據會有延時。隨着開放，咱們迅速遷入過去。由於有實時的數據需求，咱們用了AWS版本的連接數據作同步。然而仍然會因爲大量的數據，致使計算存儲量問題。

基於以上狀況，咱們搭建了本身的EMR數據集羣，以後進行分析數據、離線運算結果，能夠迅速被業務部門使用與訪問，進而能夠支持到物流計算、KPI計算。可是當不一樣數據源的數據量都在快速增加的時候，這樣的方式也變的不是很穩定。

在我剛開始作這件事的，咱們工程師是本身寫任務，管理大量腳本，跑各類有先後依賴的任務，很是花費工程師的精力，特別是在工程師只有兩三個。在這種狀況下，咱們接觸到了DataPipeline，他們拿出了相對成熟的數據管理平臺DataPipeline，而且經過私有化部署在咱們服務器上以及完善的解決方案，這在很大程度上幫助咱們解決了工程師遇到的諸多問題。能夠相對比較穩定的支撐咱們推薦、搜索、一線分析、業務分析等不一樣的場景。

6.數據平臺工具

咱們在只有幾個工程師的狀況下支撐了整個數據架構，供業務部門進行數據分析。咱們目前用Airflow作一些任務調度，以及經過Tableau進行可視化分析。

3、Growth的分析框架

下面和你們分想一些關於Growth內容。隨着業務量的增加，有了數據、以及分析工具後，咱們須要進行分析，持續化完成增加目標，包括拉新、激活、召回到留存這些模式。我今天和你們分享的內容將更偏數據分析的框架，這個框架簡單總結是如下五步。

第一步：監測

須要有一個能夠監測的數據平臺或者數據工具。經過數據平臺/數據工具，進而能夠分析當前發生了什麼，以便如何進行優化和迭代。監測最理想狀態是天天當我進到辦公室的前5分鐘，瀏覽一下數據簡報，對整個平臺、整個產品的情況有一個大體評估。

第二步：挖掘/猜測

當發現產品有好/壞情況變更後，再進一步拆解這些指標，進行分析，作進一步挖掘。

下圖是一個Growth案例，例如我關心的是整個產品使用總時長，天天都會關注指標變更，由於天和天之間有周末，所以會有較多的波動，而經過七天平均時長來看，就相對平緩一些，這是經過時間層面看出趨勢變化。

一旦看出趨勢變得很差/更好，經過把目標、指標拆解進行分析。一個簡單的拆解思路就是對於使用時長來講，經過內容產生和內容消費兩個端來看，到底多少人貢獻了能夠增加時長的內容，以及多少人來消費這些內容，增長時長。例如，享物說是一個內容消費平臺，咱們的內容都是用戶發佈的，發佈內容包括話題、筆記或者是物品，我可能會分爲如下幾個維度，誰、何時、如何發佈、新用戶/老用戶、哪些地區的用戶、在工做日仍是節假日、晚上仍是白天，發佈的內容會分不一樣品類、母嬰類、穿搭類、美妝類仍是其餘，如何發佈？是經過小程序、APP、安卓、IOS、PC端，從活動頁面進入仍是從專題頁面進入。

之因此進行維度拆分，當咱們看到一個大指標發生變化的時候，沒法馬上知道是全局仍是隻在某個時間節點上發生了變化，所以在進行這樣的拆分後，若是這一指標在每一個維度都發生了變化，能夠判斷多是全盤的變化；若是這個指標只在某幾個維度發生了變化，例如只在上海地區新用戶男性中發生了變化，咱們可能會有一些基本的假設，進一步就能夠用這些假設驗證是否是上海最近作了線下活動，或者是否是在IOS版本上發生了BUG。

第三步：測

在對指標進行維度拆分後，基於挖掘/猜測，再經過數據進行驗證。進而對產品的一些功能進行改進或者流程上的迭代。

第四步：讀

完成「測」的部分後，進一步將你想要作的改動放到產品裏面驗證，跑一段時間數據，經過A/B測試以及數據效果能夠發現精細的測量結果。

第五步：迭代

迭代部分就是經過重複這個過程，在產品的樣式、按紐文案、佈局上作各類各樣的改進和測試。由於想要快速產生產品或者指標效果，質的飛躍是比較困難的，經過不斷優化可以逐步把產品往好的方向推動。

以上是基於數據作增加類分析的簡單框架，最後和你們分享的內容是如何用數據講故事的套路。

4、用數據講故事的套路

當咱們須要展示數據或者展示論點的時候，若是隻是呈現數據，別人沒法直接看出來你想要表達的觀點。若是是將數據可視化，就會更容易的讓人清晰知道你想要表達什麼。例以下面這張典型的電商數據可視化圖，橫軸表明物品瀏覽量，縱軸是物品實際銷售量，不一樣顏色的圈表明了不一樣的品類物品，不一樣大小表明了不一樣的利潤率。因此它表明一個物品被看了多少次之後，成功交易出去。好比右下角，表明的意義是不少用戶看，可是沒有人買的東西，左上角表明用戶看見馬上就買的物品，這是咱們在看到這張圖對轉化率直觀的感覺。

爲何數據可視化或者用數據講故事特別重要？在一個數據分析師或者數據科學家的整個工做流程中，可視化只佔很是小的一部分。更多精力是放在確保數據正確性，確保數據採集、數據清洗、整理、計算、建模整個完整流程。可是經過可視化或者用數據講故事，每每是最能被人感知的環節，並且在這個環節也最缺乏現成的經驗或者可直接學習的教材或者技能。因此在這個方面和你們相互交流的一些經驗。

1. 兩種數據分析需求

通常數據分析分爲兩類，一類叫作解釋性分析，一類叫作探索性分析。探索性分析是當咱們經過數據報表或者是一些平常的數據分析，發現問題後，咱們會進一步帶着這個問題找一些假設，而後再用數據驗證它。若是一旦以爲這個假設可行，咱們就會須要一些解釋性的分析把它給相關的人看，告訴他爲何有這樣的假設，以及以爲爲何應該作ABC不一樣的方案。這時候咱們須要用數據解釋前面提出的方案/論點，這兩個過程每每是必不可少的。

2. 把數據變成故事

當咱們向別人呈現數據報表/PPT，第一，聽衆會是不一樣的人；第二，會是不一樣的場景。例如工程師，他可能會更關注你的數據分析如何推導生成的，爲何產生這樣的結果？他會對結果推理的可信度以及產生過程有一個很是強的質疑，你須要給他很是強的證據。若是是銷售、市場人員，對這個過程就不是特別關注，他關注你的分析結果對他會產生哪些結果，以及如何利用這一結果，所以就須要對不一樣的人說不一樣的話。

另一種狀況，有的人天生帶着一些先入爲主的偏見或者意識。例如，當你拿着數據分析結果和產品經理討論的時候，他會拿用戶反饋的直接結果，來駁斥你的數據分析推理。爲何會有這樣的狀況呢？由於用戶反饋是一個更直接、讓你直觀感覺更強的意見，可是數據確是一個比較冷冰冰放在那兒的東西。除此以外，還有一個緣由叫作倖存者偏見，願意給你反饋，特別是負面反饋的人是很是多的。由於用的好的人可能就不說話了，用的不爽的人才會過來罵一罵，若是你對有些功能提出不一樣意見的人，可能他的意見表達更強烈，你會更關注到他。這是在平衡用戶反饋結果仍是數據調研結果作決策的時候須要注意的點。

3. 電梯間測試

這當中經常使用的例子就是電梯間測試，無論是創業仍是在公司裏給上級領導彙報一項工做，或者想要爭取一個新的方案經過，都會有這樣一個過程：如何在短期內讓對方GET到你想要表達的點。當他願意進一步和你作溝通的時候，你再給出更多證據或者數據來證實，最終當他和你結束這場對話的時候，它進入的只是你一個或者一兩個結論，這就是電梯間測試的所有過程。

呈現數據也是這樣，當你呈現數據給他的時候，你只但願他記住一個或者一兩個點，可以GET到你這段數據須要表達的意思。

下面我用兩個例子來解釋，第一個例子是原來作過一個客服工單完成度記錄。把每月客服工單完成狀況記一記，區分收到的工單和處理的工單，從這個報表的呈現上其實沒有什麼問題，可是咱們也看不出須要關注什麼。它的優化是什麼？背後其實想說的是隨着後面幾個月，咱們收到的工單愈來愈多，收到的工單處理不完，因此把收到的工單和處理的工單直接羅列在這裏，對後面幾個月作直接數字直觀的呈現，把結論貼在這兒，告訴上級由於後面處理不完工單了，須要急增人手。這是第一眼看上去知道你這個圖要表達什麼、說明什麼。

對於餅圖也是同樣。餅圖在我看來是一個很是很差的數據工具，儘可能不要用餅圖。當咱們在作共性優化以後，有更多人滿意，可是由於其中混雜的人數比較多，須要反應一下才能看出不一樣的顏色表明不一樣的含義，再對應觀察一下才會發現原來是滿意的人多了。另外，若是我想要表達徹底不一樣的意見，經過作3D餅圖操縱數據結果。

下圖是徹底同樣的餅圖，當我用不一樣的方式作3D餅圖的時候，你會在左邊看出來是支持人更多，右邊反對的人更多。

以上分享的內容基本涵蓋了我工做過的不一樣領域，最初是如何經過數據架構或者數據工程迭代去支撐業務，進一步如何經過數據作增加，最後是當我有各類各樣分析場景後，我如何讓分析和溝通變得更加高效。

謝謝你們，給你們分享的就是這麼多。

點擊這裏，免費申請DataPipeline產品試用