Push Notification Pre-Launch Checklist

How to use this checklist

This is a working checklist, not an article. Print it or keep it open in a tab, assign one owner per section, and treat each section as a gate: you do not move to launch day until every box in it is either checked or consciously waived in writing. Most first-campaign failures are not creative failures — they are an unchecked box in opt-in, deliverability, or measurement discovered after the send.

The four sections mirror the lifecycle of a push program. Opt-in and consent decide who you may message and whether they trust you. Deliverability decides whether the message physically arrives. Content decides whether the arrival was worth it. Measurement decides whether you can prove any of it. The final section is a launch-day sign-off you fill in once, right before the first real send.

The checklist assumes app push via APNs (Apple) and FCM (Google). Nearly all of it also applies to web push and to wallet-pass campaigns — the lock-screen channel PushNotice provides — with one simplification: wallet passes skip the app-install and OS-permission steps, so for that channel the opt-in section reduces to the consent-record and opt-out items.

Opt-in and consent

The permission prompt is a one-shot resource on iOS — a denied OS dialog is effectively permanent. Everything in this section protects that first ask and the legal record behind it.

• Permission ask is triggered by a user action, not app launch

  Ask after the user does something notifications genuinely improve — placing an order, following a topic — never on first open before any value is shown.

• Pre-permission primer screen is in place

  A soft-ask explains what you will send and roughly how often before the OS dialog appears, so a not-now costs nothing and a yes is informed.

• iOS provisional authorization has been considered

  Quiet delivery to Notification Center lets skeptical users sample your notifications without ever seeing a hard prompt.

• Android 13+ runtime permission flow is tested

  POST_NOTIFICATIONS is a runtime permission on Android 13 and later — test the ask on a current OS version, not only on older devices where it is granted by default.

• Android notification channels are defined by category

  Separate channels for orders, promotions, and alerts let a user mute one category without killing the whole channel.

• Consent is recorded with timestamp, source, and scope

  Store when, where, and what each user agreed to — you will need it for audits, complaints, and debugging.

• A preference center exists, not just on/off

  Users can choose categories and frequency; the only alternative to too many is usually none.

• Opt-out is honored across every sending system within minutes

  Suppression must apply to campaigns, automations, and transactional-adjacent sends alike — one message after opt-out is a trust and legal problem.

• The denied-permission path is designed

  The app works fine without notifications, and any re-ask waits for a genuinely better moment — iOS will not show the OS prompt again, so the route is Settings.

• Opt-in state is synced between device and backend

  Handle the case where a token still exists but the user has since revoked permission in OS settings.

• Legal review is done for every market you send to

  Marketing-push consent rules differ by region (GDPR and ePrivacy in the EU, among others) — confirm your basis for each audience before launch.

Deliverability and infrastructure

Delivery failures are silent by default: the campaign dashboard says sent while lock screens stay dark. This section makes the pipeline observable before it matters.

• Production push credentials are verified end to end

  The APNs key and FCM service account belong to the production app ID and project, and one named person owns rotation and expiry.

• Sandbox and production environments are cleanly separated

  A build pointing at the wrong APNs environment fails silently — send a real test through the production path before launch.

• Test sends verified on physical devices, both platforms

  Check delivery with the app in foreground, background, and force-quit, and with the device locked — behavior differs in each state.

• Device token refresh is handled

  Tokens rotate; the app re-uploads its token on every launch and the backend updates the record instead of accumulating duplicates.

• Invalid tokens are pruned from feedback responses

  Process unregistered and expired errors from APNs and FCM and stop sending to dead tokens — persistent errors can hurt your sending health.

• Message TTL is set deliberately per campaign type

  Decide how long a message is worth delivering to an offline device — a flash-sale push has no business arriving tomorrow.

• Collapse behavior is decided

  Use collapse identifiers so stacked updates about the same thing replace each other rather than piling up.

• Priority levels match message urgency

  High priority wakes devices but is throttled when abused; default to normal priority for anything that can wait a few minutes.

• Full-audience send duration is known

  Time a complete send end to end in staging — a campaign that trickles out over an hour changes your quiet-hours and expiry math.

• Quiet hours are enforced in the recipient's time zone

  Local time, not server time — a 9 a.m. send from your office is a 3 a.m. send somewhere else.

• A per-user frequency cap spans all sending sources

  Overlapping automations and campaigns must share one cap, or a user can get three messages in a morning from three well-behaved systems.

• Delivery failure monitoring alerts a human

  Error-rate spikes from APNs or FCM should page or message someone, not sit in a log file.

• The kill switch has been rehearsed

  Someone has actually paused a send mid-flight in staging, and everyone on the launch knows who can do it in production.

Content and message quality

A notification is read on a lock screen in about a second, often truncated. Every item here assumes the least generous rendering, not the marketing mockup.

• The point is in the first few words

  Assume truncation on both platforms — if the message only works when fully expanded, it does not work.

• Title survives truncation

  Keep titles roughly within 30 to 40 characters and check how they clip on a small phone, not just in the composer preview.

• One message, one action

  The tap should have a single obvious next step; two ideas in one notification means two weak notifications.

• Deep links are tested on both platforms

  The tap lands on the exact intended screen — including from a cold start, while logged out, and after the linked content has expired.

• Every personalization token has a fallback

  First-name and similar merge fields need defaults so nobody receives the message with a blank where their name should be.

• Rich media degrades gracefully

  The notification must make sense if the image never loads, and image dimensions match each platform's requirements.

• Emoji and special characters are render-checked on devices

  Check both platforms and at least one older OS version — a broken glyph reads as a broken brand.

• A second person has proofread the actual lock-screen preview

  Review the notification as it renders on a device, not the copy document it came from.

• Urgency claims are true

  Ends tonight must actually end tonight — false scarcity is the fastest way to train opt-outs.

• The sender is recognizable at a glance

  App name and icon identify you instantly; a user who has to wonder who is messaging them is already annoyed.

• Localization is complete or the segment is scoped

  Either every target language is finished or the audience excludes users you cannot address properly — no machine-translated surprises.

• Expired-content behavior is defined

  Decide what a user sees when they tap a two-day-old notification about a promotion that has ended.

Measurement and analytics

If measurement is wired after launch, the first campaign — the one with the cleanest audience you will ever have — produces no usable data. Wire it first.

• The primary metric is defined in writing before the send

  One number — taps to purchase, redemptions, sessions started — agreed by everyone who will later judge the program.

• Sent, delivered, and tapped are tracked as separate numbers

  Conflating them hides infrastructure problems inside engagement numbers; a delivery drop looks identical to a creative flop otherwise.

• The attribution window is agreed and fixed

  Decide how long after a tap a conversion counts, write it down, and use the same window for every campaign so results stay comparable.

• A holdout group is planned

  A small segment that receives nothing is the only honest answer to what the channel is actually adding.

• Opt-out rate is a per-campaign dashboard metric

  Treat it as a primary health signal reviewed with every send, not a monthly afterthought.

• Uninstalls and permission revocations are watched after each send

  A spike after a campaign is the audience answering you — make sure that answer is visible.

• Campaign naming and tagging conventions are set

  A consistent taxonomy and link parameters decided now save you from unqueryable results three months in.

• Results break down by platform

  iOS and Android differ in delivery mechanics and audience behavior — a blended number can hide a completely broken half.

• Tracking is verified end to end with a real test send

  Fire one test campaign and watch the delivery, tap, and conversion events arrive in analytics before launch day, not after.

• Baseline metrics are captured before launch

  Record current conversion and retention numbers now, or the after will have no before.

• A reporting owner and cadence are named

  Who reads the numbers, on what schedule, and what threshold triggers a change — otherwise dashboards decorate rather than decide.

Launch-day sign-off

Fill this in once, immediately before the first real send. If any field is blank, that blank is the reason to wait.