品牌資料漫談(1)——主資料

在日常工作中,資料可以幫助業務人員更好地瞭解業務現狀,並針對資料反饋進行策略上的調整。而就品牌資料而言,主資料則是其需要重視、卻往往在維護或管理上都不到位的資料型別。這一資料型別都包含哪些細分類目?一起來看看作者的分析吧。

品牌資料漫談(1)——主資料

這裡根據過往的一些專案經驗,整理了一下品牌現有的一方資料。因為行業不同會有一些資料特性上的差異性,這裡簡單跟大家分享討論一下。

下圖是總結一方資料的幾個種類(可以獲取到個體級別的資料)。如果有遺漏後面再行補充。

品牌資料漫談(1)——主資料

作為第一部分先簡單地聊一下主資料。

這部分的資料往往不被品牌重視,所以維護或是管理通常都不是很到位,甚至一些品牌誰來維護這些資料都沒有清晰的歸屬。

這類資料其實是所有資料的基礎,可以大大地減少其他資料應用時的冗餘資訊。而且在進行業務場景分析時可以便捷地拓展需要新增的維度。

一、產品主資料

各類主資料中最重要的肯定是產品主資料。這類資料記錄著每個產品的基礎屬性,不同的行業也會有一些特殊的屬性欄位。根據資料質量這裡暫時分為3個階段。

第一個階段,產品主資料最少要有兩個欄位,產品ID和唯一產品名稱。

其中產品ID一般是唯一主鍵。有些主資料亂的品牌可能有多份產品主資料,對應不同的系統(POS、天貓、CRM等)。這類問題一般是品牌數字化前期沒有主資料的概念,每個系統都製作了一份系統涉及到的產品,和全量的產品相比會有一些缺失,並且各自更新自己用到的部分。後續可能需要在產品主資料裡面合併該產品在各個系統裡面的ID是什麼。合併以及維護都有不小的工作量。

第二個階段,產品主資料會有若干層級清晰的品類定義,從這裡開始,業務定義的重要性就會越來重。一般來說三個層級會比較合適一些(美妝-面部-基礎粉底,甜品-蛋糕-紙杯蛋糕),一些特殊的行業可能會多一些。

這些品類定義一般是行業通用的,根據品牌的特性做針對性的調整,後續可以直接做成對應的標籤圈選人群。例如近半年購買過超過3次美妝產品的客戶,近三個月購買過基礎粉底的客戶等。

同時這類維度也可以直接轉化成銷售Dashboard的維度指標,結合訂單裡面的渠道維度,可以瞭解各個渠道不同品類的銷售趨勢。當一些品類快速增長時,可以儘早地發現並調整品牌策略。

第三個階段,產品主資料會補充一些可用於結構化分析的屬性維度。

例如食品類的產品還有規格(2*15g,4*16個等)、口味(香草、藍莓等)、新品、季節性等屬性標識。

這些指標可能有些品牌一直都有,但比較混亂,部分產品欄位有缺失,沒法直接做資料分析。當然一些屬性可能會變化,例如新品標識,這類標識放在訂單會可能會更合適一些。

這部分拓展欄位之前品牌並可能沒有很重視地去進行管理,但是現在品牌期望從資料中得到一些產品屬性層面的建議,卻發現維度不夠豐富。這類屬性只要有明確的邏輯還是比較好補充的,例如根據規格判斷產品種類是自用、囤貨或是送禮,根據口味和季節性判斷嚐鮮產品的喜好人群。這類拓展的維度就要看行業特性以及業務側的需求去管理了。

二、套組主資料

這類主資料不太好維護,一方面是因為套組的內容經常會有調整,有些品牌會沿用之前的套組ID,導致不同時間段內,同一套組ID內的產品不一樣。另外一方面是因為這類資料往往並不是品牌的人員直接維護,一旦趕上有活動忙起來,資訊沒空及時地同步給相關人員,基本都是在用的時候才去找相關人員補充資訊。

套組資料在實際應用中也是比較麻煩的,一方面不同套組的業務目的不太一樣,有的是節日套組,有的是為了清理一些庫存,有的是為了給目標產品引流。這類業務資訊通常都不會在主資料中體現。

另外從分析的維度來說也比較難以拆解。僅僅是套組之間的比較最終也要歸因到單品上,資料更新的及時性和準確性的要求就會很高。

最複雜的肯定就是金額的拆解,如果只是拆解到人還比較容易處理。比如說一個200元套組內含有品類ABC三種產品,那近30天有購買過系列的人群三種就可以各算1,購買件數也可以比較容易拆解。

但是如果需要分析的人群是近30天購買品類A的金額高於100元的人群,那這個套組內個各個產品應該算多少。有些品牌可能套組是單獨計算的,也就是品類相關的訂單不計算套組的產品金額,套組為一個獨立的品類(套組金額佔比不高)。

當然最客觀的演算法應該是根據套組內產品定價的比例去拆分金額,但在一些特定的業務目的場景下就不太合適了。比如說為了主推產品A設計了一份包裝禮盒,裡面其他的附屬產品其實都是以贈品的形式包含在內的,在計算金額的時候品牌可能也會更傾向於都算在主推產品上面。

套組的計算邏輯感覺沒有一套全行業完全客觀公正的方法,需要根據品牌特性主觀地確認一套拆分邏輯,這樣後續在使用或分析相關資料的時候才能保持前後邏輯的一致性。

跨品牌套組

跨品牌套組指的是,一個套組內有一個集團下多品牌的產品,遇到的問題其實和套組遇到的問題是類似的,但本質卻是集團內部架構特殊情況的體現。套組的業務目的就有可能延伸到集團層面,也可能是大品牌帶動小品牌的初期啟動。在確認計算邏輯的時候就要涉及到多品牌同時溝通確認的問題了。

三、門店主資料

這類主資料一般是針對有線下門店的品牌。

基礎類的門店主資料包含門店ID和門店名稱,同時會有具體的地址、所在城市、所在省份的資訊。除此之外,根據品牌業務的定義會再進行精細的分類。

向上細分會根據城市做二次分類,有的根據地域(華南、華北),有個根據城市經濟水平(一線、新一線),有的則有自己的重點城市(重點城市,非重點城市)。

這類的分類往往會結合內部的業務情況,製作成日常的報表或Dashboard展現各個地域的銷售情況,也會去幫助判斷消費者的活躍城市。

向下細分則會根據門店所屬的商圈,小區數量,客流情況進行分類(例如步行街、城市商圈),同類型的門店也會橫向比較,針對一些表現稍差的門店也會做一些深入的調研分析。

維護這類資料主要的難點是開閉店的狀態往往更新得不及時,導致一些計算類的指標會受到影響。再延伸一下到標識門店內是否包含一些特定的服務專案資訊(例如保養體驗或是否支援外賣等),這類特定功能的變動往往也有一些更新滯後的問題。

四、導購主資料

最初導購類資料是為了幫助門店統計各個導購帶來的銷售金額,以評估各個導購的表現。現在因為多了企微名片、企微群這樣的觸客渠道,將導購帶來的資料從銷售延伸到了售前階段。這類資料的應用暫時還是比較傳統。後續在企微部分再做深入討論。

以上是針對專案中常見的一些主資料的介紹,後續有補充的會再行修改。

當然這也肯定不是全面的介紹,每個主資料的細節也會因為行業有不同程度的差異,特別是一些業務邏輯或業務側重點也會在主資料上有所體現。歡迎各類討論共同學習。

本文由 @52赫茲 原創釋出於人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基於 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

頂部