The first_open app lifecycle event
first_open is an automatically collected app event that fires the first time a user opens an app after installing or reinstalling it. It anchors app acquisition the way first_visit anchors web acquisition, marking the start of the user's relationship with the app. It is logged by the SDK without instrumentation. Understanding it helps you read new-user and install-attribution reports correctly on mobile.
What it marks
first_open is logged by the Firebase/GA4 SDK the first time the app is launched after installation or reinstallation (automatically collected events). It is the app equivalent of the web's first_visit: the event that establishes a user as new to the app and seeds acquisition reporting. Because it is automatic, you should not send a custom first-launch event of your own.
Reading acquisition with it
first_open underpins install-to-engagement analysis: how many first launches occur, what users do immediately after, and which campaigns drove the install. Reinstalls and identifier resets can produce a first_open for someone who used the app before, so treat new-user counts as 'new under the current identifier' rather than absolutely new. Pair first_open with deep-link and campaign context to attribute installs.
- Fires on first launch after install/reinstall
- App analogue of the web first_visit event
- Reinstalls can re-fire it for returning users
How it appears in analytics and logs
A first_open after a user you already knew usually means a reinstall or a reset identifier, not a brand-new person, so read new-user counts with that in mind.
Diagnostic use case
Anchor app new-user and acquisition reporting on first_open, the SDK-logged first launch after install, rather than on session_start or a custom event.
What WebmasterID can help detect
WebmasterID measures first-party web first-visits; first_open is the mobile lifecycle analogue, documented here so acquisition concepts span both surfaces.
Common mistakes
- Sending a custom first-launch event that duplicates first_open.
- Reading every first_open as an absolutely new person.
- Ignoring campaign context needed for install attribution.
Privacy and accuracy notes
first_open marks a lifecycle moment, not an identity. Keep any attached parameters non-identifying and follow store data rules; this is educational, not legal advice.
Related pages
- first_open vs first_visit
first_open and first_visit are the new-user events in GA4, split by platform: first_open fires on the first launch of an app after install, while first_visit fires on a user's first visit to a website. They play the same role — establishing a user as new — but trigger on different platforms and signals. Confusing them, or comparing them across app and web, leads to misread new-user numbers.
- The app_open event
app_open is a GA4 event collected automatically by the Firebase/GA4 SDK when a user opens an app or brings it to the foreground after it was in the background. It marks app launches and returns, underpinning app engagement, retention, and session analysis — but a foreground event is not the same as meaningful use.
- Automatically collected events
Automatically collected events are events GA4 logs by default once the tag or SDK is present, without you instrumenting them — first_visit, session_start, user_engagement, and app lifecycle events among them. They are distinct from enhanced measurement (auto web-interaction events you toggle) and from recommended/custom events you send yourself. Knowing what is automatic prevents you from re-instrumenting events GA4 already provides.
- Event Explorer
Explore app lifecycle and acquisition events.
Sources and verification notes
- Google Analytics Help — Automatically collected eventsfirst_open for app data streams.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.