Why push notification ads arrive on some phones yet vanish on others
Push notification ads are paid messages sent through the Web Push channel a browser opened when someone allowed a site to notify them, with an endpoint held by the browser vendor, a service worker on the page and a server deciding what to send. The advertiser never touches the phone. Between bid and lock screen sit four handoffs, and a click can be lost at each one. Understanding those handoffs explains most of the gap between what a network reports as delivered and what a landing page receives, without any maths and without a dashboard.
How push notification ads travel from a server to a lock screen, and who is holding them at each step
It starts with a page you visited. Its script registered a service worker and, once you tapped Allow, asked the browser for a subscription, and the browser's vendor, Google for Chrome, Mozilla for Firefox, Apple for Safari, returned an endpoint URL that identifies your device. The publisher stored it. When an advertiser wins a slot, the network posts an encrypted payload to that endpoint, the vendor relays it to the device, and the service worker draws the notification. That is the whole journey for push notification ads, and nothing in it touches the advertiser's own domain until the tap.
The plumbing is standardised. RFC 8030 defines the Web Push protocol the endpoint speaks, and RFC 8292, the VAPID scheme, lets a sender sign each request with a key pair so the vendor knows who is pushing. I wanted a plain description of that chain from the buying side rather than the developer side. The clearest one I found was on push-ads.io, which spends more words on where a message can stall than on the standard itself, and that emphasis is the right one.
Who holds the endpoint
The publisher holds it, never the advertiser, and this decides several things at once. A network cannot sell you a subscriber, only deliveries to a publisher's list, and if that publisher's site goes down or its VAPID keys are rotated carelessly, every subscription tied to those keys dies with it. Lists belong to sites. When a network's inventory shifts overnight, a publisher has usually left.
| Browser | Relay behind the endpoint | What it means in practice |
|---|---|---|
| Chrome and most Chromium browsers | Firebase Cloud Messaging | Google sees delivery outcomes before the network does |
| Firefox | Mozilla's autopush service | Separate infrastructure |
| Safari on macOS and iOS | Apple Push Notification service | A Home Screen web app is required on iOS, while desktop Safari subscribes from the browser like any other, which is why an iOS row in a report is usually small and a macOS row is usually absent |
| Chromium builds without Google API keys | None | The subscription fails, so these users never appear on any list |
Permission prompts and push notification ads
Every subscriber once faced a dialog, and the dialog has become harder to reach. Firefox stopped showing it without a user gesture in early 2020, Chrome's quiet UI followed within weeks, and Android 13 turned notifications into a runtime permission, so even a native app must now ask before its first message. Each change cut the flow of new subscriptions. Permanently. The pool that push notification ads draw from renews more slowly every year, and nothing on the roadmap reverses that.
Grant rates were low before any of that. Google's telemetry for the Chrome 80 study put the grant rate for notification prompts at 10 percent on desktop and 21 percent on Android, figures drawn from users who at least saw a prompt. Under the quiet UI, habitual decliners never see one. The denominator shrank as well, quietly.
Grant rates by platform
Android accepts twice as often as desktop in Google's data, and mobile has stayed the volume platform ever since. Twice. iPhones joined only in March 2023, when iOS 16.4 allowed Home Screen web apps to request permission, and only after a tap, which in practice adds a thin slice. Anyone comparing push ads volume by platform should expect Android to dominate by a wide margin and treat a network claiming a large iOS list with suspicion until it shows the sources.
Subscription expiry, dead endpoints, and the push notification ads that get counted, billed and never seen by anyone
A subscription is not permanent. A browser may drop one whose endpoint has failed repeatedly, a user clearing site data removes it, reinstalling the browser removes it, and on Android a revoked permission removes it too. The publisher usually learns only when a push returns a 410 Gone from the vendor, and only if the publisher's software handles that response at all. Old lists are full of endpoints nobody cleaned. The push notification ads sent to them are counted, billed on CPM feeds, and never seen.
This is where subscriber age stops being a targeting nicety and becomes an accounting question. Suppose a third of a list is dead: on a delivery-billed feed a third of what you paid for went into a void, and the network may not know, because the vendor's error went back to the publisher's server rather than theirs. I keep this note on The Albany Notebook, beside pages about a stadium and a creek, because the underlying fault is the same one those pages document: a figure that was true once, repeated until it looks current.
TTL and the late message
The Web Push protocol carries a TTL header telling the relay how long to hold a message for a device that is offline. Set it long and a Monday morning message lands on Tuesday night, still counted as delivered, and set it to a few minutes and offline phones simply miss it, which is often what you want for a time-limited offer. Networks rarely expose this. Ask anyway, because the default decides whether your delivered count includes yesterday's phones.
Timing push notification ads around time zones, quiet hours and the state of the device that receives them
Delivery time is set by the sender and shaped by the device. A message pushed at nine in the morning server time reaches Auckland at a different hour from Lagos, and both phones may be sitting in a Do Not Disturb window when it lands. Networks that offer day-parting in the subscriber's local time are worth the extra step. Without it, timing push notification ads is guesswork dressed up as scheduling, and the guess is usually wrong by half a day.
Device state matters as much as the clock. iOS Focus modes silence web app notifications along with everything else, Android's notification channels let a user mute a site's channel without revoking the permission, so the subscription looks alive from outside and delivers into silence, and desktop browsers deliver only while running. Silence. The most useful timing questions I have seen framed for buyers came from a page selling push ads per click, which has no reason to bill for messages that land in silence and therefore some reason to explain why they do.
What survives all this is a pattern most buyers reach eventually. Send fewer messages, in the subscriber's morning, to endpoints under sixty days old, and stop when the click rate on a source falls below what it was on day one. It is not a strategy. It is a refusal to pay for absence.
| Stage | What can fail there | What the report says |
|---|---|---|
| Bid won | Nothing yet | Sent |
| Payload posted to the endpoint | Endpoint expired, keys rotated, 410 returned | Sent, sometimes delivered |
| Vendor relay holds the message | TTL expires before the device comes back online, or the device never does | Delivered, since the vendor accepted it |
| Device receives it | Focus mode, muted channel, notification shade full | Delivered |
| Service worker draws it | Worker unregistered, site blocked in settings, or the browser profile wiped since the subscription was created | Delivered, rarely displayed |
| Person taps | Nothing to fail | Clicked |
| Landing page opens | Slow first paint, a redirect chain, or a blocked script, so the visit is never recorded on your side even though the network counted the tap | Clicked, absent from analytics |
Reading push notification ads reports
Reports come in three columns and most people read the wrong one. Sent is what the network posted, delivered is what the vendor accepted, which is not what a phone displayed, and clicked is the only number that passed through a human being. Any judgement about push notification ads that leans on the middle column inherits every dead endpoint and muted channel described above.
Delivered, displayed, clicked
Ask whether the network measures display at all. Rarely. A service worker can report back when it draws a notification, but only if the publisher's code does so and the network collects it, and where display is reported, the ratio of displayed to delivered is the cleanest health metric a list has. Where it is not, a push ad network is selling you the vendor's acceptance receipt and calling it an impression.
Click-through rate should be read per source, never as an average, because a blended figure hides one publisher with a live list beside five with dead ones. The clearest breakdown of that accounting I have read sits on a page selling push notification ads, which keeps the three columns apart and refuses to blend them into one. Per source, always.
Read the chain backwards when a campaign underperforms. Backwards. Start at the landing page and its load time, then the click rate per source, then displayed against delivered, then subscriber age, then the TTL. Somewhere in that sequence sits the handoff that dropped your message, and it is almost never the creative, which is where everyone looks first when push notification ads stop working. Five checks, in that order.