Kronotrop风格的12家third-wave咖啡连锁分布在9座城市:不同的咖啡师,相同的菜单,相同的拿铁SKU。区域经理周一早上想看一个父级仪表盘,而不是12个标签页。这里是多租户Looker Studio搭配异常检测的方案。
架构:门店 → BigQuery → Looker
每家门店在UTC 00:30把每日JSON投递到Cloud Storage。BigQuery的scheduled query在03:00执行UPSERT到分区表orders_daily。Looker Studio连接这一张表 — 无需在12个源之间做拼接。
父级仪表盘四个页面:总览、门店对比(热力图)、产品下钻(12店拿铁)、异常。过滤器在页面间持久化。
粒度:产品×门店×小时×周
没有合适的粒度,就无法说"拿铁本周下滑"。模式:
- 小时:
(branch_id, sku, 小时, 星期)— 高峰时段异常 - 日:
(branch_id, sku, 日期)— Z-score基线 - 周:
(branch_id, sku, iso_周)— 周环比
12店×60 SKU×365天≈26.3万行/年。BigQuery成本每月低于0.02美元。
Z-score异常:拿铁-2σ → Slack告警
每天04:00BigQuery查询在滚动28天窗口内对每对(门店,产品)计算μ和σ。今日销量(今日-μ)/σ就是Z-score。当|Z|≥2时写入anomalies表,Cloud Function触发并发送Slack #ops-alerts消息。
示例告警:"卡德柯伊店Flat White Z=-2.4(今日18,均值47)。可能原因:咖啡师更换、浓缩咖啡机校准、橱窗布局。"主管30分钟内联系门店。假阳性约12% — 可接受。
常见问题
Looker Studio对12家店免费吗?是的,Looker Studio免费;成本在BigQuery,此量级每月5美元以下。
我们没有POS,只用thMenu可以吗?可以。把thMenu订单从D1每晚导出到R2再加载到BigQuery。Pro+套餐开放分析导出。
为什么选2σ而不是3σ?3σ对精品咖啡太保守,会漏掉真实的运营下滑。2σ的精确率约88%,召回率高。
觉得有用?分享给朋友。