97 lines
5.4 KiB
Markdown
97 lines
5.4 KiB
Markdown
# 餐饮零售数据中台 V2.0 - 产品需求文档 (PRD)
|
||
|
||
**文档版本：** V2.0
|
||
**产品定位：** 聚焦餐饮零售化（中央工厂分销 + 门店加热外带 + 线上冷链）的数据洞察与智能营销大脑。
|
||
**核心价值：** 告别经验主义，用数据指导“怎么拿货、怎么卖（商品洞察）”和“谁在买、怎么让他多买（客户洞察）”。
|
||
|
||
---
|
||
|
||
## 一、 业务背景与产品目标
|
||
|
||
在“纯拿货 + 加热外带/线上零售”的新型餐饮模型下，业务的核心痛点已从传统的后厨管理转移至**供应链终端流转效率**与**全渠道客流变现**。
|
||
本系统的建设目标是打通有赞云的交易、商品、会员底层数据，构建两大洞察网络，实现：
|
||
|
||
1. **降本增效：** 精准预测订货量，降低门店预制菜过期损耗。
|
||
2. **营收增长：** 识别高优人群，通过 O2O 场景交叉营销提升客单价与复购率。
|
||
|
||
---
|
||
|
||
## 二、 目标角色与使用场景
|
||
|
||
1. **运营操盘手 / 决策层**
|
||
* **使用诉求：** 洞察全盘销售趋势与客户贡献度；发现商品关联规律以制定套餐；圈选特定人群包推送到有赞进行精准发券。
|
||
2. **直营店长 / 执行层**
|
||
* **使用诉求：** 获取每日系统生成的《智能拿货建议单》；查看门店商品异常降速预警并执行促销打折指令。
|
||
|
||
---
|
||
|
||
## 三、 核心功能模块定义
|
||
|
||
### 3.1 商品洞察网络 (Product Insights)
|
||
|
||
*聚焦解决“货与场”的匹配，指导门店科学订货与上架策略。*
|
||
|
||
#### 3.1.1 销售趋势分析 (Sales Trend Analysis)
|
||
|
||
* **业务逻辑：** 监控单一大单品（如：麻辣小龙虾预制包）在不同时间周期（日、周、月）的全渠道单量起伏。
|
||
* **功能点：**
|
||
* **生命周期折线图：** 剔除异常波动（如极端天气），拟合真实动销趋势线。
|
||
* **智能订货预测模型：** 结合过去 14 天平滑流速与周末权重，为门店生成《次日/周最优拿货单》，防止爆款断货或冷门款积压。
|
||
|
||
#### 3.1.2 关联销售分析 (Market Basket Analysis)
|
||
|
||
* **业务逻辑：** 基于经典购物篮算法（如 Apriori 算法），挖掘外卖/线上购物车中的连带规律。
|
||
* **功能点：**
|
||
* **高频组合发现：** 输出如“买冷链酸菜鱼的用户，65% 关联购买了速冻糍粑”的洞察结果。
|
||
* **策略支撑：** 指导运营人员在有赞后台进行“满减套餐”打包或在下单页配置“猜你喜欢”推荐。
|
||
|
||
#### 3.1.3 商品复购分析 (Item Repurchase Analysis)
|
||
|
||
* **业务逻辑：** 评估“这道菜到底好不好吃/值不值”的客观指标。
|
||
* **功能点：**
|
||
* **单品粘性测算：** 计算某 SKU 的“30天内二次购买率”。
|
||
* **波士顿矩阵打标：** 首单高但复购极低的打上“需优化/淘汰”标签；复购率持续居高的打上“核心引流款”标签，重点保障进货量。
|
||
|
||
---
|
||
|
||
### 3.2 客户洞察引擎 (Customer Insights)
|
||
|
||
*聚焦解决“人与钱”的深度挖掘，将外卖流量沉淀为私域资产。*
|
||
|
||
#### 3.2.1 专属人群特征画像 (Audience Profiling)
|
||
|
||
* **业务逻辑：** 打破线上商城与线下外卖的数据隔离，构建 OneID 统一视图。
|
||
* **功能点：**
|
||
* **跨端身份映射：** 以手机号/微信 UnionID 为主键，缝合该用户的全渠道轨迹。
|
||
* **立体标签库：** 自动打标，如“工作日外带客”、“微辣偏好”、“高客单冷链囤货客”、“周五高频活跃”等。
|
||
|
||
#### 3.2.2 专属分层人群包 (Tiered Audience Segments)
|
||
|
||
* **业务逻辑：** 业务人员基于特征标签，自由组合圈选人群，用于精准触达。
|
||
* **功能点：**
|
||
* **动态分群圈选：** 例如交集提取“近 30 天门店外带 > 3 次” 且 “历史线上商城消费 = 0” 的特定人群。
|
||
* **自动化触达：** 将圈选好的人群包直接对接有赞发券 API，定向推送“同款冷链预制菜 7 折体验券”，完成 O2O 场景折叠。
|
||
|
||
#### 3.2.3 RFM 与销售贡献分析 (RFM & Sales Contribution)
|
||
|
||
* **业务逻辑：** 基于交易流水，动态计算每位客户的 R (最近消费)、F (消费频次)、M (消费金额)。
|
||
* **功能点：**
|
||
* **二八定律验证面板：** 直观展示前 20% 的超级用户（如订阅制月卡用户）贡献了多少大盘利润。
|
||
* **价值分层自动化应对：**
|
||
* *高价值客：* 专属客服、新品试吃权。
|
||
* *沉睡预警客：* 系统自动触发大额无门槛召回券。
|
||
|
||
---
|
||
|
||
## 四、 最小可行性架构与数据采集底座 (MVP Architecture)
|
||
|
||
为控制初创期研发与运维成本，V1.0 采用轻量级技术栈：
|
||
|
||
1. **核心框架：** 采用 Java (Spring Boot) 开发独立的数据中台微服务，配合 MyBatis 处理复杂 SQL 与映射。
|
||
2. **数据接入 (有赞云 API)：**
|
||
* **异步离线拉取：** 依赖 XXL-JOB 或 Spring Task，每小时/每天凌晨定时分页拉取 `youzan.trade` (订单历史) 和 `youzan.item` (全量商品)。
|
||
* **轻量级实时接收：** 接收有赞 Webhook (如订单支付成功)，放弃中间件，直接使用 Spring Boot 的 `@Async` 异步线程池或 Redis Stream 进行轻量级缓冲，避免阻塞有赞回调。
|
||
3. **数据存储：**
|
||
* **MySQL：** 作为核心数仓，存放 OneID 宽表、清洗后的订单流水及 RFM 聚合结果。
|
||
* **Redis：** 刚需组件。处理有赞全局 `access_token` 的高可用缓存、API 接口限流控制，以及轻量级的短平快队列。
|