In-app message events
In-app message events record how users interact with messages shown inside an app — impressions, dismissals, and action clicks from an in-app messaging campaign. In the Firebase/GA4 model these arrive as automatically collected events when in-app messaging is in use. They let you measure whether on-device prompts drive the action you intended, distinct from push notifications delivered outside the app.
What these events capture
When an app uses in-app messaging, the framework logs events as a message is shown, dismissed, or its action tapped. In the Firebase/GA4 model these are automatically collected, so you do not hand-instrument each campaign. The result is a funnel from impression to action you can analyse per campaign. Refer to Firebase in-app messaging documentation for the exact event names, which are framework-defined.
Distinguishing in-app from push
In-app messages appear while the user is already in the app; push notifications arrive outside it and are opened to enter the app. They answer different questions: in-app messaging measures prompting an engaged user, push measures re-engagement of someone away from the app. Keep them separate in analysis so you do not conflate 'nudged a present user' with 'brought a user back'.
- Impression, dismiss, and action events per campaign
- Automatically collected when in-app messaging is used
- Distinct from push-notification open events
How it appears in analytics and logs
Impressions without matching action events mean messages are seen but not acted on — a content or targeting issue rather than a delivery failure.
Diagnostic use case
Measure whether in-app messages drive intended actions by analysing their impression, dismiss, and action events against subsequent in-app behaviour.
What WebmasterID can help detect
WebmasterID covers first-party web signals; in-app messaging is a mobile concept included here so the events reference spans web and app surfaces.
Common mistakes
- Conflating in-app messages with push notifications.
- Hand-instrumenting events the framework already logs.
- Putting user identity into campaign parameters.
Privacy and accuracy notes
In-app message events describe interactions with a campaign, not the user's identity. Keep campaign and action parameters non-identifying.
Related pages
- Push notification open events
A push-notification open event (notification_open in the Firebase/GA4 model) records that a user tapped a push notification to enter the app, as opposed to merely receiving it. It is the re-engagement counterpart to notification receipt: receipt means delivered, open means acted on. As an automatically collected event for messaging-enabled apps, it lets you measure whether push campaigns actually bring users back.
- App store subscription events
When a Firebase/GA4 app project is linked to the Apple App Store or Google Play, the stores can report subscription lifecycle events — purchases, renewals, cancellations, refunds — into analytics. These app-store subscription events let you analyse recurring revenue alongside in-app behaviour. They originate from the store, not your client SDK, so their availability and naming depend on the platform's own documentation.
- 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.
- Event Explorer
Explore campaign-driven app events.
Sources and verification notes
- Google Analytics Help — Automatically collected eventsIncludes in-app messaging events for Firebase apps.
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.