Push notifications for a WooCommerce store, end to end

By Abdalla Kamesh · Updated September 25, 2026 · Published September 7, 2026 · 5 min read

“Unlimited push notifications” is on every app builder’s feature list, which makes it sound like one feature. It is three, they do completely different jobs, and stores that treat them as one thing burn their permission and never get it back.

The three kinds, ranked by how much they are worth

1. Transactional — order status. “Your order shipped.” “Out for delivery.” These are the most valuable notifications you will ever send and the ones people never turn off, because they were asked for implicitly at checkout. They also cut support volume: a large share of “where is my order?” emails exist only because nothing told the customer.

2. Triggered — behavioral. Abandoned cart, back in stock, price drop on a wishlisted item. Sent to one person because of something that person did. High relevance, and correspondingly high conversion.

3. Broadcast — campaigns. “Weekend sale, 20% off.” Sent to everyone or a segment. This is the one everybody thinks of first and the one that does the most damage when overused, because it is the only category where the customer’s reaction can be “why is this store texting me?”

A store that sends only category 3 has built an app-shaped email list. A store that sends 1 and 2 well earns the right to send 3.

How permission actually works (and why it decides everything)

This is where an app differs fundamentally from web push, and it is worth understanding precisely.

On iOS, an app must ask for notification permission with a system dialog. You get one good shot: if the customer taps “Don’t Allow,” you cannot ask again from inside the app — they have to go to Settings and turn it on manually, which essentially nobody does. So when you ask is a design decision worth real money. Asking on first launch, before the person has seen a single product, is how stores end up with a 30% opt-in rate. Asking after a first order, or when someone taps “notify me when back in stock,” is how they end up with 70%.

On Android, apps targeting recent versions also require a runtime permission prompt, with the same one-shot dynamics. Older installs may be opted in by default, which is why Android opt-in rates usually look better than iOS in the same store’s analytics.

On the web, browser push has its own prompt, and the numbers are considerably worse — the prompt is easy to dismiss, it appears in a context where people are used to dismissing things, and on iOS Safari it requires the site to be added to the home screen first. That gap is the real argument for an app: not that push exists, but that push people actually receive exists.

What each notification should contain

The mechanics of a good push are boring and consistent:

Title: the thing that happened. “Your order is out for delivery” — not your store name. The OS already shows your store name and icon.
Body: the specific detail. The product, the amount, the timing. “Trailhead Jacket, arriving today by 8pm.”
Deep link: the exact screen. A notification that opens the app’s home screen wastes the tap. Order updates open that order. Back-in-stock opens that product. A cart reminder should bring the shopper back to a cart that is still full — in StoreToNative it opens the app, with the cart still saved.
No urgency theater. “🔥🔥 LAST CHANCE 🔥🔥” trains people to swipe you away. Save real urgency for when it is real.

Deep linking is the part most often done badly, and it is the difference between a 2% and a 12% conversion rate on the same message.

The order-status notification that pays for the app

Set this up before you touch campaigns. When a WooCommerce order changes status, the app tells the customer. In StoreToNative this is on every plan and needs no configuration beyond connecting your store — status changes flow through WooCommerce’s own webhooks, so it works with whatever plugin or fulfilment tool is setting the status.

Two details make it good rather than noisy:

Do not notify every status. “Processing” often means nothing to the customer. Shipped, out for delivery, delivered, and refunded are the ones people care about.
Include the tracking, not a promise of tracking. A notification that says “tracking is now available” and then opens a screen without a tracking number is worse than silence.

Campaigns: the frequency question

The honest answer, from the shape of every dataset that has ever been published on this: the opt-out cliff is steeper than the revenue curve. Two or three broadcasts a week is a level most stores sustain. Daily works only if daily is the product — flash-sale retail, groceries, news.

Practical rules that survive contact with reality:

Segment before you increase frequency. Sending twice as often to half as many people is almost always better than doubling the blast.
Respect the clock. Send in the customer’s local evening, not your morning. A 3 a.m. notification is an uninstall.
Cap it. Decide your weekly maximum in advance, because “one more send” always looks free.
Watch uninstalls, not just opens. Open rate goes up right before an audience leaves; a small dip in installs after a heavy week is the real signal.

What to measure

Four numbers, in this order of usefulness:

Opt-in rate, split by platform. This is your permission asset. If iOS is under 50%, fix when you ask before you send anything else.
Delivery-to-open rate per campaign. Compare campaigns to each other, not to industry averages you cannot verify.
Revenue after the send, within a sensible window. StoreToNative shows app revenue and push opens per day for the whole app — not per campaign — so leave room between sends when you want to see which one moved money.
Opt-out and uninstall after each send. The cost side of the ledger.

The mistakes that cost the most

Asking for permission on first launch. The single most expensive default in mobile commerce.
Sending your first campaign the day you launch, to an audience of eleven people, and concluding push does not work.
One message for everyone, when a wishlist and an order history are sitting right there.
Treating push as free. It is free to send and expensive to spend: every message draws down a permission you cannot re-earn.
No quiet hours. See 3 a.m., above.

Where to start, this week

Turn on order-status notifications. Move your permission prompt to after the first meaningful action. Set up one triggered notification — back in stock is the easiest to justify to a customer. Then, and only then, send a campaign, and measure the opt-out alongside the revenue.

Related reading

Unlimited campaigns and order-status notifications are on every StoreToNative plan; abandoned-cart recovery is on Pro. The feature table has the exact split.

Help page: Push notifications, the step-by-step guide.