US | Analytics | Published 2026-08-29 | Updated 2026-09-26

App Analytics to Set Up Before Launch, Not After

Define a small event set before launch, then verify completed actions instead of treating every visit as a conversion.

Illustrative scenario: the following launch-week example is hypothetical, not a client result.

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 can include existing customers, your own staff and friends who shared the link. Record that audience mix rather than assuming it represents future visitors. If people struggle with signup, combine the funnel data with usability checks to understand why.

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: green_button_tapped loses meaning when the screen changes. Prefer documented standard events when their definitions match the action, and put variable detail in parameters. Avoid duplicating an automatically collected purchase with a second custom completion event. Use stable custom names only for actions not covered by the standard set.

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

Store acquisition and in-product analytics answer different questions. Store impressions and download reporting belong in the store consoles, while first opens and subsequent product actions belong in your analytics setup. Google Analytics also documents an Android-only app_remove event. Its package-removal count is not equivalent to Google Play daily uninstall metrics; do not combine or substitute the two.

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.

Review applicable consent, privacy and store-disclosure requirements for the countries you serve and the actual behavior of each SDK. Keep analytics collection consistent with that review, and make your Google Play Data safety and App Store privacy disclosures match the shipped product. This checklist is not legal advice or a compliance certification.

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.

A five-step measurement acceptance test

Updated September 26, 2026. Use this worksheet before describing a launch as measurable. These are acceptance criteria, not results from a CrateShip client.

1. Identify the stream. Record the product, canonical website or app package, analytics property, stream ID and platform. A mobile stream and a web stream can share a property without representing the same audience. Keep their reports separate.
2. Define success. Write the exact completed action and its evidence: an account successfully created, a booking accepted or an order confirmed. Opening an app, clicking a store link or seeing a signup screen is intent, not that completed action.
3. Exercise the failure path. On a dedicated test account, cancel the form and retry after a validation error. The completion event should not fire. Do not use a real customer's account or intentionally damage live data.
4. Check one success and one retry. In a test environment, complete the action and confirm the expected event and parameters in the platform's debug tools. Refresh or repeat the callback to check that the same completion is not counted twice. Avoid making a live payment solely to test a dashboard.
5. Record the reporting boundary. Write the date range, timezone, platform, consent or collection limitations and whether internal tests are excluded. Record an unavailable metric as unknown, not zero. Review reporting later; a debug event alone does not prove attribution or a populated production report.

A simple tracking-plan row can read: sign_up; successful account creation; method parameter; test environment; owner: product team; acceptance: one success, no event for a rejected form. Match the standard event definition to your actual flow before adopting it. Do not log a signup just because someone tapped Continue.

Do not combine incompatible traffic numbers

Keep search impressions and clicks, website visits and users, app opens, and completed conversions in separate columns. Infrastructure requests include asset loads and crawlers; they are not a count of people. A website-to-store click is not an install, and an install is not a completed registration. This separation helps you identify whether the next improvement belongs in discovery, the landing page, onboarding or measurement.

Primary references

• Google Analytics: automatically collected events and Android app_remove definitions
• Firebase Analytics: inspect test events with DebugView
• Google Analytics: recommended event names and parameters
• Apple: tracking permissions and app data-use requirements