The most effective default isn't a single daily send cap, but engagement-based throttling layered with campaign-level limits. Start testing a 1 to 2 sends per day baseline for most segments, with tighter limits for new subscribers, and build your delivery pipeline to respect the throttles that Apple, Google, and Chrome already enforce on their end.
TL;DR:
- Personalized throttling, based on user segments and behavior, prevents opt-outs and increases long-term engagement by avoiding over-sending.
- Setting campaign-specific caps and using rolling windows improves delivery predictability and helps manage platform-enforced throttling limits.
- Prioritizing transactional messages separately from promotional pushes reduces fatigue and maintains critical communication channels.
- Monitoring key metrics such as opt-out rate, uninstall rate, and revenue per send helps refine frequency and throttling strategies over time.
- Platforms like Firebase, Apple, and Chrome impose their own rate limits, requiring integrated backoff, jitter, and device de-duplication to ensure message deliverability.
Table of Contents
- Benchmarks and what experiments show about frequency
- Why throttling matters: user experience and long-term business impact
- Practical throttling strategies marketers can implement
- Provider and platform throttles that change how you schedule sends
- How to measure and test throttling policies
- Engineering checklist: config patterns and observability to enforce throttling
- StorePush's take on throttling and reach
- The overrated variable in push throttling
- Try engagement-first throttling with StorePush
- Sources
- FAQ
Benchmarks and what experiments show about frequency
Most ecommerce teams treat push frequency as a gut call. It shouldn't be. A randomized field experiment covering one million users found that higher send frequency did increase short-term app visits, but it also drove sharp increases in opt-outs. The catch: the effect size varied a lot by user, meaning there's no single frequency that works for everyone.
That heterogeneity is the real finding. Blanket high-frequency sends help some cohorts and quietly wreck others. The old "1 to 2 per day" rule of thumb still holds up as a starting point, but it's a floor for testing, not a finish line.
Segment-specific starting caps we'd recommend testing:
- New users (first week): one send per day, transactional only unless they've clicked something.
- Casual browsers: one to two sends per day, capped tighter on weekends if engagement dips.
- Loyal, high-engagement shoppers: up to three sends per day, since they've shown tolerance and value.
A single 2024 field experiment of 1 million users found that raising push frequency increased opt-outs alongside short-term visits, which is why personalized relevance scoring outperformed flat frequency increases in that study. Treat every cap above as a hypothesis, not a rule.
Why throttling matters: user experience and long-term business impact
An opt-out isn't a one-time loss. It's the permanent closure of a channel that would have kept paying off for months. Every uninstall or notification block shrinks the pool of shoppers you can reach without paying for another ad impression, which is the whole point of owning push in the first place.
The KPIs that actually move when you over-send:
- Opt-out rate, which climbs fastest among users who never asked for high frequency in the first place.
- Uninstall rate, often the delayed cousin of opt-outs, showing up weeks after fatigue sets in.
- Click-through rate, which tends to decay per send as volume increases within the same window.
- Revenue per send, the number that tells you whether more messages are actually making money or just spending down goodwill.
Push fatigue is rarely a content problem. It's usually a settings and cadence failure: no cap logic, no priority tiers, no way for a shopper to dial down volume instead of shutting the channel off entirely. Retention strategy research points the same direction: giving people control over frequency protects the long-term relationship better than any single message ever could.
Practical throttling strategies marketers can implement
Once you accept that one global cap won't fit every shopper, the work becomes building rules that adapt. Here's the sequence we'd follow:
- Prompt for permission after an affinity signal, not on page load. A shopper who has added something to cart or viewed three products is a far better candidate than someone who just landed.
- Set campaign-level caps, not just a global daily limit. A welcome series, a cart-recovery flow, and a promotional blast should each have their own ceiling so they don't stack on top of each other in the same day.
- Use rolling windows per user instead of resetting counts at midnight. A 24-hour rolling cap of two sends behaves more predictably than a calendar-day cap that lets someone get four messages across an evening and the next morning.
- De-duplicate across devices. A shopper with a phone and a desktop browser subscribed is still one person. Treat them as one recipient in your throttle logic, not two.
- Separate transactional from promotional priority. Order confirmations and shipping updates deserve immediate delivery. Promotional pushes should never compete with them for the same priority flag, a distinction PubNub's ecommerce guidance also treats as non-negotiable.
- Back off on 429 responses, and add jitter. If a provider tells you to slow down, retry with exponential backoff and randomize the delay slightly so retries from many devices don't collide in the same instant.
- Test concrete rolling-window values, like one send per 24 hours versus one send per 12 hours for the same segment, and let opt-out and revenue-per-send data pick the winner.
Pro Tip: Build your throttle logic around campaign type first and user segment second: it's easier to protect a transactional queue from promotional noise than to retrofit priority after a fatigue spike.
Segmentation and behavioral personalization work best when they're layered on top of this cap structure rather than replacing it. A well-personalized message sent too often still burns out its audience.
Provider and platform throttles that change how you schedule sends
Your throttling policy runs inside limits you don't control. Firebase Cloud Messaging (FCM), Apple Push Notification service (APNs), and the Chrome Push API each enforce their own ceilings, and ignoring them causes delivery problems that look like your own bugs.
FCM documents a default quota and returns HTTP 429 responses when you exceed it, which means your send pipeline needs backoff logic built in, not bolted on after the first outage. APNs treats priority as a real signal: priority 10 requests immediate delivery, while priority 5 is power-conserving and can be batched or delayed, and Apple's documentation confirms APNs holds only one queued notification per app per device, so a burst of low-priority sends to the same device just overwrites itself. Chrome's 2026 web-push guidance enforces engagement-based limits and flags sites that prompt aggressively or send without regard to user interaction.
A delivery delay that shows up only on certain devices or certain hours often points to provider throttling, not your infrastructure. A delay that's constant across every send, regardless of volume, usually points back to your own connection handling.
How to measure and test throttling policies
Guessing at caps is how teams end up either under-sending or triggering opt-out spikes. Run it as an experiment instead.
- Track delivery rate, open rate, click-through rate, opt-out rate, and revenue per send as your core set. Any cap change should move at least one of these in a measurable direction.
- Randomize by user, not by campaign, so you can isolate the effect of frequency itself rather than message content.
- Run tests for at least two to three weeks to capture the delayed opt-out and uninstall behavior that doesn't show up in day one metrics.
- Look for heterogeneous effects across cohorts. The same field experiment that found frequency lifted visits also found the opt-out cost varied sharply between users, which is the strongest argument for per-segment caps over a single global number.
A 2024 randomized experiment with 1 million users found that higher push frequency increased both short-term visits and opt-outs, and that gap between the two effects is exactly what your test buckets should be measuring.
Engineering checklist: config patterns and observability to enforce throttling
The policy only works if the pipeline enforces it. Build these primitives before you tune numbers:
- Per-user rolling counters that track sends across a moving window, not a calendar reset.
- Campaign-level caps stored separately from the global user cap, so flows don't silently stack.
- Priority flags distinguishing transactional from promotional at the message level, not just the campaign level.
- Device de-duplication keyed to a single user identity across phone, tablet, and desktop tokens.
- Connection hygiene for APNs and FCM: keep HTTP/2 connections open and reused, and distribute traffic across hosts instead of letting cached DNS concentrate everything on one endpoint, a pattern Apple's developer forums repeatedly flag as a self-inflicted cause of delivery delay.
- 429 handling with exponential backoff and jitter, plus a circuit breaker that pauses sends entirely if error rates spike past a set threshold.
Pro Tip: Alert on 429 spikes and opt-out spikes as if they were the same incident category: both usually mean your throttle logic just failed somewhere upstream.
StorePush's take on throttling and reach
StorePush re-engages shoppers through lock-screen push notifications without collecting an email, a phone number, or requiring an app install, using native iOS App Clips. That changes the throttling math a little, because the audience reached this way often has no prior push relationship to fatigue in the first place.
A few things that shape how we think about caps for stores using this approach:
- Transactional and promotional sends are separated by design, so a shipping update never competes with a promotional nudge for the same delivery slot.
- Opt-in dynamics differ from email or app-based push, since the App Clip flow means the first interaction is the notification itself, which raises the stakes on getting frequency right from send one.
- Reach extends to shoppers traditional tools miss, since no email or app is required to trigger the first re-engagement message.
The overrated variable in push throttling
Everyone treats frequency caps as the main lever. They're not. The bigger lever is priority discipline: whether your pipeline actually knows the difference between a shipping update and a flash-sale blast before it hits send. A store with a sloppy priority setup will burn out its audience at one send a day. A store with clean separation between transactional and promotional traffic can sustain more volume without the same opt-out cost.
The conventional advice, find the magic number, misses that the field experiment data already answered this: there is no magic number, only heterogeneous responses that reward personalization over volume. Teams that keep hunting for a universal cap are optimizing the wrong variable.
If you're prioritizing one fix this quarter, make it this: get transactional messages onto their own priority path before you touch a single frequency number. Everything else, segmentation, rolling windows, backoff logic, works better once that separation exists, and almost none of it matters if it doesn't.
— Lucas
Try engagement-first throttling with StorePush
Getting throttling right depends on reaching shoppers who haven't already opted out somewhere else, and on keeping transactional and promotional sends apart from the first message. StorePush handles both: it reaches cart abandoners through lock-screen push without needing an email or app install, and it keeps priority sends separate by design.
- Free plan available with no cost to start testing on Storepush.
- Pro plan runs $50 per month plus a 5% usage commission on recovered revenue, listed on Storepush.
- Book a walkthrough on the StorePush demo page to see how caps and priority routing work on your own storefront.
Sources
- Communicating with APNs - Local and Remote Notification Programming Guide
- Web push rate limits and best practices
- Mobile apps in retail: effect of push notification frequency on app user behavior
FAQ
What are the drawbacks of push notifications?
Overused push notifications drive higher opt-out and uninstall rates, and field experiment data shows those costs vary sharply by user even when short-term visits go up. Poorly prioritized sends can also bury transactional messages like shipping updates behind promotional noise.
How many push notifications are too many?
There's no universal number, since optimal frequency depends heavily on the individual user's engagement history. A common starting point is one to two sends per day, tightened for new subscribers and tested against opt-out and revenue-per-send data before raising it.
Why am I no longer getting push notifications?
This usually traces back to a platform-level throttle, an unregistered device token, or a permission the user revoked. Apple's APNs documentation lists status codes like 410 for unregistered tokens and 429 for exceeding send limits, both of which stop delivery until resolved.
What are the best practices for push notifications?
Prompt for permission only after a user shows affinity, like adding to cart, rather than on first visit, and separate transactional sends from promotional ones so urgent messages never get delayed. Cap frequency per segment and test changes with randomized buckets rather than applying one blanket rule.