A campaign push goes out to 100,000 installs. The platform dashboard says 100,000 sent. The buyer-facing metrics show 86,000 delivered. Where did the 14,000 go? This is a question every brand asks once they have a push program running at scale. The answer involves four or five mechanics that compound into the delivery gap.
Stale push tokens
A push token is the unique identifier that lets Apple Push Notification Service (APNs) or Firebase Cloud Messaging (FCM) route a message to a specific device. Tokens expire when the user reinstalls the app, switches devices, or experiences various platform-level resets. A push to a stale token fails silently — it does not bounce, it just does not deliver.
Brands with active install bases see 5–10% of tokens become stale every 90 days. The fix is regular token refresh: the app updates its token in your backend on every launch, and your push platform invalidates tokens that have not been refreshed in 90+ days. Without this hygiene, your apparent install base is inflated and your delivery rate degrades over time.
Permission revocation
Users can revoke push permission in iOS Settings or Android Settings at any time. When they do, the app is not always notified. The next push you send goes out, the platform accepts it, and the user never sees it. Your dashboard reports "delivered" but the device dropped the message.
The fix is to detect permission state on every app launch and update your delivery base accordingly. Users who revoked permission should be excluded from delivery counts and re-permissioned via a contextual prompt when they re-engage with the app. This both cleans up your metrics and lets you recover the revoked users instead of writing them off.
Android low-power mode and battery savers
Android handset makers run their own battery optimization layers on top of FCM. Samsung, Xiaomi, Huawei, and others throttle background processing aggressively for apps the user does not open frequently. The result: pushes accepted by FCM but delayed or dropped at the device level before the user sees them.
This is the hardest delivery gap to close because the cause is downstream of you. The mitigations: ask users to whitelist your app in battery settings (a polite contextual prompt the first time they grant push permission helps), use high-priority push for urgent messages (they bypass some throttling), and accept that a 5–10% delivery shortfall on Android is structural rather than fixable.
iOS silent drops on inactive users
iOS aggressively throttles push for apps the user has not opened in 30+ days. The behavior is opaque: APNs accepts the message, marks it delivered, and iOS quietly does not show it. The user never knows. The brand sees "delivered" in the dashboard but no engagement.
The defensive move: segment your push base by recency. Users active in the last 7 days are the high-deliverability cohort. Users dormant for 30+ days are at risk. Re-engagement campaigns that target dormant users should set the expectation that delivery there will be lower; budget your incrementality math accordingly.
Payload rejections
Sometimes the platform rejects a push because the payload is too large (over 4KB on APNs), contains invalid characters, or violates a platform rule. These rejections happen in the platform infrastructure, often not surfaced clearly to the brand.
The fix: a pre-send validation step that checks payload size, character encoding, and platform-specific quirks. Most modern push platforms handle this for you. If you are seeing batch rejections in the dashboard, check what fraction of pushes are bouncing before fingering downstream delivery issues.
“The delivery rate gap is mostly hygiene. Stale tokens, silent permission revocations, and Android battery savers — the boring causes account for most of the missing messages.”— Push platform engineer we work with
What good delivery looks like
For a well-maintained push base, segmented by recency, expect: 95–98% delivery on the active cohort (users open in last 7 days), 85–92% on the recent cohort (last 30 days), 60–75% on the dormant cohort (30–90 days), and 30–50% on the long-dormant cohort (90+ days). The aggregate delivery rate across all installs will sit somewhere in the 80–88% range depending on cohort distribution.
Brands that report 95%+ aggregate delivery across the entire install base are usually either reporting the wrong metric (sent, not received) or have a very fresh install base that has not yet developed dormancy. Both are temporary states.
Monitoring delivery health
Three metrics to track weekly: (1) delivery rate on your active cohort, (2) opt-in rate trend across the install base, (3) token freshness — what percentage of registered tokens were refreshed in the last 30 days. Drops in any of these signal a problem before it becomes obvious in your revenue metrics.
The work is unglamorous but compounds. A 5-point lift in aggregate delivery from cleaning up token hygiene is worth as much as a 5-point lift in tap-through rate from better creative. Both are real revenue. Most brands focus on the creative and ignore the hygiene; the brands that do both pull ahead.
