Getting the app analytics setup right in the UK is one of those launch tasks that feels optional right up until the week you need it. You ship, a few hundred people download the app, and someone asks why nobody is coming back. Without instrumentation you can only guess, and guessing is expensive. This is the setup we put into every build at Bluka: small enough to finish in an afternoon, honest enough to survive a board question, and compliant with the UK rules as they stand in 2026.
What a day-one app analytics setup in the UK looks like
A day-one app analytics setup in the UK is two tools, about fifteen events, and one written definition of activation. Product analytics covers what people do inside the app, web analytics covers the marketing site, and a tracking plan document keeps both honest. Everything else can wait until you have users to argue about.
That is the whole answer. The reason so few teams have it is that analytics work has no deadline. Nobody blocks a release for a missing event, so it slips, and six months later you have an app with real users and no memory of what they did.
Write the three questions before you open a tool
Start with the decisions, not the dashboard. Write down the three questions your product needs answered this quarter. For a pre-revenue consumer app they are usually some version of these:
- Where did the people who stayed come from?
- What did they do in their first session that the people who left did not?
- Which part of the core loop are people falling out of?
If a metric cannot change a decision you would actually make, do not track it yet. Sessions per user looks impressive on a slide and tells you nothing you can act on in month one.
Define activation in one sentence
Activation is the single action that means a new user got the value your app promised. Not signup. Not opening the app. The moment the product did its job.
For a shift-tracking app, activation might be logging a first shift and seeing take-home pay. For a booking app, a first completed booking. Give it a window, usually seven days, so the number means something: “45% of new users log their first shift within seven days” is a sentence a team can improve. “We have 2,000 users” is not.
We write this sentence into the project brief before development starts, because it quietly determines what onboarding needs to do. If you are still shaping that, our guide on choosing a tech stack for an MVP covers the same principle applied to architecture decisions.
Write the tracking plan before writing the code
The tracking plan is a spreadsheet. One row per event, with four columns: event name, when it fires, what properties it carries, and which of your three questions it answers. If the last column is empty, delete the row.
A naming convention matters more than which one you pick. We use object_action in lower snake case, so shift_logged, booking_completed, paywall_viewed. Pick a pattern on day one and hold it, because renaming events later means either losing history or maintaining a translation layer forever.
Fifteen events is plenty at launch. A realistic starter set:
| Stage | Events |
|---|---|
| Acquisition | app_installed, signup_started, signup_completed |
| Activation | onboarding_step_viewed, onboarding_completed, plus your one activation event |
| Core loop | Three to five events covering the main thing your app does |
| Monetisation | paywall_viewed, trial_started, subscription_purchased |
| Retention | app_opened, notification_opened |
Every event carries a small set of shared properties: platform, app version, and whether the user is new or returning. Version is the one people forget, and it is the one you need when a metric falls off a cliff and you want to know which release did it.
Plausible, Mixpanel and GA4: which does what
These three get compared constantly, which is odd, because they solve different problems. The honest framing is that you probably want one product tool and one web tool, not a winner.
| Tool | Best at | Weak at | Cost signal |
|---|---|---|---|
| Plausible | Marketing site traffic, privacy-first, no consent banner needed for basic use | In-app user behaviour, funnels, cohorts | From about $9 a month at 10k pageviews |
| Mixpanel | Funnels, cohorts, retention curves, per-user event streams | Website content analytics, SEO reporting | Generous free tier, then usage-based |
| GA4 | Free, ties to Google Ads and Search Console | Product questions, simple funnels, data you can trust without sampling | Free at the volumes early apps hit |
Our default for a UK consumer app is Plausible on the marketing site and Mixpanel or PostHog in the app. PostHog is worth a look if you want session replay and feature flags in the same tool, which saves a subscription later. GA4 earns its place when paid acquisition is central to the plan, because the Google Ads integration is genuinely useful and nothing else replicates it.
The tool matters less than the discipline. A clean fifteen-event Mixpanel project beats a sprawling GA4 property with 200 auto-collected events every single time.
The UK consent question changed in February 2026
This is the part that has actually moved, and a lot of advice online is out of date.
Analytics cookies and equivalent app storage used to require opt-in consent under PECR, full stop. The Data (Use and Access) Act 2025 amended that. From 5 February 2026, a narrow set of low-risk purposes became exempt from the consent requirement, and first-party analytics is one of them. The ICO finalised its guidance on storage and access technologies on 29 April 2026.
The exemption is real but narrow. It applies when:
- The analytics data is used solely to understand how people use your service so you can improve it.
- You tell users clearly what you collect, in plain language, before or as it happens.
- You give them a free and simple way to object.
It stops applying the moment the data leaves that lane. If your analytics feeds ad targeting, builds remarketing audiences, contributes to conversion modelling, or is shared with a third party for that party’s own purposes, you still need opt-in consent. Advertising SDKs sit entirely outside the exemption.
Two practical consequences. First, the penalty ceiling for PECR breaches now sits alongside UK GDPR levels, so this is no longer a rounding-error risk. Second, a privacy-first product analytics setup is now cheaper to run in the UK than a Google-linked one, because you can skip the banner that costs you a slice of every session. Read the ICO’s own guidance rather than a vendor’s summary of it, and if your app touches health, finance or children’s data, get a lawyer to look at your specific setup. We cover the wider picture in our guide to GDPR in a UK consumer app.
Instrument it, then prove it works
Instrumentation takes a competent engineer about half a day for fifteen events. Verification takes longer than people expect, and skipping it is how teams end up with three months of data they cannot use.
Do this before you call the work done:
- Fire every event on a real iOS device and a real Android device, not just the simulator.
- Confirm each one arrives with the right properties attached, including app version.
- Check that a user who signs up, activates and returns the next day produces a coherent story in the event stream.
- Trigger the objection or opt-out path and confirm events genuinely stop.
That last one gets missed constantly. An opt-out that does not actually stop collection is a compliance problem wearing a UX costume.
Book the fifteen minutes, or none of this matters
The failure mode is not bad instrumentation. It is good instrumentation nobody looks at. Put a recurring fifteen-minute slot in the calendar for the first quarter after launch, and answer the same three questions every week. Write the answers somewhere durable so you can see the trend.
Most of what you learn will be uncomfortable and useful. Onboarding is longer than you think, the feature you were proudest of gets used by 4% of people, and the thing you nearly cut is what brings people back. That is the point. If you want the acquisition side of this loop, our piece on getting your first 100 app users in the UK pairs with it directly.
What to do next
If you are pre-launch, spend the afternoon: three questions, one activation sentence, fifteen events, two tools, consent path checked against the 2026 rules. If you already launched without any of it, do the same work now and accept that your history starts today rather than at launch.
If you would rather have this built in properly alongside the product, send us a project brief. Analytics is part of every build we ship, because a product you cannot measure is a product you can only redesign by argument.
Sources worth reading directly: the ICO guidance on storage and access technologies and the text of the Data (Use and Access) Act 2025.
.webp)
.webp)
