The app_remove event (uninstalls)
app_remove is an automatically collected GA4/Firebase event indicating that an app package was removed (uninstalled) from a device, available on Android via Play. It is the closest thing to a churn signal at the device level — but it is reported with delay and is platform-limited, so it is directional, not real-time. This page covers how it works and how to read uninstall data honestly.
What this means
app_remove is an automatically collected event that indicates an application package was removed from a device. On Android it is derived from Google Play signals about uninstalls. It appears in your event stream after the fact, letting you see uninstall volume over time as a coarse churn indicator at the device level.
Delay and platform limits
Uninstall reporting is not instantaneous: Play reports removals on its own schedule, so app_remove lags the actual uninstall and is approximate for recent days. Availability and exact mechanics differ by platform. Read it as a trend, not a precise real-time count, and pair it with engagement decay (users who stop opening the app) for a fuller churn picture rather than relying on uninstalls alone.
- Indicates an app package was uninstalled
- Reported with delay; not real-time
- Platform-limited — read as a trend, not exact
How it appears in analytics and logs
A rise in app_remove after a release suggests the update pushed users away — but because reporting is delayed, treat the timing as approximate rather than instant.
Diagnostic use case
Use app_remove as a coarse uninstall/churn signal on supported platforms, while understanding its reporting delay and platform limits.
What WebmasterID can help detect
WebmasterID is web-first; for web, churn is inferred from return behaviour rather than an uninstall event, but the privacy discipline is identical.
Common mistakes
- Treating app_remove as a real-time, exact uninstall count.
- Assuming identical availability on every platform.
- Equating no uninstall event with an active user.
Privacy and accuracy notes
app_remove records that an app was uninstalled, not who did it. It is a device-level lifecycle signal with no personal identifier attached. This is educational, not legal advice.
Related pages
- The app_update event
app_update is an automatically collected GA4/Firebase event that fires when a user opens an app after it has been updated to a new version. It records the previous app version so you can see adoption of releases and behaviour changes after an update. It is distinct from first_open (a brand-new install) and app_open (any foreground), marking specifically the first launch on a new version.
- The os_update event
os_update is an automatically collected GA4/Firebase event fired when a user opens an app after the device's operating system has been updated to a new version. It records the previous OS version, helping you correlate behaviour or crash changes with platform updates. Like app_update it is a lifecycle signal about the environment, not the person — useful for compatibility analysis after a major OS release.
- 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.
- Event Explorer
Inspect uninstall and lifecycle events.
Sources and verification notes
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.