SaaS Analytics Stack by ARR Stage: What to Instrument When

Analytics infrastructure has a tendency to grow in the wrong direction: teams at $200K ARR build data warehouses they will not need for three years, and teams at $8M ARR are still making product decisions off a single GA4 dashboard that cannot answer a cohort question. The right analytics stack is not the most sophisticated one you can afford — it is the one that answers the questions your current stage actually requires. The questions change as you scale, and so should the instrumentation.

$0–$1M ARR: three questions, minimal infrastructure

At the pre-revenue and early-revenue stage, the analytics questions that drive the most decisions are: where are signups coming from, are users completing onboarding and reaching first value, and what does the first week of usage look like for users who retain versus users who churn immediately. These three questions do not require a data warehouse, a CDP, or a product analytics platform. They require a web analytics tool that captures acquisition source accurately, a handful of server-side events for the activation moment, and a lightweight query against those events.

The instrumentation error at this stage is over-building. Founders who have read about product-led growth implement PostHog or Amplitude before they have 50 active users, then spend weeks configuring dashboards that have no data to populate. The overhead is not just setup time — it is the ongoing cost of maintaining event schemas and debugging instrumentation when the product is changing weekly. At sub-$1M ARR, the right move is the simplest stack that gives you reliable acquisition data and a clear signal on whether your activation path is working. You can distinguish web analytics from product analytics and buy only what the current decision set requires.

$1M–$3M ARR: add product event tracking

Once you have cleared $1M ARR and have north of 50-100 active users per month, the questions shift from "is the acquisition working" to "why are some users retaining and others churning in week two." Answering this requires user-level event data: not just that a user logged in, but which features they touched, in what order, and whether they reached the moments you know correlate with retention. This is when a lightweight product analytics layer starts paying for itself.

The key decision at this stage is how many events to track. The answer is fewer than you think. Start with the activation event, the two or three core actions that define active usage, and the event that precedes conversion to paid. Track those consistently before adding anything else. A five-event schema you query every week is worth more than a fifty-event schema you configure once and never open. The instrumentation discipline that compounds is tight, well-named events tied to specific product hypotheses — not comprehensive coverage of every click in the UI. See how this connects to the product metrics that predict growth to frame which events to prioritise first.

$3M–$10M ARR: cohort retention and segmentation

The $3M-$10M ARR band is where the retention problem becomes the central analytics problem. You have enough users to see cohort patterns clearly, and the difference between 60% six-month retention and 80% six-month retention is the difference between a business that needs constant acquisition to cover churn and one that compounds. At this stage the analytics investment that pays back most reliably is cohort retention analysis — not feature analytics, not attribution modeling, not NPS dashboards.

Cohort retention analysis requires two things: consistent event tracking (you need at least three to six months of clean event history) and a way to define active and inactive that matches your product's usage model. A tool used daily has different retention curves than one used monthly, so the benchmark you compare against matters less than the shape of your own curve over time. The useful question is not "what is our D30 retention" but "is the cohort from three months ago retaining better or worse than the cohort from six months ago, and what changed between them." Answering that requires good event data and cohort-aware querying, which a basic web analytics tool cannot provide.

$10M+ ARR: attribution, NRR analytics, and the full stack

Above $10M ARR, the acquisition spend is large enough that channel attribution decisions have material budget implications, and the customer base is large enough that expansion revenue analytics — tracking net revenue retention, upgrade triggers, and expansion paths — starts to outweigh new acquisition in terms of revenue impact per analytic insight. This is when a full-stack investment in attribution tooling, a proper data warehouse, and NRR measurement makes sense.

Attribution at this stage means going beyond last-click reporting in GA4 and building multi-touch models that account for the full buying journey. B2B SaaS buying cycles often span weeks or months across branded search, review sites, content, and direct traffic — none of which last-click models represent accurately. The full-funnel attribution framework for SaaS lays out how to approach this without over-engineering the solution. NRR analytics requires joining product event data with billing data — a data warehouse is now justified, and the query patterns that matter are expansion by cohort, feature-to-upgrade correlation, and churn prediction from engagement signals.

The tool selection logic at each stage

Tool selection should follow the measurement questions, not the other way around. At the seed stage, a lightweight privacy-friendly web analytics tool plus server-side event logging to your database of choice handles the decision set. You do not need a full product analytics platform, a session replay tool, or a data warehouse. At the growth stage ($1M-$10M), a product analytics layer becomes worth the overhead — the question is whether you buy a standalone tool or add product analytics to your existing web analytics setup. The all-in-one suite versus best-of-breed decision turns on how much engineering time you can dedicate to integration and maintenance versus how much you need a single coherent data model across acquisition and product.

At scale, the components converge: a web analytics tool for acquisition and traffic measurement, a product analytics layer for behavioral data, a data warehouse for cross-cutting queries, and an attribution platform when paid spend justifies the modeling overhead. The mistake at every stage is buying for the stage two levels above you. A $500K ARR SaaS buying Amplitude and Segment is not investing in future capability — it is generating instrumentation debt and spending engineering time on infrastructure that does not answer any question the current stage requires.

What good ARR-stage instrumentation looks like in practice

Concretely: at seed, you instrument three events (trial started, activation event fired, payment completed) and query them weekly. At growth, you expand to ten to fifteen events covering the core product usage loop and run cohort retention queries monthly. At scale, you build a full event taxonomy, connect it to billing data, and run attribution and NRR analysis on a regular cadence. Each phase represents a meaningful jump in instrumentation investment — and each jump is only justified when the previous phase's questions are answered reliably and the new phase's questions are driving decisions.

The discipline that makes this work is writing down what question each event or dashboard is supposed to answer before you build it. "We track feature_X_used because we want to know whether users who use feature X in their first week retain at higher rates" is a good reason to add an event. "We track feature_X_used because we might want to know about it someday" is not. The teams with the best analytics at each ARR stage are rarely the ones with the most events — they are the ones with the clearest link between what they track and what decision it informs.