Push Notifications Timed to Local Geo Time
Push notifications timed to local geo time send based on each user's own time zone, not the time on your server or your own clock. Blast on UTC or your own local time and part of the base gets pinged at 3 a.m. and mutes notifications for good. Here's how to build a geo-based send schedule and why it directly moves CTR and opt-out rates.
Why server time is the wrong reference
A PWA base is usually collected from several geos at once, and the gap between, say, LatAm and Southeast Asia can run past 12 hours. One blast at '10 a.m. server time' lands at lunch for part of the base and in the middle of the night for another. Night pushes don't just go unread — users mass-tap 'turn off notifications,' which drags down deliverability for every future send.
How a user's local time gets determined
Time zone gets attached at subscription, based on IP geo or the geo-targeting data from the traffic source. In segmentation this is usually its own field, separate from overall campaign time, that the send schedule reads from. For a wide geo — Brazil's four time zones, for instance — splitting the segment by region beats averaging across the whole country.
Which send windows perform best
For consumer verticals — gambling, sweepstakes, e-com — response tends to peak right after waking up (8-10 a.m.), around lunch (1-2 p.m.), and in the evening (7-10 p.m.) local time, when the phone is actually in hand. Weekday work hours usually underperform on CTR for entertainment offers. Treat any of these windows as a starting point and confirm them with a split test on your own base, not someone else's numbers.
Setting up geo-based scheduling in APEX
APEX's push engine segments the base by geo and schedules delivery against each segment's local time instead of one global slot. The same segmentation field applies to triggered pushes too — an abandoned-deposit trigger still fires on the event, but delivery still waits for the right local window. For multi-geo setups this removes the manual work of recalculating send times per country.
Common mistakes when scaling across geos
The usual mistake is keeping one schedule when a new geo gets added and just cloning the campaign as-is — a 6-8 hour gap turns a morning window into a midnight send. The second is ignoring local holidays and weekends, when activity patterns shift. The third is sending too often 'just in case' without respecting the window — opt-outs eat up whatever the segment had left.
FAQ
- How do you find a user's time zone without heavy analytics?
- Geo from IP or from the traffic source's data is usually enough to map to a country's time zone. For large countries spanning several zones, segmenting by region is more accurate if the base size justifies it.
- What times should you avoid sending pushes altogether?
- Generally the deep-night window (midnight to 7 a.m. local) — deliverability and open rates bottom out there and opt-outs climb. Weekday work hours often underperform too on entertainment verticals.
- Does every vertical need the same send time?
- No, activity patterns differ: gambling and sweepstakes respond better in the evening, e-commerce closer to lunch and after work hours. Test windows per vertical rather than reusing one offer's schedule for another.
- How does time-based scheduling work alongside triggered pushes?
- A trigger — an abandoned deposit, say — still fires on the event, but actual delivery can wait for the next suitable local window instead of going out instantly at night. That way the trigger and the schedule work together instead of against each other.
Cloaking, anti-bot, push, split tests and your own domains — in one service.
Get started free