OpenBookv3.4

Plazza's warehouse, read independently off DB 8 (Redshift) · built 20-Jun-2026 · three planes: Home fuses live pulse + trend + today's ranked actions · ⚡ Now = the fast clock (here-and-now) · 📊 Understand = the slow clock (why), grouped into 5 themes · headline net revenue = modified-NMV (delivered basis, ex-GST; referral + new-user added back) — ties Finance MIS within ~0.4% · cancelled excluded · every card has "Show logic" with the exact SQL it ran

Which clock you're reading: snapshot nightly refresh (intraday once hosted) · period trailing trend · anchor model assumption
⚡  Live pulse snapshot · 20-Jun-26full control tower →
📈  State of the business trailing · window noted per card
✅  Today's ranked actions by ₹ impact
Every card's "do-this" across OpenBook, deduped and ranked by rupee impact. jumps to the analysis that explains it; work the list opens the Metabase worklist (the row-level workbench).
The book has 8 chapters (schemas). Three tell the truth (orders, catalogue, events), one summarizes it (analytics), and four are feeds — two of which have silently stopped. Every number elsewhere in this dashboard traces to the tables below.

The data layer — lineage, grain & live census

live, 20-Jun-26
Four tiers feed one spine — analytics.db_orders — which this dashboard reads nightly. Click any table for its grain, join key, freshness and the trap that bites. Row counts are live; structure & traps per the canon.

Schemas — the chapters

live, 20-Jun-26

Critical tables — what they are and how they bite

live, 20-Jun-26

Revenue rosetta — four numbers, one truth

Oct-25 → Mar-26
Same window, four definitions. Always name the field.

Dead / frozen sources

as of 20-Jun-26
Queries on these run fine and return stale data — the dangerous kind of broken.

    Where to look for store ops & ops in general

    reference
    The fast clock. This is a snapshot as of the nightly refresh (20-Jun-26) — the store floor, the field, and live availability. It goes truly live (intraday) once OpenBook is hosted at an auth'd URL. The other tabs are the slow clock (trends & why); this one is the here-and-now.

    Pulse — last full day vs typical

    live snapshot · 20-Jun-26
    Where the business is running right now. Pace = last complete day against the same weekday's recent norm.

    Store floor — order pipeline

    last full day
    Where orders sit by stage. Cancellations flagged.

    The field — in flight now

    live snapshot
    Orders on the road this moment, by rider state.

    Live availability by store — what's out, what's expiring

    live snapshot · 20-Jun-26Work the OOS replenishment list in Metabase →
    Out-of-stock and near-expiry SKUs on shelf this moment. Asymmetry between stores is the action.

    Monthly orders & net revenue

    analytics.db_orders, app + POS

    AOV (ex-GST)

    Net revenue ÷ orders

    New vs repeat customers per month

    New = first-ever order that month

    Daily orders

    POS (walk-in counter) split out

    Customer retention by acquisition cohort (% ordering in month N)

    Jun-25 → Jun-26 (all history)
    Rows = first-order month. Right edge of recent rows is incomplete by definition. The selector cuts the matrix by the three first-order attributes the cut sweep ranked highest (value, distance, basket depth).

    NMV retention (month-N revenue as % of month-0 revenue)

    Jun-25 → Jun-26 (all history)
    The basis of the cumulative-NMV story — judge each row yourself.

    Tally vs the data book's "810% cumulative M12 NMV retention" (card #1404)

    cohorts Jun-25 → Jun-26

    How fast do customers come back? (time to 2nd order)

    cohorts Sep-25 → Apr-26
    % of cohort placing a 2nd order within N days

    Retention is decided in the first basket

    first orders ≥60d old
    60-day repeat rate by first-basket content

    What actually drives retention — the cut sweep

    first orders ≥60d old · all history

    Days between consecutive orders

    all history
    All repeat purchases

    Customer base by frequency × recency

    as of 20-Jun-26
    Where the base stands today

    Revenue concentration

    last 180 daysTop customers (VIP list) in Metabase →
    Customers ranked by spend, deciles

    First-order size predicts loyalty

    first orders ≥60d old
    60-day repeat by first-order value

    Daily search → add-to-cart

    last 30 days
    posthog_react live events

    The long tail of demand

    last 30 days
    Head vs tail of distinct queries

    WHY high-volume searches don't convert

    searches: last 30d · assortment: live 20-Jun
    High-volume queries (incl. good converters as controls), looked up live against the catalogue and instant assortment. Triage, not a verdict — name-ILIKE matching both false-matches and misses, so treat the catalogue-gap / stockout labels as a starting list to confirm, not a conclusion.

    Assortment fix-list — where search demand dies (v0, 11-Jun)

    Static view of the 1,609-query fix-list sweep (analyses/2026-06-11-assortment-fixlist-v0.csv). Est-₹/mo = searches × ATC-gap-to-18.3%-benchmark × 0.5 cart→order × median MRP — a ranking tool, not a forecast; becomes margin-true after FDD COGS reconciliation. Top 30 by ₹ at stake shown.

    Top searches and conversion

    last 30 daysWork the assortment-gap list in Metabase →
    Click headers to sort

    Monthly net item revenue by store

    Item-revenue spine (gross of coupons)

    Instant TAT p50 by store

    last 8 weeks
    Placed → delivered, minutes

    Store mix, last 30 days

    last 30 days

    Gross margin by category (Finance spine)

    Oct-25 → Jun-26
    Ties Finance MIS · provisional pending cohort confirm · GM compressed ~26%→~18% as discounting scaled (real)

    Discount depth & coupon usage

    Delivery TAT by week (instant)

    last 12 weeks

    Cancellation rate by week

    last 12 weeks

    Distance vs delivery time (instant)

    last 60 days

    Contribution margin per order — weekly (pre-delivery, vs ₹145 last-mile)

    last 12 weeks

    WHY TAT moved — stage decomposition (instant)

    last 14 weeks · p50 min

    The flywheel — acquisition → first basket → habituation → retention → frequency → economics

    live, 20-Jun-26
    Every number below is computed from this page's own datasets on each nightly refresh. Where a stage is leaking, the row says so.

    P0 fixes, ranked — insight → action → metric to watch

    cut sweep 11-Jun-26
    Ranked by the cut sweep (effect × cohort size × stability), validated with 2-way cuts for confounding. Actions are role-neutral — assign per your current functional split.

    In-app order ratings — weekly (live)

    all history, nightly refresh
    The internal review system: every rating carries its order_id. The operational queue lives in Metabase → collection "Customer callbacks (auto)" → card #2032.

    What 1–3★ in-app raters tag (live)

    all history, nightly refresh

    App-store rating trend

    Google Play + App Store reviews from the #plazzaverse AppFollow feed (static harvest — re-run scripts/voc_build.py to refresh)

    Why customers leave 1–3★ reviews

    all harvested reviews
    Keyword-classified themes; "tied to order" = reviewer name exact-matched to a warehouse order placed ≤45d before the review

    Review forensics — what the customer said vs what the warehouse shows happened

    most recent negatives + a sample of positives
    Order column = the matched customer's last order before the review (exact name match only, ambiguous names dropped — coverage is conservative). Diagnosis is computed from db_orders + tat_dashboard stages + refunds.

    Monthly P&L — the automated close (radar dashboard 108)

    Apr–Jun 26 · nightly mirror
    Absolute, ₹'000. Source: Finance MIS — radar/dashboard/108. Section rows in bold; % rows derived.

    Net revenue → EBITDA waterfall (per order)

    Finance MIS, per order
    Built from the per-order P&L above. Green = inflow, pink = cost. CM-I = after fulfilment; CM-II = after marketing; EBITDA = after corporate.

    The 4-way margin reconciliation — why "GM" ranges 4%→25%

    tie-out 15-Jun-26
    Every margin we quote, with its denominator and COGS source named. The headline: warehouse purchase_rate is GST-inclusive — deflating it ties our COGS to the books within 0.7%, and our old "6.3% CM" understated true product economics.

    Breakeven AOV — re-run at ₹145 last-mile + ₹380 marketing

    reconciled, 15-Jun-26
    Breakeven AOV (net revenue ex-GST) = cost layer ÷ product margin rate. Margin rate is now GST-corrected (13.8% post-discount today; 28% at the TGx target). Last-mile updated ₹123→₹145 (May actuals); marketing ₹380/order is the new-customer CAC layer.

    Rx upload → confirmed → delivered (monthly)

    all history · IST
    Distinct prescription carts by upload month, traced to the order. Latest month partial.

    Where Rx uploads leak — all-time

    cumulative
    Each step is a distinct, separately-fixable drop.

    Upload source decides conversion

    last 120 days
    my_rx = in-app saved/guided Rx flow · user = fresh manual upload

    Rx-linked share of all confirmed orders

    last 9 months
    Orders whose cart carried an uploaded prescription — the chronic/Rx thesis, measured.

    The cash map — where working capital is trapped (velocity × expiry)

    live, 20-Jun-26 · ex-GST cost
    How fast a batch's SKU sells (rows) × how soon that batch expires (cols). Number = ₹ at ex-GST purchase cost; colour = risk (idle and perishing = reddest). The bottom-left block is cash that is both not moving and not at expiry risk — returnable, not yet a write-off.

    Expiry write-off curve — the do-nothing path

    expired + next 12 months
    ₹ at cost expiring each month, and cumulative if none of it sells first.

    How the ₹ splits by velocity

    live
    Inventory at cost, by how fast the SKU is moving. Dead = zero sales in 60 days.

    The action list — biggest trapped cash, ranked, with what to do

    top 150 by ₹ · liveWork the full list in Metabase →
    Batch grain, deduped. Filter by action. The recommended action is a rule, not a mandate — judge each line (a newly-stocked SKU can read as "dead").

    The real signal — does a bad FIRST order kill the return? (60-day repeat by refund reason)

    new customers ≥60d old
    First orders only. Bar = % who placed a 2nd order within 60 days; dashed line = clean-first-order baseline. n shown on each bar — cells with n<100 are directional, not conclusive.

    Contacting support on the first order

    new customers ≥60d old
    60-day repeat: needed to contact support on order #1 vs not.

    Why "refunds → churn" is a trap

    all orders ≥60d old
    Across all orders, refunded orders repeat MORE — refunds mark engaged buyers. The signal lives in first orders, not the aggregate.

    Refund cost & mix by reason

    all historyAudit refunds (90d) in Metabase →
    Where the ₹ refunded actually goes.

    Refund trend — weekly

    last 20 weeks
    Count + ₹ refunded; preventable = supply / delivery / our-error.

    Last-mile economics — the ₹123 → ₹60 path

    weekly · 8 wk
    cost/order ≈ day-cost ÷ orders-per-rider-day. The master dial is drops per trip (batching) — pinned at exactly 1.0 every week. Doubling orders-per-rider-day ≈ halves cost/order.

    Own fleet vs 3PL (Pidge) — who carries the drops

    weekly · 8 wk
    Share of orders routed to Pidge (3PL) vs our own riders. Rising 3PL share means the own-fleet batching lever (card above) governs a shrinking share of drops.