全栈工程师?
嗯.....目前并不是!

十年的標籤庫建設經歷,從中我得到了什麼啟示?

根據多年工作經歷,筆者分享了關於如何建設和運營好標籤庫的經驗,分別流程、運營、創新、人員四個方面出發。

記得很多年前剛開始建設標籤庫的時候,目的還是很單純的,想着數據倉庫既然是數據的匯聚地,那麼對於標籤也需要有一個匯聚地,這就是標籤庫,在一個系統上承載所有的客戶標籤,實現360度的客戶洞察,然後提供計算、搜索,收藏等一系列功能,想想也是很酷的事情。

第一期標籤庫承載了幾百個標籤,但好不容易建設完成了,卻發現使用者寥寥。為了推動標籤庫的使用,當時還想着模仿維基百科。

業務人員可以依託標籤庫在企業內建立一種標籤生成,發布,修改,下線的扁平化運營機制,這樣大家的經驗通過標籤庫就可以沉澱下來,比如業務人員提交業務規則,然後管理人員審核後進行開發併發布,還可以提供各種評論功能,這將是一個多麼美好的標籤生態啊。

但你會發現這只是一廂情願,維基百科的理念在一個企業內是基本玩不轉的,這牽涉到規模、機制、流程等一系列問題。

我們吸取了教訓,繼續為標籤庫找出口。

第一個手段就是希望基於原子標籤的組裝來實現自助取數,從而替代傳統的人工取數。

但企業內取數的特點是靈活性非常高,既有營銷清單又有分析報表,基於標籤來實現複雜的分析顯然不大可行,而對於簡單的清單取數還不如設計幾張寬表來得有效。

第二個手段是希望基於標籤庫直接為營銷平台提供精準客戶群,我們打通了標籤庫和營銷平台,帶來了標籤庫使用量的提升。

但當標籤庫的客戶群無法滿足營銷要求時,我們還是要走人工定製模式,而這涉及到需要走不同的流程。

在標籤庫的運營上,似乎總是差了一口氣,即使進入了大數據時代。

直到最近一年,當新的數據產品經理出現,當團隊對於數據、產品、營銷、流程有了更多的認識后,標籤庫才算進入了新的階段。

以下是最近標籤庫產品經理給的需求圖,這就是我們所需要的,標籤庫需要自我革命,不停的拓展使用場景,而使用體驗也至關重要。

十年的標籤庫建設經歷,我得到了什麼啟示?

很多大企業的BI其實不缺資源,缺的是對於一線的真正理解,缺的是一個真正的數據產品經理,能夠對於企業的數據、平台、業務、機制、流程有個全局的理解,然後綜合利弊給你一個解決方案。

那些等着業務人員提出需求,然後被動接受需求,實現需求的建設模式,很難打造出好的標籤平台。

什麼意思呢?就是你的數據產品經理,最好做過建模,搞過平台、干過營銷、還懂流程,如果懂點運營更好,這樣他才具備較好的決策判斷能力,做事比較大氣,知道哪些是一線真正需要的,哪些是性價比相對高的,哪些是聊勝於無的,哪些是不可能實現的。

關於如何建設和運營好標籤庫,筆者近來有四個體會,特此分享於你。

關注流程

標籤庫不能獨立於企業的生產流程之外,標籤庫串接了多少流程,往往決定了它流量的基本面,沒有流程的支持,你的標籤庫始終是個奢侈品,再好的體驗,也不如接入一個企業的流程成為其中的必需一環來的重要。

標籤庫起碼可以串接以下兩個核心生產流程:

(1)標籤庫與營銷平台的銜接流程:如果你的營銷平台使用的客戶群全部來自標籤庫,那恭喜你,你的標籤庫是有些生命力的,但在銜接的過程中,要關注用戶體驗,比如不要粗暴的將標籤庫頁面內嵌到營銷平台。

平台的銜接一定要無縫,就好像標籤庫不存在一樣,用戶在營銷平台發起的投放流程應該最為便捷的選擇到自己在標籤庫創建的客戶群,反之,在標籤庫也應該最為方便的將客戶群推送到營銷等外部平台,這考驗產品經理的功力。

很多系統銜接變成了簡單的用戶群導入導出,大量的線下操作,不僅造成了流程事實上的斷裂,而且讓標籤庫變得可有可,營銷平台如果大多數時候用外部手工導入客戶群,標籤庫價值何在呢?

一線很難有先知先覺,反正習慣了也就這樣,但計算一下就知道有多少人工無謂的浪費,一線提不出需求,不是它不需要,而是往往它不知道還可以這樣,這種事情太多了。

(2)標籤庫與開發平台的銜接流程:現在大家都在提大數據的PaaS,各種高效的數據建模和開發工具讓你的數據處理效率獲得了極大提升,但很多時候你卻沒有解決數據的最後一公里問題。

比如你作為開發人員剛開發完了一個模型,然後需要業務人員去進行營銷投放,你可以計算一下需要經歷多少流程,多少系統,多少人員,多少時間才能完成這個數據的最終推送,如果我告訴你只要在系統上點擊兩次就完成了,是不是效率更高?

事實上,每多一個流程,每多一個審批,每多一個中間人,每多一個系統,企業的營銷效率就會打個折扣。

標籤庫作為企業的客戶管理中心,要最大可能的直接對接所有的數據管理平台,將數據推送到標籤庫的功能按鈕就要像FB的like按鈕一樣,無處不在,只要你的數據要推送到渠道營銷,你的平台就得設計這個like按鈕。

關注運營

前面的流程可以解決流量的基本面問題,但如果你要真正的發揮出標籤庫價值,就需要關註標簽的質量,其始終是標籤庫的核心競爭力。

很多企業建了很多標籤,要麼無人問津,要麼曇花一現,為什麼?

有兩個主要原因:一個是人家沒有讀懂你的標籤,不敢用,另一個原因是人家用了效果不好,不想用。

這就需要靠運營,但大多企業建設標籤庫的時候人員一堆,但建完了就呈鳥獸散,實際上每建完一個標籤,標籤團隊就多了一個負擔,得有人為這個標籤的效果提升負責。

我們現在都在提中台,標籤也是中台,而數據中台最核心的工作,不是建什麼功能,而是持續的提升模型和標籤質量,讓這些數據持續的產生價值。

因此,需要建立標籤效果的反饋機制,比如依據營銷的成功率進行標籤的評估,你起碼得知道哪個標籤跟哪個營銷活動有關,你才能從營銷的成功情況評判標籤的價值,而流程貫通往往又是自動化評估的前提。

但光知道了標籤的效果還不夠,還需要有專人去優化提升,這就需要責任到人,一個好的標籤生命期往往只有半年,假如沒有強大的建模團隊保障,標籤容易曇花一現。

很多模型和標籤之所以建了再建,最終問題就是運營的問題,企業的標籤庫有建設團隊,但往往沒有運營團隊。

在IT系統上我們會特別關注運維,因為系統無法穩定、高效運行會直接影響生產,其實標籤也一樣,標籤的價值無法維持最終也影響生產,但標籤運營往往做不好。

也許企業對於數據的理解還比較淺,數據驅動運營有很長的路要走,也許是組織機制的問題,比如營銷歸屬市場,標籤歸屬IT部門管理,中間會存在邊界不清的問題,也許是責任界定的問題,比如營銷真的做壞了也很難追責到標籤身上,更大可能是政策、產品、渠道出了問題。

KPI雖然不是萬能的,但沒有KPI讓標籤運營失去了方向,在起步的時候,我們需要有一些目標感的東西。

做了大數據之後,我們才非常艱難的形成了對於部分重點標籤的前端反饋機制,但還遠遠不夠,比如以下是寬帶模型的反饋示例,你只有不停的獲得一線的數據,才能知道努力的方向:

十年的標籤庫建設經歷,我得到了什麼啟示?

下面的這位同事專門負責流量模型的建設,就是要不停的迭代。

十年的標籤庫建設經歷,我得到了什麼啟示?

關注創新

標籤庫建設的主要目的就是服務好精準營銷,我們希望把很多數據的能力以標籤這種標準化形式進行高效輸出,側重在檢索、實時、簇群、性能等方面進行提升,當然每個企業的實際情況不同,但一定要敢於打破常規,為業務人員更好的賦能。

(1)檢索:標籤多意味着檢索效率低,大多業務人員習慣於就訪問自己關注的那幾個標籤,因此需要設立業務專區,根據自身企業的業務分類將標籤分門別類,但無論哪種分類都解決不了一線靈活管理的要求,因此還需要提供自定義目錄能力,共性的標籤確保權威性,個性的標籤確保靈活性。

(2)實時:用戶的興趣有短和長之分,很多用戶的購買決策往往是瞬時的產物,其實跟長期的偏好關係不大。

以前我們的實時營銷是基於事件觸發來進行推薦的,比如你需要對進入某個商場的人進行產品推薦,在系統層面往往是先離線圈定一波購物潛在人群,也即靜態標籤,然後再配置一個觸發規則,在這批人進入某個商場的時刻觸發營銷(LBS)。

現在我們衍生了標籤的內涵,業務人員可以將整個場景(LBS)封裝成一個動態標籤,動態標籤的管理模式跟靜態標籤完全一致,這樣標籤庫就可以把場景知識也沉澱下來,雖然在營銷的時候技術實現不同,但對於用戶來說是透明的,這有助於實時營銷的普及及推廣。

(3)簇群:每個用戶都處於一個特定群體中,我們的世界實際是被各種社交網絡包圍着的,考慮到運營商有大量的社交通信產品,比如家庭網,親情網,寬帶,集團等等,因此需要結合業務實際突破了原有以用戶為核心的標籤管理方式,打造簇群這種新的標籤體系,這樣可以大幅提升客群管理效率和生成效率,比如營銷家庭產品肯定更關注戶主,因此就需要家庭標籤,而不是個人標籤。

(4)性能:標籤庫特別關注兩種性能,一個是實時計算能力,一種是實時查詢能力,前者解決標籤組合計算生成客戶群的效率問題,比如10個標籤組合關聯得到目標用戶群,你得在極短的時間生成,後者解決的是實時統計的問題,因為業務人員需要基於實際數據量調整策略。

雖然當前能支撐的技術不少,但一定要結合企業實際選擇適合的,比如前者可以採用GBASE(其實還不夠快,但夠用就好),後者可以採用ES等。

關注人員

可以看到,標籤庫跟企業的各種平台都有千絲萬縷的關係,產品化難度其實挺高,不是安裝一下就可以拍屁股走人了,當然很多時候標籤庫不成功,不是產品問題,而是管理問題,這裡重點提二點:

第一,從自身人員的角度講,企業需要有自己的數據產品經理和核心建模團隊,光有項目經理是遠遠不夠的,標籤庫這種系統要運營好,付出的代價非常大。

筆者並不認為合作夥伴可以替代企業自己的這類角色,最多是輔助角色,企業不可能把一個客戶洞察中心讓一個合作夥伴去管,因為只要跟數據緊捆綁,就意味着本地化屬性非常高,意味着巨大的交易成本。

第二、從合作夥伴的角度講,一定要在本地配備足夠的人員,他們才是產品提升的眼睛,適當的定製化不可避免,研發團隊除了聽取一線的聲音,更要關注開放性,為本地PSO賦能。

現在數據類的組件太多了,各有千秋,一個產品不可能打包天下,在一個地方做的足夠好就非常不錯了。

標籤庫可以跟互聯網公司的DMP相類比,DMP在精準廣告投放平台的作用可是居功至偉,相對還是比較成熟的。

但考慮到傳統企業相對薄弱的數據基礎,複雜的營銷機制和流程,單薄的人力資源配備,其建設和運營標籤庫的難度實際非常大,而考慮到每個企業的實際情況不同,又決定了大家不一樣的演進路線。

希望我的分享於你有啟示。

 

作者:傅一平,從事電信行業工作,在數據倉庫、數據架構、機器學習、數據產品、數據管理、精確營銷、數據變現等領域有10多年從業經驗,公眾號:與數據同行(ID:ysjtx_fyp)

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《十年的標籤庫建設經歷,從中我得到了什麼啟示?》
文章链接:https://www.pmbear.com/archives/9446
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们