4、数据基础与数据采集：需要收集哪些数据，数据来源与采集方法

餐饮需求预测模型的精度，首先取决于数据基础的质量与完整性。许多企业在建模初期急于选择算法，却忽视了“数据地基”的搭建，导致模型上线后预测偏差大、业务部门不信任。本章将系统梳理需求预测所需的数据维度、来源渠道与采集方法，帮助学员建立一套可落地、可复用的数据采集框架。

4.1 核心数据维度：从“卖了多少”到“为什么卖”

需求预测不是简单地把历史销量做时间序列外推，而是要理解销量背后的驱动因子。我们将数据分为四大维度：销售结果数据、客流与运营数据、外部环境数据、特殊事件数据。其中销售结果是“因变量”，其余三类是“自变量”或“解释变量”。

4.2 数据来源与采集方法：五类渠道的实操要点

不同数据来源的采集方式、实时性、稳定性差异很大。我们将来源分为五类：POS/ERP系统、外卖平台、客流系统、公开API、内部运营记录。

4.2.1 POS/ERP系统（核心内部数据）

POS系统是销售数据的“母体”。采集时需注意：

• 字段完整性：确保包含下单时间、出品时间、结账时间，而非只有日期。
• 菜品维度：避免只存“菜品名称”，应同时保存“菜品ID”“分类ID”“规格ID”，防止改名或合并导致历史断裂。
• 折扣与赠菜：单独标记“实收金额”与“原价金额”，否则促销期间销量会被低估。
• 退菜与取消：记录退菜原因（口味/超时/错误），用于修正净销量。

4.2.2 外卖平台数据（美团、饿了么、抖音）

外卖数据通常通过平台商家后台导出或开放API获取。建议每日定时拉取前一日数据，包括：

• 订单量、实收金额、平台补贴、用户实付
• 菜品销量（按平台SKU）
• 配送时长、超时订单数
• 店铺评分、评价数（作为质量信号）

4.2.3 客流与等位数据

客流数据来源包括：

• 排队叫号系统：取号数、等位时长、弃号率
• 摄像头AI识别：进店/离店人数（需注意隐私合规）
• WiFi探针：设备MAC计数（精度较低，仅作参考）
• 收银系统：通过订单数 × 平均桌均人数估算

客流数据是“产能约束”的关键输入。例如，当门店满座时，销量上限受桌位数和翻台率限制，模型需要识别这种“天花板效应”。

4.2.4 天气与外部环境API

推荐使用以下公开数据源：

• 和风天气/彩云天气：提供逐小时温度、降水、风力
• 高德/百度地图API：获取商圈热力、交通拥堵指数
• 国家法定节假日接口：每年国务院发布后更新

采集频率建议：天气数据每日至少拉取一次，若做小时级预测则每小时拉取。历史天气数据可一次性补采近2年。

4.2.5 内部运营记录（促销、活动、异常事件）

这部分数据往往被忽视，但对模型解释性至关重要。建议建立运营日历表，记录：

• 促销活动：类型（满减/折扣/买一送一）、渠道、时间、预算
• 门店异常：停水停电、装修、设备故障
• 周边事件：修路、大型活动、竞争对手开业
• 菜单变更：新品上市、下架、价格调整

4.3 数据采集流程与质量管控

数据采集不是“一次性导出”，而是需要建立持续、自动化的管道。推荐以下五步流程：

1. 盘点数据源：列出所有可用系统，确认字段、权限、导出方式
2. 定义数据字典：统一字段命名、单位、枚举值（如渠道：1=堂食，2=外卖，3=自提）
3. 建立自动采集任务：使用Python脚本或ETL工具（如Kettle、DataX）每日定时拉取
4. 数据校验：设置阈值检查（如日销量波动超过±50%触发告警）
5. 存储与备份：建议使用数据库（MySQL/PostgreSQL）或数据仓库，保留至少2年历史

案例拆解：某连锁快餐品牌的天气-销量联动采集

背景：某中式快餐连锁（30家门店）发现雨天外卖订单明显上升，但堂食下降，导致总销量预测不准。原模型仅使用历史销量，MAPE（平均百分比误差）高达28%。

目标：将天气数据纳入预测模型，并区分堂食/外卖渠道。

关键操作：

• 接入和风天气API，按门店所在城市拉取每日降水、温度、风力
• 在POS数据中拆分堂食/外卖订单，分别统计日销量
• 建立“天气-渠道-销量”交叉分析表，发现：降水量>5mm时，外卖销量+35%，堂食-18%
• 将天气特征作为外部变量加入XGBoost模型

结果：模型MAPE从28%降至19%，其中外卖预测精度提升最明显（MAPE从32%降至21%）。

代价与风险：天气API调用需付费（约500元/年），且极端天气（台风）样本量少，模型可能过拟合。复盘发现，需要额外加入“风力>8级”的虚拟变量来修正。

4.4 常见误区与总结复盘