用户画像基础：概念、标签体系与数据架构

用户画像这个词，这几年被炒得很热。说白了，它就是给用户打标签，然后通过这些标签来描述一个人。我在做电商项目时，老板总说「我们要懂用户」，但怎么才算懂？画像就是答案。

今天咱们聊聊三个核心问题：画像到底是什么？标签怎么设计？背后的数据怎么组织？

一、用户画像到底是什么？

用户画像，英文叫 User Profile。它不是一张照片，而是一组标签的集合。比如「25岁、女性、喜欢买美妆、月消费2000+」——这就是一个简单的画像。

我习惯把画像分成两类：

• 基础画像：性别、年龄、地域、职业等静态信息
• 行为画像：购买偏好、活跃时段、浏览路径等动态信息

你想想看，如果只知道用户是男是女，那能做的事很有限。但如果你知道他每周五晚上10点都会打开APP刷美妆视频，那推荐就精准多了。

二、标签体系设计——画像的骨架

标签体系是画像的骨架。骨架歪了，画像就站不住。我在项目中踩过不少坑，这里分享几个关键原则。

2.1 标签的分类层级

我一般把标签分成三级：

层级	说明	举例
一级标签	最粗的维度	人口属性、消费能力、兴趣偏好
二级标签	具体分类	年龄区间、消费等级、品类偏好
三级标签	原子标签，不可再分	25-30岁、高消费、美妆爱好者

为什么要分三级？因为不同业务场景需要不同粒度的标签。运营活动可能只看一级，个性化推荐需要三级。

2.2 标签设计原则

嗯，这里要注意几个坑：

• 可计算性：每个标签必须有明确的计算逻辑。不能是「大概感觉」
• 互斥性：同一层级的标签不能重叠。比如「高消费」和「中高消费」不能同时存在
• 完整性：覆盖所有用户。不能有「未知」就完事了

三、画像数据架构——怎么存？怎么算？

标签设计好了，接下来就是数据架构。说白了，就是数据从哪来、存哪去、怎么更新。

3.1 数据分层

我习惯把画像数据分成三层：

1. ODS层（原始数据）：用户注册信息、订单记录、浏览日志等原始数据
2. DWD层（明细数据）：清洗、去重后的用户行为明细
3. DWS层（汇总数据）：按用户聚合的标签结果

举个例子，用户今天浏览了10次美妆页面，ODS存的是10条日志，DWD存的是清洗后的10条记录，DWS存的是「美妆浏览频次：10」这个标签。

3.2 存储方案

标签数据怎么存？我推荐用宽表 + 标签库的组合：

• 宽表：每个用户一行，每列是一个标签。适合查询快，但扩展性差
• 标签库：用KV结构存，用户ID + 标签名 + 标签值。扩展性好，但查询慢

实际项目中，我通常把高频标签放宽表，低频标签放标签库。这样既快又灵活。

3.3 更新策略

标签不是一成不变的。我见过最蠢的做法是每天全量重算——数据量大时根本跑不完。

建议用增量更新：

• T+1更新：每天凌晨跑一次，更新行为类标签
• 实时更新：用流处理框架，用户一有动作就更新
• 定时刷新：基础属性类标签，每周或每月更新一次

四、核心知识体系图

下面这张图，是我对用户画像知识体系的总结。你可以把它当作本章的思维导图。

五、一个简单的标签计算示例

光说不练假把式。我写个简单的 SQL，展示怎么算「高消费用户」这个标签。

-- 计算用户近30天消费总额
-- 标签规则：消费总额 > 5000 为高消费
WITH user_spend AS (
  SELECT 
    user_id,
    SUM(amount) AS total_spend
  FROM orders
  WHERE order_date >= DATE_SUB(CURRENT_DATE, 30)
  GROUP BY user_id
)
SELECT 
  user_id,
  total_spend,
  CASE 
    WHEN total_spend > 5000 THEN '高消费'
    WHEN total_spend > 1000 THEN '中消费'
    ELSE '低消费'
  END AS consumption_level
FROM user_spend;

这段代码很简单，但实际项目中要考虑更多：比如退款订单要不要算？跨月数据怎么处理？嗯，这些细节往往决定标签的准确性。

六、总结一下

用户画像不是玄学，它是一套工程化的方法。从概念到标签设计，再到数据架构，每一步都有章可循。

我个人习惯，做画像项目时先花 30% 的时间梳理业务需求，再花 30% 设计标签体系，最后 40% 才是写代码。顺序搞反了，后面全是坑。

好了，这一章就聊到这。记住：好的画像，是让机器懂用户，而不是让用户懂机器。