68 lines
4.4 KiB
Markdown
68 lines
4.4 KiB
Markdown
# 餐饮零售数据中台 V2.0 业务蓝图 (聚焦数据洞察)
|
||
|
||
**文档版本：** V2.0 (边界收拢版)
|
||
**业务模式：** 纯分销与零售（中央工厂拿货 + 门店加热外带/外卖 + 线上冷链零售）
|
||
**核心愿景：** 打造基于有赞生态的“洞察大脑”，通过商品数据优化采购与流转，通过客户数据实现高频复购与场景跨越。
|
||
|
||
---
|
||
|
||
## 一、 商品洞察网络 (Product Insights：卖什么，怎么订)
|
||
|
||
**业务目标：** 告别经验主义备货，实现高动销、低库存、零过期损耗。
|
||
|
||
### 1. 全渠道 SKU 动销与生命周期洞察
|
||
|
||
* **全域销量折算模型：** 将“门店加热售出的熟食份数”与“线上售出的冷链包装份数”统一映射为底层 SKU 消耗总量，呈现单一预制菜的全盘真实热度。
|
||
* **双栖波士顿矩阵 (BCG Matrix)：**
|
||
* **热食爆款：** 门店端高频复购，出餐快，作为“引流款”持续吸客。
|
||
* **冷链爆款：** 线上端高客单囤货，作为“利润款”重点推流。
|
||
* **双栖滞销款：** 线上线下双重遇冷，系统输出《淘汰建议清单》，直接从向央厨的采购目录中剔除。
|
||
|
||
### 2. 智能订货与库存健康度洞察
|
||
|
||
* **基于流速的订货预测：** 结合有赞过去 7-14 天的日均消耗流速（动销率）、周末/节假日权重，自动计算单店合理的《次日/周采货建议单》，防止门店盲目多订或少订。
|
||
* **效期流转预警洞察：** 追踪从总仓拿货的各批次在库时间。当预制菜库存可用天数超出安全阈值，或保质期剩余不足 30% 时，系统自动标记为“临期资产”，并触发门店在有赞外卖或小程序挂出“今日特惠”以加速出清。
|
||
|
||
### 3. 购物篮关联分析 (Market Basket Analysis)
|
||
|
||
* **连带率洞察：** 分析外卖/外带场景下的高频组合（例如：点红烧肉加热快餐的用户，有多大比例会顺手带一瓶冷萃茶）。通过洞察支持有赞前端的“套餐组合”和“猜你喜欢”策略，提升客单价。
|
||
|
||
---
|
||
|
||
## 二、 客户洞察引擎 (Customer Insights：谁在买，怎么复购)
|
||
|
||
**业务目标：** 将即买即走的“外卖快餐客”，转化为高客单价、高留存的“家庭冷链囤货客”。
|
||
|
||
### 1. O2O 全域 OneID 画像洞察
|
||
|
||
* **身份跨端融合：** 抓取有赞的外卖订单、自提订单与线上商城订单，以“手机号/微信生态 ID”为主键，将同一用户的“外带热食记录”与“网购冷链记录”无缝拼接。
|
||
* **场景跨越追踪：** 清晰刻画用户流转轨迹（例如：某用户连续三周在 A 门店买工作日加热午餐，上周末在线上商城首次下单了同款半成品）。
|
||
|
||
### 2. RFM 客户价值分层洞察
|
||
|
||
系统利用 T+1 定时任务，每日计算用户的 R(最近消费)、F(消费频次)、M(消费金额)，并自动打标：
|
||
|
||
* **核心高优客：** 双渠道高频购买（既吃外卖又买冷链），系统可自动推送“月度订阅制套餐”。
|
||
* **单栖高频客：** 仅在外卖端高频，中台可自动触发有赞短信/模板消息，推送“同款冷链预制包试吃券”，引导向零售场景跨越。
|
||
* **流失预警客：** 曾经高频但近 30 天未下单，系统生成召回名单，匹配高额无门槛券。
|
||
|
||
### 3. 同期群留存洞察 (Cohort Analysis)
|
||
|
||
* **拉新质量评估：** 监控每个自然月（或特定营销活动）获取的新客户，在后续 1 个月、3 个月、6 个月的留存率与复购率变化。
|
||
* **转化漏斗洞察：** 追踪“外卖包裹内塞入冷链网购优惠券”的实际核销链路，计算真实的场景转化率（热食 -> 零售转化率）。
|
||
|
||
---
|
||
|
||
## 三、 数据流转与技术支撑底座 (Tech Foundation)
|
||
|
||
中台不干涉前端业务履约，专注做数据的“抽水机”与“计算器”：
|
||
|
||
* **数据采集源 (有赞云 API)：**
|
||
* `交易域`：实时获取订单流水、支付明细、购买商品列表。
|
||
* `商品域`：同步全量商品库、SKU 信息。
|
||
* `客户域`：拉取会员基本信息、积分资产、行为轨迹。
|
||
* **处理架构架构建议：**
|
||
* 采用 Spring Boot 编写高频定时任务，解决全量历史数据的拉取与状态对账。
|
||
* 引入 Kafka 缓冲订单洪峰，使用 Flink 处理实时动销流速与实时规则匹配。
|
||
* 业务数据沉淀至 MySQL，利用 Redis 保障全局 Token 有效期与高频接口限流。
|