Product Analytics for an Early SaaS: Track Less
By CodexierPublished 5 min read
Most early SaaS teams either track nothing and guess, or track every click and drown. Neither tells you whether people get value from the product. With a few dozen or a few hundred users, the useful approach is small: write down the questions you need answered, track only the events that answer them, name those events consistently and look at them every week. This guide shows how, and how to stay on the right side of GDPR while you do it.
Questions before events
Good early questions are about activation and retention. Do sign-ups finish setup? How long until they do the thing the product exists for? Do they do it again the next week? Which features do paying customers use that trial users do not? Each question points to a few events. If an event does not help answer any question, leave it out; you can add it later, and unused events only add noise and personal data you have to justify.
A minimal event plan
| Event | Answers | Useful properties |
|---|---|---|
| account_created | How many sign-ups, from where | plan, signup_source |
| onboarding_completed | Do sign-ups finish setup? | steps_skipped, time_to_complete |
| core_action_completed | Did they reach first value? | action_type |
| teammate_invited | Is the product spreading inside the customer? | role |
| subscription_started | Which path leads to paying? | plan, billing_period |
| subscription_cancelled | Who leaves and when? | reason, tenure_days |
Replace core_action_completed with your product's own key action: report_generated, invoice_sent, booking_created.
- Name events as object plus past-tense action, in lower case with underscores, and never rename them casually.
- Keep a tracking plan in a shared document: event name, when it fires, properties, owner.
- Send important events from the server, not only from the browser, so blockers and closed tabs do not lose them.
- Use an internal user ID, not an email address, as the identifier in the analytics tool.
Tools and privacy
Product analytics tools such as PostHog, Mixpanel and Amplitude all offer EU data residency, and PostHog can also be self-hosted. Choose based on where the data is stored, whether you can sign a data processing agreement, and whether the free tier covers your volume. Under the Swedish electronic communications rules, storing or reading identifiers on a user's device requires consent unless it is strictly necessary for the service, and analytics usually is not. Our guide on GDPR for SaaS founders covers the wider picture.
Server-side events
Events about actions in your own backend, such as a subscription starting, can be recorded without any browser tracking at all, as part of running the service.
Consent for client tracking
Session-level browser analytics and recordings need consent. Respect the choice in the tool configuration, not just in the banner.
Minimise properties
Never send free-text fields, names or email addresses as event properties. They end up in places that are hard to delete from.
Funnels and retention
Two views answer most early questions. A funnel from account_created through onboarding_completed to core_action_completed shows where new users stop. A retention view shows what share of each week's sign-ups perform the core action again in the following weeks. With small numbers, look at individual users as well: a list of the last twenty sign-ups and what each did tells you more than a chart built on twenty data points.
- Build the activation funnel and note the biggest drop.
- Build weekly retention by sign-up cohort for the core action.
- Compare paying and non-paying users on which features they use.
- Talk to five users from the biggest drop-off before you change anything.
Reviewing data weekly
Analytics that nobody looks at is a cost with no return. Set a fixed thirty-minute slot each week: check the funnel, the newest cohort's retention and anything unexpected, then write one or two decisions in a shared log. Over a few months that log becomes the most valuable product document you have, because it links what you changed to what happened.
When you do not need outside help: if you have a developer on the team and a clear list of questions, the setup is a few days' work and you can do it yourselves with this guide. Help pays off when nobody owns tracking, events are already messy or consent is unclear. Our tracking and analytics setup delivers a tracking plan, implementation and consent configuration; see pricing or book a call.
Frequently asked questions
Is Google Analytics enough for a SaaS product?
GA4 is built for websites and marketing attribution. It can track product events, but user-level funnels and retention are easier in a product analytics tool. Many teams use GA4 for the marketing site and a product tool inside the app.
How many events should we track at the start?
Ten to twenty is plenty for an early product. Each should answer a question you have written down. It is far easier to add events than to clean up a tracking plan with hundreds of inconsistent ones.
Do we need consent for product analytics inside a logged-in app?
If the tool stores or reads identifiers on the user's device and the tracking is not strictly necessary to deliver the service, consent is required. Server-side recording of business events that are part of running the service is a different case, but still needs a legal basis under GDPR.
When should we invest in a data warehouse?
When questions start to need data from several systems at once, such as billing, CRM and product usage together. Before that, a product analytics tool and your billing system's reports are enough.
Get a tracking plan that answers real questions
Bring your product and the questions you cannot answer today. In fifteen minutes we can sketch the events you need and tell you whether you can set them up yourselves.
Book a free 15-minute call