How do I set up analytics for a mobile app?

Your app launched two weeks ago. A hundred people downloaded it. You have no idea what they did next.

That gap, between installation and understanding, is what mobile analytics closes. But most founders set it up wrong, too late, or not at all, because the tooling looks technical and the terminology is dense. It does not have to be.

This guide covers what you actually need to track, what it costs, how mobile differs from web, and what privacy rules now constrain all of it.

Every analytics tool will offer you hundreds of things to measure. Most of them are noise. The ones that matter map directly to whether your business is working.

Start with five events. An event is just something a user does in your app — you define it, you name it, you decide when it fires.

The five events worth tracking from day one: the app opens, the user creates an account, the user completes the core action your app exists to enable (books a session, sends a message, finishes a task), the user makes a purchase if your app has revenue, and the user goes quiet for seven days (the early churn signal). Everything else is optional until you have enough users to make the data meaningful.

Why five and not fifty? Because a 2022 Mixpanel study found that teams tracking fewer, better-defined events made product decisions 30% faster than teams drowning in metrics. More data without a framework for acting on it is not an asset — it is a distraction.

Beyond events, two numbers belong on your weekly dashboard from the start. Retention on day seven (what percentage of people who downloaded your app on Monday are still using it the following Monday) and conversion from sign-up to that core action. Those two numbers tell you whether people see the value in your product before you spend a dollar on marketing.

One common mistake: instrumenting analytics after launch and scrambling to reconstruct user behavior from incomplete data. Analytics must be wired in during development, before the first user touches the app. The code that fires when a user taps a button costs almost nothing to add during a build and costs significantly more to retrofit.

The tooling ranges from completely free to several thousand dollars a month, and the price does not correlate with quality as simply as you might expect.

Firebase Analytics, Google's mobile analytics product, is free with no meaningful cap on events or users. For most apps under 100,000 monthly active users, it covers everything in the previous section without costing anything. The tradeoff is that its data export and custom reporting capabilities are limited unless you pay for BigQuery, Google's data warehouse product, which starts at about $25/month at startup scale.

Mixpanel and Amplitude both offer free tiers that cover roughly 20 million events per month, which is more than enough for an early-stage product. Their paid plans start around $25–$28/month when you need advanced cohort analysis or unlimited data history.

The expensive part is not the tool license — it is the setup. Defining your event schema, writing the tracking code, connecting it to your product analytics dashboard, and making sure data arrives cleanly takes between 20 and 40 hours of engineering time depending on app complexity. At US agency rates, that runs $5,000–$10,000. A specialized data team with a leaner cost structure handles the same scope for $1,500–$2,500.

AppsFlyer belongs in a separate category. It is an attribution tool, not a product analytics tool — it tells you which ad campaigns drove installs, not what users did after they installed. Most early-stage founders do not need it until paid acquisition is a meaningful budget line.

The practical path: start with Firebase Analytics, add Mixpanel when you need user-level querying, add an attribution tool when you spend over $5,000/month on ads. Each step costs almost nothing until you outgrow it.

Web analytics and mobile analytics answer the same question — what are users doing and why — but the underlying mechanics are different in ways that matter for setup.

On a website, a user visits a URL and leaves a clean trail. A browser fires a page view, a session starts and ends, and tools like Google Analytics handle most of the tracking with a single script added to the site header. The developer writes ten lines of code and it works.

On a mobile app, there are no pages and no URLs. The app is a continuous session that the user moves through, not a series of documents they visit. Every meaningful moment has to be explicitly named and tracked as a custom event. Nothing fires automatically. The engineering work is more deliberate, and because of that, more useful when done correctly.

Two distinctions make mobile tracking harder than web tracking.

Cross-device identity is the first. A web user who visits on their laptop and their phone looks like two different users. A mobile app user who logs in on two phones is still one account, but analytics tools need to be told to treat them as one. If this is not configured during setup, your retention numbers will look worse than they actually are because returning users get counted as new ones.

Install attribution is the second. A web visitor arrives from a URL that carries tracking parameters — you know they came from a specific ad, email, or link. A mobile app install does not work that way. When someone taps an ad and downloads your app from the App Store, the operating system strips that context for privacy reasons. To track where your installs come from, you need a dedicated attribution tool or a branch link setup. This is a step most web-focused teams miss when building their first mobile product.

Mobile analytics also generates more data, faster. A user spending 20 minutes in your app can trigger hundreds of events. Without an event taxonomy, a documented list of what you track, how you name it, and when it fires, that data becomes impossible to query consistently. Agree on naming conventions before your first line of analytics code is written.

Apple changed mobile tracking permanently in April 2021. The App Tracking Transparency framework, which shipped with iOS 14.5, requires every iOS app to ask users for explicit permission before tracking them across other apps or websites. The permission prompt appears once, and about 75% of users deny it, according to Flurry Analytics' 2022 data.

What that means practically: your iOS analytics will be based on the roughly 25% of users who opted in, plus aggregated and anonymized data Apple provides for the rest. You will see trends, not individual user paths, for three-quarters of your iPhone users. This is not a bug you can engineer around — it is the new default for iOS.

Android has not yet implemented an equivalent system, though Google announced a Privacy Sandbox for Android in 2022 with phased rollout beginning in 2024. As of mid-2023, Android analytics remain closer to the pre-ATT web model, but that is changing.

Outside of device-level tracking rules, two legal frameworks affect what you can store.

GDPR applies to any user located in the European Union, regardless of where your company is headquartered. It requires that users be able to request deletion of their data, and that you have a documented legal basis for collecting each type of data you store. Analytics event logs that include IP addresses or device identifiers count as personal data under GDPR. The safe path is to anonymize or pseudonymize analytics data and document your retention policy before you launch to European users.

CCPA applies to California residents and carries similar requirements around disclosure and deletion rights. For most early-stage mobile apps, the practical implication is a privacy policy that accurately describes what you collect and a support process for handling deletion requests.

Neither framework requires you to stop collecting analytics data. They require you to be intentional about what you collect, honest about it in your privacy policy, and capable of deleting it on request. Setting up your analytics with those constraints in mind from the start costs almost nothing extra. Retrofitting compliance onto a system that was built without it costs significantly more, both in engineering time and in legal exposure.

If your app targets users under 13, COPPA in the US and equivalent rules in the EU place much stricter limits on data collection. Most analytics tools offer a children's mode that strips personally identifiable data before it leaves the device. Enable it before you launch, not after a complaint.

The short version: build your event schema around what you actually need to make product decisions, not the maximum the tools will collect. Leaner data is easier to protect, cheaper to store, and legally safer from the start.

If you want to get analytics wired in correctly from day one, event schema designed, tools configured, privacy constraints built in, and dashboards that surface the numbers that actually matter, book a discovery call with Timespade. We set this up as part of every mobile build, and we can audit an existing app's analytics setup in a week.