Analytics System

I built this analytics platform from scratch as part of my commercial VR work. The goal was to turn product usage into something measurable and useful for both the business and its clients, rather than leaving it as raw event noise spread across applications and databases.

The system covered Unity telemetry, a web reporting layer and the supporting database structures underneath. It tracked starts, completions, content block progress, time in app, confidence changes, pass rates, tenant activity and platform-level usage, then surfaced that data through dashboards designed for actual operational and client reporting use.

The screenshots below are redacted versions of the real product. Client names, company-linked text and other sensitive details have been removed or obscured.

This view shows content block completion at a more granular level, which made it easier to spot where learners were dropping off inside a module rather than only at the top-level completion rate.

This module completion screen rolls that data up into a broader product view, giving a clearer picture of starts, completions and comparative performance across training modules.

What I built

• Telemetry flows from Unity applications into a central analytics pipeline.
• Multi-tenant reporting views with filtering by module, platform, time window and comparison mode.
• Dashboards covering completion, engagement, confidence, assessments and content block progression.
• Tenant-level controls to decide which KPI categories and benchmark behaviours are visible.
• Support tooling around the underlying statement data, including raw record inspection and reconciliation workflows.
• Reporting output that gave clients clearer quantitative and qualitative evidence of training value.

The daily activity dashboard tracked how usage moved over time, which was useful for reporting trends, checking rollout impact and understanding whether engagement was improving after content or delivery changes.

The hourly activity view added a second layer of detail by showing when usage was actually happening within the day, helping reveal session patterns that would be hidden in daily totals alone.

This KPI configuration screen is part of the tenant-level control layer. It let administrators decide which metric categories and benchmark behaviours were visible without changing the underlying data collection.

Supporting admin surfaces

The analytics work also extended beyond charts alone. I built and supported the surrounding admin and data-handling surfaces needed to make the reporting useful in practice, including tenant-level controls, module management context, raw statement inspection and reconciliation tooling.

The tenant management view supported the multi-tenant structure behind the reporting platform, making it possible to configure and maintain separate client environments within the same overall system.

The module management screen shows that the analytics work sat alongside the wider content administration flow, not as an isolated dashboard but as part of a broader product operations toolset.

This raw statement view was important for inspecting the underlying xAPI-style records directly, which helped with debugging, validation and building trust in the reported figures.

The reconciliation tooling supported the less visible side of analytics delivery: checking data consistency, resolving mismatches and making sure derived reporting stayed dependable over time.

What made this project important was not just the dashboards themselves, but the fact that it gave the business a credible evidence layer. It helped support client conversations, backed up contract discussions with measurable data, and contributed to new NHS contract wins and the company's first returning customers.

It was also a strong example of adaptability. I moved into web and database work to deliver this despite having no prior commercial background in those areas, and carried it through as an end-to-end product feature rather than treating it as somebody else's layer of the stack.