grillkol/Stat-Dashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Expand dashboard analytics and document production implementation

Browse Source
This commit is contained in:
maxwes08
2026-11-03 14:49:01 +01:00
parent 70b94f8672
commit aa0028e7e0
36 changed files with 2212 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
mockups/README.md
View File

@@ -1,9 +1,15 @@
# PostgreSQL-backed development mockups
This existing mockup is the reference product to port into production. See [PRODUCTION_IMPLEMENTATION.md](../PRODUCTION_IMPLEMENTATION.md) for the porting inventory, endpoints, Roblox payload/schedule contract, AI prompts, and production acceptance gates.
The HTML prototype now reads PostgreSQL data. The temporary Python service is a read-only development API; the planned production stack remains Lapis and React/TypeScript.
## Run on Windows
Double-click **`start-dashboard.bat`** in the repository root, or run `python start_dashboard.py`. The launcher sets up missing dependencies on first run, starts PostgreSQL and the backend, shows backend output in its terminal, and opens the dashboard in your browser. Close that terminal or press Ctrl+C to stop the backend and local PostgreSQL together. Windows process ownership also prevents background children being left behind if the terminal is closed abruptly. An already running local sample database is restarted under the launcher's ownership. A `DATABASE_URL` server is external and is never stopped. Browser tabs opened in an existing browser can be closed normally.
Use `start-dashboard.bat --no-browser` to keep the browser from opening. Only one launcher per checkout can run at a time. If another backend already occupies port 8011, close that backend's terminal first; the launcher reports the conflict.
From the repository root:
```powershell
@@ -63,12 +69,23 @@ Start with `GET /api/games`, then use the returned **internal** ID:
/api/games/{game_id}/monetization
```
Analytics accepts `days=7|14|30|90` (any integer from 1 to 90 is supported). Players supports `page`, `page_size` (maximum 100), `sort`, `direction=asc|desc`, `q`, and `segment=all|whales|playtime|first`. Sorting and pagination happen in the backend; unknown values sort last in either direction. Activity analytics accepts `activity_id` and the same segment names. Player detail accepts a snapshot field `value` for its history graph.
Analytics accepts `days=7|14|30|90` (any integer from 1 to 90 is supported). Players supports `page`, `page_size` (default and maximum 20), `sort`, `direction=asc|desc`, `q`, `ranking` for the fourth Hall of Fame stat, and `segment=all|whales|playtime|first`. Sorting and pagination happen in the backend; unknown values sort last in either direction. Activity analytics accepts `activity_id` and the same segment names. Player detail accepts `value` and `value2` for its comparison graph.
Player records use `/api/games/{game_id}/players/{player_id}/{snapshots|sessions|activities|events|purchases}?page=1`, always 20 per page and newest first. Repeated `event` parameters filter event names; repeated `product` parameters filter internal product IDs. Filters apply before pagination. The graph uses chronological snapshot timestamps independently of the table page. Other aggregate tables also have 20-row page controls.
`/api/games/{game_id}/prompts` supplies the Product prompts monetization tab. Prompt interactions are independent of activity runs. Owned gamepasses and product totals appear in separate player-overview cards. The Players Hall of Fame shows four top-five rankings with avatar placeholders; production avatar loading is not connected.
Prompt analytics accepts `source=all|game|player`. New interactions default to unknown unless an explicit `trigger_source` is reported. The prompt-source comparison always shows all sources for context, while product metrics follow the filter. Charts with more than two lines support search, per-line toggles, and All/None controls.
All API values are queried from PostgreSQL; there is no in-memory sample-data fallback. Database errors return HTTP 503, and the UI shows an error and `N/A`. The HTTP server serves only HTML/CSS/JS assets, not credentials, database files, Python, or SQL source.
## Pages
Overview now starts with a broad **Everything at a glance** analysis, with daily/weekly numerical reports underneath and no Game health section header. It interprets audience/concurrency/spending relationships, engagement strengths, onboarding weaknesses, activity/progression friction, payer concentration, offer placement, and priorities. Matched saved-player values add economy/progression context. The former Summaries navigation/page is removed; old `summaries-mockup.html` links redirect to Overview preserving their query string. Structured topic evidence remains available internally in the report payload.
Overview includes daily Game Health sample-analysis cards for yesterday and the past seven complete UTC days. Each game has separate text and evidence. `/api/games/{game_id}/reports` returns the current pair; PostgreSQL caches them by game/date/window, and the backend checks for a new UTC day every minute. Reports catch up after downtime. No AI key or model call is needed for these sample narratives. The public API remains read-only for ingestion/settings; report-cache writes are internal server maintenance.
Overview, Sessions, Retention, Events, Players, Player info, Activity sessions, Monetization, and Project settings follow the `pagename-mockup.html` convention. Login remains a visual prototype. All pages share `mockup.css`; `mockup.js` loads the shared `data-ui.js` module. Activity definition editing remains a UI draft; this service does not expose an ingestion or settings-write API.
See [METRICS.md](METRICS.md) for calculation definitions, denominators, and handling of unavailable data.
@@ -91,3 +108,5 @@ To stop only the local sample database:
```powershell
.local/pgsql/bin/pg_ctl.exe -D .local/pgdata -m fast stop
```
Project settings includes a Data quality log with category filters and pages of 20. Missing/unresolved records remain stored and visible there while regular prompt/activity analytics use known results. Report warning notes, unresolved columns, and unknown-source prompt comparisons are omitted from the main views. Recent open sessions remain visible; stale unended sessions appear in the diagnostic log.