In-page push and classic push ads both use the same "chat head" or "toast" creative style, but they run in completely different places. In-page push renders inside your site's own HTML — no permission required, no subscriber list, live the moment the page loads. Classic push renders through the browser's or OS's native notification system, and only reaches people who already opted in via a permission prompt, often days or weeks after they left your site. If you need revenue from the traffic you have right now, in-page push is the more reliable starting point. If you can build and maintain a subscriber base, classic push pays better per impression but takes longer to prove itself.
Neither format is universally "better" — they solve different problems. In-page push monetizes a page view; classic push monetizes a relationship with a returning visitor. The right choice depends on how much traffic you get, how many of those visitors you can realistically get to opt in, and how patient you are before revenue shows up.
| In-page push | Classic push | |
|---|---|---|
| Where it appears | Inside the page, styled as a notification | Native OS/browser notification, outside the browser |
| Requires opt-in | No | Yes — a permission prompt |
| Revenue timing | Immediate, tied to page views | Delayed, tied to subscriber list growth |
| Typical fit | New or low-traffic sites, all verticals | Established sites that can sustain a subscriber list |
| Main risk | Can look like a fake system alert if styled aggressively | List decays fast; browsers restrict prompt behavior |
| Setup effort | One ad tag, works immediately | Tag plus a permission-prompt strategy and ongoing list hygiene |
The table oversimplifies one thing worth saying plainly: classic push isn't just "in-page push, but better." It depends on a subscriber list that has to be built, maintained, and re-earned, and that list decays whether you touch it or not.
In-page push ads
In-page push is a creative format, not a delivery mechanism — the "push" look (an icon, a headline, a short line of body text, styled like a phone alert) is rendered directly in the page's DOM, usually in a corner or as a banner. Because it's just HTML and CSS running on your page, it doesn't touch the browser's notification permission system at all. There's nothing for the visitor to accept or decline. It shows up the moment the ad script loads, the same way a banner or native ad slot would.
That's the format's biggest practical advantage: every page view is a monetizable impression from day one. A brand-new site with no returning audience and no subscriber base can still run in-page push and earn from its first visitors. It also sidesteps the platform-level restrictions that have made classic push harder to run — since nothing asks for permission, there's no permission prompt for a browser to throttle or a user to dismiss.
The trade-off is that in-page push only exists while the page does. Close the tab, and the ad is gone — there's no re-engagement mechanism, no way to reach that visitor again unless they come back on their own. Revenue is capped by traffic volume in a way classic push isn't. There's also a design responsibility here: because the creative mimics a system notification, it can read as deceptive if it's styled too close to an actual OS alert (fake close buttons, fake "your device" branding). Reputable ad networks restrict this in their creative policies, and it's worth holding your own placements to the same standard — a push-style ad that looks like a real system warning erodes trust in your site, not just the ad.
Classic push ads
Classic push ads run through the browser's or operating system's actual notification system — the Push API and the Notifications API that Chrome, Firefox, and most mobile OSes support natively. To send one, a visitor first has to grant your site notification permission through a native browser prompt. Once they accept, you (or your ad network) can push a notification to their device at any time afterward, whether or not they're on your site — it lands in their notification tray like a message from any app.
That persistence is the appeal. A subscriber who opted in last month can still see a notification today, so classic push turns a single visit into an ongoing channel instead of a one-time impression. It generally commands higher CPMs than in-page formats because the audience is opted-in and the format interrupts more directly than an on-page element.
The cost is everything it takes to get there. The permission prompt itself is a conversion funnel — most visitors decline or ignore it, and browsers have deliberately made that prompt harder to win. Chrome, for example, rolled out a "quieter" permission UI specifically to cut down on sites that hit every visitor with a notification request on page load, replacing the disruptive full prompt with a muted, easy-to-ignore icon for sites with low opt-in rates (Chromium blog). Even after someone opts in, lists decay: people uninstall browsers, switch devices, or simply stop engaging, and a list you don't refresh loses value every week. Running classic push well means treating it as ongoing list management, not a one-time ad tag.
How to choose between in-page push vs classic push ads
Start with traffic volume and consistency. If you're getting steady daily traffic, in-page push is the lower-friction choice — it monetizes what you already have without asking anything of the visitor. If your traffic is thin or sporadic, in-page push is still the right starting point, because classic push needs volume just to build a subscriber list worth sending to.
Weigh that against how much you can invest in list health. Classic push rewards sites with a reason for people to come back — content that updates regularly, deals, alerts — because that's what justifies the permission ask and keeps the list from going stale. A one-off landing page or a site with no repeat-visit hook rarely earns enough opt-ins to make classic push worthwhile.
Most sites that run both don't choose one over the other — they run in-page push as the baseline monetization for all traffic, then layer classic push on top once they have enough return visitors to sustain a list worth maintaining. A network like Adsy runs both formats through the same integration, so publishers can start with in-page push and add classic push once the traffic and repeat-visit pattern support it, rather than having to rebuild the stack later.
If you're unsure where you stand, the honest test is simple: look at your returning-visitor rate. A site where most traffic is one-time search or social visits gets little value from a subscriber channel — in-page push captures that traffic just fine. A site with a meaningful share of repeat visitors has an audience worth asking for permission, and that's where classic push starts to pay off.
FAQ
Can I run in-page push and classic push at the same time?
Yes. They don't compete for the same inventory — in-page push runs on the page itself, and classic push fires independently through the browser's notification system. Many sites run both, using in-page push for immediate coverage and classic push for re-engagement.
Which format pays more per impression?
Classic push generally commands higher CPMs because the audience has opted in and the format interrupts more directly. But it only reaches subscribers, while in-page push reaches every page view — so total revenue depends more on volume and opt-in rate than on the per-impression rate alone.
Does in-page push need user consent?
It doesn't require the browser's notification permission, since it's rendered as page content rather than a system notification. Depending on your jurisdiction, general ad-consent rules (like cookie/ad-tracking consent under GDPR or similar frameworks) may still apply to the ad tech serving it — that's separate from the OS-level permission classic push needs.
Why do my push notification opt-in rates keep dropping?
Browsers have tightened how and when the permission prompt appears, muting it for sites with historically low accept rates. Prompting immediately on page load, before a visitor has any reason to trust the site, is the most common cause of low acceptance.
Is in-page push considered a "safe" ad format?
It's widely used and accepted by mainstream ad networks, but the styling matters. Creative that closely imitates a real system alert (fake OS branding, fake close buttons) crosses into deceptive territory and is typically against network policy — legitimate in-page push should be identifiable as an ad.
Conclusion
In-page push and classic push solve different problems: one monetizes the page view you already have, the other monetizes a subscriber relationship you have to build first. Neither replaces the other — most sites that run both start with in-page push for immediate, no-friction coverage and add classic push once they have a returning audience worth the permission ask and the ongoing list upkeep it requires.
Key takeaways
- In-page push works on every page view with no opt-in required; classic push only reaches visitors who accepted a permission prompt.
- Classic push typically pays more per impression but depends on building and maintaining a subscriber list that decays over time.
- Browsers have made the notification permission prompt harder to win, which makes prompt timing and site trust signals matter more than they used to.
- Style in-page push as a recognizable ad, not a fake system alert — mimicking real OS notifications risks both policy violations and visitor trust.
- Check your returning-visitor rate before investing in classic push; a low-repeat-visit site gets little value from a channel built for return visits.
