The four-module framework

I've set up product analytics for dozens of SaaS companies. The same pattern shows up almost every time. Whatever the industry, the business model, or the tools a team picks, a product ends up needing the same four foundational layers, built in the same order. This guide is organized around that order.

It's written for the people who do the work. Founders setting up analytics for the first time, product managers who need numbers they can trust, and engineers wiring up the events. You don't need prior analytics experience. You do need the patience to build one module at a time instead of tracking everything at once.

The four modules, in the order you build them:

• Basic
• Authentication
• Feature tracking
• Revenue

#The four modules

Here's a short tour of each. The detailed setup lives in the Amplitude implementation section, where the worked code and configuration go.

#Basic

The first module gets the SDK installed and initialized correctly. Amplitude, PostHog, and Mixpanel all ship with a lot of behavior out of the box. Install the SDK and you get page view tracking, session replay, and autocaptured clicks without writing a single custom event.

The part that needs care is initialization. In a React app especially, you have to make sure the SDK loads once and survives re-renders. There's a long list of config options too, and which ones you set depends on your stack, for example how page views get counted when your app does client-side routing.

You get real insight from this module alone, before any custom events exist. The out-of-the-box page views and session replays already show you where people land and where they drop off.

#Authentication

The second module makes sure your analytics tool knows who each user is. Every user gets Sign-up, Sign-in, and Sign-out events, and you identify them with a stable ID the moment they sign in.

Everything downstream leans on this. Feature usage, revenue, and retention all assume each event belongs to one real person. Get identity wrong and the tool will split one user into several. Cookies expire, ad blockers wipe local storage, someone signs in from a second device, and now your user count is inflated and you can't tell whether three events came from three people or one.

Identifying users covers the concepts behind this.

#Feature tracking

The third module covers the features worth measuring with events. You work one functional area at a time, each as a self-contained piece.

Take invoicing software. Invoice creation is the core workflow, so you start there. When a user creates an invoice, you track it end to end, with the events and properties you'll actually use in analysis later. Finish that, verify it, then move to the next area, like adding a client or sending a reminder.

Depth beats coverage. Twenty features tracked badly tell you less than four tracked well. Which actions deserve an event and which to skip is its own decision, covered in Tracking on successful states.

#Revenue

The fourth module is the most involved. It puts revenue data into your analytics tool, so you can read every other chart through the lens of who actually pays.

You track the money-moving events, each carrying the right amount and currency. A purchase completes, a subscription starts, a subscription cancels. Done well, you can split any chart by paying versus free and see which behaviors separate the two. You can also find which features show up before someone converts and sticks around.

Most of this data comes from Stripe webhooks rather than the browser. Mapping Stripe webhooks covers the mapping, and Stripe revenue tracking covers the implementation.

#Why this order

Two things drive the order. Each module needs the one before it, and building them in small batches keeps the work clean.

#Each module depends on the last

The first module is self-explanatory. Nothing works until the SDK is installed.

Authentication gives you a stable identity for every user, so the tool records events for one person instead of inventing two or three. Without it, you can't tell whether your numbers describe real users.

Feature tracking sits on top of authentication. Every "Invoice created" or "Customer dropdown opened" is tied to the real person who did it, which is the only reason usage analysis means anything.

Revenue sits on top of feature tracking. Once usage events are reliable and tied to users, you can compare how paying users behave against everyone else and steer the product toward the behavior that leads to revenue.

#Smaller batches, fewer mistakes

It's easier to align a team and ship when you're focused on a handful of events instead of a list of twenty you're implementing all at once.

Each module has its own quirks and failure modes, and they're easier to spot when you're looking at one module at a time. Verifying Sign-up, Sign-in, and Sign-out is straightforward when you're not also debugging feature events and revenue in the same pass.

When a module is tested and signed off, the team stops re-checking it. By the time you reach revenue, nobody is still wondering whether authentication fires correctly, because that question was closed two modules ago.

#After the foundation is in place

The four modules get you a foundation. The work doesn't stop when they're done.

Feature tracking keeps going. Every new feature gets events, every changed feature gets its events updated, and every removed feature gets its tracking pulled out so it doesn't linger as dead data.

Revenue tracking moves whenever your pricing does. Change a plan or a billing model and the events have to follow, or the numbers drift away from reality without anyone noticing.

This ongoing work is where a strict event taxonomy earns its keep. A naming convention the whole team follows, an agreed set of properties, and the habit of updating tracking alongside the feature keep new events from muddying the data you already trust.

Event taxonomy and Naming conventions cover how to set this up.

#Where to start

Start with the Concepts section. It covers events, properties, and user identity, the building blocks every module here assumes you understand. If you already work with a tool like Amplitude, go straight to Setting up Amplitude and build the first module.