Are Users Actually Using What You Built? A Founder's Guide to Product Analytics After Launch

Overview

Your product is live, but sign-ups alone cannot tell you whether users get value from it. This guide shows how to choose a small set of defined measures, record them cleanly, read them without overstating them, and act on them.

Key Points

• Measure whether eligible users reach value, return, and finish the core journey — with counts beside every rate.
• The five measures are a suggested starting set, not a universal list.
• You may not need a separate product analytics platform: Google Analytics 4 also records events and journeys.
• Agree a tracking plan, and quality-check it pre-release for duplicates, failed actions, and test traffic.
• Settle privacy first: UK consent is the default for non-exempt analytics; the statistical exception covers aggregates, not individuals.

The short answer

Product analytics answers questions about what users do: where they start, whether they reach value, where recorded completion falls, and whether they come back. Its answers are only as good as the questions, the definitions, and the events recorded.

Start before any tool is chosen: write down the actions that suggest a user has received value, and the steps leading to them. Products often have several important workflows; begin with the most important.

Start from the value, not the dashboard

Start with the GOV.UK Service Manual approach: begin with the service's purpose and the needs it meets, derive a small number of benefits, and only then decide what to measure. The Manual warns against relying on digital analytics alone, and recommends combining measures with user research: numbers show where recorded completion falls, but not why.

Work through these questions first:

• What core action delivers value, in the user's own terms — and which other workflows matter?
• What must a new user do first to reach it?
• What would a returning user do to show the product is still useful?
• What outcome would worry you, even while sign-ups rise?

Keep the answers to one page. Disagreement about the core action is settled through research and discussion, not via a dashboard.

Tools overlap: the question decides

The familiar split — 'web analytics' for page views, 'product analytics' for the rest — does not hold. Google Analytics 4 is event-based, and Google's guidance uses funnel exploration to follow a form step by step, including drop-off between steps. Product analytics platforms offer their own event models and retention views; the same signed-in workflow can often be recorded in either.

What differs is the question and instrumentation: events recorded, how users and accounts are identified, and whether analysis follows individual journeys or aggregate patterns. Choose tools by analysis needs, usability, privacy, integration effort and cost.

Five measures to start with

This is a suggested starting set, not one that suits every product. For each rate, state the counting unit (user, or account in business-to-business software), the eligible denominator, the window, and the qualifying action. Report counts beside rates; distrust small or incomplete cohorts.

• Activation: eligible new users (or accounts, where the account buys) completing a stated value action in a stated window — say, a first project within seven days. A hypothesised indicator of value, checked against retention, not proof of value delivered.
• Retention by cohort: each sign-up group's share performing a meaningful return action — the core action, or another you define — in a later interval such as week four. Compare only cohorts old enough to complete it.
• Feature adoption: eligible active users or accounts using a feature in a stated period (available, and relevant to their plan or role). Judge frequency by natural need: a one-off feature, such as a year-end export, may succeed with a single use.
• Journey completion: report whole-journey conversion (starters finishing every step) and step-to-step conversion separately. A fall between steps shows where completion drops, not why users stopped; that needs observation, support evidence or conversation.
• One guardrail: a measure chosen to reveal harm from the decision at hand — failed payments beside a checkout change, say. Normalise it where customer numbers change (support requests per 100 active accounts), so growth does not distort it.

These measures describe product use; AI output quality is separate (see our guide to measuring AI performance after launch). Add measures only for real questions; one without an immediate decision may be context, not a priority.

One headline number, handled with care

Many teams choose one headline number — often called a north star metric — capturing the core value delivered. Used well, it aligns the team; used carelessly, it trains them to optimise for the number instead of the customer. A recommended way to test a candidate:

• If it rises, are customers genuinely better off, or could it rise with their experience unchanged?
• Could the team inflate it cheaply, for example by prompting clicks that add no value?
• Does it help the team decide what not to build, as well as what to build?
• Would it still describe success in a year's time?

Let it change as the product matures, explaining why and running old and new side by side; treat it as a focus for discussion, not proof.

Make the numbers trustworthy

Poorly defined tracking produces confident arguments from unreliable data, so agree a tracking plan before release. Mixpanel's documentation recommends object-verb snake_case naming, such as project_created — one convention, not a universal rule: respect prescribed platform names and parameters, and be consistent.

A workable plan for one feature covers:

• The event name and exact trigger; success events reflect completed actions — sign-up fires on registration success, not form display.
• Properties carrying detail, rather than separate event names: one purchase event with a plan property.
• Anything never to record, such as passwords or payment details.
• An owner, and what happens when the event's meaning changes.

Keep the plan where it will be maintained — inside the feature specification is one approach; a maintained register can serve equally. Before release, quality-check in a test environment:

• Each event fires once — no duplicates from retries or double submissions.
• Failed actions are not counted as successes.
• Required properties are present, and user and account identification is consistent.
• Test and internal traffic is excluded or marked; no unplanned events.

For an existing product, record pre-change values: before-and-after comparison aids judgement, but alone does not establish causation. At a first launch, a comparable real-user baseline may not exist — say so. Staging and team activity is not customer evidence.

Read the numbers honestly

Numbers mislead without context. Averages hide mix changes: if casual users leave, average session length can rise while the product shrinks. Cumulative totals can conceal recent deterioration inside a still-rising total, although a slowing growth rate or plateau can still be informative. One good week proves little without a baseline and a trend.

Three habits help: segment before acting on an average (new versus returning users; device or plan where behaviour plausibly differs); read cohorts, not just totals; and pair numbers with another source — support requests, observation, a short conversation — before acting on one measure alone.

A hypothetical illustration, with no real company implied: after a redesign, a scheduling tool's headline number rises, cohort retention is flat, and rescheduling support requests grow. That establishes neither that more users reached a frustrating step nor that the redesign caused anything; who signs up, seasonality, pricing, or tracking could each contribute. It justifies investigation, not a conclusion.

Privacy and consent are part of the setup

UK PECR (Privacy and Electronic Communications Regulations) applies where analytics stores or accesses information on devices; UK GDPR also applies where personal data is processed. The ICO's guidance on the PECR rules states the starting position: tell users about the technologies used, and obtain prior consent to the UK GDPR standard unless an exception applies; consent means a clear affirmative action — not continued browsing or pre-ticked boxes.

The ICO's guidance on the exceptions sets out a narrow statistical-purposes exception: the sole purpose must be collecting statistics about how the service is used, to improve it. Give users clear, comprehensive information and a simple, free means of objecting; unlike consent, required beforehand for non-exempt analytics, the exception works through information plus no objection. Outputs must be aggregate and non-identifying, and individual-level information must not be kept beyond aggregation.

The exception therefore limits much of the analytics above: it concerns how a service is used, not who uses it, and does not cover individual tracking, histories, profiling or cross-service tracking; aggregate dashboards do not exempt them. For non-exempt device storage or access, obtain prior consent; a cohort report alone does not determine exemption. UK GDPR duties still apply where personal data is processed, and pseudonymous identifiers are not automatically anonymous. This article is general information, not legal advice.

Recommendations: collect only what a named decision needs; keep personal details out of event properties without a governed reason; make refusal easy. Duties differ by jurisdiction.

A review rhythm that turns numbers into decisions

A short, regular review is recommended, not a formula: it keeps measures tied to decisions, but guarantees none. It sits within the routine in our guide to software maintenance after launch. Keep it short:

• What moved, against the recorded baseline?
• What is explained by a product change, and what is not?
• What one change or investigation is agreed, and who owns it?
• Should any measure be retired?

Practical next steps

If your product is live, start here; if you are still scoping a first version, our guide to scoping a first version covers that stage:

• Agree the core value action, and other important workflows, in writing.
• Adopt the five starting measures, each with unit, denominator, window and qualifying action; report counts beside rates.
• Audit existing events: retire duplicates, complete definitions, remove ungoverned personal details.
• Record baselines where they exist, set the review rhythm, and settle consent and objection controls first.

Frequently asked questions

Is web analytics not enough?

It depends on the question and the instrumentation, not on the tool's label. Google Analytics 4 records events and offers funnel exploration, so it can follow a signed-in workflow with the right events in place; a dedicated platform may offer deeper user-level analysis. Many teams manage with the tool they have.

How many events should we start with?

Fewer than feels comfortable: the events describing the core journey and the starting measures — a handful, not dozens, each answering a real question. Adding events is easy; restoring trust in a polluted set is slow.

What if the numbers look wrong?

Check both kinds of explanation: instrumentation (trigger, definition, duplicates, test traffic — a common cause is firing on page load, not completion) and behaviour (new user mix, seasonality, a change elsewhere). If a definition changed in a rebuild, mark the break.

Sources

Principal sources, read on 3 November 2026 (Asia/Karachi). The ICO exceptions page was retrieved as indexed text from a 29 October 2026 crawl, not a fresh live read:

GOV.UK Service Manual — How to set performance metrics for your service (official guidance, 2017).

GOV.UK Service Manual — Measuring the success of your service (official guidance, 2018).

Google Analytics Help — Recommended events (official documentation).

Google Analytics Help — How to report on your lead generation form (official documentation on funnel exploration).

Mixpanel Docs — Events (official documentation; updated 27 October 2026).

Vestd — North Star metrics that don't mislead (company blog, 2025).

ICO — What are the PECR rules? (official guidance).

ICO — What are the exceptions? (official guidance; indexed text, crawl dated 29 October 2026).

Supplementary commentary only: law-firm summaries by Hunton Andrews Kurth and Osborne Clarke, retained for context, not as core legal evidence.

Start here if your numbers do not yet show where users reach value. iCodeLTD's SaaS development service covers architecture, account management, backend development, testing, and ongoing iteration for subscription products. The project cost calculator gives an indicative cost and timeline range from scope and complexity; the contact page is the route to discuss a live product.