Analytics Checklist Before You Launch an App

Analytics has an awkward property: many of its settings are not retroactive. A data filter, a custom dimension, a longer retention period — each starts working when you create it. Set them up the week after launch and the launch itself, the period you will most want to study, stays measured the old way for good.

Decide what the data must answer

Write down three to five questions before writing any event code. For a first release, a useful list looks like this:

• Do people finish onboarding?
• Do they reach the core action at least once?
• Do they come back in the first week?
• Where do paying users come from?
• Which screen do people leave from?

Each question should map to one or two events. Anything that does not answer a question can wait for the second release.

Before release

1. 1

   Name events once, for every platform

   Lowercase with underscores, Google's recommended event names where one fits, and identical names on iOS and Android.

2. 2

   Register parameters as custom dimensions

   Parameters you want in reports or explorations must be registered, and registration does not fill in data from before it.

3. 3

   Mark key events

   Onboarding complete, core action complete, purchase. Keep the list short enough to mean something.

4. 4

   Keep test traffic out

   A separate Firebase app for development builds, Analytics off in debug builds, and a developer traffic filter in GA4 — tested first, then activated.

5. 5

   Set data retention

   Explorations and funnel reports only reach back as far as the retention setting — 2 or 14 months for standard properties. Standard reports are not affected.

6. 6

   Check the reporting time zone and currency

   The time zone decides where each day starts, and a later change only applies from then on.

7. 7

   Decide on BigQuery export

   If you will want raw events later, link it now: the export starts from the day you link it.

8. 8

   Confirm collection is on in the release build

   If Analytics is switched off for debug builds or until consent, make sure the release configuration turns it back on.

Verify on a real device

• first_open and session_start arrive on a fresh install
• Each key event arrives exactly once per action, with every parameter filled
• screen_view arrives once per screen, with names you can read
• Nothing arrives before consent, if your app asks for it
• A sandbox or license-tester purchase runs through your purchase events without errors

Launch week

What goes wrong if you skip it

• The launch cohort — usually the largest and most studied — contains your testers
• Explorations can no longer reach back to launch once the retention period passes
• A parameter added "later" leaves the launch weeks without a breakdown
• Launch-day numbers are compared across a time zone change made afterwards

How this fits with Appnaly

Appnaly reads the GA4 data this checklist produces, so each item shows up there: filtered test traffic stays out, events appear per app under the names you chose, and a platform that never sent data appears as a missing stream. After release, the first things worth reading are the setup guide, if any app looks empty, and the comparison of first_open with store downloads.