Privacy-first mobile analytics: what to measure without cookies or ad trackers

There are two failure modes for analytics in a mobile app. The first is flying blind: you ship, downloads tick up, and you have no idea whether anyone reaches the second screen. The second is worse — you bolt on a heavyweight analytics SDK that fingerprints your users, asks for the scary App Tracking Transparency prompt, complicates your Play Data safety form, and still leaves you staring at a dashboard of numbers nobody acts on.

You do not have to choose between blindness and surveillance. Privacy-first analytics — measuring cohorts instead of individuals — answers almost every product question that actually matters for a growing app, without cookies, ad trackers, or cross-app identifiers. This post is the playbook: what to measure, what to skip, and how to wire it up so it helps you ship instead of slowing down store review.

Why the default analytics SDK is a liability

The classic mobile analytics SDKs were built for an ad-funded world. They assume you want to identify a person, follow them across sessions and sometimes across apps, and stitch that into an advertising graph. On mobile in 2026 that assumption is expensive:

• On iOS, tracking that reaches other companies' apps or data brokers triggers App Tracking Transparency. Most users tap “Ask App Not to Track,” so your data is partial anyway — and you paid for it with a prompt that hurts trust.
• On Android, Google Play's Data safety section makes you declare exactly what you collect and share. “We embed an SDK that sends advertising IDs somewhere” is a disclosure that scares users reading your listing.
• Under GDPR and similar laws, anything that identifies a person — including persistent device IDs and cookies — needs a legal basis and usually a consent banner. That is a lot of compliance surface for metrics you may never look at.

The irony: almost none of that machinery is required to answer the questions a small team actually has.

Measure cohorts, not people

The core idea behind privacy-first analytics is simple: you almost never need to know who did something. You need to know how many, where, and on what. “How many installs activated this week?” “Is retention better on iOS or Android?” “Which countries are growing?” “Did the new onboarding lift the sign-in-to-first-action rate?” Every one of those is a question about a cohort, not a named user.

When you stop trying to identify individuals, the privacy problem mostly dissolves. A random per-install identifier that is not linked to a login lets you count unique installs and sessions without building a profile of a person. No cookies, no advertising ID, no cross-app graph — and nothing that ties “this screen view” back to “this email address.”

The metrics that actually grow a mobile app

Here is a measurement plan that fits on an index card and survives both App Review and a GDPR question. Each of these is a cohort metric — no per-person tracking required.

1. Activation rate. Of the installs that opened the app, how many reached the one action that means “this app is useful to me”? Define that action precisely (first note saved, first workout logged, first message sent) and measure the percentage that get there.
2. Sign-in completion. Of users who tapped “Sign in,” how many finished? A drop here is usually an OAuth or redirect problem, not a product problem — and it is invisible without an event.
3. Day-1 and Day-7 retention. Cohort by install week and watch the curve flatten (or not). Retention is the single best signal that you have product-market fit; it needs counts, not identities.
4. Platform split. iOS vs Android vs web tells you where your users are and where to spend QA time. It also explains crashes and conversion gaps you would otherwise blame on copy.
5. Geography. City and country show you where growth is real, which markets to localize, and whether a Product Hunt or press spike actually converted anywhere.
6. Key funnel events. Three to five named events along your core flow — not fifty. Onboarding start, onboarding complete, paywall view, purchase. Resist the urge to log everything; you will drown.

Notice what is missing: session replays, individual user timelines, advertising attribution. Those are the parts that create privacy risk and store-review friction, and for most teams they never change a decision.

How Kembo does analytics

We built Kembo around exactly this philosophy, because we already handle the part of your app where identity lives — Google and Apple sign-in and sessions — and we refused to turn that into a tracking funnel.

Analytics in Kembo is opt-in per project. It is off until you turn it on, and you turn it on for the projects where you want it. When you do, you add a small module to your app and start seeing usage by city, country, and platform, plus the events you choose to send along your core flow.

• A random id per install— generated on device, not derived from the user's login. Your analytics never says “Alex viewed the paywall”; it says “one install in Berlin on iOS viewed the paywall.”
• No cookies and no ad trackers. There is no advertising identifier, no cross-app graph, nothing to feed a data broker.
• Not linked to sign-in. Authentication and analytics are deliberately separate, so measuring usage never compromises the identity you are trusted to protect.
• Same SDKs you already use — Expo, Flutter, Capacitor, and Web — so the module drops into the app you are already building.

Analytics is a Pro capability, opt-in per project, so it is there when you ship to production and silent while you are still building.

Where analytics fits in your launch sequence

Analytics is not the thing that gets you approved — sign-in is. If you are heading into store review, get Google and Apple working on real devices first (we wrote about why that always eats a week in the Wednesday before App Store and Play review). Once auth is solid and you flip a project to production, turn on analytics and instrument the three or four events that map to your activation moment. That is enough to learn from your first real cohort without a compliance project.

1. Ship sign-in; confirm it works on physical iOS and Android.
2. Define your activation action in one sentence.
3. Turn on analytics for the project and send activation + sign-in completion events.
4. Watch platform split and Day-1/Day-7 retention by install week. Iterate on the weakest number.

You can respect users and still understand them

Privacy-first is not the cautious, lesser option — for a mobile product it is usually the better one. You collect less, disclose less, and survive App Tracking Transparency and Play Data safety without flinching, while still answering the questions that decide what to build next. The trick is to measure cohorts, keep your event list short, and keep identity out of your metrics on purpose.

That is the whole design of Kembo: hosted Google and Apple sign-in, secure sessions, and optional privacy-first analytics that counts installs and events without ever building a profile. Start a free project, ship sign-in this week, and turn on analytics that you would be happy to describe on your own privacy page.