Visit Website →
← Back to blog

Regional Push Timing: IANA Zones, TTL, and the 00:00–04:00 Rule

October 16, 2026
Regional Push Timing: IANA Zones, TTL, and the 00:00–04:00 Rule

Send every push at each subscriber's local hour, grouped into IANA time zone buckets, and keep sends out of the 00:00–04:00 local window. Aim for morning, lunch or early evening depending on your app type and how urgent the message is. Add a small spread per bucket, a short TTL for time-sensitive offers, and test behavior-based timing on your highest-value users.

TL;DR:

  • Store each subscriber’s IANA identifier instead of a fixed UTC offset, recalculate send times for daylight saving, and apply frequency caps by local date.
  • Yahoo! JAPAN reported that adaptive scheduling increased click rates by as much as 60.7% in its Android app, with larger gains when content was personalized.
  • Compare local time, fixed UTC, opportunistic delivery, and a holdout receiving no messages; track conversions alongside retention, notification opt outs, and uninstalls as guardrails.
  • A study found that immediate delivery when a screen turns on can reduce app logins that day, while a 1–6 minute delay sometimes improves engagement.
StorePush
Re-engage Shoppers Who Leave Their Carts
StorePush uses native iOS App Clips to send lock-screen push notifications, even when shoppers have not shared an email address or phone number.
Visit StorePush

Table of Contents

When are the best times for push alerts by region and app type?

Start with a hypothesis, then let your own data overrule it. Three local windows come up again and again:

  • Early morning: commutes and first phone checks, potentially useful for news, habit apps and utilities.
  • Lunch: short breaks, potentially useful for deals, food and quick-browse e-commerce.
  • Early evening: couch time, potentially a good fit for considered purchases and cart reminders.

Apps differ more than regions do. A news alert competes with a flood of other alerts at rush hour, while a shipping update is welcome whenever it lands.

One tactic worth borrowing is the quiet window. An analysis of twelve months of news push data per country found that each market has its own rush hour and three quiet windows where an alert faces less competition on the lock screen. That means Tokyo's rush hour is not Madrid's, and a single global send time will hit most of your audience at the wrong moment. Map each major market's busy and quiet hours before you plan a multi-region campaign.

How do you schedule sends by time zone?

Local-hour delivery is an engineering rule as much as a marketing one. The scheduler guidance we trust says to capture IANA zone names and group subscribers into quarter-hour offset buckets, then send one wave per bucket.

  1. Store each subscriber's IANA identifier (such as America/Chicago) at opt-in. Never store a fixed UTC offset, because it breaks when clocks change.
  2. Group subscribers into quarter-hour offset buckets and run one send wave per bucket.
  3. Spread each wave over a suitable window: tighter for flash sales and wider for routine content.
  4. Resolve local time to UTC at each run so daylight saving shifts are handled for you.
  5. Skip 00:00–04:00 local, and give time-sensitive campaigns a short TTL so stale offers expire instead of arriving late.
  6. Compute frequency caps against the subscriber's local_date, not the UTC date.

Platform docs describe the same pattern: compute a DST-correct UTC fire time per bucket, send in batches, and mark a campaign sent only after every bucket finishes.

Pro Tip: Treat the campaign as "done" only when the last bucket completes. Reporting on a half-finished send makes early buckets look like winners.

Should you use behavior-based timing or fixed local hours?

Fixed local-hour sends are simple and reliable. Behavior-based delivery tries to catch an opportune moment, when the phone is in hand and the person is likely ready to engage. The payoff can be large: a deployment in the Yahoo! JAPAN Android app reported up to a 60.7% increase in click rate from adaptive scheduling, with bigger gains when the notification content was also personalized.

Research on predicting interruptibility adds that context, communication activity and phone use patterns are the strongest signals for spotting engaged moments.

The trade-offs are real:

  • Adaptive timing needs interaction history, event tracking and more infrastructure.
  • Local-hour sends need only a time zone and a scheduler, and they behave predictably.
  • Adaptive models can drift or underperform for users with sparse data.

Our recommendation is a hybrid. Default every low-data user to local-hour delivery, and switch on adaptive timing only for segments with enough interaction history. If you want to see how timing connects to personalization, our guide on personalization that recovers revenue covers it.

Which days and frequency caps work best?

Day choice follows intent. Utility and news apps tend to do fine every day, while retail and entertainment apps often see different weekday and weekend rhythms, so test both before locking in a calendar. Safe defaults:

  • Start with weekdays for work-adjacent apps and add weekends once you have evidence.
  • Set a conservative cap for promotional pushes per user in local time, and lower it if opt-outs rise.
  • Evaluate every cap against local_date, otherwise a user in Sydney can receive two messages in one evening because UTC rolled over.
  • Raise caps only for high-value segments that have explicitly asked for more, such as order-status or price-drop alerts.

How do you test and measure send times?

Run an A/B/n test with a holdout rather than switching schedules wholesale.

  1. Build arms for local-time sends, fixed UTC sends, opportunistic delivery and different spread windows, plus a no-send holdout.
  2. Track influenced opens, CTR and conversion or revenue as primary metrics.
  3. Watch retention, opt-outs and uninstalls as guardrails, since a lift in clicks that drives people to turn alerts off is a loss.
  4. Log per-bucket delivery, device-offline behavior and TTL expirations so attribution stays honest.

Be careful with "faster is better" assumptions. A quasi-experimental study found that immediate delivery on screen-on can reduce same-day app logins, while a modest delay of 1–6 minutes sometimes produced peak engagement. If you test opportunistic delivery, include a short-delay arm. Our post on push notification timing walks through a marketer-friendly test plan.

What is the checklist for launching timezone-aware campaigns?

  1. Capture the IANA time zone at opt-in.
  2. Compute quarter-hour offset buckets.
  3. Build a per-bucket job scheduler with spread.
  4. Set TTL and a local_date idempotency key so no one gets duplicates.
  5. Configure frequency caps in local time.
  6. Prepare test and holdout cohorts.
  7. Simulate daylight saving transitions and validate bucket throughput before launch.
  8. Write runbooks for retries, outages and monitoring.

Pro Tip: Run your preflight around daylight saving time changes in major markets. That is where scheduler bugs hide.

For the opt-in step, our notes on raising push opt-in rates cover how to ask for permission and the time zone in a way people accept.

Why can you trust this guidance, and how does StorePush fit?

This guide covers e-commerce push strategy. The guide draws on the cited research and scheduler documentation. Here is how our stated capabilities line up with the advice above:

  • We recommend local-hour delivery as the default in our timing guidance.
  • Our dashboard offers conversion attribution so you can see which windows produce revenue.
  • We re-engage shoppers on the lock screen through native iOS App Clips, without collecting an email or phone number.

Any performance figures we publish about our own product are company-reported, so weigh them as such and run your own test before committing.

How does culture shape push response times?

Culture sets the rhythm of the day, and push response follows it. Meal times, commute habits, work schedules and weekend structure all differ by market, which is why the news-alert analysis above found no universal best time and instead found a distinct rush hour in each country. A lunch window that works in one market can land mid-meal or mid-meeting in another.

Think in terms of local life, not just clock hours. A Friday evening alert may reach people who are out and ignoring their phones in one market, and people relaxing at home scrolling in another. Religious observance, public holidays and school calendars also reshape response in ways no global benchmark captures.

Practical steps for multi-region teams:

  • Build a market profile for each country you serve: typical commute, lunch and evening windows, and weekend pattern.
  • Ask local teammates or customers to sanity-check your assumed windows before you test.
  • Review message tone and urgency per market, since a "last chance tonight" line that suits one culture can feel pushy in another.
  • Treat each market's initial period as a learning phase and keep caps conservative until you see opt-out data.

The goal is a calendar that respects how your subscribers actually live. Regional benchmarks give you a starting guess, and your own holdout tests tell you where that guess is wrong.

How do device habits change the best send time?

Device usage varies by region in ways that move your optimal window. Some markets lean heavily on Android, others on iOS, and the two platforms handle notification grouping, permission prompts and delivery priority differently. Phone checking also clusters differently: heavy commuting by public transit means a lot of morning and evening screen time, while car-based commutes shift attention to breaks and evenings.

What matters for scheduling is whether the phone is reachable and whether the person is ready. Research on engagement prediction found that phone status and use patterns were among the top predictors of a good moment, which is a reminder that the clock alone is a rough proxy. Connectivity matters too. If many of your subscribers in a region are often offline or on spotty data, a short TTL can cause the alert to expire before the phone reconnects, so match TTL to realistic connectivity.

Push alert expiry relative to device reconnection

Early work on reinforcement-learning personalization suggests that learning each person's preferences can improve response, which is relevant when device habits differ person to person within one region.

What to do about it:

  • Segment performance by platform and region before you generalize a winning time.
  • Use longer TTLs in markets with patchy connectivity, shorter ones for flash offers in well-connected markets.
  • Check that your bucket spread does not overload delivery throughput on one platform at peak hours.

How do regional send times fit into campaigns and promotional calendars?

Regional timing should plug into your campaign calendar, not sit beside it. A global sale that starts at "9 AM" is really dozens of local launches, and each one needs its own wave. Build the calendar in local time, then let the scheduler translate each bucket to UTC.

Plan around the dates that differ by market: local holidays, payday cycles, school breaks and regional shopping events. A promotion that peaks on one country's holiday may fall flat elsewhere, so avoid copying one market's calendar across all of them.

Coordination tips that save headaches:

  • Stagger regional launches deliberately. Waves rolling across time zones also smooth load on your backend and your customer support team.
  • Keep one frequency cap across all campaigns in local_date terms, so a promotion, a cart reminder and a transactional alert do not stack into one evening.
  • Pair timing with data. Clean customer data across tools makes timezone and behavior signals trustworthy, and this comparison of customer data platforms is a useful read when you decide how to wire those signals together.
  • Review results per region after each campaign and feed what you learn into the next calendar.

For revenue-focused programs, tie each wave to an attribution window so you can see which regional send converted, not just which one got opened.

What is the single highest-impact priority for global push timing?

Capture the time zone at opt-in and ship local-time delivery before anything fancier. It is the cheapest change with the most reliable payoff, and every smarter technique builds on it. My caution is about speed: sending the instant a phone wakes feels clever, but the evidence suggests that a modest delay can beat immediacy, so test a short delay on any opportunistic send before you scale it.

— Lucas

What can StorePush do for your timing program?

We give e-commerce teams lock-screen push re-engagement through App Clips, with no email or phone number needed and no app install, plus timing analytics and integrations with Shopify, WooCommerce, BigCommerce and custom storefronts. Our Free plan costs $0 per month, so you can test local-hour sends on real cart and browse abandonment before spending anything. Start with the StorePush Free plan and see which windows recover revenue.

FAQ

What is a push message?

A push message is a short notification sent from an app or website to a user's device, appearing on the lock screen or notification tray without the user opening the app. Marketers use it for reminders, offers and updates.

What is the best time to send push notifications?

There is no single best time. Common high-engagement windows are early morning, lunch and early evening in the subscriber's local time, and each market has its own rush hour and quiet windows. Test within those windows using a holdout.

Why should push notifications be sent in local time?

Local-time delivery makes sure each person receives the message at the hour you intended, instead of at 3 AM because of a UTC schedule. It also avoids the overnight window that scheduler guidance advises skipping, 00:00–04:00 local.

Is sending a push as soon as possible a good idea?

Not always. Immediate delivery can feel intrusive, and a quasi-experimental study found it can reduce same-day app logins in some contexts, with a short delay sometimes performing better. Test a delayed arm before you commit.

Sources