Built for a mobile-videography course, the dashboard removed up to 90% of manual analytics work and increased subscription conversion by up to 7 percentage points.
A web application that aggregates performance analytics for a B2C mobile-videography course aimed at beginners. The main screen is laid out as an instrument panel — a set of key metric cards, each opening a drill-down so the team can quickly understand why a number moved. The interface is optimized for iPad and iPhone so founders and managers can check product health on the go and act on insights immediately. Before the project, the team was reconciling everything in Excel, which made it impossible to manage monetization as a system. They needed a product built from scratch, with the iOS app pushing events into a single web-dashboard.
Two co-founders: Sergio and Andrew. Sergio is a professional videographer with seven years of experience and a portfolio of around 300 projects. Andrew is a stunt performer from the Red Bull team. The product monetizes through one-time course purchases and a subscription. The core asset is the content and the methodology. Growth comes in waves driven by launches, collaborations, and paid traffic — and beyond that, everything depends on whether a beginner finishes onboarding, whether the first experience clicks, and whether the user reaches a purchase.
From hype to managed growth
Traffic was rising, but without system-level analytics it was unclear what was actually bringing paying users.
Retention for beginners
If a newcomer didn't finish onboarding or the first lessons, the brand could still sell, but the product struggled to keep the user inside.
Subscription and one-time purchases
With two monetization models, the team needed to see activity, return behavior, and repeat transactions after the first purchase.
Excel as a bottleneck
Spreadsheets meant the team saw problems late and wasted time aligning numbers instead of working on the cause.
Dashboard for founders and managers
One interface had to support both the CEO view and operational manager work (diagnosing a specific drop, deciding what to do today).
We built an event-driven analytics system: the iOS app emits standardized learning and payment events, a Node.js service turns them into funnel and retention metrics, Directus stores the product structure and interpretation rules, and the web-dashboard delivers concise answers for the co-founders and managers — where users came from, whether they activated, whether they reached the first lesson, where they dropped off, and what to change in onboarding or content.
Unified rules for counting actions
We defined which exact actions trigger statuses like "activated," "completed first lesson," "purchased," and "churned," so everyone in the business uses the same arithmetic.
Reliable event collection from the iOS app
We implemented event delivery to prevent data loss on weak internet, traffic spikes, or retries (offline queue + idempotency keys + retry-with-backoff).
Data as an audit journal
We identified the need to confirm at any moment what the app actually sent and to trace how each metric was calculated.
Clear business metrics
We built a stable set: how many users reached the first lesson, how they progress through modules, where they vanish, and how that ties to payments.
Fast and convenient reporting
We structured the data so the panel opens fast and answers in seconds.
Admin center for management
We gave the team a way to update course and lesson structure, names, categories, and progress rules without developer involvement.
Two sales models
We designed separate views for subscription and one-time purchases to see which produces better post-purchase behavior.
Dashboard as a decision tool
We designed an interface that answers specific questions: where the drop-off is in learning, on which step, in which course, after which screen, and what to check first.
Data quality control
We implemented data-quality indicators that flag immediately when data stops arriving or starts coming in incorrectly, so decisions stay grounded in trustworthy inputs.
Built-in cues
We added in-dashboard cues: where the biggest drop-off sits, which lessons or steps look suspicious, what likely broke after the release — so the team gets to action faster.
The client arrived with a detailed spec, so the first step was checking it for implementability. We split requirements into blocks (iOS event ingestion, metric calculation, dashboard UI, user roles, export and reconciliation) and analyzed the places where risk usually hides in specs: metric definitions, time zones, duplicate events, "pending/failed" payments, period correctness. Output: a short list of clarifications and definitions to define.
+4 Resource
After launch and the first iterations, the team saw measurable impact across the product’s core performance areas.
on manual analytics
in completion of the key early-stage step
in conversion to paid among activated users
decisions are now driven by reliable data
Or send us a message and we'll get back to you within 15 minutes during business hours