How to Set Up Analytics Before Your App Launches
Data from day one is worth ten times more than data from month two. If you are launching without analytics configured, you are flying blind at exactly the moment when the information is most valuable.
The Analytics Philosophy
You do not need comprehensive analytics. You need the right analytics. The goal is to instrument the specific events that will tell you whether your core hypothesis is true, and whether users are progressing through the core journey you designed.
Everything else is noise that wastes engineering time and increases data complexity.
The Five Events Every App Needs
1. First Open The first time any user opens the app after installing it. This is your baseline — every other metric is a subset of this.
2. Onboarding Completed When a user successfully completes your onboarding flow and reaches the app's core state for the first time. The conversion rate from First Open to Onboarding Completed is your first critical metric. If a significant portion of users are not completing onboarding, your onboarding needs work before anything else.
3. Core Action Performed The first time a user performs the central action of your app: logs a workout, makes a booking, sends a message, creates a listing — whatever your core action is. This is your product-market fit signal. If users complete onboarding but never perform the core action, your product has a value communication problem.
4. Day 1 Return Did the user open the app again within 24 hours of their first open? Day 1 retention (commonly called D1 retention) is the single most predictive early indicator of long-term retention. Track it from day one and watch for any drop after a product change — the direction matters more than any benchmark.
5. Day 7 Return Did the user open the app again within 7 days? D7 retention separates apps that users find habitually useful from apps they try once and forget. If D7 is improving over successive cohorts, that is a healthy signal — if it is flat or declining, onboarding or core value is the problem.
Platform Recommendations
Firebase Analytics: Free, powerful, integrates with the full Google ecosystem (Google Ads, BigQuery for advanced analysis). The best choice if you are already using Firebase for your backend.
Mixpanel: Best-in-class funnel analysis and user-level event history. The free tier is generous enough for most early-stage apps. Choose Mixpanel if you expect to do deep funnel analysis.
PostHog: Open source, self-hostable, includes session recording and feature flags. The best choice if you want full data ownership or are building a web app alongside your mobile app.
Implementation Guidance
Define every event in writing before implementation begins. For each event, document: event name, when it fires, and the properties attached (user ID, platform, app version, feature version).
This event taxonomy document is a contract between you and your developer. Without it, event names become inconsistent ("onboarding_complete" vs "OnboardingComplete" vs "onboarding_finished"), and your data becomes useless for comparison over time.
Test every event in development before shipping. The most common analytics mistake is shipping with broken events — events that fire at the wrong time, with wrong property values, or not at all. Build analytics testing into your pre-launch QA checklist as a first-class requirement.
The Dashboard You Actually Need at Launch
On launch day, you need to see four numbers in near-real time: 1. Total installs today 2. Onboarding completion rate 3. Core action completion rate 4. D1 retention rate from yesterday's installs
Everything else can wait until you have enough data to be statistically meaningful.
Choosing Your Analytics Tool
You do not need to pay for analytics to launch. Every serious tool has a free tier that will carry a pre-product-market-fit app comfortably. Here is what each actually offers, so you can pick on facts rather than marketing.
Firebase Analytics (Google Analytics for Firebase) is free with no event-volume cap, which is rare. You can define up to 500 distinct event types and log an unlimited number of them. It is the natural choice if your app already uses Firebase for its backend. The trade-off: its reporting is less flexible for deep user-level investigation than the dedicated tools below.
Mixpanel offers a free plan capped at one million events per month, with unlimited team seats and no credit card required. That ceiling is high enough for most early apps. Mixpanel is built around funnels, retention, and cohorts, which makes it a strong default if you want to understand behavior, not just count installs.
Amplitude has a free Starter plan covering up to 10,000 monthly tracked users and up to two million events. It sits in the same category as Mixpanel — deep behavioral analysis, funnels, retention, cohorts — and the choice between the two often comes down to which interface you prefer.
PostHog includes one million events per month free, with no credit card required, and it is open source and self-hostable under an MIT license. Pick PostHog if you want full ownership of your data, or if you are building a web app alongside your mobile app and want one tool for both.
Pick one and instrument it well. Running two tools at launch doubles the work and rarely doubles the insight. Add a second later, once you know what questions you are trying to answer.
Event-Based Analytics vs Funnel Analytics
These two terms confuse a lot of first-time founders, so here is the plain-language version.
Event-based analytics counts things that happened. How many users opened the app today? How many performed the core action this week? Each event is a single fact with a timestamp and some properties attached. Event analytics answers "how much" and "how many."
Funnel analytics measures movement through a sequence of steps. It takes an ordered list of events — say, First Open, then Onboarding Completed, then Core Action Performed — and shows what percentage of users made it from each step to the next, and where they dropped off.
The difference matters because the numbers tell you different things. Event analytics might show that 200 people performed your core action. Useful, but incomplete. A funnel shows that 1,000 people opened the app, 600 finished onboarding, and only 200 reached the core action. Now you know exactly where you are losing people: the biggest leak is between onboarding and the core action, not at the front door.
Set up at least one funnel before launch: First Open to Onboarding Completed to Core Action Performed. It is the single most useful view you will have in your first month.
Tracking In-App Purchases for Revenue Analytics
If your app makes money, revenue is just another event — and you should treat it that way from day one.
Send a "Purchase" event whenever a user pays, and attach the amount and currency as properties (for example, value: 9.99 and currency: "EUR"). Once revenue lives in your analytics tool alongside everything else, you can answer questions that download numbers never will:
- Which onboarding path leads to the most paying users?
- Do users who perform the core action in their first session pay at a higher rate?
Two practical notes. First, Firebase Analytics can automatically collect in-app purchase and subscription events on Apple platforms without extra code, which saves setup time if you are on that stack. Second, the revenue figure your analytics tool shows is not your bank balance — Apple and Google take their platform commission, and refunds happen. Treat in-app revenue as a directional signal, and reconcile actual euros in your App Store and Google Play payout reports.
Record amounts in a single currency, or at minimum store the currency on every purchase event. Mixing euros and dollars in one metric without labeling them produces numbers that look precise and mean nothing.
Cohort Analysis for Retention
A cohort is a group of users who share a starting point — most commonly, the week they first opened your app. Cohort analysis tracks each group separately over time instead of blending everyone into one average.
This matters because a single blended retention number hides the truth. If you ship an onboarding improvement in March, the users who arrived in January drag your average down and make the change look like it did nothing. Cohorts solve this: you compare the people who joined before the change against the people who joined after, week by week.
The standard view is a retention table. Each row is a cohort (week one, week two, and so on). Each column is how many weeks later. Each cell shows the percentage of that cohort still active. Read it top to bottom and you can see whether newer cohorts retain better than older ones — the clearest evidence that your product is actually improving.
All four tools above build this for you automatically once your First Open and return events are firing correctly. You do not need a data analyst. You need the events instrumented properly and the discipline to look at the table every week.
The one number to watch: whether each new cohort's week-one retention is higher than the last. If it is climbing, you are moving toward product-market fit. If it is flat, your changes are not landing where it counts.
What a Good Pre-PMF Dashboard Looks Like
Before product-market fit, your dashboard has one job: tell you whether the product is getting better. It should fit on one screen and contain nothing you would not act on.
A strong pre-PMF dashboard shows:
- New users per week — your top-of-funnel volume, so you know your other numbers are meaningful.
- Activation rate — the percentage of new users who complete onboarding and perform the core action. This is your single most important pre-PMF number.
- The core funnel — First Open to Onboarding Completed to Core Action Performed, with drop-off at each step.
- Weekly cohort retention — the table above, so you can see whether retention improves cohort over cohort.
- Revenue per week (if you monetize) — and the percentage of active users who pay.
That is the entire dashboard. Resist the urge to add more.
The mistake almost every founder makes is building a dashboard full of vanity metrics — total downloads, total events, screen views — that climb no matter what and never tell you what to fix. They cannot tell you whether your product is working. Activation and retention can.
Check this dashboard weekly, not hourly. Pre-PMF, daily numbers are too noisy to act on, and staring at them only makes you anxious. Look once a week, ask what changed, and decide what to ship next. That loop — measure, learn, ship — is the entire point of setting up analytics before you launch.