What should an MVP track?

Only what supports a decision. For most MVPs that means ten to twenty named events covering the steps from sign-up to the activation moment, the one repeated action that shows the product is delivering value, and enough context to see which audience or channel each user came from.

What is activation in product analytics?

Activation is the moment a new user first gets the value the product promises, such as a student opening their first generated lecture summary. It is specific to each product, should be written down in one sentence, and is a far better early signal than sign-ups.

Should we build our own analytics for an MVP?

Usually not. An off-the-shelf product analytics tool is enough for a first version. The engineering effort belongs in a clean tracking plan, server-side events for important outcomes and consistent user identity, plus making sure the account is in your company's name and raw data can be exported.

Product Analytics for an MVP: What to Track Before You Launch

Q: When should analytics be added to an MVP?

Before launch, as part of the build. The tracking plan should be written alongside the feature list so activation and the events that measure it are agreed before development starts. Analytics added after launch tends to slip and the first weeks of real data are lost.

TL;DR: An MVP exists to answer a question: does this solve a real problem for a specific person, well enough that they come back? Product analytics is how you get that answer instead of an opinion. You do not need a data team or a dashboard wall. You need a written list of the decisions the data should inform, a short tracking plan of ten to twenty named events tied to the core loop, consistent user identity across devices, and three numbers someone actually reviews every week: activation, retention and the one action that means the product delivered value. Wire it before launch, keep it honest, and resist tracking everything.

Most MVPs launch with either no analytics at all or a default install that records page views and button clicks nobody will ever read. Both leave the founder guessing on the one question the MVP was built to answer. This guide is for founders and product owners planning a first version who want to know what to measure, how much of it to build, and what usually goes wrong.

Start with decisions, not events

The most common mistake is opening an analytics tool and asking "what should we track?" The better question is "what will we decide in the next three months, and what would change our mind?"

Write down the decisions first. For a typical MVP they look like this:

Is the core loop working? Do people who sign up reach the moment where the product does its job?
Where do people drop off? Which step between install and that moment loses the most people?
Do they come back? Of the people who got value once, how many return without being prompted?
Which audience or channel is worth doubling down on? Do users from one source behave differently from another?

Every event you track should help answer one of these. If an event does not map to a decision, it is noise you will pay for later in cleanup, storage and confusion. We use the same discipline when we take products from idea to live users, which we describe in launching a software product.

Define activation before you write any code

Activation is the moment a new user first gets the value the product promises. It is the single most useful definition you can make, and it is specific to your product.

A few examples from products we build and run:

LectureNotes AI records lectures and turns them into summaries and outlines. Signing up is not activation. Activation is a student opening their first generated summary of a real lecture.
Lifemaxxing AI builds personalized self-improvement plans. Activation is closer to a user receiving their plan and logging the first piece of progress against it, not finishing onboarding.
Fyuel, an accounting platform for the fuel trade, is a business tool. Activation there looks like a company getting real customers, suppliers and transactions into the system, because a ledger with nothing in it has not delivered anything.

Notice that none of these are "created an account" or "viewed the dashboard." Pick the action that means the product worked, write it down in one sentence, and make sure everyone on the team agrees. Then track every step that leads to it.

Write a tracking plan

A tracking plan is a short document, usually a spreadsheet, that lists every event the product sends, when it fires, and what properties it carries. It is the difference between analytics you can trust and a pile of inconsistently named clicks.

For an MVP, keep it small. Ten to twenty events is plenty. A useful plan has:

Event name in a consistent format, such as summary_viewed or plan_created, always past tense, always the same style.
When it fires, described precisely. "When the summary screen finishes loading with content" is better than "when the user sees the summary."
Properties that add context, such as the plan type, the platform, or how the user arrived.
Where it fires, on the device or on the server.
Which decision it supports, so nobody adds events without a reason.

Track outcomes on the server when you can

Events that record something the product did, such as a payment succeeding, a summary being generated or an invoice being saved, are more reliable when they are sent from your backend. Device-side tracking can be blocked, lost when a user goes offline or duplicated when an app retries. Keep device events for things only the interface knows, such as which screen a user abandoned.

Name things for humans

Six months from now, someone new will read these events. btn_click_3 tells them nothing. checkout_started with a plan property tells them everything. Good naming costs nothing at build time and saves real hours later.

Get identity right early

Analytics breaks quietly when the same person looks like three different users. This happens when someone browses anonymously, signs up on the web, then logs in on their phone.

Decide early how you will:

Link anonymous activity to an account once someone signs up, so the steps before registration still count toward their journey.
Recognize one person across web and mobile, usually by using your own user ID rather than a device ID.
Handle teams and accounts if you sell to businesses. For a B2B tool like Fyuel, you often care about whether a company activated, not just whether one person did, so events need to carry an account or organization ID as well.

Fixing identity after launch usually means your early data, the data from your most important period, cannot be fully trusted. It is a small decision with a long tail.

The three numbers to review every week

You can build an elaborate dashboard, but early on, three numbers do most of the work.

Activation rate

Of the people who signed up in a given week, how many reached the activation moment? This tells you whether your onboarding and first experience work. If it is low, look at the funnel between sign-up and activation to see where people stop.

Retention by cohort

Group users by the week they signed up and see how many come back in the following weeks. A cohort chart is more honest than a total user count, because a growing total can hide the fact that each new group is leaving just as fast as the last. Retention is the number that tells you whether the product solved something.

The core value action

Pick the one repeated action that means the product is delivering value: summaries viewed, plans updated, transactions recorded. Watch how often active users do it. This is usually a better health signal than daily active users, because people can open an app without getting anything out of it.

Put these three in front of the team at the same time every week. A number nobody looks at is not a metric, it is storage.

Qualitative signal still matters

Numbers tell you what is happening. They rarely tell you why. In an MVP, where you may have dozens or hundreds of users rather than millions, the why is often more useful.

Pair analytics with:

Short conversations with users who activated and with users who dropped off.
Session recordings on key flows, if your privacy approach allows it and users have been told.
One in-product question at the right moment, such as after the first summary or the first completed plan.

When the data and the conversations disagree, investigate rather than picking the one you prefer.

Privacy and consent are part of the design

Analytics tools collect personal data, and the rules depend on where your users are. Before launch, decide what you collect, whether it is linked to an identifiable person, how long you keep it and how users can opt out or delete their data. Avoid sending sensitive content, such as the text of a user's notes or financial details, into third-party analytics at all.

On mobile, these choices also have to match the privacy disclosures you make to Apple and Google, including what your analytics library collects. We walk through that side in the app store release process. For AI features, the same care applies to what you log from prompts and outputs, which we cover in adding AI to an existing product.

Build, buy or keep it simple

For most MVPs, an off-the-shelf product analytics tool is the right choice. Building your own event pipeline and dashboards is rarely worth it before you know whether the product has users. The engineering effort belongs in the tracking plan, the server-side events and identity, not in charts.

A few practical guidelines:

Pick one tool, not three. Multiple tools with slightly different numbers create arguments rather than decisions.
Make sure you own the data. The account should be in your company's name, and you should be able to export raw events. This is part of the same principle we describe in software ownership and handover.
Check what it costs as you grow. Many tools price by event volume, which is another reason not to track everything.
Add feature flags alongside analytics if you plan to test variations, so you can compare groups cleanly.

Common mistakes

Tracking everything by default. Auto-captured clicks feel thorough but bury the signal.
Adding analytics after launch. It quietly slips, and the first weeks of real data are lost.
Celebrating sign-ups. Acquisition can be bought or borrowed for a week. Coming back cannot.
Never testing the events. Events break when screens change. Include them in your QA checklist, as described in software testing and QA.
No owner. If no named person reviews the numbers weekly, the setup decays.

How it fits into the build

Instrumentation is not a separate project. It is a few days of deliberate work inside the MVP build, done alongside the core features, and it is much cheaper to do then than to retrofit later. When we scope a first version, the tracking plan is written with the feature list, so the definition of activation and the events that measure it are agreed before development starts. If you are budgeting a first version, what an MVP costs covers the wider picture, and our ship-in-days playbook explains how we build quickly without skipping this kind of groundwork.

Questions to ask your development team

What decisions will our analytics help us make in the first three months?
What is our activation moment, in one sentence?
Where is the tracking plan, and who owns it?
Which events fire from the server, and which from the device?
How do we connect a user's activity across web, mobile and before sign-up?
Who reviews activation, retention and the core value action each week?
What personal data do we collect, and is any of it sensitive?
Do we own the analytics account and can we export the raw data?

The bottom line

An MVP is an experiment, and analytics is how you read the result. Define activation, write a short tracking plan around the core loop, get identity right, send important outcomes from the server and review three numbers every week. Do that before launch and you will know, rather than hope, whether your first version is working and what to build next.

Planning an MVP and want to know from the first week whether it is working? Book a demo and we will scope the build and the tracking plan together. See our work: LectureNotes AI, Lifemaxxing AI, Fyuel, Covoisino, Raqts and more.