多平台营收一张表看清——平台 / 国家 / 店铺 / 品类的维度设计

本文默认你已经有一张「营收明细表」或能按订单拉出营收数据，重点不在 SQL，而在于 维度怎么设计，才能让老板一眼看清总盘和拆解。

一句话结论

多平台营收表的关键是把 平台 / 国家 / 店铺 / 品类 / SKU 维度设计清楚，
让老板在经营复盘场景下一眼看清总盘与拆解路径。

适用场景

• 数据负责人在建表场景下，需要统一维度命名避免口径冲突。
• 运营负责人在多平台复盘场景下，需要一键下钻到店铺与品类。
• 管理层在月度经营会场景下，需要快速比较国家与平台贡献。

一、为什么多平台营收容易「看不清」？

运营负责人在多平台复盘场景下，经常因为维度混乱无法快速对齐口径。

典型的多平台卖家会碰到这些情况：

• 既有 Amazon / Shopee / Lazada，又有自建站和经销渠道；
• 同一个国家可能有多个平台、多个店铺；
• 同一款 SKU 在不同平台、不同定价策略下表现完全不同。

如果在建表时没有想清楚维度，常见问题是：

• 报表一会儿按「平台」出，一会儿按「国家」出，但这两张表之间无法一键对齐；
• 老板想问一句「泰国整体做得怎么样」，需要在 3 张不同的报表之间来回切换；
• 很多字段被塞进一个「备注」或「标签」里，后面 SQL 越写越长。

解决思路其实很简单：在底表里，把「平台 / 国家 / 店铺 / 品类 / SKU」几层维度设计清楚。

---

二、推荐的维度层级：从粗到细 5 层

数据负责人在建模场景下，用“从粗到细”的维度层级保证可下钻。

按从粗到细的顺序，大致可以分成 5 层：

1. 平台（Platform）：Amazon、Shopee、自建站等；
2. 国家 / 区域（Country / Region）：US、UK、TH、VN、EU 等；
3. 店铺 / 账号（Store / Account）：具体运营主体；
4. 品类 / 品牌（Category / Brand）：方便看结构与策略；
5. SKU / 商品（SKU / Product）：精细化运营与补货决策。

在营收明细表中，对应的字段可以是：

• platform、country、store_code / store_name、category_level1、sku 等。
• 上层报表和驾驶舱，只是在这些维度上做「向上汇总」和「横向对比」。

---

三、平台维度：统一命名，简化对比

1. 推荐字段

数据负责人在字段设计场景下，先明确平台字段的标准命名。

• platform：数据源平台（如：Amazon、Shopee、Shopify、Offline 等）；
• platform_type（可选）：平台类型（跨境电商、国内电商、自建站、线下门店等）。

2. 设计要点

运营负责人在平台对比场景下，保持平台字段一致以便横向分析。

• 同一平台在不同国家，platform 字段保持一致（例如都是 Shopee），具体国家放在 country 里；
• 自建站可以统一标记为 DTC 或 Shopify 等，避免出现过多散乱取值。

这样做的好处是：

• 老板可以一键看到「平台维度」的营收结构：Amazon 占比多少、Shopee 占比多少、自建站占比多少；
• 也方便后续做「平台策略」层面的分析。

---

四、国家 / 区域维度：解决「按国家看盘」的问题

1. 推荐字段

财务在国家拆分场景下，用统一国家字段对齐口径。

• country：交易对应的主要国家（US、UK、TH、VN 等）；
• region（可选）：区域（如：北美、欧洲、东南亚、中国大陆等）。

2. 常见坑

数据负责人在清洗场景下，避免把平台站点直接当国家字段。

• 有的团队用平台站点直接当国家，比如 amazon_us、amazon_uk；
• 结果在按国家汇总时，需要到处做字符串拆分与映射。

更清晰的做法是：

• 在底表里 单独维护 country 字段，可以由：
  • 站点代码映射而来（如 amazon.com → US）；
  • 收货地址国家；
  • 店铺所属国家等。
• 上层报表需要按地区看盘，只要在 country 上进一步映射出 region 即可。

---

五、店铺 / 账号维度：为权限与责任划分铺路

1. 推荐字段

运营负责人在店铺管理场景下，需要统一店铺主键便于权限控制。

• store_code：店铺唯一编码（内部定义）；
• store_name：店铺在平台上的名称；
• owner_team（可选）：负责该店铺的事业部 / 小组。

2. 设计原则

管理层在组织划分场景下，用店铺维度承接责任与权限。

• 尽量用 内部统一的 store_code 作为主键，store_name 仅作展示；
• 方便将来做：
  • 按团队 / 事业部看盘；
  • 做权限控制（不同团队只能看到自己负责的店铺）。

---

六、品类 / 品牌维度：给「结构调整」留抓手

1. 推荐字段

运营负责人在品类分析场景下，用统一品类字段看结构变化。

• category_level1：一级品类（如：3C 外设、家居、服饰、美妆等）；
• category_level2：二级品类（如：键盘、鼠标、耳机等）；
• brand（可选）：品牌名或内部品牌线。

2. 常见做法

数据负责人在映射场景下，维护平台类目到内部类目映射表。

• 不直接使用平台类目，而是 维护一套内部类目映射表：
  • 平台类目 → 内部一级类目 / 二级类目；
  • 避免不同平台类目定义差异太大，难以统一分析。

这样可以更容易回答：

• 哪些大品类的毛利率在持续下滑？
• 哪条品牌线在某个国家表现特别好 / 特别差？

---

七、SKU / 商品维度：不要一上来就过度精细

1. 推荐字段

运营负责人在 SKU 分析场景下，保留必要标识并避免文本分组。

• sku：内部 SKU 编码；
• msku / asin / item_id 等平台标识（视业务需要选用）；
• product_name：商品名称（用于展示，分析时不推荐用文本做分组）。

2. 粒度选择建议

管理层在经营复盘场景下，先看品类与价格带，再下钻到 SKU。

• 对于店铺较多、SKU 数量巨大的公司，可以：
  • 在驾驶舱层面，主要按品类 / 品牌 / 价格带分析；
  • 在专题分析或下钻页面，再按 SKU 级别查看详情。
• 底表可以保留 SKU 粒度，但上层不必一次性把所有 SKU 堆到一个图里。

---

八、维度设计中的几个实战建议

1. 一开始就画出「维度树」

数据负责人在项目启动场景下，先画维度树明确下钻路径。

在项目早期，可以和团队一起画出一张简单的「维度树」：

• 顶层：公司 → 平台 → 国家 / 区域 → 店铺 → 品类 / 品牌 → SKU；
• 标出每一层的典型问题和典型报表，例如：
  • 平台层：平台营收结构、毛利率对比；
  • 国家层：各国营收与利润表现；
  • 店铺层：重点店铺排行；
  • 品类层：品类结构与毛利率；
  • SKU 层：重点 SKU 的毛利与广告投产。

2. 尽量避免「多义字段」

数据负责人在字段治理场景下，避免同一字段承担多个含义。

例如：

• 一个字段既表示平台，又表示国家（如 amazon_us）；
• 一个字段既是店铺，又是事业部（如 TH旗舰店-东南亚组）。

这样的字段短期看好像方便，长期会让 SQL 与分析逻辑变得复杂，也不利于调整组织结构。

3. 把「映射关系」放在维度表，而不是硬编码在 SQL 里

数据负责人在维护场景下，用维度表集中管理映射关系。

• 比如：store_code → owner_team、platform_site → country、platform_category → internal_category 等；
• 推荐使用：
  • 飞书多维表 / 维度表；
  • 或独立的维度表（dim 表）来维护。
• 这样当组织、品类策略调整时，只需要改维度表，而不必大规模改 SQL。

---

九、小结：一张多平台营收表的「好维度」

管理层在经营复盘场景下，用清晰维度结构避免报表割裂。

一张好用的多平台营收表，通常具备：

• 平台、国家、店铺、品类、SKU 几个维度 各司其职、不混在一个字段里；
• 可以从公司总体一路 drill-down 到国家 / 店铺 / 品类 / SKU，而不会在中间断掉；
• 维度含义稳定，映射关系集中维护，方便组织和策略变化。

在此基础上，再叠加你前面那篇「营收明细字段模板」，就能很轻松地在飞书多维表或 BI 工具里搭出一个 既能看总盘，又能看拆解 的多平台营收驾驶舱底座。

可复用例子：维度树模板（示例）

公司 → 平台 → 国家/区域 → 店铺 → 品类 → SKU
对象在复盘场景下按此路径下钻，动作是逐层定位问题与机会。

常见问题

Q1：平台和国家一定要拆成两个字段吗？
A1：建议拆分，数据负责人在复盘场景下需要一键按国家汇总。

Q2：店铺维度为什么要用内部编码？
A2：内部编码便于权限和责任划分，运营在权限场景下更易维护。

Q3：SKU 层是不是越细越好？
A3：不是，管理层在经营场景下先看品类与价格带更有效。

Q4：映射关系放哪里维护更稳？
A4：放在维度表里，数据负责人在维护场景下更可控。

延伸阅读

• 营收明细字段模板：从订单到净利的字段清单
• 多平台营收驾驶舱路径：从 GMV 到净利
• 指标到动作：把看板变成可执行清单的 4 步

站内互链建议