溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
夏凱
卡內基梅隆大學計算機系畢業，曾供職于Evernote數據團隊和微軟Bing.com搜索引擎廣告部門。回國后作為早期成員加入小紅書，先后從事大數據，用戶增長，項目和團隊管理等工作。
我最初是在美國做搜索型廣告。回國之后，加入小紅書，做基礎的數據服務、數據平臺。作為創業團隊，最開始想做數據挖掘、數據統計、增長，但是沒數據，所以先得把數據的采集、管理、計算、儲存的技術架構搭起來，有了技術架構之后，再做進一步的數據分析，基于分析與決策，然后再做增長，進而推動產品的迭代和公司各個層面的決策。因此，我將從技術架構、到分析、增長、產品的路徑進行分享。
一、享物說是什么
先介紹一下現在做的一個事情，享物說是一個小程序，也有APP，主要是做用戶與用戶之間物品互換社區，有一點像閑置交易。由于免費，用戶與用戶之間，通過我們定義的小紅花積分互相換東西，用戶黏性與興趣非常高，增長率也非常快，同時借著小程序傳播非常快的特點，在過去10個月內，我們從0做到3000萬的節奏。B端商業/企業端可以在平臺上送東西做推廣、回饋粉絲活動。除此之外，我們也會做一些公益，如捐贈圖書館等。
隨著數據增長的速度，會對數據團隊提出很大的挑戰。對我們來說，最初的挑戰是業務在10個月內以非常快的速度增長，我們內部從零到一搭建一個完善的數據平臺，支撐高速發展的業務是比較困難的。因此，基于業務，我們首要考慮的是需要支持什么樣的業務數據分析需求；第二是如何在短期內迭代一個MVP的產品支撐這些需求，基于以上思考，我們利用云計算工具和第三方服務，加上我們團隊工程師的努力，再根據產品反饋、業務部門使用數據的反饋，我們對數據平臺進行了迭代。
第一點：提高產品和改善用戶體驗。在對產品功能設計、流通布局、頁面設計等方面進行決策的時候，我們更多是希望依賴數據，而不是經驗。然而通過數據分析支持決策，就需要采集、計算、存儲與分析工具。有這樣一個場景，我們曾經很強烈的爭論過，在產品設計與業務設計之間，到底應該用單列瀑布流的形式，還是用雙列的形式？
單列圖文并茂，可以沉浸式的瀏覽，但是一次只能看見一個；雙列的布局是一屏可以看到多個，點進去再退回來，但是可能會打斷用戶瀏覽。今天看來類似抖音與快手的布局，在當時還沒有快手讓我們做參考。當時，我們把這兩個布局分別分配10%的流量，過一段時間后，通過看使用時長、用戶黏性詳情，我們依靠數據決策采用了雙列布局。由于抖音的出現，我們重新設計了單列布局，讓用戶體驗變的更直接、更沉浸、交互性更強。
第二點：IF U CAN'T MEASURE IT, CAN'T MANAGE IT。在公司管理或者決策分析時，在沒有數據支持情況下，大家很容易陷入主觀討論和爭議。因此，我們在進行產品流程/功能的迭代，通過借助數據分析工具，根據數據分析結果制定完善的迭代方案，避免陷入無意義的爭論中。
最后一點，上升到文化層面：主動意識+智商+理智環境+信息透明 = RELIABLE DECISION MAKING。我個人認為幫助整個公司/組織做可信賴的決策支持，有四個因素：主動意識、足夠自驅以及智商，后面兩個因素和數據息息相關，分別是理智環境和信息透明。在相對理智的環境，讓每個人都可以發聲，讓每個人的意見都可以被尊重，通過數據進行決策。另外一個因素就是信息透明，每個做決策/參與決策的人，基于足夠多的數據信息，進行有效的判斷。
對于一家企業而言，對數據需求強烈的部門如市場部、運營部、銷售部等，市場部每年推廣費用巨大，通過數據分析進行ROI計算，因此市場部對于數據質量、渠道流量質量有極高的要求；運營部門對數據靈活性有很高的要求，比如說今天運營部做一個活動，如何衡量活動對拉新的效果以及對老用戶促銷效果，通過分層對不同用戶的召回效果進行評判活動的質量。而這在數據靈活性、指標靈活性上面需要進行多維分析。
研發團隊更多是支持線上業務，因此對數據平臺的高可用有很強的依賴，如果他的推薦用到你的數據結果，不管是計算用戶中短期的用戶畫像，或者直接通過數據結果做推測或者對搜索排名做決策的時候，需要數據保持高可用，并且提供可編程可直接對接的接口。產品這塊提出的需求，一是基于自己的KPI指標體系，二是不同的產品經理會看不同的指標。大的產品經理，會看GMV，小的產品經理會看注冊、轉化、點擊、測試結果等，這些要支持各種不同力度下鉆，以及指標分析。
最初，我們是通過在業務數據庫里面跑數據，工程師需要寫腳本，以及通過跑數據填到Excel里面，再給到業務部門。這種方式非常不靈活，以及會影響線上的業務訪問，即使將數據同步到其他數據庫里面，依舊會出現只有最終業務數據結果，沒有過程問題。例如訂單數據，要想知道這個訂單從簽收、流轉、發貨的狀態流轉上是比較困難的，因為只有當前的用戶狀態、交易狀態、支付狀態等最終結果。
在迭代過程中，我們需要的是用戶行為日志，通過狀態變更日志這樣的方式，把一些結果的數據落到日志里面，最后再做分析。這樣就提出來對日志的采集、同步計算與結構化的需求。
當時一部分業務在騰訊云，后來我們采用了混合云方式。我們的數據平臺架構隨著業務量的升級，經過幾次迭代，下面和大家分享一下我們在迭代過程中是如何思考的，以及為什么做這樣的決策。
最初的業務分析需求比較簡單，當時對數據分析需求較急的是業務部門，如對某些接口的訪問數、某些功能的瀏覽量、點擊量分析這些需求，工程師一天就可以完成。然而隨著業務量上升，接下來各種各樣的靈活性數據分析需求撲面而來，無法應對。
前端、客戶端、小程序、移動平臺、PC等來的流量，這些數據會最終會落到兩個地方，用戶行為數據會落在用戶的訪問日志上，這些日志被進一步收集采集；業務數據會通過定時同步的方式，把業務數據定時同步到文件儲存上，最終這些數據會落到AWS，基于數據倉庫，我們直接落到數據倉庫，這個數據倉庫可以結構化，實現速度較快，需要維護與搭建的成本相對較低。
當時遇到兩個問題：一個是這套系統的靈活性比較有限，當有實時、大量的數據需求，以及需要快速拿到分析結果時，會產生計算跟不上展示問題。另外，當時的AWS只有線下庫的專區，數據會有延時。隨著開放，我們迅速遷入過去。因為有實時的數據需求，我們用了AWS版本的鏈接數據做同步。然而仍然會由于大量的數據，導致計算存儲量問題。
基于以上情況，我們搭建了自己的EMR數據集群，之后進行分析數據、離線運算結果，可以迅速被業務部門使用與訪問，進而可以支持到物流計算、KPI計算。但是當不同數據源的數據量都在快速增長的時候，這樣的方式也變的不是很穩定。
在我剛開始做這件事的，我們工程師是自己寫任務，管理大量腳本，跑各種有前后依賴的任務，非常花費工程師的精力，特別是在工程師只有兩三個。在這種情況下，我們接觸到了DataPipeline，他們拿出了相對成熟的數據管理平臺DataPipeline，并且通過私有化部署在我們服務器上以及完善的解決方案，這在很大程度上幫助我們解決了工程師遇到的諸多問題。可以相對比較穩定的支撐我們推薦、搜索、一線分析、業務分析等不同的場景。
我們在只有幾個工程師的情況下支撐了整個數據架構，供業務部門進行數據分析。我們目前用Airflow做一些任務調度，以及通過Tableau進行可視化分析。
下面和大家分想一些關于Growth內容。隨著業務量的增長，有了數據、以及分析工具后，我們需要進行分析，持續化完成增長目標，包括拉新、激活、召回到留存這些模式。我今天和大家分享的內容將更偏數據分析的框架，這個框架簡單總結是以下五步。
需要有一個可以監測的數據平臺或者數據工具。通過數據平臺/數據工具，進而可以分析當前發生了什么，以便如何進行優化和迭代。監測最理想狀態是每天當我進到辦公室的前5分鐘，瀏覽一下數據簡報，對整個平臺、整個產品的狀況有一個大致評估。
當發現產品有好/壞狀況變動后，再進一步拆解這些指標，進行分析，做進一步挖掘。
下圖是一個Growth案例，例如我關心的是整個產品使用總時長，每天都會關注指標變動，因為天和天之間有周末，因此會有較多的波動，而通過七天平均時長來看，就相對平緩一些，這是通過時間層面看出趨勢變化。
一旦看出趨勢變得不好/更好，通過把目標、指標拆解進行分析。一個簡單的拆解思路就是對于使用時長來說，通過內容產生和內容消費兩個端來看，到底多少人貢獻了可以增長時長的內容，以及多少人來消費這些內容，增加時長。例如，享物說是一個內容消費平臺，我們的內容都是用戶發布的，發布內容包括話題、筆記或者是物品，我可能會分為以下幾個維度，誰、什么時候、如何發布、新用戶/老用戶、哪些地區的用戶、在工作日還是節假日、晚上還是白天，發布的內容會分不同品類、母嬰類、穿搭類、美妝類還是其他，如何發布？是通過小程序、APP、安卓、IOS、PC端，從活動頁面進入還是從專題頁面進入。
之所以進行維度拆分，當我們看到一個大指標發生變化的時候，無法立刻知道是全局還是只在某個時間節點上發生了變化，因此在進行這樣的拆分后，如果這一指標在每個維度都發生了變化，可以判斷可能是全盤的變化；如果這個指標只在某幾個維度發生了變化，例如只在上海地區新用戶男性中發生了變化，我們可能會有一些基本的假設，進一步就可以用這些假設驗證是不是上海最近做了線下活動，或者是不是在IOS版本上發生了BUG。
在對指標進行維度拆分后，基于挖掘/猜想，再通過數據進行驗證。進而對產品的一些功能進行改進或者流程上的迭代。
完成“測”的部分后，進一步將你想要做的改動放到產品里面驗證，跑一段時間數據，通過A/B測試以及數據效果可以發現精細的測量結果。
迭代部分就是通過重復這個過程，在產品的樣式、按紐文案、布局上做各種各樣的改進和測試。因為想要快速產生產品或者指標效果，質的飛躍是比較困難的，通過不斷優化能夠逐步把產品往好的方向推進。
以上是基于數據做增長類分析的簡單框架，最后和大家分享的內容是如何用數據講故事的套路。
當我們需要展現數據或者展現論點的時候，如果只是呈現數據，別人無法直接看出來你想要表達的觀點。如果是將數據可視化，就會更容易的讓人清晰知道你想要表達什么。例如下面這張典型的電商數據可視化圖，橫軸代表物品瀏覽量，縱軸是物品實際銷售量，不同顏色的圈代表了不同的品類物品，不同大小代表了不同的利潤率。所以它代表一個物品被看了多少次以后，成功交易出去。比如右下角，代表的意義是很多用戶看，但是沒有人買的東西，左上角代表用戶看見立刻就買的物品，這是我們在看到這張圖對轉化率直觀的感受。
為什么數據可視化或者用數據講故事特別重要？在一個數據分析師或者數據科學家的整個工作流程中，可視化只占非常小的一部分。更多精力是放在確保數據正確性，確保數據采集、數據清洗、整理、計算、建模整個完整流程。但是通過可視化或者用數據講故事，往往是最能被人感知的環節，而且在這個環節也最缺少現成的經驗或者可直接學習的教材或者技能。所以在這個方面和大家相互交流的一些經驗。
一般數據分析分為兩類，一類叫做解釋性分析，一類叫做探索性分析。探索性分析是當我們通過數據報表或者是一些日常的數據分析，發現問題后，我們會進一步帶著這個問題找一些假設，然后再用數據驗證它。如果一旦覺得這個假設可行，我們就會需要一些解釋性的分析把它給相關的人看，告訴他為什么有這樣的假設，以及覺得為什么應該做ABC不同的方案。這時候我們需要用數據解釋前面提出的方案/論點，這兩個過程往往是必不可少的。
當我們向別人呈現數據報表/PPT，第一，聽眾會是不同的人；第二，會是不同的場景。例如工程師，他可能會更關注你的數據分析如何推導生成的，為什么產生這樣的結果？他會對結果推理的可信度以及產生過程有一個非常強的質疑，你需要給他非常強的證據。如果是銷售、市場人員，對這個過程就不是特別關注，他關注你的分析結果對他會產生哪些結果，以及如何利用這一結果，因此就需要對不同的人說不同的話。
另外一種情況，有的人天生帶著一些先入為主的偏見或者意識。例如，當你拿著數據分析結果和產品經理討論的時候，他會拿用戶反饋的直接結果，來駁斥你的數據分析推理。為什么會有這樣的情況呢？因為用戶反饋是一個更直接、讓你直觀感受更強的意見，但是數據確是一個比較冷冰冰放在那兒的東西。除此之外，還有一個原因叫做幸存者偏見，愿意給你反饋，特別是負面反饋的人是非常多的。因為用的好的人可能就不說話了，用的不爽的人才會過來罵一罵，如果你對有些功能提出不同意見的人，可能他的意見表達更強烈，你會更關注到他。這是在平衡用戶反饋結果還是數據調研結果做決策的時候需要注意的點。
這當中常用的例子就是電梯間測試，不管是創業還是在公司里給上級領導匯報一項工作，或者想要爭取一個新的方案通過，都會有這樣一個過程：如何在短時間內讓對方GET到你想要表達的點。當他愿意進一步和你做溝通的時候，你再給出更多證據或者數據來證明，最終當他和你結束這場對話的時候，它進入的只是你一個或者一兩個結論，這就是電梯間測試的全部過程。
呈現數據也是這樣，當你呈現數據給他的時候，你只希望他記住一個或者一兩個點，能夠GET到你這段數據需要表達的意思。
下面我用兩個例子來解釋，第一個例子是原來做過一個客服工單完成度記錄。把每個月客服工單完成情況記一記，區分收到的工單和處理的工單，從這個報表的呈現上其實沒有什么問題，但是我們也看不出需要關注什么。它的優化是什么？背后其實想說的是隨著后面幾個月，我們收到的工單越來越多，收到的工單處理不完，所以把收到的工單和處理的工單直接羅列在這里，對后面幾個月做直接數字直觀的呈現，把結論貼在這兒，告訴上級因為后面處理不完工單了，需要急增人手。這是第一眼看上去知道你這個圖要表達什么、說明什么。
對于餅圖也是一樣。餅圖在我看來是一個非常不好的數據工具，盡量不要用餅圖。當我們在做共性優化之后，有更多人滿意，但是因為其中混雜的人數比較多，需要反應一下才能看出不同的顏色代表不同的含義，再對應觀察一下才會發現原來是滿意的人多了。另外，如果我想要表達完全不同的意見，通過做3D餅圖操縱數據結果。
下圖是完全一樣的餅圖，當我用不同的方式做3D餅圖的時候，你會在左邊看出來是支持人更多，右邊反對的人更多。
以上分享的內容基本涵蓋了我工作過的不同領域，最初是如何通過數據架構或者數據工程迭代去支撐業務，進一步如何通過數據做增長，最后是當我有各種各樣分析場景后，我如何讓分析和溝通變得更加高效。
謝謝大家，給大家分享的就是這么多。
點擊這里，免費申請DataPipeline產品試用
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
