惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

爱范儿
爱范儿
Microsoft Azure Blog
Microsoft Azure Blog
G
Google Developers Blog
宝玉的分享
宝玉的分享
V
V2EX
MongoDB | Blog
MongoDB | Blog
S
SegmentFault 最新的问题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Microsoft Security Blog
Microsoft Security Blog
博客园 - 聂微东
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
IT之家
IT之家
Martin Fowler
Martin Fowler
大猫的无限游戏
大猫的无限游戏
Recent Announcements
Recent Announcements
人人都是产品经理
人人都是产品经理
博客园 - 司徒正美
美团技术团队
F
Fortinet All Blogs
N
Netflix TechBlog - Medium
Hugging Face - Blog
Hugging Face - Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
罗磊的独立博客
B
Blog RSS Feed

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
品牌数据漫谈(1)——主数据
52赫兹 · 2023-02-02 · via 人人都是产品经理

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

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

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

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

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

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

一、产品主数据

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

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