Notifications: push and in-app messages
Sending the right message at the right time: one-off campaigns, automated journeys, in-app messages.
Four channels, one audience and measurement engine.
Prerequisites: the Notifications product enabled in the project's SDK settings, and at least one push key connected - APNs for iOS, FCM for Android and the web.
With no key configured, the API simulates sends and logs them. A campaign can therefore look like it went out with nothing leaving. That is useful in development and misleading in production: check your keys before the first real send.
The channels
| Channel | Where it shows |
|---|---|
| Mobile push | System notification, app closed or in the background |
| In-app | Modal, banner or full screen, app open |
| Web push | Browser, through FCM |
| Mobile landing | A destination page rendered by the SDK |
A campaign can combine several channels. It refuses to go out without content on at least one.
Campaigns
Notifications → Campaigns. A one-off send to an audience.
Life cycle
Draft → Scheduled → Sending → Sent, with Paused and Archived as
branches.
A campaign stays a draft as long as you want. Scheduling requires a date in the future; cancelling stays possible until the send has started.
Tutorial - a first campaign
- Notifications → Campaigns → New campaign.
- Name it for your team, not for the user: "Summer promo - iOS push" is still findable in six months.
- Choose the channel, write the title and the message.
- Choose an audience, or set rules on the fly.
- Send now, or Schedule for a date.
- Come back to Analytics an hour later: sent, delivered, opened, clicked.
Make a first send to a narrow audience. A badly worded push cannot be taken back, and it costs uninstalls.
Audiences
Notifications → Audiences. Reusable segments, shared between campaigns and automations.
An audience combines rules with AND / OR:
- platform (iOS, Android, web)
- language
- plan
- tags
- devices registered on the project
The number of matching users is estimated live while you build the rules. It is the most useful guard rail on the screen: an audience that drops to zero is visible before the send, not after.
A campaign can also carry its rules inline, with no named audience. Handy for a one-off; worth naming as soon as the segment is used again.
Automations
Notifications → Automations. A journey triggered by behaviour, not by a date.
The typical use case: onboarding, re-engagement, follow-up after abandonment.
| Setting | What it decides |
|---|---|
| Trigger | The event that brings a user into the journey |
| Steps | The messages, in order, with their delays |
| Exit rules | What interrupts the journey along the way |
| Re-entry | On every trigger, never, never while active, or after a delay |
An automation combines push, email and in-app in a single journey: the message follows the user wherever they are reachable.
Exit rules are not optional
The trigger brings people in, the exit event takes them out. A "you have not finished signing up" follow-up that keeps going after they signed up is the best way to get your app uninstalled. Set the exit event at the same time as the trigger, not afterwards.
The events come from the SDK, through trackEvent.
Templates
Notifications → Templates. Reusable models for in-app messages and mobile landings: modal, banner, full screen.
A template carries the layout; the campaign carries the content. Three campaigns that share a visual identity share a template.
Analytics
Notifications → Analytics. What the sends produced.
Engagement funnel: sent → delivered → opened → clicked. Every lost step reads at a glance.
Breakdown: volume by channel and by type (campaigns / automations).
Per-message performance: the detail, message by message.
What to look at first:
| Gap | What it says |
|---|---|
| Sent ≫ delivered | Stale tokens, or the wrong push environment |
| Delivered ≫ opened | The title is not appealing, or the timing is wrong |
| Opened ≫ clicked | The message promises something other than what it opens |
Settings
Notifications → Settings.
- Push channels: the state of the APNs and FCM integrations, with a direct link to their configuration.
- SDK: enabling the product on the project - without it, no device token is registered.
- User preferences: maximum number of devices per user, behaviour beyond that, handling of devices with no opt-in.