數據產品索隆，標籤體系建設流程

我是要成為世界級大劍豪的男人——索隆。

索隆系列篇會記錄小白數據產品索隆，在數據中台部門的工作點滴，讓我們一起來看看索隆在進入偉大航路新賽道摸爬滾打的歷程。

上一篇數據產品索隆經歷了一頓來自領導鷹眼的深度抨擊，數據產品索隆，坎坷的標籤體系建設之路，對現有的業務不夠了解，對數據的分佈也缺乏認識，可不是四處碰壁嘛。

正當索隆一籌莫展之時，鷹眼早已洞察一切，於是高冷的鷹眼主動過來了解索隆的現狀。

鷹眼：索隆呀，現在遇到哪些問題？

索隆：眉頭一皺，説道，在需求階段，運營的場景、目標、策略等需求不夠落地，提供過來的信息過少；在設計階段，由於數據有一般依賴人為錄入，底層的數據質量較差，之間的ID體系未打通，識別的數據量有限；並且公司處於中台建設初期，數據基礎建設不完善，元數據缺乏管理，四處找庫找表，還要對接各個業務方問字段含義可謂是心力交瘁。

鷹眼：意識到索隆現在落入了碎片化問題的陷阱中，接着會心一笑，開導着索隆；標籤建設是數據產品工作中的一部分，符合產品經理的工作流；其實我之前提的問題也是在針對於工作流中的關鍵節點，你仔細想想產品的工作流是什麼？

索隆：產品的工作流這還不簡單，無非就是需求採集—需求分析—產品規劃—產品設計—開發測試—上線—運營—需求採集…走一道輪迴。

鷹眼：這些問題對應在工作流哪些關鍵節點？

索隆：若有所思，仔細一想之前提的問題確實在流程節點上，不同的問題分別對應在需求階段、設計階段、運營階段上。

鷹眼：要知道的是，萬事不離其宗，無論外界如何千變萬化，在實際工作中，都需要找到一條核心的主線，有了主線才能環環相扣，在上游準備好下游需要的條件，思慮更加周全。

那數據產品作為產品經理的分類之一，其基本方法論是一致的，只不過是在數據細節設計上會考慮得更細，接下來我們一塊來理理標籤構建流程。

一、標籤構建流程

標籤的整體構建流程符合產品工作流，包含需求階段、規劃設計階段、研發階段、運營階段。

1. 第一階段：需求階段

1）需求採集

需求採集可分為定量、定性兩種類型：

• 定量的發放調研問卷的形式，廣泛採集業務需求；
• 定性地進行用户訪談，深度挖掘業務應用場景和核心需求。

而由於數據中台部門並不是面向C端用户，而是面向內部各大業務應用方，發放調研問卷的方式執行難度很大，通常前期會採用用户訪談的方式，先小範圍的採集核心用户的需求。

按標準流程來開展調研，最終的調研結果會更具有落地性，但這對於一個初入公司的新人來説，需要注意如下幾個要點：

• 快速瞭解各方業務，完成初版標籤系統性建設目標的設定；
• 做好調研計劃，明確每個階段的輸入輸出，可能的困難和風險；
• 領導先行，從上至下進行推動；
• 站在業務方角度思考標籤價值點，找到雙方最佳的團隊協作平衡點；
• 制定需求採集模板，引導業務方輸出想要的結果。

2）需求分析

在需求採集階段，明確用户類型、需求場景、期望，接下來需要進一步挖掘和提煉用户需求，解決用户痛點問題，並把用户需求轉化為標籤數據需求。

通常數據需求是整體解決方案的方案中的一環，這也是我們常説的是數據用於輔助決策的原因。

所以作為一個數據產品經理，不僅僅是站在數據視角，提供專業的方案；還需站在業務視角，站在全局視角來看，業務方是在什麼場景下，遇到了什麼問題，期待怎樣的解決方案；而整個解決方案中，需要數據部門做怎樣的支持。

因此，業務部門與數據部門往往是聯動協調的一種關係，數據需求的開發最佳的實現方式，是能夠有業務產品進行配合；這樣在前期對於業務需求的把握，以及對標籤設計庫表字段、各要素的權重確定都有很大幫助。

而比較尷尬的是，數據中台是個相對比較中立的部門，既需要業務需求，又不能沉浸在業務需求中；所以在整個過程中需要考慮好系統建設目標和業務建設目標，所以必不可少的一個環節就是要對需求進行分析，這也十分考驗數據產品功力。

對於業務方提出的問題，需要符合smart法則，即具體的specific、可衡量measurable、可實現attainable、相關的relevant、時限性time-based。

例如，業務方初始設定的目標為，提升未簽約用户的再召回率1%。

策略及推送頻次：對超時、核銷的用户，通過篩選不同城市、渠道、跟進次數，進行差異化召回，每週1次。

乍一看，目標和策略都很清晰，有目標、有策略，並進行了量化，但是在實際執行時往往是漏洞百出。

• 目前未簽約用户量是多少？提升到多少才算1%？
• 效果如何監測，是否需要分析師制定tableau實驗組和對照組的看板？
• 超時、核銷的現有用户量有多大，推送的計劃是什麼？每個城市的未簽約用户數據如何？
• 第一波先推送哪些城市？推送頻率如何？

2. 第二階段：規劃設計階段

1）標籤規劃

標籤整體規劃看起來很虛，但是在實際項目過程中至關重要。

有了標籤建設全階段的規劃，可以更容易得到公司資源的支持，也能夠幫助團隊達成共識目標；在工作中有方向不迷茫，提升團隊成員的個人價值感，提升整體團隊凝聚力。

中台建設的基礎是基於業務而又高於業務，數據中台的建設需要業務進行推動，但又不完全依賴於業務，在建設過程中有如下幾個要點：

• 需要平衡好系統建設和業務需要之間的關係；
• 建設好底層數據集市；
• 與領導和業務方達成階段性版本規劃共識，避免返工。

2）標籤設計階段

標籤設計流程會分為：明確建設目標、架構設計、標籤規則設計、數據梳理。

• 明確建設目標，通常會分系統性建設目標和業務建設目標，在對標籤進行整體產品規劃後，通常會對一期的目標有更清晰的認識。
• 標籤的架構設計，包含業務架構、產品架構、數據架構設計，塑造全局觀。
• 建設ID體系，實現用户的ID互通，這對於整個標籤的建設至關重要；通常需要維護一個ID映射庫，用手機號、IMEI等來標識其為同一用户。
• 標籤規則設計，包含標籤層級設計，標籤業務含義的確定，標籤取數邏輯確定。

標籤分為統計類標籤、規則類標籤、算法類標籤，通常統計類標籤較為簡單，又稱為事實標籤，是事實數據的呈現；規則類和算法類標籤較為複雜，通常需要數據分析師與算法工程師協同來進行確定。

3. 第三階段：標籤研發階段

研發會比較關注標籤寬表中需要有哪些字段、標籤的細緻取數邏輯、取自哪個庫下的哪個表、字段代表的值取哪幾個狀態。

常見的業務表會存staus=ycz、dzz、yjy…這樣的數據字段，那對於開發測試而言，他們通常對業務瞭解較少，無法主觀做出判斷取哪些狀態；所以數據產品在標籤設計階段需要了解，業務上會有哪些狀態，最好是能夠將數據的取值給羅列出來。

對於測試而言，會比較關注測哪些庫，研發的取數跟產品設計是否一致、取值含義等。

4. 第四階段：運營階段

數據產品在整個過程中都需要不斷思考標籤可能的應用，如做個性化推薦、對接到畫像系統中、push和短信推送、建設用户行為分析系統等等。

建立標籤體系是為了幫助業務方，為用户提供更加精準和個性化的服務，提高單個用户的價值；那花費巨大精力開發出標籤，佔着存儲與計算資源，若是無人使用，則面臨着剛上線又下線的風險。

所以數據產品一方面要進行推廣，可以組織對業務方的培訓，告訴業務方標籤代表的含義，如何使用這些標籤；另一方面，在運營推廣出去之後，進行標籤監測，監測標籤的使用人數、熱度等，輔助判斷標籤在實際應用中的重要性，後續可以將一些無用標籤下架。

二、結束語

索隆聽完鷹眼對標籤建設全流程階段的解析後，感覺自己信心滿滿，心想：看來之後我可以按照標準流程套路走，穩步前行，這樣就可以在偉大航路上乘風破浪，暢通無阻。

實際項目往往是十分險惡的，那麼索隆在實際項目過程中是否暢通無阻呢？他又將遇到哪些磨難？

下一篇，為你揭曉~

歷史文章鏈接：

數據產品索隆，坎坷的標籤體系建設之路

作者：草帽小子；公眾號：一個數據人的自留地，wx：luckily304

本文由 @草帽小子 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議