棱镜 PRISM × 餐饮数据治理
DATA
数据治理规范
及框架流程
从一张杂乱的 Excel，到一份敢下决策的洞察
李小单
棱镜 PRISM 创始人 · 13年企业增长经营专家
2026 · 餐饮经营数据治理规范
先问一个问题
从 POS 后台导出的那张表——
真的能用吗？
会员被重复计算、菜品掺了锅底饮料、订单没去重、口径每个月都在打架……
数据 ≠ 可用数据

不是不关心，是原始数据里全是陷阱——不洗，就不敢用。

PART 01 · 数据从哪来
01
原始数据
导出
只要做一件事——把 Excel 给我
① 给什么数据
② 给多久的数据
③ 从哪里导
只需要做这些
不用上系统，不用买软件，不用对接技术——导 Excel 就行
① 给什么
五类原始数据
·
会员数据
·
菜品数据
·
订单明细
·
品项销售明细
·
营业数据
·
等不限于以上
② 给多久
三个周期可选
1年
看清完整画像
半年
看清近期趋势
3个月
精准锁定当下
③ 从哪导
现有后台即可
·
POS 后台（如哗啦啦）
·
美团管家后台
·
会员系统后台
·
扫码点单后台
不用清洗、不用排版
原始导出，原样给我

30 分钟导完——剩下交给我。

分析周期 · 5–7 个工作日
交付形态举例——找到黄金客群
交付目标举例
黄金客群
用 5 个维度综合分析，从会员池里精准捞出
撑起营收的那群人
消费范围周期决定结论
给的是开卡以来 → 开卡以来黄金客群
给的是近 3 月 → 近 3 月黄金客群
5 个分析维度（RFM 升级版）
① R
最近消费
Recency
多久没来了
② F
消费频次
Frequency
来了多少次
③ M
消费金额
Monetary
花了多少钱
④ 开卡日期
注册时间
Register
吃龄多长
⑤ 客单价
单次水平
Avg Ticket
每次花多少
为什么是这 5 个
RFM 解决「谁是活跃的、谁来得多、谁花得多」；叠加开卡日期看「吃龄、是不是新贵」，叠加客单价校准「单次购买力」——五维交叉，才不会把"去年常来现在没来"和"上个月刚来"的人混成一团。

5–7 天后，会拿到一份带名字、带画像、带行动建议的客群报告。

PART 02 · 价值论证
02
为什么
必须治理
不洗数据，每个决策都在踩雷
① 数据是负债 还是资产
② 我们的方法论壁垒
③ 交付物全景
治理前 vs 治理后
同一份数据——洗之前是负债，洗之后是资产
治理前 · 数据是负债
×
会员数虚高 30%（一个人算三个）
×
客单价算错 4 倍（分母没去重）
×
复购率三个人算出三个数
×
968 道菜里 2/3 是锅底饮料打包费
×
不同报告数字打架，不知道信哪个
×
VIP 门槛拍脑袋，68% 都是"高价值"
结果——不敢基于数据做决策
治理后 · 数据是资产
✓
真实会员数（一人一档，不重复计算）
✓
客单价精准（去重订单数做分母）
✓
复购率口径统一，全公司一个数
✓
真菜品库干净（324 道可分析）
✓
基线锁定，所有引用指向同一份真相
✓
科学分层，14% 锁定真高价值客群
结果——敢拍板、敢行动、敢算 ROI

不可能基于一个看不清的东西做决策——治理就是把"看不清"变成"看得清"。

我们的方法论 · 三条线交叉验证
数据洗得再干净，也只回答了"是什么"——"为什么"要靠三条线交叉
第一条线
到店观察
水下信息
去店里吃饭、观察、和店长聊。
POS 看不到的东西：会员为什么来、扫码点单为什么有效、谁是真买单的人。
第二条线
AI 智能分析
数据清洗 + 模型
从 968 道菜筛出 324 道、算出每个会员的 R/F/M、识别出 448 道菜里 83.5% 是亏的。
但 AI 算不出"为什么"。
第三条线
POS 事实数据
原始记录
谁、何时、哪家店、吃了什么、花了多少。
事实不等于真相——POS 说"3 个月没来"，不说"为什么不来"。
三条线交叉，才是结论
没有到店观察 → 不知道会员的意义是"请客买单"
没有 AI 分析 → 从 14,852 人里找不到那 206 个黄金客群
没有 POS 数据 → 结论没有事实支撑
三条线缺一条，结论就不可信。

这就是为什么——我们出的每一个结论，都不是只看数据写出来的。

PART 03 · 框架流程
03
数据治理
框架流程
把脏数据，洗成敢下决策的金矿
① 三层清洗 + 对数 + 二次洞察
② 每一步都有「表格形态变化」可看
③ 结论必须客观，不够客观不下
从给我 Excel，到交付基础结论
7 个节点 · 5–7 个工作日
A · 清洗主线（机器跑）
STEP 0
原始 Excel
杂乱无序
→
第一层
基础规范
剔脏·标准化
→
第二层
业务口径
一人一档·去重
→
第三层
基线报告
RFM 5 维分层
B · 对数 + 二次洞察（人机协同）
线下沟通
腾讯会议对数
第一轮·核对口径
→
第四轮
修正清洗
规则固化
→
结论
基础结论
客观·可引用
→
下钻
第二层洞察
画像·策略·行动
前 3 层清洗
机器
对数 + 洞察
人机协同
全程周期
5–7工作日
0
STEP 0 · 起点
交给我的，长这样
一张 Excel，什么都有，什么都看不清——这是 90% 餐饮店的现状。
原始数据快照
订单号
手机号
金额
菜品
渠道
日期
10023
null
0
宫保鸡丁
堂食
05-12
10024
138****0925
-50
牛肉
美团
05-12
####
139****1188
258
锅底
堂食
05-12
10025
'null'
190
羊肉
堂食
05-13
10025
'null'
312
可乐
堂食
05-13
10026
137****6677
0.01
测试菜A
测试
05-13
10027
(空)
88
打包盒
美团
05-13
这张表里藏着的陷阱
×
同订单重复行（一桌多单未合并）
×
退款单混入（金额负数）
×
锅底/饮料/打包盒当菜品
×
测试单 0.01 元
×
"没有"的三种写法：NULL / '' / 'null'
×
手机号缺失、日期格式不一
不洗直接用——复购率虚高、客单价腰斩、客群分层失真，每个决策都在踩雷。

这就是为什么——清洗必须分多层走，一刀切解决不了。

1
STEP 1 · 第一层清洗
基础规范 · 把"不是东西的"剔出去
这一层做的事
01
剔除非经营门店：不归自己管的、试营业的、关停的，先剥离
02
剔除非菜品项：锅底、自助小料、饮料、餐盒费、配送费——不是"顾客点的菜"
03
剔除无效订单：测试单、0 元单、0.01 元单、已退款废单
04
剔除历史僵尸菜：去年卖过今年早停的，从可分析菜品库摘掉
05
字段类型标准化：日期、金额、数量的格式统一
表格形态变化
清洗前 · 7 行混着 5 类问题
订单
金额
菜品
渠道
10023
0
宫保鸡丁
堂食
10024
-50
牛肉
美团
####
258
锅底
堂食
10026
0.01
测试菜A
测试
10027
88
打包盒
美团
↓
清洗后 · 只剩"真正的菜 + 真正的单"
订单
金额
菜品
渠道
10023
0
宫保鸡丁
堂食
10025
190
羊肉
堂食
10025
312
宫保鸡丁
堂食
客观结论
菜品 968 → 324 道；订单 1.2 万 → 3,000 单有效。（数据为示例）

第一层完——杂音没了，但同一个人还是被算成三个。

2
STEP 2 · 第二层清洗
业务口径 · 让"三个人"变回"一个人"
这一层做的事
01
顾客身份合并：同一个人在不同渠道留下的身份，合并成一个人
02
订单去重：拼单一桌点 8 道菜只算 1 单——分母必须去重
03
缺失值全态判别：空值、空串、占位符——"没有"的各种写法一个不漏
04
复购口径锁定：跨天复购 vs 非跨天复购——必须明示
05
客单价分母修正：总收入 ÷ 去重订单数（不是 ÷ 行数）
表格形态变化
清洗前 · 一个人 = 三个身份
会员ID
识别键
金额
次数
M001
会员卡
2,000
5
M052
138****0925
1,800
4
M103
微信 wx_88
2,200
6
↓ 身份合并
清洗后 · 三个身份 = 一个人
顾客识别键
合并来源
累计金额
次数
C_10086
M001+M052+M103
6,000
15
客观结论
真实会员 13,597 → 14,852；客单价 ¥83 → ¥333（差 4 倍）。（数据为示例）

第二层完——人认对了，数才算对了。

3
STEP 3 · 第三层清洗
基线报告 · 每个人打上"五维标签"
这一层做的事
01
RFM 三维打分：每个会员算 R / F / M 分值
02
叠加开卡日期：算吃龄，区分"新贵"与"老客"
03
叠加客单价：单次购买力校准
04
阈值对标客户体系：分层门槛对标客户既有会员体系——不拍脑袋
05
客群标签生成：核心常客 / 沉睡大客 / 新贵大客 等
基线报告样式（五维齐全的底表）
识别键
R 最近
F 次
M 额
开卡
客单
客群标签
C_10086
3 天前
15
¥6,000
2.3 年
¥400
核心常客
C_10231
92 天前
12
¥4,800
3.1 年
¥400
沉睡大客
C_10458
7 天前
2
¥2,100
0.2 年
¥1,050
新贵大客
C_10512
18 天前
6
¥780
1.5 年
¥130
一般价值
C_10600
—
0
¥0
0.1 年
—
零消费
这就是后续所有分析的
唯一权威底表——每行一个真实会员，五维 + 标签齐全。以后所有报告都从这张表取数，不再各算各的。

第三层完——干净、归一、五维齐全的基线出来了，但还不能直接用。

4
STEP 4 · 线下沟通第一轮
腾讯会议对数 · 把基线核对清楚
数据洗得再干净，不对一遍就不敢交付——水下信息只有老板知道。
对数 · 对什么
①
门店范围对不对——这家店是否属于经营范围？
②
会员数对不对——有没有内部员工该剔除？
③
阈值对不对——会员等级门槛跟既有体系一致吗？
④
异常值对不对——单笔 ¥5 万是真大客还是团购核销？
对数结果 → 触发第四轮清洗
反馈
口径修正
→
第四轮
规则固化
→
永久
基线锁定
规则固化意味着
"路劲店不属于经营范围"——写进规范，以后每次分析自动排除，不用每次人工确认。
为什么必须有这一步？ AI 算不出"这家店是否属于经营范围"——这种水下信息，只有老板知道。对数，就是把水下信息注入数据。

第四轮完——基线锁定，数字不再打架，所有引用指向同一份真相。

5
STEP 5 · 输出
基础结论 → 下钻第二层洞察
基础结论（客观·可引用）
黄金客群（撑 50% 营收）
206人
真实活跃会员
10,430人·70.2%
可精准召回流失客
409人
真实菜品库
324道
※ 数据为示例（5 店合并口径）
↓
第二层洞察（下钻·可行动）
下钻 ①
黄金客群画像
吃龄·频次·客单价·偏好菜
下钻 ②
沉睡大客名单
谁该召回·优先级排序
下钻 ③
菜品偏好交叉
这群人爱点什么·该推什么
下钻 ④
行动建议
短信·券·套餐·场景话术
结论不够客观，就不下
能引用的才写进报告，推断类一律标"初步判断·待核实"。

到这里——一张 Excel，变成了一份敢拍板、敢行动的报告。

交付物全景 · 不只是黄金客群
数据治理一次完成——后续所有分析都从同一张基线底表长出来
01
客群分析系列
黄金客群 · 流失客池 · 沉睡大客 · 新贵大客 · 零消费会员
02
菜品诊断系列
真菜品库 · 味型结构 · 亏损菜识别 · 菜单优化 · 套餐设计
03
经营诊断系列
复购率 · 客单价 · 翻台 · 折扣率 · 同店对比 · 月损根源
04
营销行动系列
流失召回 · 沉睡唤醒 · 新客锁客 · 生日营销 · 午市拉升
05
门店对比系列
多店横评 · 历史纵评 · 行业对标 · 标杆识别 · 经验复制
06
数据资产系列
五维底表 · 客群标签库 · 口径词典 · 规则库 · 月度看板

一次治理，六条产品线持续产出——基线越用越值钱。

PART 04 · 实战验证
04
治理之后
赚到了什么
用真实数据说话——治理不是成本，是投资
① 短信召回 ROI
② 扫码点单验证
③ 年化收益
实战数据 · 治理后的增长
某连锁餐饮（5 店·火锅烤肉）3 个月治理成果——数据为示例，5 店合并口径
短信召回（端午大规模）
96–192倍
ROI
触达 11,990 人 · 8 天回店 393 人 · 增量 ¥114,879
精准召回（流失池）
164倍
ROI
409 人 · 29 人回流（7.09%）· 增量 ¥6,694
扫码点单（单店验证）
+9.3%
会员数正增长
4 店唯一正增长 · 订单 +16.3% · 活跃率 96.6%
精准召回 vs 宽口径召回
召回率是宽口径的 2.2 倍
为什么？治理后——知道该给谁发短信。
年化收益（保守估算）
¥200 万/年
扫码点单推广 ¥237 万 + 短信召回 ¥146 万

3 个月治理，撬动年化 200 万+ 增长空间——治理前的数据是负债，治理后的数据是资产。

PART 05 · 后续服务
05
后续服务
流程
基线只是起点——把数据治理变成月月见效的增长引擎
① 月度迭代
② 策略落地
③ 效果追踪 · 复盘
后续服务流程图
每个月绕着这个圈走一圈——数据治理不是一次性项目，是经营习惯
M1
数据更新导出
给最新一个月数据
→
M2
基线自动复用
规则已固化·自动清洗
→
M3
增量对比
本月 vs 上月·谁在掉
→
M4
策略匹配
召回·锁客·推菜
M5
策略落地执行
短信·券·套餐·话术
→
M6
效果数据回传
回来多少人·赚多少
→
M7
复盘 + 老板月报
ROI·优化点·下月动作
→
M8
规则再迭代
阈值调整·基线升级
第一个月
建基线 · 找黄金客群
第二个月起
每月一圈 · 持续赚钱
长期
数据资产越滚越值钱

数据治理的价值——不是出一份报告，是让每个月都敢基于数据做决策。

一句话总结
不可能基于一个看不清的东西做决策。
数据治理就是把"看不清"变成"看得清"——
不是为了做报表好看，是为了敢于基于数据做决策。

数据治理前的数据是负债——治理后的数据是资产。

PRISM.
棱 镜
数据治理规范 · 框架流程
李小单 · 棱镜 PRISM 创始人