Design a useful push notification journey

Choose a useful moment, respect permission and recover safely when the reminder cannot arrive. Define the customer outcome and a fair experiment before claiming the notification helped.

Bring them back to something useful

A notification earns its place when the destination helps the customer finish what they came to do.

Worked scenario: Alex Lee · Friday visit. The following is an illustrative application workflow, not a live result.

1. Have a reason. A confirmed visit is approaching. Your application has a useful reason to contact Alex. Observable state: Concept · Relevant update.
2. Respect choice. The example only shows the notification when the customer has allowed it. Observable state: Concept · Permission checked.
3. Open. A tap leads to the relevant application view, carrying the visit reference. Observable state: Concept · Destination selected.
4. Continue. Alex sees the time, location, and booking details without searching through the application. Observable state: Concept · FN–1042 in view.

What this changes

• For your customer: Return directly to the task that matters.
• For your product: Connect the notification to a meaningful application state.
• Before you launch: Configure the channel, permissions, and device lifecycle for your app platforms.

Explore the illustrative example ↗

Before you call it complete

Confirm each observable state in your own integration. The application must establish the business outcome separately from a successful API request or delivery event. Exercise the relevant unsuccessful case in the product’s working example and follow its technical references.

Make the reminder useful without depending on it

Set up Push for your app or browser platform. Connect your app or browser platform, configure notification credentials and test registration and permission before sending. This guide covers the customer journey and its measurement.

Worked example: Alex has a confirmed studio visit at 14:00. At 13:30, a concise reminder can help them find the booking details. The booking stays accessible in the app even if no notification arrives. The booking service owns schedule and authorization; the app team owns permission, device association and the destination; the messaging owner owns timing and contact policy.

1. Choose the useful trigger. Use the current confirmed booking, not a stale copy from an earlier schedule. Suppress the reminder if the visit is canceled, moved or already past. Resolve the visit's time zone and local customer timing; do not repeatedly remind because a job was retried.
2. Ask in context. Explain appointment updates when the customer books, then request permission through the supported OS flow. Respect app preferences and current OS settings. Denied means no push; provisional Apple authorization is quiet delivery, not full banner/sound permission. This guide changes no device setting.
3. Set the destination. The notification identifies a useful booking action without private lock-screen detail. The app authenticates the customer and authorizes FN–1042 before opening it. Expired sessions return through safe sign-in; changed or canceled bookings display current state rather than an old promise.
4. Set the deadline. This 13:30 reminder loses value at 14:00. Stop generating it at the deadline and select supported expiry for each platform. Check collapse/replacement semantics when schedules change. A provider's accepted message ID does not prove arrival; zero TTL has special immediate-delivery behavior in FCM, not a universal “never expires” meaning.

Planning decision: keep booking details available in the app, prepare one contextually permitted reminder and connect the configured Bird Push channel to the app’s notification journey. The app team records permission and deadline tests before any customer pilot. Apple permission and FCM message lifespan inform these platform decisions.

Send a controlled campaign in Bird

Open your Bird workspace with a configured Push channel and message template. Follow Create and send a Push Campaign to choose the channel, test audience and template, then review the message before scheduling it.

Write the title as the useful update and the body as the next action. Check the preview at the actual device text size; a character count alone does not predict truncation. Avoid personal details that could appear on a locked or shared device. These examples are editorial choices for the fictional journey:

Use one clear tap destination. Keep the promised action available through normal app navigation too. Check long translations, large text, quiet/provisional presentation, offline startup and expired login. Apply frequency and quiet-time rules to the customer across their devices; two registrations should not automatically mean two useful reminders.

Use the campaign's test option first. Check the title, text and tap destination on the intended device. Complete the same booking action from the notification and from normal app navigation; both should open the current authorized booking. Keep the campaign result and the application's booking event distinct when measuring the outcome.

Recover without inventing permission or delivery

Permission denied or quiet

Denied permission stops the outbound push path. Keep the booking accessible, respect the decision and explain available settings when the customer asks. Provisional permission remains its own quieter mode. Neither state authorizes another channel automatically.

Registration invalid or customer changed

The app team owns current account/device association, registration freshness and invalidation. Retire an invalid destination; obtain current registration through the supported platform flow and recheck permission before a later useful reminder. On logout or reassignment, prevent a previous customer's private booking from reaching the next user. Do not retry a stale registration indefinitely. Follow Bird device registration and logout handling and the platform token guidance.

Deadline passed or receipt missing

An offline device returns at 14:10. Suppress the obsolete 13:30 reminder under the supported expiry policy and show current booking state when the customer opens the app. Test actual platform behavior before promising stale-message removal. A missing receipt before the deadline stays unknown: it may reflect unavailable telemetry, not failure. Reconcile the original attempt and do not create a duplicate notification or alternate contact solely because an acknowledgement is absent.

Rehearse the allowed case and all four blocked cases in the existing Push journey example. The allowed concept opens the original booking card. Denied permission, expired registration, unknown receipt and stale reminder supply distinct recovery guidance; Recovery does not grant permission or register a device. Prepare and export a local brief with the trigger, app owner and deadline.

Separate a recorded journey from a caused outcome

Attribution assigns an observed outcome to a campaign under a stated rule. It does not establish that the notification caused the outcome. Alex could have opened the booking without a reminder. Keep provider acceptance, supported device receipt, notification interaction and application outcome as separate observations; missing receipt is not zero engagement.

For this illustrative rule, attribute the first authorized booking-details view between 13:30 and 14:00 to the most recent qualifying reminder tap in that interval. Join a safe campaign/attempt reference to the owning booking event, deduplicate by customer and booking, and disclose how competing touches are handled. A normal app navigation can produce the outcome without a tap, so it belongs in the outcome analysis even though this tap-based rule does not attribute it. This is an application measurement design, not a supported Bird tracking product.

OneSignal's confirmed receipt documentation illustrates why device acknowledgement needs specific platform/SDK support and is distinct from opening. Do not assume that capability exists in Bird or infer failure from missing evidence.

Write the experiment before reading the results

1. Question and eligibility. Does this optional reminder increase timely access to booking details? Include consented customers with one upcoming confirmed booking, an eligible app/platform and permission at assignment. Required service or safety notices stay outside this optional-reminder experiment.
2. Assignment. Randomize by stable customer identity to reminder or no-reminder holdout before sending. Keep all of a customer's devices in that assignment and use the first eligible booking in the study. Keep other relevant communications and the booking experience the same.
3. Primary outcome. Count customers with an authorized booking-details view from 30 minutes before the visit until its start, regardless of notification tap or receipt. The booking service owns this event. Report unique outcome customers divided by all assigned eligible customers in each group.
4. Missing evidence. Failed delivery, later permission changes and missing receipts stay in their assigned groups. Do not compare only openers or delivered devices. Report missing application telemetry separately; a logging outage is not a confirmed non-conversion.
5. Analysis and decision. Before launch, have the analyst set sample size from baseline rate and minimum useful effect, a fixed analysis window, uncertainty method and stop rules. Report the rate difference with its uncertainty. Do not stop on the first favorable result. Track complaints, notification opt-outs, duplicate contact, stale reminders and operating cost alongside the outcome.

Worked arithmetic, entirely fictional

Assigned reminder: 1,000 customers
Booking outcome: 30 / 1,000 = 3%
Assigned holdout: 1,000 customers
Booking outcome: 20 / 1,000 = 2%
Observed difference: 1 percentage point
Illustrative large-sample 95% interval:
about -0.37 to +2.37 percentage points

The interval is a teaching approximation for these independent fictional groups, not a prescribed production analysis. It spans no effect: the sample does not establish a reliable benefit. No measured Bird uplift is claimed. Even if all 30 reminder-group outcomes were attributed by a rule, they would not become 30 incremental outcomes.

Diagnostic denominator example, assuming one attempt per assigned customer: 900 accepted notification attempts out of 1,000 submitted attempts; 700 confirmed device receipts out of those 900 accepted attempts where receipt support was confirmed; 100 unique tap customers out of 1,000 assigned reminder customers. These are fictional counts with different units. Report receipt support and unknowns alongside them, never swap 700 devices or 100 openers into the primary customer denominator. If receipt support covers only a subset, report that eligible subset explicitly.

Decision from the example: retain the holdout result and uncertainty; inspect guardrails and data completeness before changing the journey. More taps alone do not justify rollout. Firebase's messaging experiment guide is a primary example of a no-message baseline, defined goal and experiment analysis. Its product setup is separate from this customer-level application design and establishes no Bird integration.

Build the complete path

Copy this record before a pilot. Use the local export for the journey fields, then add the experiment and operational evidence.

Customer value / booking owner / app owner / contact owner:
Confirmed trigger / time zone / quiet timing / deadline:
Platform / application and channel / implementation owner:
Permission context / denied and provisional behavior:
Registration freshness / logout association / invalidation:
Authenticated destination / changed booking / expired session:
Expiry and replacement policy / stale-reminder test:
Original attempt / supported receipt / unknown recovery:
Experiment question / eligibility / customer assignment:
Outcome owner / deduplication / start and end of window:
All assigned customers per group / unique outcome customers:
Attribution rule / qualifying tap / competing touch policy:
Attempt and device metrics / support coverage / unknowns:
Baseline / minimum useful effect / sample size / analyst:
Analysis date / uncertainty method / missing-data decision:
Opt-outs / complaints / duplicates / cost / stop rules:
Evidence / unresolved owner / next check / go or hold:

For Fieldnotes: optional booking reminder at 13:30, expires at the 14:00 visit; authenticated FN–1042 destination; app team owns permission and registration; analyst owns customer assignment and outcome counts. Complete the expiry and permission tests, then use the Push campaign procedure for the controlled send. Talk to the Push team about your application and volume requirements.

Connect the next step

• First working Push notification: register a browser, send through the API and open the destination.
• Push troubleshooting: audience, payload, credentials, permission and app-state diagnosis.
• Push journey example: local allowed, denied, invalid-registration, unknown and expired cases.
• Email tracking and metrics: measurement definitions and limits for a separately supported channel.

Your application owns the customer relationship and business actions. Preserve the appropriate identity, consent, and outcome when you move between products.

Questions to resolve

Does an attributed booking prove incremental value?

No. Attribution follows a rule. A controlled comparison estimates the effect, with uncertainty and guardrails.

Can a missing receipt trigger another reminder?

It is insufficient on its own. Reconcile supported evidence, usefulness and contact policy before another action.

Go deeper in the documentation

• Apple permission: context, settings and provisional authorization.
• FCM lifespan: acceptance and expiry.
• FCM registration: freshness and invalidation.
• OneSignal confirmed receipt: platform-specific acknowledgement limits.
• Firebase messaging experiments: baseline and outcome analysis.

Explore Push and its interactive example ↗