Web Push: Retention Without Third Parties

Web push notifications bring visitors back to your shop - without requiring an installed app and without handing data to third parties. An abandoned cart, a saved item back in stock, a price drop: a single click on a notification takes the customer straight to the right product page. This guide shows how web push works for retention and recovery, how delivery runs technically through your own server, and what to keep in mind for a GDPR-compliant setup.

Why push-based retention matters right now

The average cart abandonment rate sits at 70.19% (Baymard Institute) - and on mobile even at 85.65% (Baymard Institute). So only about one in ten visitors who add an item to the cart actually buys; the rest leave. Some of those abandonments are lost for good, others can be won back - provided you have a channel to reach the customer again without their email address. That is exactly where web push comes in.

The key difference from classic email remarketing: a web push opt-in needs no email address and no registration. The visitor grants permission in the browser, and from that moment you can reach them - even when your shop tab is closed. The channel is yours: the subscription lives as a technical endpoint in your own database, not in a customer account on someone else's platform. Web push complements measures like wishlists for higher conversion that surface purchase intent.

There is also a structural shift in marketing: classic retargeting via ad platforms is becoming less precise and more expensive as third-party cookies disappear and tracking rules tighten. Anyone who wants to reach visitors reliably needs their own channels - so-called first-party touchpoints. An email address is the best known, but it requires a registration or a purchase. Web push closes the gap before that: even an anonymous visitor can opt in to notifications, long before creating an account.

For retention this is a measurable lever across the entire customer lifecycle - from the first visit through the abandoned cart to reactivation after weeks of inactivity. Instead of buying each visitor once and expensively, you build a base of reachable contacts that belongs to you. That base does not lose value when the rules of individual ad platforms change.

How web push works technically

Web push relies on three building blocks that work together in the browser and on your server: a service worker, the push service of the browser vendor, and your own application server. The flow is standardized and supported by roughly 96% (caniuse/MDN) of browsers in use worldwide.

1. The visitor grants notification permission in the browser. The browser then creates a PushSubscription object with a unique endpoint and two keys.
2. You store this subscription in your shop database - linked to the cart, the wishlist, or an anonymous session ID.
3. When a trigger fires (cart abandonment, restock), your server signs the message with a VAPID key pair and hands it to the browser's push service.
4. The push service delivers the message, the service worker receives it and shows the notification - even when the shop tab is closed.

VAPID (Voluntary Application Server Identification) is the key to authentication: your server identifies itself as a legitimate sender with a private key, so only you can send to your subscribers (MDN Web Docs). The public part of the key is stored in the browser at opt-in.

// Register service worker and subscribe to push
const registration = await navigator.serviceWorker.register('/sw.js');

const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true, // required in Chrome
  applicationServerKey: VAPID_PUBLIC // your public VAPID key
});

// Send the subscription to your own shop server
await fetch('/api/push/subscribe', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(subscription)
});

On the server side, the message is then sent using the subscription. This can be implemented in custom-built backends just as well as in a Shopware shop, where a plugin couples delivery to cart and inventory events.

The service worker is the core: a small piece of JavaScript that runs in the background independently of the open page. It receives the push event and decides which notification to display, with which title, text, icon and target link. Because it is active even when no tab of your shop is open, delivery works even hours after the last visit.

It is important to understand that you do not send the message directly to the user's device. Instead you hand it to the push service of the respective browser vendor, which handles the actual delivery. This intermediate step protects the user's privacy, because the endpoint reveals neither a phone number nor a device address. For you the effort stays manageable, since the browser vendor provides the complex delivery infrastructure.

The biggest advantage of web push is not the reach of individual messages, but building a reachable audience that works independently of other platforms.

XICTRON e-commerce team

Cart recovery: winning back the abandonment

The most effective use case is the cart reminder. 39% (Baymard Institute) of abandonments are caused by unexpected extra costs at checkout, and nearly one in five customers abandons because of a too long or complicated checkout (Baymard Institute). A well-timed push reminder brings these customers back - ideally with a deep link straight into the filled cart.

Browser web push campaigns reach an average click-through rate of 0.84% (PushPushGo). That sounds low, but read it in context: the message costs nothing per send, reaches the user outside the shop and needs no email address. Personalization lifts the impact noticeably - one documented test doubled the click rate through first-name personalization, from 2.68% to 5.22% (Pushwoosh).

The sequence is decisive: a single message works less well than a thoughtful, short sequence. A three-step pattern has proven effective - a friendly reminder shortly after the abandonment, a second nudge the next day with a concrete benefit, and possibly a final message before the cart technically expires. The key is to send each further message only if the previous one did not lead to a purchase, and to stop the sequence immediately once the customer converts.

The impact stands or falls with the relevance of the content. A message that names the concrete item and ideally shows it as an icon beats a generic reminder by a wide margin. Timing matters too: delivery at a suitable time of day can noticeably raise the reaction rate, which is why aligning with prior visit behavior pays off. Treat web push as part of holistic conversion optimization rather than an isolated single measure.

Back in stock: using peak purchase intent

When a sold-out item is available again, you meet customers with clear purchase intent - they actively registered for a notification. Conversion is correspondingly high: in the email channel, back-in-stock messages delivered the highest conversion of all automated message types in 2025 at 6.46% (Omnisend), alongside very high open rates of 59.19% (Omnisend). Because web push reaches the user without the detour via the inbox, the channel is well suited to exactly this occasion-based outreach.

Web push is especially suited to this case because the message reaches the user immediately - with limited stock, speed often decides. Couple delivery to the inventory event so the notification fires automatically as soon as stock rises above zero again. Combined with bundles and set articles, the average order value can be raised further.

Beyond pure restock, the channel suits further occasion-based scenarios with high relevance: a hint when a watched item drops in price, a reminder of an expiring voucher, or information about the last available stock. What they all share is that they arise from a concrete event and offer the recipient immediate value - that sets them apart from plain advertising and keeps the opt-out rate low.

Gift cards and seasonal promotions can also be supported sensibly via web push. Anyone covering gift cards in the shop, for example, can remind recipients of balances to redeem. The clear occasion remains essential: every message should have a reason that is understandable from the customer's perspective.

Browser support and the iOS specifics

On desktop and Android, web push is broadly available - support sits at around 96% (caniuse/MDN) and covers all common current browsers. Apple introduced web push with iOS 16.4 (Apple Developer) too, but with one important limitation: on the iPhone, web push only works when the site is installed as a Progressive Web App via the home screen - not in a regular Safari tab (WebKit). With Safari 18.5, Apple extended the standard in 2025 with Declarative Web Push (Apple/WWDC).

In practice this means web push delivers its biggest leverage with your desktop and Android visitors. For iOS users it is worth offering an installable PWA in parallel - an area where our programming and development services come in.

GDPR-compliant implementation

A web push opt-in is consent within the meaning of the GDPR and should be obtained cleanly. A subscription endpoint counts as personal data once it can be linked to a session or account. So observe a few ground rules.

• No forced browser dialog on the first page view - obtain informed consent first via your own explanatory pre-prompt (soft opt-in).
• Clear purpose: communicate what the notifications are used for (cart, restock, promotions).
• Withdrawal at any time: an easily reachable opt-out mechanism belongs in the privacy policy and ideally in the customer account.
• Data minimization: store only what you need for delivery, and remove invalid endpoints regularly.
• Check data processing: with first-party delivery via your own server, there is no transfer to a marketing service provider.

A thoughtful frequency makes sense not only legally but economically: 46% (Pushwoosh) of users opt out when they receive two to five messages per week. As a rule of thumb, no more than two to five relevant messages per week, with a clear occasion rather than blanket advertising. When designing accessible prompts and opt-in banners, a look at the risks of overlay widgets helps avoid usability problems.

In practice a two-stage approach works well. First you show your own designed banner that explains the value of the notifications and invites the opt-in. Only when the visitor agrees do you trigger the native browser dialog. This avoids a premature system dialog being permanently blocked - once a user declines the browser dialog, the request cannot easily be repeated technically. The two-stage model protects this valuable resource.

Also document the time and scope of consent in a traceable way, so you can demonstrate legitimacy if in doubt. Since the push endpoint is linked to a device or session, include it in your deletion concept and remove it reliably on withdrawal as well as on persistently failed delivery. That keeps your recipient list clean and your data lean.

Common pitfalls and how to avoid them

With a clean architecture these points can be planned in from the start. Whether as part of conversion optimization or as a technical feature in B2B e-commerce - delivery can be coupled to your existing processes.

A frequently underestimated point is monitoring. Push services acknowledge every send with a status - from this you can tell whether an endpoint is still valid or needs cleaning up. Evaluating these responses not only keeps the list clean but also gives reliable metrics on delivery, display and clicks. This data is the basis for gradually improving content, frequency and timing.

Equally important is a trial rollout. Instead of messaging all subscribers at once, it is worth starting with a segment to test wording and triggers. That way you gather experience on the right frequency before rolling the channel out broadly. We recommend this step-by-step approach for larger e-commerce projects too, to set content and frequency on a solid basis.