在日常工作中,数据可以帮助业务人员更好地了解业务现状,并针对数据反馈进行策略上的调整。而就品牌数据而言,主数据则是其需要重视、却往往在维护或管理上都不到位的数据类型。这一数据类型都包含哪些细分类目?一起来看看作者的分析吧。

这里根据过往的一些项目经验,整理了一下品牌现有的一方数据。因为行业不同会有一些数据特性上的差异性,这里简单跟大家分享讨论一下。

下图是总结一方数据的几个种类(可以获取到个体级别的数据)。如果有遗漏后面再行补充。

作为第一部分先简单地聊一下主数据。

这部分的数据往往不被品牌重视,所以维护或是管理通常都不是很到位,甚至一些品牌谁来维护这些数据都没有清晰的归属。

这类数据其实是所有数据的基础,可以大大地减少其他数据应用时的冗余信息。而且在进行业务场景分析时可以便捷地拓展需要新增的维度。

一、产品主数据

各类主数据中最重要的肯定是产品主数据。这类数据记录着每个产品的基础属性,不同的行业也会有一些特殊的属性字段。根据数据质量这里暂时分为3个阶段。

第一个阶段,产品主数据最少要有两个字段,产品ID和唯一产品名称。

其中产品ID一般是唯一主键。有些主数据乱的品牌可能有多份产品主数据,对应不同的系统(POS、天猫、CRM等)。这类问题一般是品牌数字化前期没有主数据的概念,每个系统都制作了一份系统涉及到的产品,和全量的产品相比会有一些缺失,并且各自更新自己用到的部分。后续可能需要在产品主数据里面合并该产品在各个系统里面的ID是什么。合并以及维护都有不小的工作量。

第二个阶段,产品主数据会有若干层级清晰的品类定义,从这里开始,业务定义的重要性就会越来重。一般来说三个层级会比较合适一些(美妆-面部-基础粉底,甜品-蛋糕-纸杯蛋糕),一些特殊的行业可能会多一些。

这些品类定义一般是行业通用的,根据品牌的特性做针对性的调整,后续可以直接做成对应的标签圈选人群。例如近半年购买过超过3次美妆产品的客户,近三个月购买过基础粉底的客户等。

同时这类维度也可以直接转化成销售Dashboard的维度指标,结合订单里面的渠道维度,可以了解各个渠道不同品类的销售趋势。当一些品类快速增长时,可以尽早地发现并调整品牌策略。

第三个阶段,产品主数据会补充一些可用于结构化分析的属性维度。

例如食品类的产品还有规格(2*15g,4*16个等)、口味(香草、蓝莓等)、新品、季节性等属性标识。

这些指标可能有些品牌一直都有,但比较混乱,部分产品字段有缺失,没法直接做数据分析。当然一些属性可能会变化,例如新品标识,这类标识放在订单会可能会更合适一些。

这部分拓展字段之前品牌并可能没有很重视地去进行管理,但是现在品牌期望从数据中得到一些产品属性层面的建议,却发现维度不够丰富。这类属性只要有明确的逻辑还是比较好补充的,例如根据规格判断产品种类是自用、囤货或是送礼,根据口味和季节性判断尝鲜产品的喜好人群。这类拓展的维度就要看行业特性以及业务侧的需求去管理了。

二、套组主数据

这类主数据不太好维护,一方面是因为套组的内容经常会有调整,有些品牌会沿用之前的套组ID,导致不同时间段内,同一套组ID内的产品不一样。另外一方面是因为这类数据往往并不是品牌的人员直接维护,一旦赶上有活动忙起来,信息没空及时地同步给相关人员,基本都是在用的时候才去找相关人员补充信息。

套组数据在实际应用中也是比较麻烦的,一方面不同套组的业务目的不太一样,有的是节日套组,有的是为了清理一些库存,有的是为了给目标产品引流。这类业务信息通常都不会在主数据中体现。

另外从分析的维度来说也比较难以拆解。仅仅是套组之间的比较最终也要归因到单品上,数据更新的及时性和准确性的要求就会很高。

最复杂的肯定就是金额的拆解,如果只是拆解到人还比较容易处理。比如说一个200元套组内含有品类ABC三种产品,那近30天有购买过系列的人群三种就可以各算1,购买件数也可以比较容易拆解。

但是如果需要分析的人群是近30天购买品类A的金额高于100元的人群,那这个套组内个各个产品应该算多少。有些品牌可能套组是单独计算的,也就是品类相关的订单不计算套组的产品金额,套组为一个独立的品类(套组金额占比不高)。

当然最客观的算法应该是根据套组内产品定价的比例去拆分金额,但在一些特定的业务目的场景下就不太合适了。比如说为了主推产品A设计了一份包装礼盒,里面其他的附属产品其实都是以赠品的形式包含在内的,在计算金额的时候品牌可能也会更倾向于都算在主推产品上面。

套组的计算逻辑感觉没有一套全行业完全客观公正的方法,需要根据品牌特性主观地确认一套拆分逻辑,这样后续在使用或分析相关数据的时候才能保持前后逻辑的一致性。

跨品牌套组

跨品牌套组指的是,一个套组内有一个集团下多品牌的产品,遇到的问题其实和套组遇到的问题是类似的,但本质却是集团内部架构特殊情况的体现。套组的业务目的就有可能延伸到集团层面,也可能是大品牌带动小品牌的初期启动。在确认计算逻辑的时候就要涉及到多品牌同时沟通确认的问题了。

三、门店主数据

这类主数据一般是针对有线下门店的品牌,不过现在因为都在做omni-channel的数据合并,所以也会将线上门店包含在门店主数据内(天猫、微商城、官网等)。

基础类的门店主数据包含门店ID和门店名称,同时会有具体的地址、所在城市、所在省份的信息。除此之外,根据品牌业务的定义会再进行精细的分类。

向上细分会根据城市做二次分类,有的根据地域(华南、华北),有个根据城市经济水平(一线、新一线),有的则有自己的重点城市(重点城市,非重点城市)。

这类的分类往往会结合内部的业务情况,制作成日常的报表或Dashboard展现各个地域的销售情况,也会去帮助判断消费者的活跃城市。

向下细分则会根据门店所属的商圈,小区数量,客流情况进行分类(例如步行街、城市商圈),同类型的门店也会横向比较,针对一些表现稍差的门店也会做一些深入的调研分析。

维护这类数据主要的难点是开闭店的状态往往更新得不及时,导致一些计算类的指标会受到影响。再延伸一下到标识门店内是否包含一些特定的服务项目信息(例如保养体验或是否支持外卖等),这类特定功能的变动往往也有一些更新滞后的问题。

四、导购主数据

最初导购类数据是为了帮助门店统计各个导购带来的销售金额,以评估各个导购的表现。现在因为多了企微名片、企微群这样的触客渠道,将导购带来的数据从销售延伸到了售前阶段。这类数据的应用暂时还是比较传统。后续在企微部分再做深入讨论。

以上是针对项目中常见的一些主数据的介绍,后续有补充的会再行修改。

当然这也肯定不是全面的介绍,每个主数据的细节也会因为行业有不同程度的差异,特别是一些业务逻辑或业务侧重点也会在主数据上有所体现。欢迎各类讨论共同学习。

本文由 @52赫兹 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。