The Analytics Pipeline: Why You Have a Dashboard But No Answer
From a raw event to a number someone acts on — and why most things called analytics fail at the very first stage.
Most product dashboards show what was easy to compute rather than what informs a decision: user count, course count, total revenue. All correct, and none of them implies an action.
Start from the question, not the data
Before tracking anything, write down the questions that must be answerable: "which lesson do people abandon?", "do learners who attend a live session buy more?", "how long until someone opens their first lesson?". Every event you track without a matching question is storage cost and future noise.
Event naming is a long-lived contract
- A stable `resource.action` name in past tense: `lesson.completed`, not `completeLesson`.
- Few properties with declared types; free-form fields become chaos within months.
- User id and tenant id on every event, or you will not be able to segment anything later.
- A schema version, because the meaning of an event will change and you will not know when unless you record it.
Separate analytics from your production database
Running aggregate queries against production works until you grow, then slows the product itself at the worst possible time. Copy events into a separate store meant for analytical reads, even a simple one. The separation is not architectural luxury, it protects the experience.
A metric you do not know what to do about is decoration on a screen.
Pre-aggregate what is read often
Do not compute "completion rate per course" on every page load. Roll it up on a schedule into a summary table. The rule: what is read more often than it changes gets computed in advance; what is read rarely gets computed on demand.
The metrics worth showing
- Conversion across defined steps: visit → signup → first lesson → completion. The weakest step tells you where to work.
- Retention over time: the share who came back after a week, not the number of accounts.
- Time to first value: how long before a real first lesson? It is the strongest early signal of retention.
- Drop-off per lesson: the one number that improves content directly.
For the theory behind storing and processing events at scale, Designing Data-Intensive Applications is the book most people building these pipelines end up returning to. And for a shared vocabulary instead of invented event names, OpenTelemetry has become the de facto standard.
If you are building a product: event design is the cheapest thing you do today and the most expensive to fix in a year, because data you never recorded cannot be recovered. Talk to us.
FAQ
Buy a tool or build a pipeline?
A tool for your own product analytics, a pipeline for what you show customers inside your product. Conflating the two is expensive.
How long should raw events be kept?
Months for raw, years for aggregates. Keeping everything forever is cost without return.
How do I avoid event sprawl?
Document the event schema like a public interface, and refuse any new event that has no question behind it.