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