Quick answer
Push deliverability is the share of valid, eligible devices that receive a notification from APNs or FCM. Reliable diagnosis separates audience eligibility, provider acceptance, device receipt, display, and user open because each stage fails for different reasons.
Expert rule: Diagnose the funnel in order—eligible, accepted, received, displayed, opened—rather than guessing from opens alone.
A practical framework
A useful push notification deliverability program needs a shared model before it needs more campaigns or tooling. Use these four layers to align product, growth, design, engineering, analytics, and compliance:
- Eligibility: consent, audience rules, frequency caps, and quiet hours
- Provider acceptance: valid credentials, tokens, topics, payload, and quotas
- Device receipt: connectivity, OS policy, battery mode, and app state
- Display and action: channel settings, notification content, grouping, and routing
Step-by-step playbook
Move from a bounded use case to a measurable operating system. Document ownership and decision criteria at each step so the program can scale without creating inconsistent experiences.
- Track token creation, refresh, invalidation, platform, environment, and last-seen time
- Remove invalid tokens based on provider responses
- Log a campaign identifier from send request through app receipt
- Use platform-appropriate priority and collapse behavior
- Maintain a real-device test matrix for supported OS and app versions
What to measure
Clicks and opens are diagnostic signals, not the final outcome. Connect exposure to the user behavior and business result the experience is designed to change.
- Eligible devices and valid-token coverage
- Provider accepted, rejected, and invalid-token counts
- Confirmed receipt where platform instrumentation permits
- Display, open, and post-open completion by OS version
Worked example
If accepted sends remain stable but Android opens collapse after a release, segment by OS and app version. A changed channel identifier or disabled importance may be the cause even though FCM accepted every request.
The implementation should include a clear eligible population, a measurable exposure event, suppression after goal completion, and a control or holdout whenever causal lift matters.
Common mistakes to avoid
- Treating provider acceptance as confirmed delivery
- Sending sandbox tokens through production credentials
- Ignoring Android notification channel settings
- Comparing open rates without accounting for permission and measurement differences
These mistakes usually come from optimizing one message or dashboard in isolation. Review the full user journey and its guardrails before scaling a local win.
Implementation checklist
- Write a one-sentence user benefit for the push notification deliverability use case
- Define eligibility, exclusions, priority, and suppression before launch
- Confirm events, identity, consent, and fallback behavior with engineering
- Review accessibility, localization, privacy, and platform edge cases
- Predeclare the primary outcome, guardrails, and decision threshold
- Launch gradually, inspect segment-level quality, and document learning
Conclusion
Diagnose the funnel in order—eligible, accepted, received, displayed, opened—rather than guessing from opens alone. Teams that make this principle operational create experiences that are easier to understand, safer to scale, and more likely to improve durable activation, retention, or revenue.
Related resources
- Push Notification Opt-In Strategies
- Frequency Capping for In-App Messaging
- Push Notifications vs In-App Messages
Ready to put this framework into practice? AppStorys helps mobile teams build, target, experiment with, and measure contextual in-app and cross-channel experiences without waiting for every app release. Book a demo.
