Scentralizowane raportowanie dla sieci 12 kawiarni: ta sama latte, 9 miast

Sieć third-wave w stylu Kronotrop z 12 lokalami w 9 miastach: różni bariści, to samo menu, ten sam SKU latte. Regional manager chce w poniedziałek rano jeden parent-dashboard, nie 12 zakładek. Oto setup multi-tenant Looker Studio z wykrywaniem anomalii.

Architektura: lokal → BigQuery → Looker

Każdy lokal o 00:30 UTC wrzuca dzienne JSON na Cloud Storage. Zaplanowane zapytanie BigQuery o 03:00 UPSERT'uje do partycjonowanej tabeli orders_daily. Looker Studio łączy się z tą jedną tabelą — bez sklejania 12 źródeł.

Cztery strony: przegląd, porównanie lokali (heatmapa), drill-down produktu, anomalie. Filtry przechodzą między stronami.

Granularność: produkt × lokal × godzina × tydzień

Bez właściwej granularności nie da się powiedzieć, że latte spadło w tym tygodniu. Schemat:

• Godzinowa: (branch_id, sku, godzina, dzień_tyg) — anomalia szczytu
• Dzienna: (branch_id, sku, data) — baseline Z-score
• Tygodniowa: (branch_id, sku, iso_tydzień) — week-over-week

12 lokali × 60 SKU × 365 dni ≈ 263 tys. wierszy/rok. BigQuery utrzyma to poniżej 0,02 $/miesiąc.

Anomalia Z-score: latte -2σ → alert Slack

Zapytanie liczy o 04:00 w 28-dniowym oknie ruchomym μ i σ per (lokal, produkt). Wartość dzisiejsza (dziś - μ) / σ to Z-score. Jeśli |Z| ≥ 2, wiersz w anomalies, Cloud Function odpala, wiadomość na Slack #ops-alerts.

Przykład: "Kadıköy Flat White Z=-2,4 (dziś 18, średnia 47). Prawdopodobnie zmiana baristy lub kalibracja espresso." Supervisor dzwoni w 30 minut. False-positive ~12% — akceptowalne.

FAQ

Czy Looker Studio jest darmowy dla 12 lokali? Tak. Looker Studio jest darmowy; płaci się tylko za BigQuery — przy tym wolumenie poniżej 5 $/miesiąc.

Nie mamy POS, tylko thMenu. Da się? Tak. Nocny eksport z D1 do R2, potem ładowanie do BigQuery. Pro+ tier udostępnia feed analityczny.

Dlaczego 2σ a nie 3σ? 3σ jest zbyt konserwatywne — realne spadki operacyjne by uciekły. 2σ daje 88% precision przy dobrym recall.

Czy to było pomocne? Udostępnij.