随着網際網路進入下半場，流量紅利逐漸消失，一方面，企業開始重視如何通過資料來挖掘同一個使用者的更多價值；另一方面，不管是産品經理、營運還是市場都開始通過“資料驅動”尋找新的增長空間。
01 資料驅動，在國内企業的落地中很“骨感”
在國外，有一個名為Instagram的照片分享軟體，這個軟體早期并沒有火起來，後來他們通過資料分析發現了一個非常強硬的使用者需求點，即“純粹拍照并分享”。圍繞這一點，他們對産品進行了大改版，并在較短時間内實作了使用者數量快速增長，這是一個很好的資料驅動案例。反觀國内，大一點的創業公司會優先考慮如何做概念，如何存活下來，像上述那樣用資料實作業務驅動的很少。
對于資料驅動，很多人做到一定程度之後，腦海中會形成一定的方法論和體系，進而形成驅動流程群組織機制。大家也聽了很多方法論，包括增長黑客等，貌似自己已經很懂資料驅動了，但是實際操作起來可能連“什麼是事件屬性這種基礎的概念都不了解”，這是很多業務線同學普遍的現狀。
另外，很多公司認為做資料驅動就應該有一個高大上的資料平台，這兩年标簽畫像平台或者資料中台的概念比較火，它們真的能夠實作資料驅動嗎？不見得。目前，很多公司的資料品質非常差，資料驅動就更無從談起，這是國内大中小企業普遍存在的情況。
早些時候，大家對“資料驅動”的了解是“報表驅動”。2016年、2017年的時候，一家處于C輪、D輪的深圳公司，該公司有1000多份報表，每張有10個Sheet，每個表格有20多個名額，大家可以算下一共有多少個名額，他們内部的資料團隊都不知道哪些名額有用、哪些沒有用。為了督促大家去看這些報表，公司還監控了郵箱。
“早前，我做資料産品和資料分析的時候，很多産品同學說所有的都要埋點，包括頭像、點選次數等，他會問這些點真的有用嗎？想好這些名額資料的目的了嗎？這些都是十分有意思的現象和問題。資料驅動是一件好事，但在國内企業的落地中确實很“骨感”。資料驅動不是一個簡單的工具，也不是多個分析師或者少個分析師的問題，而是整體的格局問題。“陳新祥在直播中提到。
02 從幾個案例進行拆解
現在，很多企業都想實作資料閉環，其實閉環就是非常典型的方法論。那麼，這個方法論究竟能不能解決問題？能不能在組織和團隊裡運作起來？背後是否缺失了哪些環節？在這裡，陳新祥分享了一個國内的實際案例。
如上圖所示，Phase 1是初定的觀測名額，包括日活、PV、注冊書、功能使用次數、收入、客單價、日活躍占比、新老使用者占比、增長率、X轉化率等。他們的CEO發現，雖然該有的名額都有，但就是因為都有才失去了聚焦。于是開始精簡思路，把團隊力量凝聚到一根繩上，Phase 3是最終剩下的兩個名額。
當然，這是他們根據産品的情況以及公司所處的發展階段做的取舍：當時公司不急着變現于是收入被拿掉了，日活做的資料沒有太大作用于是被拿掉了，拉新也被拿掉了。他們覺得産品留存很好，在當下階段團隊已經做到能力範圍的上限了，投入更大的精力也不會有很大的提升。之後，他們隻留下了日活躍占比和日活躍參與度，并調整了内部的報表體系。
今天，很多C端産品要改版要更新，那麼，在改版之前要搞清楚為什麼要改？目标是什麼？之後所有的工作都是以這兩個問題的答案為導向。
以友盟+服務的客戶為例，每一年都會提出很多新的需求，比如進一步提升産品粘性、進一步提升使用者量等諸如此類，我們要做的是盡力滿足他們，但不論對産品做什麼樣的功能更新，都要以客戶的目标為主。
上圖是非常典型的2B行業自上而下的流程圖，大家要做的第一件事就是定一個目标，不要忽略這件事，它真的非常重要，因為不管是更新産品的功能還是其它，一定要十厘清楚公司的KPI，這樣才能決定産品最核心的KPI。
搞清楚這些之後，要跟橫向團隊配合好，還要跟下面的人對齊。2B 行業企業的目标非常明确，一般是提高付費企業客戶量，這背後有産品的日活周活，以及新增注冊客戶數等。再往下就是産品闆塊，包括産品版本、功能子產品以及跟其他産品的協同。
向上要跟公司目标對齊，橫向要跟合作團隊對齊，向下是具體的産品功能拆解。需要注意的是：定好目标，目标不要多，最好隻有一個或者兩個。
B端的産品比較複雜（如上圖所示）包括官網注冊、H5、新增賬號、建立項目、內建代碼、使用産品、留存日活、pro付費等，KPI拆解到了新增賬號數、注冊轉化率、有效內建數、首次完成激活等。在這之中，有些目标需要自己做，有些需要跟别的團隊協同合作。
定好目标後，一定要了解産品背後的資料品質。關于資料品質，公司内部、部門之間的名額定義各不相同，不過普遍存在資料不準、沒有資料、資料髒亂差、易用性差等問題。如何解決？其實，資料中包含着業務需求，需求弄清楚了才會轉化到埋點設計，埋點方案再轉化為具體的研發。
随着産品功能疊代，還需要重新走一遍全部流程。在這個流程裡，業務需求來自很多團隊，包括産品團隊、營運團隊、市場團隊等，橙色标注的文字是一個産品經理一定要重點關注的節點和事項（如下圖所示）。
從業務需求到需求規範，一定要做統一收口，如果沒有線上工具化的體系，可以指定一個人，讓他做統一收口，收口完成之後要形成公司或者部門内部比較完整的名額字典和次元字典。與此同時，一定要對名額字典進行拆分，看看哪些是公共性名額（跨部門或者公司級别）和個性化名額。
有些公司需要這樣的同步方式，再往下是具體的采集方案設計，前面已經拆分出了公共性名額和個性化名額，它們延伸出來就是公共埋點和個性埋點，公共埋點是非常重要的業務性名額，這個名額很長時間都不會變。再往下是研發口徑，不管是公共埋點的事件規則、屬性規則，還是采集時機，都要做統一管理，最後再進行驗證。
在整個流程裡，最關鍵的是要有專人做統一收口，基于對資料和采集的了解做分流，中間規範跟标準動作要規範，因為不論是新版還是新功能上線都要走這個流程。
這是一個視訊類的案例，要針對具體需求設計資料采集方案，網際網路領域比較流行基于事件和屬性進行分類。相關人員可以把屬性融到事件裡，之後再去做限定，等到哪一天想看XXX視訊的點選，基于屬性可以直接看到。這是一個非常理想的體系，可以實作資料采集埋點的規範化。
在此基礎上，還得針對兩類事件做統一的設計和規劃，浏覽頁面和功能互動是統計資料中最多的，如果浏覽頁面和功能互動沒有規範化就會導緻資料髒亂差。
為什麼這麼說？以手機淘寶為例，手機淘寶的終端有網頁、安卓、iOS、小程式等，頁面浏覽和功能互動都有不同的部分，如果完全分開按照最糟糕的情況永遠規範不好。
目前，一個比較好的解決方法就是把它前置，所有的功能在某一個頁面的某一個位置，以一個具體的按扭呈現出來，并設定一個唯一的參數ID，再用事件和屬性進行歸類。這樣一來，所有的頁面和功能隻需做一個埋點，所有頁面的标記都可以用ID來标記。
不同終端都有一個ID是長期關系，後面都會用相同的邏輯和體系進行标注，隻要維護好需求、事件命名，以及業務層級ID，最終采集到的資料品質是非常好的。
以友盟+服務的客戶場景來說，比如在拿到一份高品質的資料之後，KPI在确定情況下進行了拆解，現在要做的就是希望團隊裡的人知道自己的KPI，KPI大屏就可以輕松解決這個問題。
同時，要把資料結果融入到團隊的工作流程裡去，比如可以在早上八點把團隊最關注的東西發到郵箱，市場推廣人員可以看到相應的報表。在上午十點的時候，産品經理可以登入背景看到更新的産品功能。
目前，由于疫情的原因，很多人在家使用釘釘移動協同辦公， 如果某個人的KPI出現異常或者波動就會自動同步到群裡，分析師會到背景分析異常原因。另外，團隊營運人員在背景可以直接用營運彈框來組織活動，并對相關人群做觸達并觀看效果……
以上内容主要圍繞資料驅動的閉環展開，包括目标、洞察、疊代、落地等各個環節，在這之中有一套标準的方法論，如果能把這套标準方法論體系化和産品化，可以極大的提升決策效率。
作者：友盟+産品專家，資料傳承官 陳新祥