以下是基于京东开放平台JD商品SKU信息API返回值的应用指南，聚焦品牌、型号、尺寸、颜色等规格数据如何系统性地驱动精准营销。核心逻辑是：**先理清返回值的规格字段结构，再解决规格值标准化问题，最后将结构化的规格数据映射到用户画像、推荐、定价与投放四个营销环节。**
---
## 一、返回值中的规格字段结构：品牌、型号、尺寸、颜色在哪里
京东SKU信息API的返回值采用多层嵌套JSON，与品牌、型号、尺寸、颜色直接相关的字段分布在三个层级。
### 第一层：商品主体层——品牌与型号的锚点
在商品主体（`product` 或 `goodsInfo`）层级，品牌以对象形式返回：
```
"brand": { "brandId": "...", "brandName": "华为(HUAWEI)", "brandLogo": "..." }
```
`brandId` 与 `brandName` 是品牌维度营销的**主键**，品牌编号用于跨店铺、跨类目的品牌聚合，品牌名称用于语义分析和人群标签命名。型号通常不作为一个独立的结构化字段存在，而是嵌在 `title`（完整标题）中，例如“华为Mate 60 Pro 5G手机 12GB+512GB 雅丹黑”。这意味着**型号信息需要从标题中进行二次抽取**，或依赖 `paramList` / `specification` 中的参数属性来补全。
### 第二层：规格定义层——尺寸、颜色的“可选值集合”
在 `specification.specs` 数组中，返回的是**该SPU下所有规格维度的可选值集合**，而不是某一个SKU的具体规格值：
```
"specification": {
"specs": [
{ "specName": "颜色", "specValues": ["白色", "黑色", "蓝色"] },
{ "specName": "尺码", "specValues": ["S", "M", "L", "XL"] }
]
}
```
这一层级回答的是“这个商品有哪些颜色可选、有哪些尺码可选” ，适合用于**选品分析、品类规格趋势判断**（例如某类目下“燕麦色”出现的频率是否在上升）。
### 第三层：SKU实例层——每一个具体变体的规格组合
在 `skus` 数组中，每一个SKU通过 `specInfo` 携带该变体的**具体规格键值对**：
```
"skus": [
{
"skuId": "12345678",
"skuName": "京东京造无线蓝牙耳机 白色 标准版",
"price": 199.00,
"stock": 1000,
"specInfo": { "颜色": "白色", "版本": "标准版" }
}
]
```
`specInfo` 是精准营销中最关键的字段——它将**每一个SKU与一组确定的规格值绑定**，使得“颜色=白色、尺码=M”这样的组合可以被直接用于匹配用户偏好。一个SPU下通常有多个SKU，规格组合（如“颜色×尺码×版本”）的数量决定了营销颗粒度的上限。
**小结**：品牌在主体层可直接取用；型号需从标题或参数属性中抽取；尺寸和颜色在规格定义层是“可选值集合”，在SKU实例层才是“具体组合值”。营销应用必须以 `specInfo` 中的实例组合为操作对象，而非仅停留在可选值集合层面。
## 二、规格值标准化：精准营销的先决条件
原始返回值中的规格值**不能直接用于人群匹配和跨商品聚合**，原因是京东SKU接口存在“规格值编码映射”问题：同一个“红色”在不同商品中可能对应不同的内部编码（如 `1627207:3232483` 对应“颜色：红色”），且不同商家对同一规格的中文表述也不统一（“黑色”/“曜石黑”/“碳晶黑”）。如果不做标准化，基于规格的画像和推荐会大量失效。
### 标准化需要完成三件事
**① 规格名归一**。将 `specName` 映射到统一的维度字典：颜色、尺码、版本、容量、材质、功率等。京东将规格属性标准化分组为颜色分类、存储版本、屏幕尺寸、套餐类型等常见维度，可以直接作为映射的参考框架。
**② 规格值归一**。对同一维度下的表述做同义词合并。例如颜色维度下，将“曜石黑”“碳晶黑”“-19黑”归并为“黑色”；尺码维度下将“42”“42码”“EUR42”统一为数值型尺码。这一步的产出是一个**规格值字典**，后续所有营销逻辑基于归一后的值运行。
**③ 编码—语义映射缓存**。API返回的 `spec_code_map`（如 `{"颜色":"3232483","尺寸":"12345"}`）需要与归一后的语义值建立映射关系并缓存，避免每次解析时重复推断。
标准化完成后的结构化模型，应当至少包含：
| 字段 | 来源 | 营销用途 |
|---|---|---|
| `sku_id` | 直接返回 | 最小营销单元 |
| `brand_id` / `brand_name` | 主体层 | 品牌人群聚合 |
| `model`（抽取） | 标题/参数 | 型号级选品与竞品对标 |
| `color_norm` | `specInfo` 归一 | 颜色偏好画像、推荐 |
| `size_norm` | `specInfo` 归一 | 尺码偏好画像、推荐 |
| `spec_combo_key` | `specInfo` 组合 | SKU级定向与货品匹配 |
| `price` / `stock` | SKU层 | 动态定价与库存驱动的营销 |
## 三、从规格数据到精准营销：四个可落地的应用方向
### 方向一：颜色与尺码驱动的用户偏好画像
单个用户的颜色偏好，可以从其历史购买和加购行为的SKU规格中聚合得到。例如，一个用户近半年的鞋服类购买记录中，`color_norm` 高频出现在“黑色”和“深灰”，`size_norm` 稳定在42—43区间，就可以在画像中打上 “深色系偏好 + 42/43码” 的规格标签。
京东生态内的京准通DMP已经提供了“商品属性偏好”标签，明确支持区分对**产品尺寸、颜色**等属性有特殊偏好的用户并进行定向投放。SKU API的返回值可以作为商家自有数据侧构建同类标签的**底层原料**：用 `specInfo` 中的颜色和尺码值，结合用户与SKU的交互记录（浏览、加购、购买、收藏），生成“颜色偏好强度”和“尺码偏好稳定性”两个可计算的指标，再与DMP标签体系对接或用于站外投放的种子人群扩展。
### 方向二：SKU级个性化推荐——从“推荐商品”细化到“推荐规格”
传统推荐停留在SPU层级（“你可能喜欢这款鞋”），但规格数据支持**在SKU层级做推荐**：直接向用户展示其偏好颜色和尺码的变体，减少用户进入详情页后再做规格筛选的摩擦。
实现路径是：以用户的 `color_norm` 和 `size_norm` 历史偏好为约束，在候选商品的 `skus` 数组中筛选 `specInfo` 与偏好匹配且库存可售的SKU，优先推荐该SKU。对于颜色偏好强但尺码不确定的用户（例如新客首次购买鞋服），可以推荐同款中**偏好颜色+中间尺码**的SKU，并在落地页突出尺码助手或退换货保障，降低决策门槛。这一做法的效果在跨品类实践中已有印证：基于颜色和尺码偏好进行推荐过滤，可以直接提升点击后转化。
### 方向三：规格级动态定价与促销触发
`skus` 数组中每一个SKU都携带独立的 `price` 和 `stock`，这意味着定价和促销可以下沉到**规格组合层级**，而非只能在SPU层级做统一动作。
几个可操作的策略模式：
- **颜色维度的差异化定价**：当某一颜色SKU的库存深度显著高于同款其他颜色时，对该 `color_norm` 的SKU设置更积极的促销价或优惠券，加速特定规格的出清，而不必拉低整个SPU的价格带。
- **尺码维度的库存驱动营销**：断码风险高（某一尺码库存极低）时，可以暂停对该尺码的付费引流，或将流量导向同款中库存充足的其他尺码SKU；反之，滞销尺码可以通过“尺码专属券”定向刺激。
- **规格组合的清仓触发**：当某个 `spec_combo_key`（如“颜色=旧款色 + 版本=标准版”）的SKU同时满足“库存高 + 近期销量低”时，自动触发该SKU进入清仓计划或捆绑销售组合，而不是等待整个SPU滞销后再处理。
InfoQ的应用指南也将“根据不同商品规格的销售情况、库存状态制定针对性营销活动”明确列为SKU返回值在精准营销中的核心用法之一。
### 方向四：品牌与型号层面的竞品对标与人群卡位
`brandId` / `brandName` 和从标题中抽取的 `model` 共同构成了**竞品对标的结构化基础**。对于品牌商家而言，可以系统性地拉取竞品同型号或同价格带的SKU返回值，比较双方在颜色覆盖、尺码跨度、规格组合丰富度上的差异，识别竞品未覆盖的规格空白（例如竞品某型号只有基础色，缺少限定色；或尺码集中在中间段而缺少大码/小码），将这些空白规格作为新品开发或定向投放的切入点。
在人群卡位层面，品牌维度可以结合 `brandId` 构建“本品购买人群—竞品浏览人群—规格偏好人群”的交叉标签。例如，对浏览过竞品某型号但未购买的用户，如果其历史规格偏好指向本品有而竞品缺失的颜色或尺码，就可以将该用户作为高潜人群进行定向触达——触达素材中直接突出“本品独有配色/尺码”的规格差异，而不是泛化的品牌广告。
## 四、实施路线图与关键注意事项
**实施顺序建议**：先完成规格值标准化（维度字典 + 同义词映射），这是所有下游应用的基础；再构建SKU级的偏好聚合管道，生成用户—规格标签；随后在推荐、定价、投放三个场景中并行试点，优先选择规格维度丰富、SKU数量较多的类目（如鞋服、家电的颜色/容量/版本维度）作为起步场景。
**三个需要提前规避的坑**：
1. **不要将 `specification.specs` 的可选值直接当作SKU规格使用**。可选值集合只回答“有哪些选项”，实际可售的规格组合以 `skus[].specInfo` 为准，二者不一致时以SKU实例层为准。
2. **型号字段的缺失需要显式处理**。API没有独立的 `model` 结构化字段，从标题抽取型号时应建立类目特定的抽取规则（如电子产品关注“型号+存储+颜色”的组合模式），并对抽取失败的情况保留 `paramList` 作为兜底来源。
3. **规格编码映射必须缓存且可审计**。同一语义值在不同商品、不同时间的编码可能发生变化，映射缓存需要记录来源SKU和更新时间，避免因编码漂移导致人群标签静默失效。
