Push Traffic : What It Is and How It Works
Push traffic is advertising delivered as browser notifications: a site collects consent, an ad network pools these subscriptions, and advertisers bid pay-per-click to message that database. Classic push arrives as a system notification well after you've left the originating site; in-page push fires inside a webpage, letting networks reach iOS users too. Both are bought mostly by affiliates and convert best on one- or two-step offers - adult and iGaming dominate demand on AdsCompass, alongside sweepstakes, dating and mobile utilities. Count the steps from click to payable action: past three, you're paying for intent an icon and headline can't create.
How the Push Notification Subscriber Base Is Built
Publishers build their subscriber base by asking visitors to grant permission to receive notifications. Advertisers don't buy a fixed audience; instead, they purchase access to that permission, and permissions decay. A subscriber is at their most responsive in the first days after opting in, least responsive on a base that has been sitting for months, and gone entirely once the browser reclaims the permission. The age of the pool matters as much as its size.
A push ad passes through four stages before it reaches a screen, and volume drops at each one.
- Service worker. The publisher's site registers a background script that the browser keeps running after the page is closed. This is what lets an ad reach someone who has already left the site.
- Subscription. When the visitor accepts the prompt, the browser returns an endpoint address and two keys used to encrypt the payload.
- Signing. The platform signs each transmission with a VAPID token, so the push service knows who is sending.
- Delivery. The message travels over the Web Push Protocol to the browser's own service: Firebase Cloud Messaging for Chrome, APNs for Safari, Mozilla's autopush for Firefox.
Deliverability therefore varies by browser, and a policy change at a single provider can reprice an entire region.
Android is best suited for this format. The permission granted in Chrome on an Android phone works exactly as intended: the notification appears on the lock screen and in the notification panel regardless of whether the browser is running, and the user grants permission with a single tap, without having to install anything. Mobile push advertising is, in essence, Android advertising. Chrome for desktop and Safari for macOS contribute significantly, while iOS contributes virtually nothing.
Push ads use a minimalist layout: an icon, a headline, a description, and a larger image that shows on desktop but is usually hidden on mobile. That leaves you about ten words to work with, so every one has to earn its place.
I would separate mobile and desktop devices at the launch stage, rather than after the first phase of optimization. Bid levels vary; bids are usually higher for mobile.
What's the Difference Between Classic Push and In-Page Push?
Classic push is delivered by the browser to subscribers who opted in. In-Page Push renders inside a web page, with no opt-in at all. Only the first uses the browser's push channel, and that's where every other difference starts: reach, timing, and how long an audience stays worth buying. On AdsCompass they're separate traffic types with their own auctions and floor prices, so the two CPCs aren't directly comparable.
| Parameter | Classic | In-Page |
|---|---|---|
| Delivery channel | Browser push service (FCM, APNs) | Rendered inside the page |
| Opt-in required | Yes | No |
| Reaches iPhone | Only installed web apps | Yes |
| Delivered when | Any time, browser closed | Only during an active page session |
| Creative | Icon, title, text, image | Icon, title, text |
| Subject to Chrome rules | Yes | No |
In-page push isn't push at all
In-page push ads are a banner styled to look like a notification and rendered inside the page, which is why the name misleads. Nothing is subscribed to and nothing runs in the background - the ad exists only while the page it's drawn on exists.
Run In-Page Push as its own campaign rather than mixing the two. The audience state is different in a way that shows up in conversion rate: one person agreed to notifications weeks ago and is being interrupted, the other is reading a page right now and is merely being shown something.
Does Push Traffic Work on iOS?
Yes, but only in one of the two formats. Classic web push doesn't work from a regular browser tab on iOS - it reaches an iPhone or iPad only if the user has installed the site to their Home Screen as a web app. Apple added this in iOS 16.4 (March 2023), and it requires three things: the site must serve a web app manifest, the user must add it through the Share menu, and the permission prompt must fire on a deliberate tap inside the installed app. Every step loses people, and an advertiser controls none of them.
Those subscribers who do get through tend to stick around - someone who installed a web app to their home screen isn't going to forget it exists. But collecting them at scale is the problem, which is why ad networks have almost no iOS push base to sell.
Mac is the exception in Apple's stack. Safari 16.1 brought web push to ordinary Mac websites in October 2022, no installation needed, so desktop Mac shows up in the inventory normally.
On AdsCompass, iOS reach comes through In-Page Push: no subscriber base to age, no permission to revoke. Any significant iOS push notification metric refers to in-page push notifications, not classic ones. If an ad network doesn't distinguish between these two types, its iOS metrics won't give you an accurate picture of what you're actually buying.
How Much Push Traffic Costs per Click
Push traffic on AdsCompass is sold on CPC, so you pay for clicks rather than impressions, and bids start from a tenth of a cent. That opening figure is the auction floor: the level at which a campaign becomes eligible to compete.
What a click clears at is set by the auction itself, which is what keeps the price tied to real demand. It follows what other advertisers are bidding at that moment, the audience behind the publisher's site (which countries visitors come from, on which devices) and which format is being bought. The same subscriber can clear at one price on Push and another on In-Page Push on the same day, which is why a fixed rate card would be out of date the moment it was published. Popunder traffic is priced in the same auction and on the same model, at a lower floor.
Live figures sit in the estimation tools section of the platform, updating from auctions that have already closed. One thing is worth knowing before you read them: the recommendation depends on your goal. Buying the largest volume of clicks in a GEO returns a different number than buying the cheapest clicks in the same GEO, so decide which of the two you want first. The same market has two correct answers.
Budget from that figure. Bidding above the floor is what puts a push ad campaign into competitive auctions and brings back data you can act on. Entry starts at $50, though the figure I give advertisers is $500: push volume is spread across a large number of individual sources, and each one needs enough spend to show what it is worth.
| Parameter | Value |
|---|---|
| Buying model | CPC only - Push, In-Page Push and Pop all bill per click on self-serve |
| Traffic types | Push, In-Page Push |
| Minimum bid | $0.001 Push, $0.0008 In-Page Push |
| Test budget | $50 minimum, $500 recommended |
Why In-Page Push Sits Outside the Browser Rules
Every notification rule Chrome has introduced applies to the Push API alone, and in-page push uses neither that API nor the Notifications API. The format collects no permission at all, so Chrome has nothing to revoke, cap or redesign. Permission revocation from October 2025, the January 2026 cap of 1,000 push messages a minute for senders judged disruptive, and the redesigned Android opt-in prompt announced in July 2026 all pass it by.
The practical consequence is that in-page volume is insulated from a category of risk that classic push carries. A rule that shrinks subscriber bases across the market has no effect on inventory that has no subscriber base. Popunder ads sit outside the same rules for a different reason: the window opens on a user click, which is exactly what the browser asks for. That is worth factoring into volume planning: a plan built on classic push in Chrome carries an exposure that the same plan built on in-page does not.
How Publishers Earn From Push Traffic
Publishers earn from push traffic by collecting notification permissions and letting an ad network monetize them, which makes it one of the few formats that keeps paying after a visitor has left. A script requests permission, the endpoint joins the network's base, and the publisher takes a share of what advertisers pay for clicks to their subscribers. Someone who reads one article and never returns can generate revenue for months.
What a base earns is set by the same auction described above, so two sites with identical subscriber counts can earn very differently. Decay is the factor publishers underestimate. Since October 2025 Chrome has removed notification permission from sites that combine high send volume with very low engagement, which acts on bases already collected, and its redesigned Android opt-in prompt makes new permissions slower to gather.
Consent is a legal object as well as a technical one. In the EU a notification permission falls under GDPR and the ePrivacy Directive, whose Article 5(3) requires consent before anything is stored on or read from a user's device. The endpoint counts as personal data, and consent has to be informed and revocable rather than harvested by a prompt fired on page load. Compliance and revenue point the same way here. Google's experiments found that sites sending fewer notifications saw clicks increase rather than fall, and a prompt fired on load collects exactly the permissions Chrome now revokes. Asking after a visitor has read something produces a smaller base that survives longer and clicks more.
FAQ
