Aegis Analytics
Live pilot (by application)Gameplay analytics for Roblox developers. It records what players actually do in an experience and helps a team investigate where sessions go wrong.
- Role
- Co-founder · product & engineering lead
- Team
- Team project at Aegis Studios Inc.
- TypeScript
- Next.js
- PostgreSQL
- Prisma
- Luau
- Roblox Studio plugin
- Better Auth


The problem
Roblox developers get top-line numbers, but answering why (where players go, what they interact with, how sessions end, whether a release changed any of that) usually means guesswork or hand-rolled logging. Aegis Analytics starts with Roblox. Whether it later supports other engines is still being evaluated.
My role
I co-founded Aegis Studios Inc. and lead product and engineering: coordinating the team, deciding what we build, and implementing the software. I helped take Aegis Analytics from concept to a working product and its first pilot.
What the product does
- A Luau SDK and Roblox Studio setup plugin record registered events (UI, prompts, areas, spawns, session lifecycle) and label each one as client- or server-reported.
- An Overview of sessions, players, Day 1 retention with its denominator, playtime, and Robux from reported purchases.
- Journey and game-map views, rule-based findings that link to the sessions behind them, saved session reports, and release comparisons.
- Optional AI explanations that cite metrics the app has already computed, behind a reviewed data disclosure and per-workspace daily spending caps. Off by default.
Architecture
Roblox servers send batched, authenticated events to a restricted ingestion listener that exposes only an ingest route and a health check. Events land in PostgreSQL (via Prisma), a worker runs deterministic analysis, and a Next.js dashboard with organization accounts and invitation-only sign-up serves the results. The public pilot website is a separate build that contains none of the private application.
Engineering challenge: honest data
Game telemetry is always incomplete. Players disconnect, servers stop, observers miss things. I designed the pipeline so gaps are never turned into invented behavior. Events carry sequence numbers and provenance, a stopped Studio playtest is recorded as a shutdown rather than a player leaving, and metrics show their denominators and coverage limits.
What we tested in the first pilot
We connected the SDK to a Roblox experience in Studio, played a scripted session, and compared every performed action against what was recorded. The event sequence arrived complete and in order, client and server sources were labeled correctly, the session ended as a shutdown, and the saved report could be reopened later.
What we learned, and what’s unproven
- The collection pipeline held up. Game-specific coverage didn’t yet: core gameplay outcomes like progression and purchases need explicit server hooks that weren’t in place.
- First-time setup took longer than our target and needs to be more self-contained.
- Collection from published Roblox servers, retention measured on real traffic, and product-market fit are not yet proven.
Status
The pilot is live and open only by application. Developers apply through the public site, and accepted studios get private access to the dashboard and help connecting their experience. There is no public sign-up.