🎯 为什么说主题域划分是数据建模的「灵魂」？
2023年夏天，某造车新势力的数据团队陷入了困境：
他们花了6个月时间，建了127张数据表，写了3500+个字段，但当业务部门问：「最近3个月购买过延保的用户，他们的平均客单价是多少？」
数据团队傻眼了：
- 用户信息分散在8张表里
- 延保信息在CRM系统的订单表
- 客单价需要从售后系统的工单表计算
- 三个系统的用户ID关联规则还不统一
一个看似简单的问题，3个数据分析师花了整整5天才给出答案。
他们的问题在哪？没有做主题域划分，数据散落各处，像一盘散沙。
📐 什么是主题域（Subject Area）？
主题域 = 按业务主题组织的数据集合，是企业数据资产的「图书馆分类法」。
类比：图书馆的启示
想象一个图书馆，如果没有分类：
- 10万本书随机堆放
- 找一本书需要翻遍整个图书馆
- 书与书之间的关系无从得知
但有了图书分类法（文学、历史、科学...）后：
- 每本书都有明确的归属
- 同类书籍聚在一起
- 找书只需要定位到对应分类
主题域就是数据世界的「图书分类法」。
🏗️ 售后业务的五大主题域
经过对100+家新能源车企的售后数据架构分析，我们提炼出通用的五大主题域：
售后业务数据架构
├─ 用户主题域 (Customer Domain)
├─ 车辆主题域 (Vehicle Domain)
├─ 工单主题域 (Service Order Domain)
├─ 配件主题域 (Parts Domain)
└─ 人员主题域 (Staff Domain)
今天我们深度拆解前三大核心域。
👤 用户主题域 (Customer Domain)
核心问题：我们的用户是谁？他们有什么特征？
用户主题域回答三类问题：
- 是谁：用户的身份属性（姓名、性别、年龄、职业...）
- 在哪：用户的地理属性（城市、区域、距最近门店距离...）
- 怎样：用户的行为属性（累计消费、服务次数、会员等级、生命周期...）
用户主题域的数据模型设计
核心实体：dim_user（用户维度表）
设计原则：一个用户，一行记录（使用SCD Type 2处理历史变化）
CREATE TABLE dim_user (
-- 主键
user_key INT PRIMARY KEY AUTO_INCREMENT, -- 代理键
user_id VARCHAR(50) UNIQUE, -- 业务键（CRM用户ID）
-- 身份属性
user_name VARCHAR(100),
id_card VARCHAR(18),
phone VARCHAR(20),
email VARCHAR(100),
gender VARCHAR(10), -- 男/女/未知
birth_date DATE,
age INT,
-- 地理属性
province VARCHAR(50),
city VARCHAR(50),
district VARCHAR(50),
address TEXT,
nearest_center_id INT, -- 最近服务中心ID
distance_to_center DECIMAL(5,1), -- 距最近中心的距离(km)
-- 职业与收入（选填）
occupation VARCHAR(100),
income_range VARCHAR(50), -- <10万/10-20万/20-50万/>50万
education VARCHAR(50),
-- 会员属性
membership_level VARCHAR(50), -- 普通/银卡/金卡/白金/黑卡
membership_start_date DATE,
membership_points INT,
-- 车辆关系（冗余字段，提升查询性能）
vehicle_count INT, -- 拥有车辆数
first_vehicle_purchase_date DATE,-- 首次购车日期
main_vehicle_model VARCHAR(100), -- 主力车型
-- 行为统计（定期更新）
total_orders INT, -- 累计工单数
total_spend DECIMAL(12,2), -- 累计消费金额
avg_order_value DECIMAL(10,2), -- 平均客单价
last_service_date DATE, -- 最近服务日期
days_since_last_service INT, -- 距上次服务天数
lifetime_value DECIMAL(12,2), -- 客户终身价值（预测）
-- 偏好属性
preferred_advisor VARCHAR(100), -- 偏好服务顾问
preferred_service_time VARCHAR(50), -- 偏好服务时段（工作日上午/下午/晚上，周末...）
preferred_contact_method VARCHAR(50), -- 偏好联系方式（短信/电话/APP）
-- 风险标签
is_vip BOOLEAN,
is_high_risk BOOLEAN, -- 是否高流失风险
churn_probability DECIMAL(3,2), -- 流失概率（0-1）
satisfaction_trend VARCHAR(20), -- 满意度趋势（上升/稳定/下降）
-- SCD字段
effective_date DATE,
expiry_date DATE,
is_current BOOLEAN,
-- 数据质量与审计
data_source VARCHAR(50), -- CRM/DMS/APP/导入
data_quality_score INT, -- 数据质量评分(0-100)
created_at TIMESTAMP,
updated_at TIMESTAMP,
created_by VARCHAR(50)
);
字段数：42个（这是一张典型的宽表）
真实案例：蔚来的用户360°画像
蔚来的用户维度表有180+个字段，构建了业内最完善的用户画像系统。
基础信息层（30字段）
- 身份信息、联系方式、地理位置
车辆关系层（25字段）
- 拥有车型、购车时间、车辆配置、电池方案（租赁/买断）
消费行为层（40字段）
- 累计工单数、累计消费、平均客单价
- 服务频次、最近活跃时间、活跃度评分
- 保养习惯、配件购买偏好
服务偏好层（30字段）
- 偏好服务顾问、偏好服务时间
- 偏好支付方式、是否使用代步车
- 是否预约、预约提前天数
社交属性层（25字段）
- APP活跃度、社区发帖数、点赞数
- NIO Radio听歌时长、参加活动次数
- 推荐新用户数量
风险预警层（30字段）
- 流失风险评分、满意度趋势
- 投诉次数、投诉类型分布
- 竞品关注度（通过APP行为推测）
这套体系让蔚来能够：
- 提前90天识别高流失风险用户，挽回率提升65%
- 精准推送服务提醒，预约率提升40%
- 个性化服务推荐，增值服务渗透率提升3.2倍
用户主题域的3个设计难点
难点1：多车用户如何处理？
**场景：**一个用户拥有2辆车，Model 3和Model Y。
方案A：用户表中冗余主力车型（推荐）
dim_user表：
user_id: U123456
main_vehicle_model: "Model 3" -- 主力车型
vehicle_count: 2
方案B：建立用户-车辆关系表
bridge_user_vehicle表：
user_id: U123456, vehicle_id: V001, is_main: TRUE
user_id: U123456, vehicle_id: V002, is_main: FALSE
实战建议：
- 如果90%以上用户只有1辆车：用方案A
- 如果多车用户比例>10%：用方案B
难点2：用户属性变化如何追溯？
**场景：**用户张三在2023年是「普通会员」，2024年升级为「金卡会员」。分析2023年数据时，应该用哪个会员等级？
解决方案：SCD Type 2（缓慢变化维度）
-- 2023年的记录
user_key: 1001
user_id: "U123456"
user_name: "张三"
membership_level: "普通会员"
effective_date: "2023-01-01"
expiry_date: "2023-12-31"
is_current: FALSE
-- 2024年的记录
user_key: 1002
user_id: "U123456"
user_name: "张三"
membership_level: "金卡会员"
effective_date: "2024-01-01"
expiry_date: "9999-12-31"
is_current: TRUE
查询2023年数据时：
SELECT u.membership_level
FROM fact_service_order f
JOIN dim_user u ON f.user_key = u.user_key
WHERE f.order_date BETWEEN '2023-01-01' AND '2023-12-31';
-- 自动关联到user_key=1001，显示「普通会员」✅
这样就保证了历史数据分析的准确性。
难点3：用户数据质量如何保证？
常见问题：
- 手机号为空或格式错误
- 地址不完整
- 重复用户（同一人多个ID）
蔚来的数据质量评分体系：
data_quality_score =
(手机号完整性 × 30%) +
(地址完整性 × 20%) +
(车辆关联完整性 × 20%) +
(行为数据完整性 × 15%) +
(重复率检查 × 15%)
实施效果：
- 数据质量评分<60分的用户，触发人工审核
- 每季度清洗一次，数据完整率从68%提升到94%
🚗 车辆主题域 (Vehicle Domain)
核心问题：我们在服务哪些车？它们的状态如何？
车辆主题域回答三类问题：
- 是什么车：车型、配置、VIN码...
- 用了多久：购车日期、行驶里程、车龄...
- 什么状态：保修状态、电池健康度、历史维修记录...
车辆主题域的数据模型设计
核心实体：dim_vehicle（车辆维度表）
CREATE TABLE dim_vehicle (
-- 主键
vehicle_key INT PRIMARY KEY AUTO_INCREMENT,
vehicle_id VARCHAR(50) UNIQUE, -- 业务键（车辆ID）
vin VARCHAR(17) UNIQUE, -- VIN码（车辆识别代号）
-- 车辆基本信息
brand VARCHAR(50), -- 品牌（特斯拉/蔚来/小鹏...）
model VARCHAR(100), -- 车型（Model 3/ES8...）
variant VARCHAR(100), -- 配置（标准续航/长续航...）
model_year INT, -- 年款（2023/2024...）
color VARCHAR(50), -- 车身颜色
interior_color VARCHAR(50), -- 内饰颜色
-- 动力与电池
power_type VARCHAR(50), -- 纯电/混动/增程
battery_capacity DECIMAL(5,1), -- 电池容量(kWh)
battery_brand VARCHAR(50), -- 电池品牌（宁德时代/比亚迪...）
battery_ownership VARCHAR(20), -- 电池所有权（买断/租赁）
motor_power INT, -- 电机功率(kW)
drive_type VARCHAR(20), -- 驱动类型（前驱/后驱/四驱）
-- 购买信息
purchase_date DATE,
purchase_price DECIMAL(10,2),
purchase_channel VARCHAR(50), -- 直营/经销商/二手
is_first_owner BOOLEAN, -- 是否首任车主
-- 所有权信息
owner_user_id VARCHAR(50), -- 当前车主ID
owner_change_count INT, -- 过户次数
-- 使用状态
current_mileage INT, -- 当前里程(km)
avg_monthly_mileage INT, -- 月均里程
vehicle_age_days INT, -- 车龄(天)
days_since_last_service INT, -- 距上次保养天数
-- 保修信息
warranty_start_date DATE,
warranty_end_date DATE,
warranty_mileage_limit INT, -- 质保里程上限
is_in_warranty BOOLEAN, -- 是否在保
extended_warranty BOOLEAN, -- 是否购买延保
extended_warranty_end_date DATE,
-- 技术状态
battery_health DECIMAL(3,2), -- 电池健康度(0-1)
software_version VARCHAR(50), -- 车机系统版本
last_ota_date DATE, -- 最近OTA升级日期
-- 服务历史统计
total_service_count INT, -- 累计服务次数
total_service_cost DECIMAL(12,2), -- 累计服务费用
last_service_date DATE,
last_service_type VARCHAR(100), -- 最近服务类型
-- 问题与风险
recall_count INT, -- 召回次数
major_repair_count INT, -- 重大维修次数
accident_count INT, -- 事故次数
risk_level VARCHAR(20), -- 风险等级（低/中/高）
-- 车辆状态
vehicle_status VARCHAR(50), -- 在用/报废/转出/失联
deregistration_date DATE, -- 注销日期
-- 数据质量
data_source VARCHAR(50),
data_quality_score INT,
created_at TIMESTAMP,
updated_at TIMESTAMP
);
字段数：53个
真实案例：特斯拉的车辆全生命周期管理
特斯拉对每辆车进行实时监控，车辆维度表每小时更新一次。
核心能力：
1. 预测性维护
- 通过车辆传感器数据，预测零部件寿命
- 提前2周提醒用户：「您的刹车片剩余寿命15%，建议尽快保养」
- 减少了70%的路边抛锚事件
2. 电池健康追踪
- 实时监控电池衰减
- 发现异常衰减车辆，主动联系用户检测
- 电池投诉率下降45%
3. OTA升级管理
- 记录每辆车的软件版本
- 推送升级时，识别哪些车还未升级
- OTA完成率从82%提升到98%
车辆主题域的3个设计难点
难点1：里程数如何保持准确？
**问题：**用户不一定每次都来官方服务中心，里程数可能不准。
特斯拉的方案：
- 通过车联网，每天自动上传里程数
- 车辆维度表的
current_mileage每天更新 - 如果连续7天未上传，标记为「数据异常」
传统车企的方案：
- 每次进店时，技师手动录入里程数
- 系统自动校验：如果新里程<旧里程，触发异常提示
- 如果里程增长过快（>1000km/天），也触发异常
难点2：二手车如何处理？
**场景：**车辆V001在2023年卖给了新车主。
方案A：更新owner_user_id（简单，但丢失历史）
UPDATE dim_vehicle
SET owner_user_id = 'U999999',
owner_change_count = owner_change_count + 1
WHERE vehicle_id = 'V001';
方案B：建立车辆-车主关系历史表（推荐）
CREATE TABLE vehicle_owner_history (
vehicle_id VARCHAR(50),
owner_user_id VARCHAR(50),
ownership_start_date DATE,
ownership_end_date DATE,
is_current BOOLEAN
);
好处：
- 可以追溯每辆车的所有车主
- 分析：「二手车主的服务频次是否高于首任车主？」
难点3：车辆报废后如何处理？
方案：软删除 + 状态标记
UPDATE dim_vehicle
SET vehicle_status = '已报废',
deregistration_date = '2024-06-15',
is_current = FALSE
WHERE vehicle_id = 'V001';
查询时自动过滤：
SELECT * FROM dim_vehicle
WHERE vehicle_status = '在用'; -- 只看在用车辆
保留报废车辆数据的价值：
- 分析报废车辆的平均里程、车龄
- 研究哪些车型更容易报废
- 预测车辆残值
📋 工单主题域 (Service Order Domain)
核心问题：发生了什么服务？效果如何？
工单主题域是售后业务的核心，记录每一次服务的完整过程。
工单主题域的数据模型设计
核心实体：fact_service_order（工单事实表）
CREATE TABLE fact_service_order (
-- 主键与外键
order_id VARCHAR(50) PRIMARY KEY, -- 工单号（退化维度）
order_date_key INT, -- 关联日期维度
user_key INT, -- 关联用户维度
vehicle_key INT, -- 关联车辆维度
center_key INT, -- 关联服务中心维度
advisor_key INT, -- 关联服务顾问维度
technician_key INT, -- 关联技师维度
service_type_key INT, -- 关联服务类型维度
-- 时间属性
appointment_datetime TIMESTAMP, -- 预约时间
arrival_datetime TIMESTAMP, -- 到店时间
start_service_datetime TIMESTAMP, -- 开始服务时间
complete_datetime TIMESTAMP, -- 完工时间
delivery_datetime TIMESTAMP, -- 交车时间
-- 业务标志
is_appointment BOOLEAN, -- 是否预约
is_warranty BOOLEAN, -- 是否质保
is_first_repair BOOLEAN, -- 是否首次维修
is_emergency BOOLEAN, -- 是否紧急服务
is_loaner_car BOOLEAN, -- 是否使用代步车
-- 财务指标（事实度量）
labor_amount DECIMAL(10,2), -- 工时费
parts_amount DECIMAL(10,2), -- 配件费
additional_service_amount DECIMAL(10,2), -- 增值服务费
discount_amount DECIMAL(10,2), -- 优惠金额
total_amount DECIMAL(10,2), -- 总金额
paid_amount DECIMAL(10,2), -- 实付金额
payment_method VARCHAR(50), -- 支付方式
-- 效率指标
waiting_duration INT, -- 等待时长(分钟)
service_duration INT, -- 服务时长(分钟)
total_duration INT, -- 总耗时(分钟)
standard_duration INT, -- 标准工时(分钟)
efficiency_ratio DECIMAL(3,2), -- 效率比(实际/标准)
-- 质量指标
satisfaction_score INT, -- 满意度评分(1-5)
satisfaction_comment TEXT, -- 满意度评价
is_first_time_fix BOOLEAN, -- 是否一次修好
rework_count INT, -- 返修次数
complaint_flag BOOLEAN, -- 是否投诉
-- 服务内容
service_items TEXT, -- 服务项目清单(JSON)
parts_used TEXT, -- 使用配件清单(JSON)
fault_description TEXT, -- 故障描述
solution_description TEXT, -- 解决方案描述
-- 里程信息
mileage_at_service INT, -- 服务时里程
days_since_last_service INT, -- 距上次服务天数
-- 工单状态
order_status VARCHAR(50), -- 已预约/进行中/已完成/已取消
cancel_reason VARCHAR(200),
-- 数据质量
data_source VARCHAR(50),
created_at TIMESTAMP,
updated_at TIMESTAMP
);
字段数：45个
真实案例：小鹏汽车的工单全流程数字化
小鹏汽车把工单细化为8个时间节点，精准追踪每个环节的效率。
完整时间链：
用户预约 → 确认预约 → 到店 → 接待 → 派工 → 开始维修 → 完工 → 质检 → 交车
T0 T1 T2 T3 T4 T5 T6 T7 T8
每个环节都有SLA（服务等级协议）：
- T2-T3（到店到接待）：≤5分钟
- T3-T4（接待到派工）：≤10分钟
- T4-T5（派工到开始）：≤15分钟
- T6-T7（完工到质检）：≤20分钟
- T7-T8（质检到交车）：≤10分钟
超时自动预警：
- 如果T2-T3超过5分钟，店长手机收到提醒
- 如果任何环节超时>30分钟，区域经理收到告警
效果：
- 平均交车时长从4.2小时降低到2.8小时
- 客户满意度从4.1分提升到4.7分
工单主题域的3个设计难点
难点1：一个工单多个服务项目如何存储？
**场景：**一个保养工单包含：更换机油、更换滤芯、四轮定位、轮胎充气。
方案A：JSON字段存储（推荐，简单场景）
service_items: [
{"item": "更换机油", "amount": 200},
{"item": "更换滤芯", "amount": 150},
{"item": "四轮定位", "amount": 300},
{"item": "轮胎充气", "amount": 0}
]
方案B：建立工单明细表（推荐，复杂分析）
CREATE TABLE fact_service_order_item (
order_id VARCHAR(50),
item_seq INT,
service_item_name VARCHAR(200),
service_item_category VARCHAR(100),
labor_amount DECIMAL(10,2),
parts_amount DECIMAL(10,2),
duration INT,
PRIMARY KEY (order_id, item_seq)
);
选择建议：
- 如果只需要展示，不需要按服务项目聚合分析：用方案A
- 如果需要分析「哪个服务项目最赚钱」：用方案B
小鹏汽车用的是方案B，因为他们需要精细化分析每个服务项目的盈利能力。
难点2：工单取消和返修如何处理？
场景1：用户预约后临时取消
order_status = '已取消'
cancel_reason = '行程冲突'
cancel_datetime = '2024-12-28 09:30:00'
保留取消工单的价值：
- 分析取消率：哪个时段/哪个门店取消率高？
- 分析取消原因分布
- 优化预约提醒策略
场景2：用户修完后又回来返修
方案：通过rework_count字段标记
-- 首次工单
order_id: 'ORD001'
rework_count: 0
is_first_time_fix: TRUE
-- 返修工单
order_id: 'ORD001-R1'
original_order_id: 'ORD001'
rework_count: 1
is_first_time_fix: FALSE
通过返修数据可以：
- 计算首次修复率（FTF Rate）
- 分析哪些故障容易返修
- 识别技师的技能短板
难点3：跨天工单如何计算时长？
**场景：**用户下午4点到店，但配件缺货，第二天上午10点才交车。
时间记录：
arrival_datetime: '2024-12-28 16:00:00'
delivery_datetime: '2024-12-29 10:00:00'
total_duration: 1080分钟 (18小时)
但实际服务时长可能只有2小时！
解决方案：分别记录在店时长和实际服务时长
total_duration: 1080 -- 总在店时长
service_duration: 120 -- 实际服务时长
waiting_duration: 960 -- 等待时长（配件到货）
这样分析时可以：
- 用service_duration计算技师效率
- 用waiting_duration识别瓶颈（配件供应慢）
- 用total_duration计算用户等待体验
💡 三大主题域的关联关系
核心关系图
用户主题域
(dim_user)
|
| 1:N
|
车辆主题域
(dim_vehicle)
|
| 1:N
|
工单主题域
(fact_service_order)
解读：
- 1个用户可以拥有多辆车（1:N）
- 1辆车可以产生多个工单（1:N）
- 所以：1个用户可以产生多个工单（通过车辆间接关联）
典型分析场景
场景1：分析高价值用户的服务特征
SELECT
u.membership_level,
COUNT(DISTINCT u.user_key) AS user_count,
AVG([f.total](http://f.total)_amount) AS avg_order_value,
COUNT(f.order_id) AS total_orders
FROM fact_service_order f
JOIN dim_user u ON f.user_key = u.user_key
WHERE [u.total](http://u.total)_spend > 50000 -- 累计消费>5万的高价值用户
GROUP BY u.membership_level;
场景2：分析不同车龄的维修频次
SELECT
CASE
WHEN v.vehicle_age_days < 365 THEN '1年内'
WHEN v.vehicle_age_days < 730 THEN '1-2年'
WHEN v.vehicle_age_days < 1095 THEN '2-3年'
ELSE '3年以上'
END AS vehicle_age_group,
COUNT(f.order_id) AS order_count,
AVG([f.total](http://f.total)_amount) AS avg_amount
FROM fact_service_order f
JOIN dim_vehicle v ON f.vehicle_key = v.vehicle_key
GROUP BY vehicle_age_group;
场景3：识别即将流失的高价值用户
SELECT
u.user_name,
[u.phone](http://u.phone),
[u.total](http://u.total)_spend,
u.days_since_last_service,
v.current_mileage,
v.days_since_last_service AS vehicle_days_since_service
FROM dim_user u
JOIN dim_vehicle v ON u.user_id = v.owner_user_id
WHERE [u.total](http://u.total)_spend > 30000 -- 高价值
AND u.days_since_last_service > 180 -- 6个月未来
AND v.current_mileage > 15000 -- 里程数较高
AND u.churn_probability > 0.6 -- 流失风险高
ORDER BY [u.total](http://u.total)_spend DESC
LIMIT 100;
这个SQL可以直接驱动用户召回campaign！
✅ 本节关键要点
- 主题域是数据的「图书分类法」，让数据井然有序
- 用户主题域：构建360°用户画像，记录"是谁、在哪、怎样"
- 车辆主题域：追踪车辆全生命周期，从购买到报废
- 工单主题域：记录每次服务的完整过程和结果
- 宽表设计：维度表要宽不要窄，宁可冗余不要关联
- SCD Type 2：用于追踪历史变化，确保分析准确性
- 三大域紧密关联：用户→车辆→工单，形成完整的业务链路
**下一节预告：**我们将学习配件主题域和人员主题域，并通过完整案例串联五大主题域。