Notification receive and open events
notification_receive and notification_open are GA4/Firebase events that track the lifecycle of a push notification: receive marks that a message arrived on the device, open marks that the user tapped it. Together they reveal delivery versus engagement — how many notifications land versus how many actually pull users back. They describe the message and campaign, not the recipient's identity.
What this means
For apps using Firebase Cloud Messaging with GA4, the notification lifecycle is captured by events such as notification_receive (the message was delivered to the device in the foreground), notification_open (the user tapped it to open the app), and related dismiss/foreground events. Each can carry the message identifier or campaign so you can attribute the resulting session to a notification.
Delivery vs engagement
Receive and open answer two different questions. notification_receive tells you the message landed; notification_open tells you it worked — the user came back. A high receive-to-open ratio is healthy engagement; a low one means the message is not compelling, mistimed, or irrelevant. Reading both, rather than just send volume, is how you tell delivery problems apart from messaging problems — and parameters stay about the campaign, never the person.
- notification_receive = delivered to device
- notification_open = user tapped to open
- Compare the two to separate delivery from engagement
How it appears in analytics and logs
Many notification_receive but few notification_open means notifications arrive but do not motivate a tap — a messaging or relevance problem, not a delivery one.
Diagnostic use case
Measure push-notification delivery and tap-through by comparing notification_receive to notification_open, so you can judge campaign effectiveness.
What WebmasterID can help detect
WebmasterID is web-first, but the same discipline applies to messaging events: record the campaign and outcome, never the individual recipient.
Common mistakes
- Reading send volume instead of open rate as success.
- Confusing a delivery problem with a messaging problem.
- Putting recipient identity into notification parameters.
Privacy and accuracy notes
These events carry the message/campaign identity, not the recipient. No personal data belongs in their parameters. This is educational, not legal advice.
Related pages
- Dynamic link and campaign_details events
Dynamic-link and campaign_details events attribute app sessions to the campaign that drove them. When a user opens the app via a tracked deep link, GA4/Firebase records campaign attribution parameters (source, medium, campaign) on a campaign_details event. This is how app installs and re-engagements get tied to a marketing source — using campaign metadata, never anything that identifies the individual user.
- 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.
- Custom events: tracking what matters to you
Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.
- Event Explorer
Inspect notification 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.