US | Analytics | 2026-08-29

App Analytics to Set Up Before Launch, Not After

Retrofitting analytics after launch permanently loses the one cohort that matters most, so here is the small, durable event set to define before your build is finished.

You ship on a Tuesday, pick up a few hundred installs in the first week from your customer email list and a mention in a trade newsletter, and by Friday you want one number: how many of those people finished signup and actually booked something. Nobody can give it to you, because the analytics work was scheduled for the sprint after launch.

That number is not delayed. It is gone. You can instrument the app next month and measure everything from that point on, but the group of people who arrived in launch week, met your roughest onboarding screens, and either stayed or quietly deleted the app will never assemble again.

The launch cohort is the only one you cannot re-run

Launch traffic behaves nothing like month-six traffic. It is warmer, more forgiving, and far more motivated: existing customers, your own staff, the friend who shared the link. That makes it your most useful diagnostic sample, because if this group stalls at your signup flow, colder traffic later will not survive it at all.

There is a second reason timing matters. Every change you make after launch is a change against something. Without a first-week baseline, "retention improved after we simplified onboarding" is a story rather than a finding. Six weeks of arguing about that costs more in developer hours than a day of instrumentation would have.

Installs, opens, activation and retention are four different numbers

Founders routinely quote installs when they mean activation. Picture a field-service booking app: installs, then first opens, then accounts created, then people who ever booked a job. Each step sheds a meaningful share of the one before it. All four figures are true at once, and only the last pays for anything.

Decide before launch which of these goes on the board you look at every Monday morning. For most service and booking apps it is activation, because installs are a marketing number and revenue is a lagging one.

Define the funnel on paper before anyone writes tracking code

Instrumentation goes wrong when it starts in the codebase. Start instead with one sentence that finishes "this user is activated when they have…". For a gym app that might be a first check-in at a club. For a restaurant loyalty app, redeeming one reward. For a plumbing or HVAC business, submitting a first job request between the 7am and 9am window when most of that demand actually arrives.

Then work backwards and list every screen between the store listing and that moment. You will usually land on five to seven steps. Those steps are your funnel, each becomes an event, and anything off that path is optional. An afternoon on paper saves the developer from guessing at what you meant.

The short list of events actually worth defining

You do not need to track everything, and trying to is the reason most analytics setups become unusable. A workable first release usually needs somewhere between six and twelve custom events on top of the automatic ones:

• Signup started and signup completed, as two separate events
• Onboarding completed, if onboarding is more than one screen
• First core action, named for what the app is for: booking created, order placed, workout logged
• Notification and location permission prompts, with the result recorded
• Invite or share sent
• Checkout started and purchase completed
• Subscription started, with the plan and trial status as parameters
• Subscription cancelled, plus the cancellation reason if you collect one

Firebase Analytics allows a large but finite number of distinct event names per app, along with caps on parameters per event and user properties. Check the current limits in the documentation before you plan around them. In practice the human limit arrives first: nobody reads a list of two hundred events.

Naming conventions that still make sense in a year

Pick a shape and never deviate. Lowercase, underscores, object first and action second, past tense: booking_created, subscription_cancelled, invite_sent. Event names are case-sensitive in most analytics platforms, so booking_Created quietly becomes a second, half-populated event.

Keep display copy out of names. An event called green_button_tapped is meaningless the week you redesign the screen. Variable detail belongs in parameters, not in the name, so you want one purchase_completed event with a plan parameter rather than three separate purchase events. Also note that Firebase reserves certain prefixes for its own automatic events, so avoid them entirely.

Maintain a one-page tracking plan: event name, exactly when it fires, its parameters, an example payload, and who owns it. That page is the deliverable, not the code. It is also what lets a new developer pick the project up eighteen months later without reverse-engineering your intentions.

What the SDK sees, and what only the store consoles see

These are two separate worlds and founders often assume one covers the other. Your analytics SDK begins at first open. Everything before that — store impressions, product page views, the conversion from page view to download, and acquisition source — lives in App Store Connect and Google Play Console. Uninstalls also live there, and no in-app SDK can see them.

The consoles also hold platform-level quality data: Android vitals in Play Console, Xcode Organizer metrics on Apple's side. Give someone on your team login access to both before launch day, not during the first panic. Attribution for paid iOS acquisition is aggregated, delayed, and the underlying framework has changed more than once, so verify how it currently works before budgeting around it.

Consent, ATT prompts and rules that keep moving

Apple requires an App Tracking Transparency prompt before an app tracks users across apps and websites owned by other companies. Ordinary first-party product analytics usually does not trigger that requirement, but the boundary depends on what your SDKs actually do and on advertising identifiers, so treat it as a question for your developer rather than an assumption.

In the EU and UK, non-essential analytics generally needs consent before it fires, which means the app has to be able to start with analytics off and switch it on afterwards. Brazil and several US states have their own regimes. Both stores also require you to declare data collection accurately — the Data safety form on Play, privacy details on the App Store — and those declarations must match what your SDKs really collect. This area changes often, so check the current requirements close to submission.

Crash reporting is a product signal, not only an engineering one

Add Crashlytics or an equivalent before launch and treat crash-free user percentage as a business metric. Google publishes thresholds for excessive crash and ANR rates in Play Console, and exceeding them can affect how your app is surfaced, so check the current figures and set an internal alert well below them.

The real reason to have this on day one is interpretation. A camera step with a heavy drop-off looks like a design problem and gets a redesign, when the cause is a crash on one manufacturer's mid-range Android handsets. Without crash data joined to your funnel, you spend a month fixing the wrong thing.

Write down the week-one baseline

Seven days after launch, record a fixed set of figures in a dated document: installs, first opens, activation rate, day-1 and day-7 retention, crash-free users, median time from install to activation, and your three largest drop-off steps. Ten minutes of work.

Every decision for the next year references that page. It settles arguments, it tells you whether a change worked, and if you ever raise money or sell the business, it is the difference between showing a trend and describing one.

The trap of the dashboard nobody reads

Most analytics projects die at the dashboard stage. Someone builds a twenty-chart screen, everyone admires it for a fortnight, then nobody opens it again. The fix is unglamorous: one screen, five numbers, reviewed at a fixed hour each week and delivered as a scheduled email so it arrives whether or not anyone logs in.

For the two or three numbers that genuinely matter, alerts beat dashboards. A message when activation drops below your baseline gets acted on. A chart that shows the same thing does not. Delete anything that has gone a month without being looked at.

If you are scoping a build now, put the tracking plan in the same document as the feature list. Our white-label Flutter apps ship in roughly 30 to 60 days from around $2,500 with full source code included, and instrumentation is far cheaper inside that window than bolted on afterwards. There is more on planning and launch decisions across the blog, and you can talk through your funnel with us before anything gets built.