Admin: Statistics page

[TheMaestr-o]

User story

As an admin operator, I want a Statistics page showing usage and content trends, so that I can understand engagement (which songs get used, which language communities are most active) and content growth over time — not just the raw counts the Dashboard (#107) shows.

Current state

Nav entry exists (added in #104) and currently points at a plain "coming soon" stub (apps/admin/app/statistics/page.tsx). This issue tracks building the real page. Not started — deliberately scoped as issue-only for now, split into two halves with very different implementation cost:

Blocked on new infrastructure (bigger effort)

• Top 10 songs (by usage/opens)
• Usage by language (site visits + song opens, split DE/EN/RU)

Neither can be built today — there is no usage-tracking table in the schema (docs/schema.md), no page-view or song-open event is currently recorded anywhere in apps/api. Building this needs: a decision on what to track (song opens? page views? both?), a new D1 table + migration, a write path from the public songbook app (or API), and almost certainly a DSGVO pass (docs/dsgvo.md) since any visit/usage tracking touches IP addresses even if aggregated before storage. This is the bulk of the real work in this issue and should be scoped as its own sub-task before implementation starts.

Buildable from existing data (smaller effort, once prioritized)

• Audience — signups per month — from subscribers.created_at, already available via GET /admin/subscribers
• Content — posts per month — from posts.published_at, already available via GET /posts
• Songbook — songs per book — from songbooks.songCount per book, already available via GET /songbooks
• Media — uploads per month — from images.uploaded_at, already available via GET /admin/images

These four don't need new backend routes — they need a time-bucketing pass over data already fetchable, similar in spirit to the Dashboard's fetchAll pagination helper, just grouped by month instead of summed. This is a reasonable next-implementation candidate once someone picks this up, independent of the usage-tracking half above.

Acceptance criteria (once implementation is scoped)

• Decide + document what usage-tracking infrastructure records (event shape, retention, DSGVO basis) before writing any tracking code
• Top 10 songs list, sourced from real usage data
• Usage-by-language breakdown (site visits + song opens)
• Audience/content/songbook/media charts, sourced from existing endpoints, bucketed by month
• Charts rendered without a new charting dependency (plain inline-SVG bar/line helpers, matching the Sparkline component pattern introduced in Admin: Dashboard overview page #107)
• Responsive at 1280/1024/768/375px, both dark and light theme
• docs/schema.md / docs/api.md updated if a usage-tracking table + route are added
• docs/dsgvo.md updated if any new data collection is introduced

Out of scope for now

• Any implementation — this issue is intentionally left at the planning/tracking stage.
• Real-time analytics — monthly/aggregate granularity is enough.

Related

• 🎨 Admin: Redesign Songbooks page — grid layout + fix 500 error #104 (Songbooks redesign) — Sidebar Statistics nav entry + stub page
• Admin: Dashboard overview page #107 (Dashboard) — Sparkline component and fetchAll pagination pattern this page should reuse