在日常工作中，数据可以帮助业务人员更好地了解业务现状，并针对数据反馈进行策略上的调整。而就品牌数据而言，主数据则是其需要重视、却往往在维护或管理上都不到位的数据类型。这一数据类型都包含哪些细分类目？一起来看看作者的分析吧。
这里根据过往的一些项目经验，整理了一下品牌现有的一方数据。因为行业不同会有一些数据特性上的差异性，这里简单跟大家分享讨论一下。
下图是总结一方数据的几个种类（可以获取到个体级别的数据）。如果有遗漏后面再行补充。
作为第一部分先简单地聊一下主数据。
这部分的数据往往不被品牌重视，所以维护或是管理通常都不是很到位，甚至一些品牌谁来维护这些数据都没有清晰的归属。
这类数据其实是所有数据的基础，可以大大地减少其他数据应用时的冗余信息。而且在进行业务场景分析时可以便捷地拓展需要新增的维度。
各类主数据中最重要的肯定是产品主数据。这类数据记录着每个产品的基础属性，不同的行业也会有一些特殊的属性字段。根据数据质量这里暂时分为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 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。