Push notifications split into two distinct technical and behavioral categories. Web push is delivered by the browser itself (via the Push API and a service worker) to anyone who grants permission on a website, without requiring an app install — reach is broad but permission grant rates are typically low, and iOS Safari only supports web push starting with iOS 16.4 and requires the site be added to the home screen first, a meaningful adoption barrier. App push is delivered through the native OS push service (Apple Push Notification service, Firebase Cloud Messaging for Android) to users who've installed the app, generally has higher permission grant rates since app installation itself signals intent, and supports richer payloads (images, action buttons, deep links into specific app screens).

The strategic difference that matters most: web push can reach someone who never installs anything, which makes it valuable as a lower-commitment channel for ecommerce and content sites, while app push requires the much higher-friction step of app install but then offers deeper, more reliable engagement once granted.

Web push vs. app push

Dimension	Web push	App push
Requires install	No — browser permission only	Yes — app must be installed first
Typical permission grant rate	Lower (10-20% common)	Higher (40-60%+ common, varies by app category)
iOS support	Limited — iOS 16.4+, requires home screen add	Full native support via APNs
Payload richness	Limited (text, basic image, click URL)	Rich (images, action buttons, deep links)
Delivery infrastructure	Browser push service (varies by browser)	APNs (iOS) / FCM (Android)
Best fit	Content sites, ecommerce without an app	Apps with habitual, frequent-use cases

Permission request timing is the single biggest lever

The most common strategic mistake in push is requesting permission immediately on page load or app first-open, before the user has any context for why they'd want notifications — this is the single biggest driver of permission denial, and critically, most browsers and OSes do not let you re-prompt a user who denied once; that decision is often permanent unless the user manually changes it in system settings. A denied prompt isn't a neutral 'try again later' outcome — it frequently forecloses the channel entirely for that user.

Best practice is a soft-ask-then-hard-ask pattern: show an in-page or in-app custom prompt first ('Want order updates? Enable notifications') that explains the value before triggering the native OS/browser permission dialog, and only trigger the real permission request after the user responds positively to the soft ask. This filters out the users who would have denied anyway from ever reaching the point of a permanent denial, preserving the option to ask again later through a different engagement moment.

permission_timing_pattern.txt

text

BAD pattern (most common mistake):
  User opens app/site -> immediate native permission prompt
  -> no context -> high denial rate -> denial is often permanent

GOOD pattern (soft-ask then hard-ask):
  User opens app/site -> no prompt yet
  User completes a meaningful action (adds to cart, finishes
    onboarding, views order confirmation)
  -> custom soft-ask UI: "Get notified when your order ships?"
     [Yes, notify me]   [Not now]
  User taps "Yes, notify me"
  -> NOW trigger native OS/browser permission dialog
  User taps "Not now"
  -> no native prompt fired, denial never becomes permanent,
     can re-offer the soft ask at a later high-intent moment

A native prompt denial is frequently a permanent, unrecoverable no

On most browsers, once a user denies a web push permission prompt, you cannot programmatically re-trigger it — the user must manually change the setting in browser preferences, which almost never happens organically. Treat every native permission prompt trigger as a one-shot opportunity and never fire it until the soft-ask or contextual moment makes approval likely.

Segmentation to avoid opt-out spikes

Once permission is granted, the same fatigue economics that govern SMS apply to push, often more sharply — a notification that interrupts for something irrelevant doesn't just get ignored, it frequently triggers the user to revoke permission entirely in system settings, which is a harder-to-reverse loss than an email unsubscribe. Segmenting push sends by actual relevance (shipping status for someone with an active order, back-in-stock alerts only for items they viewed, re-engagement pushes only after a meaningful inactivity threshold) keeps the channel viable.

A frequency cap specific to push — distinct from email or SMS caps — is worth setting explicitly, because push's interruption intensity sits between SMS and email: more disruptive than an email in an inbox, less personal than a text message, but capable of the same fatigue-driven opt-out spiral if overused.

Push works best as a status-update channel, not a promotional one

The push notifications with the lowest opt-out rates tend to be functional and expected — order shipped, price drop on a saved item, appointment reminder — rather than generic promotional blasts. Reserving push primarily for status-relevant, user-anticipated updates, and routing broader promotional content to email or in-app messaging, keeps permission grants durable over time.

What's next

Email, SMS, and push each have distinct strengths and fatigue thresholds — the real complexity emerges when all three need to work together without duplicating or contradicting each other across the same customer.

Next: Omnichannel Messaging Orchestration →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →