4 audience cohorts
Respect the clock.
Measure the lift.
Turn audience time zones, preferred windows, delivery capacity, and an explicit outcome metric into an auditable send schedule.
- DST-aware zones
- Capacity queue
- Test sizing
The cohort schedule fits the supplied constraints.
117,000 recipients across 4 named-timezone cohorts on August 4, 2026.
The model honors the preferences entered here; it does not infer them. Use historical click, conversion, or reply evidence, then validate timing with randomized tests.
IANA identifiers, not fixed offsets
0 recipients delayed
22,605 per timing variant
Local delivery preserves more of the supplied intent.
Weighted fit after throughput queuing. Each cohort starts from its own calendar date and preferred local hour.
Best half-hour UTC candidate across the supplied cohorts, before provider throughput duration.
What the provider should schedule.
One UTC instant creates many local experiences.
The strip scores every half-hour UTC candidate. Brighter cells preserve more recipient-weighted proximity to each cohort's preferred hour and operating window.
Can this send support the timing claim?
Two-sided 95% confidence and 80% power planning approximation. Randomize within each timezone cohort, keep content and audience rules fixed, and analyze the declared primary outcome. Sequential peeking and many subgroup comparisons change the error rate.
Export assumptions, UTC dispatches, local clocks, queue effects, global comparison, and experiment sizing.
The optimizer schedules assumptions; it does not manufacture audience evidence.
Each cohort supplies a named timezone, size, preferred local hour, and operating window. The planner converts the local calendar target into UTC, queues overlapping work against capacity, and compares that plan with every half-hour candidate for one global dispatch.
Named zones preserve rule changes that a fixed UTC offset cannot.
America/New_York is a ruleset; “UTC−5” is only an offset. Daylight-saving and political changes can alter the relationship between a local clock and UTC, so schedules should store the intended local time, named zone, resolved instant, and the timezone-data version used by the sending system.
Optimize for a business-relevant action, not the easiest event to count.
Clicks, conversions, and replies are available because the best timing depends on the job of the message. Keep the metric definition, attribution window, denominator, and bot filtering stable. Delivery timing can also change unsubscribes and complaints, so review guardrails alongside lift.
Randomize within timezone cohorts and hold everything else constant.
A send-time test should compare timing, not two different audiences or messages. Predeclare the primary outcome and minimum effect, allocate recipients randomly inside each cohort, run both variants on comparable dates, and avoid repeatedly checking significance until a preferred result appears.
What is the universally best time to send email?+
There is no defensible universal hour. Message purpose, audience behavior, geography, work pattern, urgency, and client habits change the answer.
Why use named time zones instead of UTC offsets?+
Named zones carry daylight-saving and political rules. A fixed offset can be wrong when those rules change.
Should I optimize open rate?+
Open data can be useful directionally, but privacy features, image loading, bots, and client behavior can distort it. Prefer a stable outcome closer to the message goal when possible.
Why does throughput change local timing?+
A provider or account cap turns one scheduled instant into a delivery interval. Large or overlapping cohorts may finish meaningfully later than their requested local time.
Does a sufficient sample guarantee a useful result?+
No. Sample size is a planning approximation. Randomization, instrumentation, stable exposure, guardrails, and honest analysis still determine whether the result is credible.