feat(analytics): day-by-hour visitor matrix for a week #87

New issue

Closed

opened 2026-09-24 23:23:42 +00:00 by gabogg · 1 comment

gabogg commented

2026-09-24 23:23:42 +00:00

Owner

Route

GET /api/analytics/timeseries/week-hourly?week_start=YYYY-MM-DD

A 7 × 24 matrix of visitors per business-day hour (04:00 → 04:00), with gap-estimated cells marked.

Used by

Week view: the busy-hours heatmap.

Notes

Could instead be a bucket=hour option on the daily series route; decide in review. Calling /timeseries/hourly seven times works but is not a contract.

Context

Part of the statistics deck redesign, draft RFC in #80 (docs/architecture/rfc-statistics-deck-display-model.md; mockup linked there). Period selection is settled in #81; the parameters below assume a period is identified by granularity (day / week / month) and its first business day. A year period is out of scope.

Shared constraints (all statistics-deck routes)

Periods are closed business periods in facility time (daily_reset_time boundaries, app/facility_time.py); an in-progress cycle is never returned.
Only counted cameras contribute (_COUNTED_CAMERA_JOIN / _COUNTED_CAMERA_FILTER); quarantined events never do.
Every period-level figure carries its data quality: gap-estimated days (ingestion anomaly ledger), Data Trust and Cycle Completeness for the cycles involved, so the deck can mark estimates.
Dwell means the open-window Mean Dwell (ADR 0006), not the retired definitions.
Access is undecided: current analytics routes use require_admin; who can open the deck is open question 7 in the RFC.
Controllers stay thin; aggregation lives in analytics_service, SQL in repositories.

## Route `GET /api/analytics/timeseries/week-hourly?week_start=YYYY-MM-DD` A 7 × 24 matrix of visitors per business-day hour (04:00 → 04:00), with gap-estimated cells marked. ## Used by Week view: the busy-hours heatmap. ## Notes Could instead be a `bucket=hour` option on the daily series route; decide in review. Calling `/timeseries/hourly` seven times works but is not a contract. ## Context Part of the statistics deck redesign, draft RFC in #80 (`docs/architecture/rfc-statistics-deck-display-model.md`; mockup linked there). Period selection is settled in #81; the parameters below assume a period is identified by `granularity` (`day` / `week` / `month`) and its first business day. A year period is out of scope. ## Shared constraints (all statistics-deck routes) - Periods are **closed** business periods in facility time (`daily_reset_time` boundaries, `app/facility_time.py`); an in-progress cycle is never returned. - Only **counted cameras** contribute (`_COUNTED_CAMERA_JOIN` / `_COUNTED_CAMERA_FILTER`); quarantined events never do. - Every period-level figure carries its data quality: gap-estimated days (ingestion anomaly ledger), **Data Trust** and **Cycle Completeness** for the cycles involved, so the deck can mark estimates. - Dwell means the open-window **Mean Dwell** (ADR 0006), not the retired definitions. - Access is undecided: current analytics routes use `require_admin`; who can open the deck is open question 7 in the RFC. - Controllers stay thin; aggregation lives in `analytics_service`, SQL in repositories.

gabogg added the

needs-triage

label

2026-09-24 23:23:42 +00:00

gabogg referenced this issue

2026-09-24 23:24:08 +00:00

feat(statistics-deck): choose which complete day, week or month the deck shows #81

gabogg referenced this issue

2026-09-24 23:33:39 +00:00

docs(statistics-deck): zero-scroll display model and the projector paradox #80

gabogg commented

2026-09-25 00:43:50 +00:00