App analytics: the five events worth tracking from day one

New apps tend toward one of two analytics extremes: tracking almost nothing, which leaves the team flying blind, or instrumenting dozens of events before launch, which produces a dashboard nobody actually looks at because it's too noisy to draw a decision from. A small, deliberate set of events, tracked well, gets a new app most of the way to actionable insight without either extreme.

We push back on both extremes early in a project, since each fails a different type of team. Founders who track nothing usually overcorrect into gut-feel decisions that real data would have contradicted; founders who track everything usually end up with a dashboard so noisy that even they stop checking it after the first few weeks. The five-event starting point is deliberately narrow enough to actually get used.

First open (and whether it converts to a completed onboarding), core action completion (the one workflow the app exists to support), retention day 1 and day 7, the specific point in onboarding where users drop off if they don't complete it, and, for anything with a paid tier, the moment a user hits a paywall versus the moment they convert. These five, tracked from day one, answer the questions that actually drive early product decisions.

Each of these maps directly to a decision a founder actually needs to make in the first few months: whether onboarding is working, whether the core loop is being used at all, whether people come back, where exactly to focus product effort next, and whether the monetization moment is converting at a reasonable rate. Very few other events, at the earliest stage, map that directly to an actual decision.

Knowing that 40 percent of users complete onboarding tells you less than knowing exactly which step of onboarding loses the most people. We instrument each meaningful step as its own event specifically so funnel analysis is possible from day one, rather than realizing months in that the data needed to diagnose a drop-off was never captured at the right granularity.

This granularity decision has to happen before launch, not after, since retrofitting step-level tracking onto an onboarding flow that's already live means losing the ability to analyze exactly the cohort of early users whose behavior would have been most informative. We treat event instrumentation as part of the initial build itself, not a follow-up task scheduled for after launch.

Beyond the initial five, we add new tracked events only in response to a specific question the team can't currently answer, not speculatively. This keeps the analytics setup lean and keeps the dashboard genuinely useful, since every event added has a clear reason for existing rather than being there because it seemed like it might be useful someday.

We keep a short running log of exactly which decision each additional event was added to inform, which makes it easy to prune events later that turned out not to matter as much as expected. An analytics setup that only ever grows, never gets pruned, tends toward the same unusable noise the five-event starting point was designed to avoid in the first place.

The instinct to instrument everything usually comes from a reasonable fear of missing something important later. We reframe that fear directly: the risk of under-tracking is a delayed answer to a question you'll ask later, easily fixed by adding the event once the question actually arises. The risk of over-tracking is a dashboard nobody trusts or checks at all, which is a much harder problem to walk back once a team has already learned to ignore it.

We also point out a less obvious cost of over-instrumenting: every additional tracked event is a small ongoing engineering maintenance burden, a schema that needs updating if the app changes, a potential source of broken tracking if a refactor moves the code that fires it. A lean event set isn't just easier to read, it's genuinely cheaper to keep accurate over the life of the product.

We bring the five-event framework into the earliest product planning conversations, before a single screen is designed, since deciding what counts as the core action and what the meaningful onboarding steps are forces a founder to articulate their actual theory of the product clearly. More than once, walking through this exercise together has surfaced a genuine disagreement within a founding team about what the app's core loop even is, a disagreement far better surfaced in a planning conversation than discovered later through conflicting interpretations of ambiguous analytics data.

For most early-stage apps, a single, reasonably priced product analytics tool covering event tracking, funnel analysis, and basic retention charts out of the box is enough, and building a custom data warehouse pipeline at this stage is usually solving a scale problem the product doesn't have yet. We steer founders away from over-investing in analytics infrastructure early, since the actual bottleneck at this stage is almost always deciding what to track and act on, not the sophistication of the tooling doing the tracking, and a simpler tool adopted quickly beats a more powerful one still being configured months later.

We do flag one exception worth planning for even at this early stage: if a founder already knows the product will need to combine analytics data with other business systems eventually, billing records, a CRM, support tickets, it's worth checking that the chosen tool can export raw event data cleanly rather than locking it inside a proprietary dashboard. That single compatibility check costs almost nothing to verify upfront and can save a genuinely painful data-migration project later, once the product has grown enough that combining those data sources actually matters to a real business decision.

We schedule a short quarterly review of the original five events against how the product has actually evolved, since a core action that made sense at launch sometimes stops being the right thing to measure once the product's actual usage pattern becomes clear. An app that pivots its core loop without revisiting its analytics setup ends up tracking the old product's behavior long after the new one has taken its place.

This review takes under thirty minutes in most cases: pull up the five events, ask whether each one still maps to a decision the team is actually making, and retire or replace anything that's stopped being useful. It's a small enough habit that it rarely gets skipped once it's on the calendar, and it's what keeps the analytics setup accurate as the product itself changes shape over its first year.