📚 课程目录第3章数据基础与采集

3、数据基础与采集：调酒业务中可用的数据类型、数据采集方法、数据质量与清洗

调酒客户需求预测的精度，本质上取决于数据基础的完备程度与数据质量的高低。在酒吧、餐吧、酒店大堂吧等业态中，数据往往散落在POS收银系统、会员管理系统、第三方外卖平台、社交媒体以及线下人工记录中。本章将系统梳理调酒业务中可用的数据类型、采集方法以及数据质量治理的完整链路，为后续的量化预测模型打下坚实的地基。

3.1 调酒业务中的核心数据类型

3.1.1 销售数据：预测的基石

销售数据是需求预测最直接、最核心的输入。在调酒业务中，销售数据不应仅停留在“每日营业额”的粗粒度层面，而应细化到单品（SKU）级别和时段级别。具体而言，需要采集以下字段：

交易时间戳：精确到分钟，用于识别高峰时段（如周五21:00-23:00）与低谷时段（如周一14:00-16:00）。
产品标识：包括鸡尾酒名称、配方版本、杯型（标准杯/双份）、是否含酒精等属性。
数量与金额：销售杯数、销售额、折扣金额、支付方式（现金/扫码/会员卡）。
渠道来源：堂食、外卖平台（如美团、饿了么）、外带窗口、客房送餐（酒店场景）。
关联订单信息：同一订单中是否包含食物、其他酒水，这有助于分析“搭配销售”效应。

  核心原理：销售数据的时间序列特征（趋势、季节性、周期性）是预测模型的主要学习对象。例如，莫吉托在夏季周末的销量可能是冬季工作日的5-8倍，这种规律必须通过历史销售数据捕捉。

3.1.2 客流数据：预测的前置指标

客流数据是销售数据的“先行指标”。在调酒场景中，客流数据包括：

进店人数：通过红外计数器、摄像头人脸识别或Wi-Fi探针获取。
吧台停留时长：反映顾客消费意愿强度。
翻台率/吧台周转率：影响服务能力和出杯速度。
排队等待人数：在高峰时段，排队人数过多可能导致顾客流失，这部分“潜在需求”也应被记录。

客流数据与销售数据结合，可以计算出转化率（下单人数/进店人数）和客单价（销售额/下单人数），这两个指标是预测模型中重要的解释变量。

3.1.3 外部环境数据：预测的调节变量

调酒消费受外部环境影响显著，以下三类数据必须纳入采集范围：

数据类别	具体字段	对调酒需求的影响机制	采集频率
天气数据	温度、降水概率、湿度、风速、空气质量	高温天气增加莫吉托、金汤力等清爽型鸡尾酒需求；雨雪天气减少外出消费	每小时
活动/节假日	法定节假日、周末、大型演唱会/球赛、周边会展、酒吧主题活动	大型活动可带来30%-80%的客流增量；节假日前夜（如圣诞夜）销量激增	每日/按事件
周边竞争动态	周边新开酒吧、促销活动、评分变化	竞争加剧可能导致客流分流	每周

3.1.4 会员与社交媒体数据

会员数据（年龄、性别、消费频次、偏好口味）为需求预测提供了用户画像维度。社交媒体数据（大众点评评分、小红书种草笔记数量、抖音打卡视频热度）则反映了品牌的线上声量，通常领先于实际客流变化3-7天。

3.2 数据采集方法与技术选型

3.2.1 自动化采集：API与数据库对接

对于POS系统、会员系统、天气服务商（如和风天气、OpenWeatherMap），推荐使用API接口进行自动化采集。具体操作流程如下：

梳理数据源清单：明确每个系统的数据字典、字段含义、更新频率。
开发采集脚本：使用Python（requests库）或Java（HttpClient）编写定时任务，每日凌晨拉取前一日数据。
建立数据仓库：将不同来源的数据统一存储到MySQL/PostgreSQL或云数据仓库（如阿里云MaxCompute）。
设置监控告警：当API调用失败或返回数据为空时，触发邮件/短信告警。

# 示例：每日凌晨2点拉取POS销售数据
import requests
import pandas as pd
from datetime import datetime, timedelta

yesterday = (datetime.now() - timedelta(days=1)).strftime('%Y-%m-%d')
url = f"https://pos-api.example.com/v1/sales?date={yesterday}&=your_key"
response = requests.get(url, timeout=30)
if response.status_code == 200:
    data = response.json()['data']
    df = pd.DataFrame(data)
    df.to_sql('sales_daily', con=db_engine, if_exists='append', index=False)
else:
    send_alert(f"POS数据拉取失败: {response.status_code}")

3.2.2 半自动采集：IoT传感器与人工录入

客流计数器（红外对射或摄像头）通过IoT网关将数据上传至云端。对于无法自动化的数据（如顾客口味偏好、现场活动效果评估），需要设计标准化的人工录入表单。建议使用平板电脑上的简道云或问卷星，在每日打烊后由值班经理填写，字段包括：当日特殊事件、顾客投诉、畅销酒水备注等。

3.2.3 采集频率与时间对齐

不同数据的采集频率差异较大，必须进行时间对齐。建议统一以小时为最小时间粒度：

销售数据：按小时聚合（如18:00-19:00的销售额）。
客流数据：按小时统计进店人数。
天气数据：取整点时刻的温度和降水值。
活动数据：以0/1变量标记当天是否有大型活动。

常见误区：部分酒吧仅记录每日总销售额，忽略了时段维度。这会导致预测模型无法捕捉“晚9点后是鸡尾酒点单高峰”这一关键规律，预测精度大幅下降。

3.3 数据质量评估与清洗策略

3.3.1 数据质量问题的典型表现

调酒业务数据常见的质量问题包括：

问题类型	具体表现	产生原因	影响
缺失值	某日天气数据为空；POS记录缺少产品类别	API故障、收银员漏选	模型无法学习该时段特征
异常值	某小时销售额为平日的20倍；客流数为负数	系统bug、测试订单未删除	扭曲统计特征，误导预测
重复记录	同一笔订单被同步两次	网络重试机制	高估实际销量
不一致	POS系统显示“莫吉托”，手工表记录为“Mojito”	命名不规范	无法按SKU汇总

3.3.2 清洗操作流程

数据清洗应遵循“先诊断、后处理、再验证”的流程：

缺失值处理：对于时间型缺失（如某小时客流数据缺失），采用前后时段的均值插补；对于属性型缺失（如产品类别为空），根据产品名称进行规则映射。
异常值检测：使用3σ原则或IQR（四分位距）方法识别极端值。例如，某小时销售额超过历史同期均值+3倍标准差时，需人工核查是否为真实事件（如包场活动）。
去重与去重：基于订单号、交易时间、金额三个字段联合去重。
标准化：统一产品名称（建立别名映射表）、统一货币单位、统一时间格式（ISO 8601）。

经验提醒：清洗规则应固化为可重复执行的Python脚本或SQL存储过程，每次数据入库后自动运行，并生成数据质量报告（缺失率、异常率、重复率），便于持续监控。

3.4 实战案例：某精酿酒吧的数据基础搭建

背景与约束：上海某精酿酒吧（约80个座位，含吧台20席），营业时间为17:00-次日02:00。该店希望建立未来7天的鸡尾酒销量预测模型，但此前仅使用Excel记录每日总销售额，数据粒度粗糙，且存在大量手工录入错误。

初始现象与目标：店长发现周末备货经常不足（经典鸡尾酒如尼格罗尼在周六晚9点后常售罄），而工作日又存在食材浪费。目标是将预测精度（MAPE，平均百分比误差）控制在20%以内。

关键输入数据与参数：

POS系统：已使用3年，可导出逐笔交易记录（含时间、品名、金额）。
客流计数器：门口安装红外对射计数器，但数据未与销售数据关联。
天气API：已购买商业天气数据服务，可获取逐小时温度、降水。
活动日历：店长手工维护的周边演唱会、体育赛事时间表。

分析判断过程：团队首先对POS导出的12个月数据进行探查，发现以下问题：约3.2%的订单缺少产品类别字段；周五和周六的销售额数据存在明显异常（部分时段为0，但客流计数器显示有人进店）；产品名称存在“古典”、“Old Fashioned”、“古典鸡尾酒”三种写法。

实际操作步骤：

数据抽取与整合：编写Python脚本，每日凌晨从POS数据库导出前一日交易明细，从客流计数器API拉取逐小时客流，从天气服务商获取逐小时天气数据，统一存入PostgreSQL数据库。
清洗规则实施：建立产品别名映射表（将“古典鸡尾酒”映射为“Old Fashioned”）；对缺失的产品类别，根据品名关键词（如含“金酒”则归类为“金酒基底”）进行填充；对销售额为0但客流>20的时段，标记为“疑似漏单”，由店长次日人工确认。
特征工程：衍生出“是否为周末”、“是否为大型活动日”、“体感温度”（温度+湿度计算）、“前一日同时段销量”等特征。
质量验证：清洗后数据缺失率从3.2%降至0.4%，异常值占比从1.8%降至0.2%。

结果对比与复盘：经过3个月的数据积累和模型训练（使用XGBoost），该酒吧的周销量预测MAPE达到18.7%，尼格罗尼的备货准确率提升35%。复盘发现，最大的收益来自将客流数据与销售数据关联后，识别出“进店但未消费”的顾客比例，从而优化了吧台服务动线。

风险提示：数据清洗过程中，人工确认异常值需要投入时间成本。建议每周固定安排1小时进行数据质量复核，避免异常值“带病”进入模型训练集。

3.5 常见误区与总结复盘

误区一：追求大而全的数据采集。并非数据越多越好。例如，采集顾客的精确地理位置可能涉及隐私合规问题，且对预测贡献有限。应聚焦于与调酒需求强相关的核心变量。

误区二：忽视数据的时间一致性。不同数据源的时钟可能存在偏差（POS系统时间与客流计数器时间相差几分钟），导致时间对齐后出现错位。应在采集时统一使用服务器时间，并定期校准设备时钟。

误区三：清洗过度导致信息丢失。例如，将“暴雨红色预警”这类极端天气事件当作异常值剔除，反而丢失了重要的需求抑制信号。应区分“数据错误”与“真实极端事件”。

总结：数据基础建设是调酒需求预测项目的“地基工程”。建议按照“明确核心指标 → 设计采集方案 → 建立清洗流水线 → 持续监控质量”四步法推进。初期可先聚焦销售、客流、天气三类数据，待模型运行稳定后再逐步引入会员、社交媒体等扩展数据源。