Startup Analytics Stack: What to Track From Day One

You do not need a data team to make good product decisions, but you do need the right handful of numbers from the very first week. This guide shows you how to build a lean startup analytics stack: which events to track, how to name them so they stay useful, which tools to look at and how to keep the whole thing honest and privacy-friendly.

A person typing on an open laptop placed on a black table, working on a digital project — A good analytics setup starts with a short list of questions, not a long list of tools.

Key takeaways

Start with 3 to 5 questions about your business, then track only the events that answer them.
A lean stack has four layers: website traffic, product events, revenue data and a simple place to review it all.
Write a tracking plan before you add any code, and use one consistent naming style for every event.
In the UK and EU, analytics cookies and similar tracking usually need consent, so plan your banner and privacy notice from day one.
Review your numbers on a fixed weekly rhythm, or the dashboards will quietly gather dust.

Most early founders fall into one of two traps. Some track nothing and run on gut feeling until a board member or investor asks a question they cannot answer. Others install every tool they read about, fire hundreds of events and end up with dashboards nobody trusts. Both groups end up guessing.

The fix is a small, deliberate setup that grows with you. In early May, as many teams settle into their second quarter plans, it is a good moment to look at what you measure and tidy it up. Whether you are pre-launch or a few months in, the steps below will give you a stack you can actually use.

Start with questions, not tools

Before you open any analytics product, write down what you need to know. Data only helps when it answers a decision you are about to make. For most early startups, the questions look something like this:

Are people finding us? Where visitors come from and which channels bring people who sign up.
Do they get value quickly? How many new signups reach the moment where your product clicks for them.
Do they come back? Whether users return in week two, week four and beyond.
Do they pay? How many move from free or trial to paid, and how fast.
Where do they get stuck? The step in signup, setup or checkout where most people drop off.

Pick the three to five questions that matter most right now. If a number would not change what you build, sell or fix next month, you probably do not need to track it yet.

Pro tip

Write your questions at the top of your tracking plan document. Every time someone asks to add a new event, check it against that list. It is the easiest way to keep your analytics lean.

The four layers of a lean analytics stack

You can think of a startup analytics stack as four simple layers. Early on, each layer can be one tool, a spreadsheet or even a single report.

1. Website and acquisition analytics

This layer tells you how people arrive: which pages they land on, which campaigns or referrers send them and how many reach your signup page. Google Analytics 4 is a common free starting point for marketing sites. Add consistent UTM tags to links in emails, social posts and ads so your sources show up cleanly instead of lumping into "direct" or "other."

2. Product analytics

This is where you learn what people do inside your product. Product analytics tools record events such as "project created" or "invite sent" and let you build funnels, retention charts and user paths. Tools you could look at include Mixpanel, Amplitude and PostHog, and GA4 can also handle basic product events. Each has a different approach to pricing, hosting and data limits, so check current features, pricing and privacy policies before you choose.

3. Revenue and billing data

Your payment or billing system is usually the most reliable source for money numbers: new paying customers, cancellations, refunds and monthly recurring revenue if you sell subscriptions. Resist the urge to recreate revenue figures from product events. Pull them from the system that actually takes the money, and reconcile with your accounting records.

4. A place to review it all

Finally, you need one place where the key numbers sit side by side. For most early teams, a simple spreadsheet updated weekly works better than an elaborate dashboard. It forces someone to look at the numbers, and it makes trends obvious. You can automate it later, once you know which numbers you keep returning to.

3 to 5 A practical number of core questions to start your analytics around, so every tracked event has a clear purpose Rule of thumb

What to track from day one

Here is a starter set of events and numbers that fits most software and online businesses. Adapt the names to your product, but keep the spirit: a few events that cover the whole customer journey.

Acquisition

Visits to your site by source and campaign
Signup page views and completed signups
Waitlist or demo request submissions if you are pre-launch

Activation

Activation is the moment a new user first gets real value. For a scheduling tool, that might be the first booking received. For a design tool, the first file exported. Define one clear activation event and track the share of new signups who reach it within a set number of days.

Engagement and retention

A "key action" event that shows someone is using the core feature
Weekly or monthly active users, defined by that key action rather than by simple logins
Retention by signup cohort: of the people who joined in a given week, how many are still active later

Revenue

Trial started, plan upgraded, plan downgraded and subscription cancelled
Payment failed, so you can spot billing problems early

Common mistake

Counting logins as engagement. People log in for many reasons, including to cancel. Tie "active" to the action that delivers value, such as sending an invoice or publishing a page, so your active user count reflects real use.

A computer screen displaying an analytics dashboard with charts, graphs and summary figures — A dashboard is only as good as the events behind it, so plan those first.

Write a tracking plan before you write code

A tracking plan is a shared document that lists every event you collect, what it means, when it fires and which details it carries. It sounds like paperwork, but it saves hours of confusion later when someone asks why two charts disagree.

List your questions. Copy the three to five questions you chose earlier to the top of the plan.
Map the journey. Sketch the steps a customer takes from first visit to paying and returning.
Choose one event per important step. Keep the list short. Ten to twenty well-defined events will cover most early products.
Agree on a naming style. For example, "object action" in lowercase with underscores: "project_created", "invite_sent", "plan_upgraded."
Add properties. Note the extra details each event carries, such as plan type or signup source. Avoid personal data you do not need.
Name an owner. One person approves new events and keeps the plan current.
Test before you trust. Fire each event in a test account and confirm it shows up once, with the right properties.

A simple tracking plan template

Copy this table into a spreadsheet and add one row per event. The rows below are examples for a made-up invoicing app.

Event name	What it means	When it fires	Key properties	Question it answers	Owner
signup_completed	A new account was created	After email is confirmed	signup_source, plan	Are people finding us?	Founder A
invoice_sent	User sent their first or any invoice	When the send button succeeds	is_first, invoice_count	Do they get value quickly?	Founder B
plan_upgraded	User moved to a paid plan	After payment is confirmed	old_plan, new_plan	Do they pay?	Founder A

Keep the plan next to your code or in your team wiki, and update it in the same week any event changes.

Hypothetical example

Imagine Sam and Leila, co-founders of a small booking app. In their first month they tracked 60 events because their analytics tool made it easy. When an investor asked how many new users made a booking in their first week, they found three similar events with different meanings and could not give a clear answer. They paused, wrote a tracking plan with 14 events, defined "booking_confirmed" as their activation event and deleted the rest from their reports. Two weeks later they could answer the question in under a minute.

Privacy, consent and data hygiene

Analytics involves personal data more often than founders expect. IP addresses, device identifiers and user IDs can all count. Getting this right early is far easier than cleaning it up after launch.

Consent in the UK and EU. Non-essential cookies and similar tracking, including most analytics, generally need the visitor's consent under UK and EU rules such as PECR and GDPR. Set up a clear consent banner and make sure your tools only load after consent where required.
Clear privacy notices. Tell people which tools you use, what you collect and why, in plain language.
Collect less. Do not send names, email addresses or payment details into product analytics unless you have a strong reason and a lawful basis.
Check where data is stored. Some tools offer EU hosting or self-hosting. If you sell to European customers, it may matter to them.
Separate test data. Use a separate project or filter for internal and test accounts so your team does not inflate the numbers.

This section is general information, not legal advice. Privacy rules differ by country and change over time, so check the official guidance from your data protection regulator and speak to a qualified privacy professional if you handle sensitive data.

Common mistake

Copying an analytics snippet onto your site before the consent banner is ready. If your visitors are in the UK or EU, that can mean collecting data without consent from your very first day. Launch the banner and the tracking together.

Build a weekly review habit

The best analytics stack in the world is useless if nobody looks at it. Set a fixed 30-minute slot each week, ideally the same day and time, to review your core numbers as a team.

Update the weekly sheet. Add this week's figures for traffic, signups, activation rate, active users and new paying customers.
Compare with last week and last month. Look for big jumps or drops, not tiny wiggles.
Ask why. Link any change to something you shipped, a campaign you ran or a data problem.
Pick one action. Decide on one experiment or fix for the coming week based on what you saw.
Log it. Write the decision in the sheet so you can see later whether it worked.

When to add more tools

Your stack should grow only when a real question cannot be answered with what you have. Common signals that it is time to add something include:

You need to combine data from several systems and the spreadsheet is taking hours each week.
You want session recordings or heatmaps to understand a confusing page, and you have the consent setup to support them.
You run enough A/B tests that a dedicated experimentation feature would save time.
Your team has grown and several people need self-serve access to reports.

Before you add a tool, write down the question it answers and who will own it.

Your analytics stack checklist

Write your 3 to 5 core business questions
Map the customer journey from first visit to paying and returning
Choose one tool per layer: website, product, revenue and review
Define one activation event and one key action
Create a tracking plan with a consistent naming style
Set up a consent banner and privacy notice where required
Filter out internal and test accounts
Test every event before relying on it
Book a 30-minute weekly review and keep notes

Frequently asked questions

Do I need product analytics before launch?

Not necessarily. Before launch, website analytics and a simple record of waitlist signups are often enough. Add product analytics in the weeks before your first real users arrive so you capture their behavior from the start.

Can I use just one tool for everything?

For a while, yes. Some tools cover both website and product events. The main thing is to keep revenue numbers tied to your billing system and to review everything in one place. Split tools only when one clearly cannot answer your questions.

How many events should we track?

There is no fixed number, but many early products do well with 10 to 20 clearly defined events. More events mean more maintenance and more chances for confusion, so add new ones only when they answer a real question.

Is it a problem if our numbers differ between tools?

Small differences are normal because tools count sessions, users and time zones differently, and consent choices affect what is collected. Pick one source of truth for each number, note it in your tracking plan and stick with it.

The bottom line

A startup analytics stack does not need to be big to be useful. Start with a few sharp questions, track the handful of events that answer them, keep revenue numbers tied to your billing system and review everything together once a week. Build consent and privacy into the setup from day one, especially if you serve UK or EU visitors.

Spend an afternoon this week writing your tracking plan. It is a small investment that will make every future product, marketing and fundraising conversation clearer and calmer.