Analytics and tracking for a new app, set up right

Symptom

A month after launch you try to answer a simple question, like how many people who signed up went on to pay, and you can't.

None of these produce an error. The app works. You just can't trust the numbers, which means you can't tell whether the MVP is working.

Why it happens

Analytics in AI-built apps usually gets added by a single prompt late in the build. The tool drops in a script, sprinkles a few events where it guesses they belong, and moves on. Nobody decided what the data was for.

The specific causes I see most:

• No questions, so no plan. Events get added wherever it is easy, not where a decision depends on them.
• Names drift. Each prompt invents a new name for the same action, and dashboards that match on names quietly split your data.
• Everything happens in the browser. Ad blockers, closed tabs and failed requests all drop events. That is fine for page views and bad for sign-ups and payments.
• Revenue counted twice, or not at all. A purchase event fires on the success page, which some customers never see and others reload.
• A heavyweight tool where a light one would do. A tracker that sets identifiers needs consent under UK rules, the consent banner gets ignored, and you lose most of your data.
• Built-in analytics mistaken for product analytics. Lovable's Analytics view shows visits, sources and pages for published apps, sets no cookies, and does not track custom events such as sign-ups or purchases; its docs suggest a tool like PostHog for that. Bolt hosting analytics needs a paid plan, covers the last 30 days, and its docs say there is no built-in way to separate bots from real visitors.

The fix

1. Write down the questions first

Before any code, list the three to five questions the MVP exists to answer. For a booking tool, that might be: where do visitors come from, how many sign up, how many make a first booking, how many pay, and how many come back within 30 days.

Each question maps to one or two events. Anything that doesn't answer a question can wait.

2. Pick tools by job

You rarely need one tool to do everything.

Plausible's data policy says it doesn't use cookies or persistent identifiers, and doesn't write to local storage. It counts a daily unique visitor from a hash of a salt, the site domain, the IP address and the user agent, and discards the salt every 24 hours, so visitors can't be followed across days. Data is processed and stored in the EU.

3. Agree a naming pattern and enforce it in code

My rule is Object then past-tense action, in title case: Account Created, Project Created, Checkout Started, Subscription Started. One pattern, no exceptions.

Plausible's docs say the goal name in your site settings must match the event name exactly, including capitals, and events don't appear on the dashboard until a matching goal exists. Past events are not backfilled, so create the goals before launch.

The easiest way to stop drift is to make the wrong name impossible to type:

// lib/analytics.ts
import { init, track } from "@plausible-analytics/tracker";
 
export type EventName =
  | "Account Created"
  | "Project Created"
  | "Checkout Started"
  | "Subscription Started";
 
let started = false;
 
export function startAnalytics() {
  if (started || typeof window === "undefined") return; // init throws if called twice
  init({ domain: "yourapp.co.uk" });
  started = true;
}
 
export function trackEvent(name: EventName, props?: Record<string, string | number | boolean>) {
  track(name, { props });
}

Call startAnalytics() once in a client component near the root of the app. The npm package tracks page views automatically by default, and leaves outbound links, file downloads and localhost events off unless you switch them on. Keep personal data such as emails out of event properties.

4. Send the important events from the server

Events that matter for decisions should not depend on the browser. Plausible has an Events API for this. It needs the visitor's User-Agent and, when sent from a server, X-Forwarded-For, so it can count the visitor correctly. Forward both from the incoming request.

// lib/analytics-server.ts
import type { EventName } from "@/lib/analytics";
 
export async function trackServerEvent(
  req: Request,
  name: EventName,
  props?: Record<string, string | number | boolean>
) {
  try {
    await fetch("https://plausible.io/api/event", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "User-Agent": req.headers.get("user-agent") ?? "",
        "X-Forwarded-For": req.headers.get("x-forwarded-for") ?? "",
      },
      body: JSON.stringify({ name, url: req.url, domain: "yourapp.co.uk", props }),
    });
  } catch (err) {
    console.error("Analytics event failed", err); // never let analytics break sign-up
  }
}

Call it from the route that creates the account, after the insert succeeds. Plausible accepts up to 30 custom properties per event.

For money, count it in Stripe and fulfil from a verified webhook, as covered in adding Stripe to an AI-built app properly. If you want revenue on the analytics dashboard too, the Plausible package accepts a revenue option with an amount and currency, but treat that number as a guide, not your accounts.

5. Get the UK cookie rules right

In the UK, cookies and similar technologies fall under PECR, not just GDPR. Storing or reading anything on a user's device needs consent unless an exception applies.

The Data (Use and Access) Act 2025 added a statistical purposes exception, sometimes called the analytics exception. The ICO's guidance says it only covers storage or access whose sole purpose is collecting statistics to improve your service. You still have to give clear information about it and a simple, free way to object. If you use a third-party provider, it must act as your processor, not a joint controller, and must not combine your data with other information it holds. Advertising purposes are never exempt.

In practice:

• A cookieless tool like Plausible stores nothing on the device, which is why Plausible says you don't need a banner for it. Describe it in your privacy notice anyway.
• A tool that sets identifiers for analytics only may fit the exception, if you meet its conditions.
• Anything used for advertising, profiling individuals, or shared for the provider's own purposes needs consent. Load it only after the user agrees.
• Where you do ask, the ICO expects reject to be as easy as accept, and non-essential technologies to stay off until consent is given.

This is my reading of the ICO's guidance, not legal advice. GDPR for UK startups covers the wider picture.

6. Check it works

Turn on captureOnLocalhost in development, or test on a preview deployment. Sign up, create something and start a checkout, then check each event arrives with the right name and properties. Compare a day's sign-ups in analytics with new rows in the database. A small gap from ad blockers is normal. A big one means an event is in the wrong place.

How to prevent it

• Keep the list of events and what each one answers in a file in the repository, next to the EventName type.
• Review analytics code after every prompt that touches sign-up, onboarding or billing.
• Treat the database as the truth for counts and Stripe as the truth for money. Analytics shows the journey between them.
• Add a new event only when you can name the decision it informs.
• Review the privacy notice whenever you add a tool.

This sits alongside the rest of the launch checklist for AI-built apps and is one step in the prototype to product guide.

When to get help

If you are a few weeks from launch and can't yet say which numbers would tell you the MVP is working, that is worth fixing before you spend on traffic. Setting up analytics around the questions that matter, with events in code and a privacy notice that matches, is part of my Launch package.