The framework

Most SaaS teams have analytics. Few trust it.

The warning signs are always the same. Events get added as needs come up, with no overall plan. Tracking decisions get made in isolation. Six months in, the data doesn't quite line up with reality, and nobody trusts the numbers enough to base decisions on them.

The tools aren't the issue. Amplitude, PostHog, Mixpanel — they all work. What's missing is the system tying them together: a coherent way to decide what to track, when, how, and in what order.

This guide is that system. It's the reference I use on every project, and it's what I wish I'd had when I started doing this work.

#The trap

The default approach is to try to track everything at once. Map out every event, instrument every interaction, ship it all in one big sprint.

The result is predictable. Events misfire. User IDs go missing on half the events. Revenue numbers don't match Stripe. Some events fire client-side, some server-side, with no consistent rule for which. By the time you sit down to use the data, you've got a tangle nobody has the bandwidth to untangle. So you stop trusting it. So you stop using it. So nobody on the team checks the dashboards.

The fix isn't ambitious. It's the opposite: build less, but build it right.

#The four modules

This guide breaks analytics implementation into four modules. Each one is small enough to finish, validate, and start using before you move on. You don't have to wait until everything's perfect to get value.

Module 1 — Basic tracking. Install the SDK. Capture page views, device data, traffic sources, sessions. About an hour of work. Gives you traffic analytics immediately: where users come from, which pages they visit, how long they stay.

Module 2 — Authentication tracking. Identify users across sessions and devices. Without this, you can't measure retention, build user profiles, or distinguish ten users from one user who visited ten times. This unlocks the entire user-lifecycle layer.

Module 3 — Feature tracking. Measure how users engage with specific product areas. Which features get used. Which ones predict retention. Where users drop off in flows.

Module 4 — Revenue tracking. Connect behavior to money. Trial starts, conversions, renewals, cancellations. This is where analytics shifts from "what users are doing" to "what drives the business."

Each module takes one to two sprints. Each one is independently useful — Module 1 ships, you start getting value, then Module 2 builds on it.

#Why the order matters

These aren't arbitrary categories. Each module depends on the previous one.

Authentication comes after basic because identifying users is pointless if you can't track them at all. Features come after auth because anonymous engagement data has a ceiling — you can't measure retention or build cohorts without user IDs. Revenue comes last because revenue is the lens that gives engagement data meaning: knowing 500 people used a feature is interesting; knowing your highest-paying customers ignore it while churning users hit it constantly is actionable.

Skip the order and you'll spend the next year backfilling. Follow it and each module compounds on the last.

#How the guide is organized

The guide is split into two sections.

Concepts covers the ideas that apply regardless of which analytics tool you use. Event taxonomies. Naming conventions. Client-side vs. server-side tracking. Identifying users. Mapping payment webhooks to analytics events. Read these once and they apply forever.

Amplitude implementation walks through actually building each of the four modules in Amplitude. Future sections will cover PostHog and Mixpanel — the patterns translate, the code changes.

You can read straight through — that's the canonical path. Or jump to a specific chapter when you have a specific question. Each chapter opens with what it assumes you've already read.

#Who this is for

This guide is written for the person responsible for getting analytics to actually work in a SaaS product. Most often that's an engineer or technical PM, but the concepts section is written so anyone — analysts, marketers, founders — can read it and understand what's happening.

If you're implementing the tracking yourself, you'll use both sections. If you're writing requirements for an engineering team to implement, focus on concepts; share the implementation chapters with the engineers.

#A note for analysts and marketers

If you're not the one writing the SDK calls, you can skip the code examples. But your role in defining the requirements is critical.

Vague requests lead to incorrect implementation. Instead of asking developers to "track sign-ups," specify exactly when the event fires (on the confirmation page, only when registration succeeds), which user properties get set before it (account_type, email), and what happens on failure (a separate Sign-up failed event with the error type). The more precise you are about when, where, and under what conditions an event fires, the more accurate your data will be.

The concepts section — especially the chapters on event taxonomy and naming conventions — gives you the vocabulary to write those specifications.

#What you'll have when you're done

• Page views, sessions, and traffic data flowing reliably
• Users identified across sessions and devices, with retention analysis that actually works
• Feature usage tracked at meaningful state transitions, not random clicks
• Revenue events tied directly to Stripe webhooks — trial conversions, renewals, cancellations, expirations all firing correctly
• Dashboards that answer the questions your team actually asks: which channels convert, who's retaining, what drives revenue
• Data you trust enough to base decisions on

That last one is the actual goal. The rest is in service of it.

#A note on tools

This guide currently uses Amplitude as the implementation example. That's the tool I work with most often, and the patterns translate cleanly to PostHog and Mixpanel — same event-based model, same separation of events from user properties, same client/server trade-offs. When PostHog and Mixpanel chapters get added, the concepts section won't change.

If you're using something else — Heap, Segment, Pendo — the concepts section is still useful. The implementation chapters are Amplitude-specific, but the structure (what events to track, when to fire them, how to handle device and session IDs server-side) carries over.

#Where to start

If you're new to analytics implementation, read the concepts section first, then work through the implementation modules in order. Each chapter takes 5–15 minutes to read.

If you already have basic tracking in place and want to add authentication or revenue tracking, jump straight to those chapters. Each one tells you what it assumes you've already done.

If you want a single page to bookmark and come back to, the chapter on mapping Stripe webhooks to analytics events is the one. It's the most reference-heavy chapter and the one I look up most often myself.