# Email Send Time Optimizer and Timezone Cohort Planner

> Convert audience time zones, preferred local windows, delivery capacity, and a declared outcome metric into an auditable UTC dispatch plan and a controlled timing experiment.

- **Canonical page:** [https://emailbump.com/tools/email-send-time-optimizer](https://emailbump.com/tools/email-send-time-optimizer)
- **Interactive tool:** [Open the email send time optimizer](https://emailbump.com/tools/email-send-time-optimizer)
- **Category:** campaign operations, audience timing, and experimentation
- **Updated:** July 2026
- **Privacy:** All cohort assumptions, calculations, schedules, and exports remain in the browser
- **Network boundary:** The planner does not upload recipient data, query an ESP, or schedule a real send
- **Decision boundary:** The result operationalizes supplied timing preferences; it does not discover a universal best time, prove causality, predict inbox placement, or guarantee recipient behavior

## The question this tool actually answers

“What is the best time to send email?” sounds like one question but usually hides at least four:

1. What local clock time is plausible for each audience cohort?
2. What UTC instants must a sending system schedule to create those local experiences?
3. Can the sender deliver each cohort quickly enough to preserve the intended window?
4. Does the available audience support a controlled test of a timing difference on a useful outcome?

The optimizer answers those operational questions from explicit inputs. It does not claim that Tuesday at 10 AM, Thursday afternoon, or any other generic recommendation applies to every list. Message purpose, urgency, geography, working patterns, industry, device behavior, audience history, frequency, and the outcome being optimized can all change the result.

The strongest send-time plan begins with audience evidence. Historical data can suggest candidate windows, but observational patterns are not automatically causal. People who receive different messages at different times may also differ in geography, lifecycle state, tenure, activity, or campaign type. Use history to create hypotheses and randomized experiments to test them.

## What the interactive planner produces

The tool creates five connected outputs.

### Local-time cohort schedule

Each cohort has:

- a name;
- an IANA time zone identifier;
- a recipient count;
- a preferred local hour;
- an allowed local operating window;
- one shared local calendar date.

The planner converts each cohort's local date and preferred hour into a UTC instant using the browser's internationalization and timezone data. It then sorts the resulting dispatches and passes them through a shared delivery-capacity queue.

### Capacity-aware dispatch manifest

A provider or account cap turns a requested instant into a delivery interval. If one cohort is still consuming capacity when another should begin, the later cohort is delayed. The manifest preserves:

- requested UTC start;
- actual queued UTC start;
- estimated UTC finish;
- actual local start;
- queue delay;
- recipient count;
- timing fit after the delay;
- whether the actual start remains inside the allowed window.

This distinction matters. A campaign scheduled for 10:00 local is not necessarily delivered at 10:00 local when a sender can process only a fraction of the audience each hour.

### Best single-global-send comparison

Some sending systems cannot schedule by recipient time zone, and some urgent messages should go everywhere at once. The planner evaluates every half-hour UTC candidate across a 24-hour day. For each candidate, it converts the instant into every cohort's local clock, calculates timing fit, weights that fit by recipients, and counts recipients outside their allowed window.

The highest weighted candidate becomes the best single-global comparison under the supplied assumptions. It is not a universal recommendation. A different cohort mix, preference, or window can select a different instant immediately.

### Visual clock map

The UTC heat strip shows how weighted fit changes across the day. Cohort clock cards show the local time each audience would experience at the best global instant. This makes the compromise visible: a reasonable hour for one region can be overnight for another.

### Randomized test sizing

The experiment planner converts:

- baseline outcome rate;
- minimum relative lift;
- test allocation;
- total audience;
- control and challenger timing;

into an approximate required sample per variant, total required sample, available test audience, likely number of comparable sends, and projected incremental outcomes in the available challenger group.

The default calculation uses a two-sided 95% confidence target and 80% power approximation for two independent proportions. It is a planning calculation, not a significance result.

## Why named time zones matter

A time zone is not the same as a UTC offset.

UTC−5 describes one numerical relationship at one moment. America/New_York describes a ruleset for civil time, including daylight-saving transitions and historical or future rule changes represented by the installed IANA Time Zone Database. Europe/London, Asia/Kolkata, Australia/Sydney, and America/Sao_Paulo are also named zones with their own rules.

Storing only an offset can create errors when:

- daylight-saving time begins or ends;
- a jurisdiction changes whether it observes daylight saving;
- a government changes an offset;
- a campaign is scheduled far in advance;
- a recurring campaign crosses a transition;
- two places currently sharing an offset later diverge.

Store four pieces of evidence for a durable schedule:

1. intended local calendar date;
2. intended local clock time;
3. named IANA zone;
4. resolved UTC instant.

The sending system should also record which timezone-data release or runtime produced the resolution. IANA updates the database when political bodies change boundaries, offsets, or daylight-saving rules. A schedule resolved months earlier may need re-resolution when rules change before delivery.

## Daylight-saving gaps and repeated times

Clock changes create two special cases.

A spring-forward transition can make some local times nonexistent. A clock may jump from 01:59 to 03:00, so 02:30 has no corresponding instant.

A fall-back transition can repeat a local interval. A clock may move from 01:59 back to 01:00, so 01:30 corresponds to two distinct instants.

The tool's normal daytime hours avoid most transition periods, but the general problem still belongs in production scheduling. A sender must define a policy:

- move a nonexistent time forward to the next valid instant;
- move it backward;
- skip the send;
- use a fixed UTC instant for that occurrence;
- choose the earlier or later instant when a local time repeats.

Record that policy. Do not let a runtime choose silently for a high-risk or recurring campaign.

## Model inputs

### Local send date

The date is interpreted separately in each cohort's named zone. “August 4” means August 4 on the recipient cohort's local calendar, not August 4 UTC everywhere.

That can produce UTC dispatches on different calendar dates. A 9 AM Auckland send may occur on the preceding UTC date, while a 10 AM Los Angeles send occurs much later.

### Delivery capacity per hour

Capacity should represent the binding operational throughput after all relevant limits:

- account or plan limits;
- provider rate limits;
- IP or domain ramp constraints;
- internal job throughput;
- recipient-domain throttling;
- safety caps during migrations or incidents.

The planner applies one shared constant rate. Real delivery is not perfectly uniform. Providers can burst, retry, throttle by destination, or separate transactional and broadcast pools. Use a conservative sustained rate and preserve actual provider telemetry after sending.

### Outcome metric

The tool supports unique clicks, conversions, and replies.

Choose the event closest to the message's job that can be measured consistently. A product announcement may use qualified clicks or feature adoption. An onboarding email may use activation. A sales message may use replies or meetings. A recovery message may use completed payment.

Open rate is not included as the primary planning option because image loading, caching, privacy protections, bots, and client behavior can separate a recorded open from a human reading event. Opens can still be useful directionally, but an optimizer should not automatically treat them as business value.

### Baseline rate

Use a baseline from comparable messages, audiences, and outcome windows. A click baseline from newsletters may not fit a security alert. A conversion baseline from highly active users may not fit a dormant cohort.

Define the denominator explicitly. “3% conversion” could mean:

- conversions divided by delivered messages;
- conversions divided by unique recipients;
- conversions divided by clicks;
- conversions within seven days divided by eligible recipients.

The experiment assumes independent recipient-level binary outcomes with one stable denominator per variant.

### Minimum relative lift

The minimum relative lift is the smallest timing improvement worth detecting.

If the baseline is 3.2% and the minimum relative lift is 15%, the challenger target is:

    3.2% × 1.15 = 3.68%

The absolute difference is 0.48 percentage points. Statistical sample size depends on the absolute difference, so low baseline rates and small relative lifts can require large audiences.

Do not choose the minimum effect only to make the test fit the current list. Define a practical threshold from economics, customer experience, and operational cost.

### Test allocation

The allocation is the share of the total audience available to the control and challenger timing variants. The tool divides that test pool equally between two variants.

Reasons to allocate less than 100% include:

- preserving a production treatment;
- limiting exposure to a disruptive challenger time;
- maintaining a separate holdout;
- testing only eligible cohorts;
- reducing operational risk.

A smaller test pool may require repeated comparable sends.

### Challenger offset

The offset moves the challenger relative to each cohort's preferred local hour. A +3 hour challenger tests later delivery in every zone; a −2 hour challenger tests earlier delivery.

Check the allowed window. A challenger outside the operating window may be unacceptable even if it creates stronger experimental separation. Timing tests should not knowingly violate quiet hours, recipient expectations, contractual requirements, or product urgency.

## The timing-fit heuristic

The planner needs a transparent way to compare schedules. It uses a heuristic rather than pretending to predict engagement.

For a cohort, the circular distance between actual local hour and preferred local hour is the shorter path around a 24-hour clock. The proximity score is:

    proximity = max(0, 100 − 13 × distance in hours)

If the actual hour is inside the cohort's allowed window, fit equals proximity. Outside the window, fit is multiplied by 0.35.

The overall strategy score is the recipient-weighted average:

    weighted fit = Σ(cohort fit × cohort recipients) / Σ(cohort recipients)

This score has no industry benchmark and no probabilistic interpretation. An 85% fit does not mean an 85% open probability or an 85% chance of winning. It is only a consistent comparison of the preferences entered into this plan.

The editable preference is the evidence-bearing input. The score makes tradeoffs visible.

## Throughput queue simulation

Dispatches are sorted by planned UTC time. For each cohort:

    actual start = max(planned start, previous dispatch finish)

    duration hours = cohort recipients / capacity per hour

    finish = actual start + duration

This is a single-server queue with constant throughput. It is deliberately simple and auditable.

If several cohorts resolve to the same UTC instant, the largest cohort is ordered first. That is a deterministic tie-breaker, not necessarily the best production policy. A real sender may:

- interleave cohorts;
- reserve capacity by region;
- run parallel queues;
- prioritize higher-risk or more time-sensitive groups;
- cap per-domain volume;
- spread a cohort across several IP pools.

If queue delay is material, divide capacity explicitly or move planned starts. Do not merely hide the delay from the report.

## Interpreting local versus global delivery

Local-time cohort delivery is usually appropriate when:

- the message is not urgent;
- recipient time zones are known with reasonable quality;
- the message benefits from waking or working hours;
- the sending platform supports reliable cohort scheduling;
- throughput can preserve local windows.

A single global dispatch may be appropriate when:

- the message is urgent or synchronized;
- the event begins at one absolute instant;
- legal or product timing requires simultaneous notice;
- time zones are missing or unreliable;
- local optimization creates unacceptable operational complexity.

The comparison helps quantify the timing compromise. It does not decide the product requirement.

## Timezone data quality

Recipient time zone may come from:

- an explicit profile preference;
- billing or shipping location;
- account locale and organization location;
- product activity timestamps;
- IP-derived location;
- a default workspace or company zone.

These sources have different reliability and privacy implications. IP inference can be wrong because of mobile networks, corporate gateways, travel, and VPNs. A company headquarters zone may not describe an individual employee. A stale profile may describe a former location.

Store provenance and recency where possible. Create an “unknown” policy rather than forcing low-confidence recipients into a precise local schedule. Examples include:

- use the account's declared zone;
- use a conservative global window;
- assign by recent product activity;
- exclude from the timing experiment;
- ask the recipient for a preference when appropriate.

Never upload recipient-level location data to this browser tool. Aggregate cohorts before planning.

## Designing a credible send-time experiment

### Write the hypothesis

A useful hypothesis names:

- population;
- control timing;
- challenger timing;
- message class;
- primary outcome;
- attribution window;
- minimum practical effect;
- guardrail metrics.

Example:

> For active trial users in each named timezone cohort, sending the onboarding reminder three hours later will increase seven-day activation conversion by at least 15% relative without increasing unsubscribe or complaint rates.

### Randomize inside cohorts

Do not compare East Coast recipients sent at 9 AM with Pacific recipients sent at noon and attribute the difference to clock time. Geography and recipient composition are confounded.

Within each timezone cohort, randomly assign eligible recipients to control or challenger. Preserve allocation proportions. Analyze the overall stratified result and predeclared cohorts, not every segment discovered after the fact.

### Hold content constant

Use the same:

- subject and preheader;
- sender identity;
- HTML and text content;
- offer and expiration;
- audience eligibility;
- personalization rules;
- tracking;
- delivery infrastructure where practical.

If content changes, the experiment tests a package rather than time.

### Control calendar effects

Hour-of-day and day-of-week can interact. A Tuesday 9 AM control compared with a Friday 1 PM challenger changes two factors. Holidays, launches, billing cycles, and news can also affect behavior.

Run variants on comparable dates or randomize timing within the same campaign where the outcome allows it. Repeated campaigns should rotate or balance calendar positions.

### Choose one primary outcome

Declare one primary outcome before looking at results. Secondary metrics help explain behavior, and guardrails detect harm, but testing many outcomes and selecting the best-looking result inflates false-positive risk.

Useful guardrails include:

- unsubscribe rate;
- spam complaint rate;
- bounce or deferral rate;
- support volume;
- conversion quality;
- revenue per recipient;
- downstream retention.

### Avoid uncontrolled peeking

Checking significance repeatedly and stopping when the p-value first crosses a threshold changes the error rate. Use a fixed horizon, a valid sequential design, or an analyst-approved monitoring rule.

### Preserve assignment

For repeated sends, keep a recipient in the same timing variant when the hypothesis concerns cumulative experience, unless the design explicitly uses crossover assignment. Changing treatment between sends can create contamination and carryover.

## Sample-size method

Let:

- p1 be the baseline probability;
- p2 be baseline multiplied by one plus the minimum relative lift;
- p-bar be the average of p1 and p2;
- Δ be p2 minus p1;
- 1.96 represent a two-sided 95% normal critical value;
- 0.84 represent approximately 80% power.

The planner uses:

    n per variant =
      [1.96 × √(2 × p-bar × (1 − p-bar))
       + 0.84 × √(p1 × (1 − p1) + p2 × (1 − p2))]²
      / Δ²

The result is rounded up.

This approximation assumes independent binary outcomes and two similarly sized variants. It does not account for:

- clustering by company or household;
- repeated observations from the same recipient;
- covariate adjustment;
- unequal allocation;
- finite-population correction;
- sequential monitoring;
- many comparisons;
- noncompliance or missing events;
- overdispersion;
- revenue distributions;
- timezone-stratified estimators.

When accounts contain many recipients whose actions are correlated, randomization and analysis may need to occur at the account level. Consult a statistician for high-stakes or complex experiments.

## Why “sends needed” is directional

When one campaign's allocated test pool is smaller than the sample requirement, the tool divides required per-variant sample by available per-variant sample and rounds up.

That estimate assumes each future send is comparable and contributes fresh independent recipients or otherwise valid repeated observations. Reusing the same people without a repeated-measures design does not simply create more independent sample. Message fatigue, learning, and carryover can change response.

Treat the number as a planning signal: the hypothesis may need a longer program, broader eligible population, larger practical effect, or a different outcome.

## Operational workflow

### 1. Define the message job

State whether the email is transactional, lifecycle, campaign, sales, operational, or urgent. Timing flexibility differs. A password-reset email should not wait for a preferred marketing hour.

### 2. Build aggregate cohorts

Group eligible recipients by reliable named timezone and meaningful behavioral preference. Preserve an unknown-zone cohort and document its policy.

### 3. Estimate sustainable capacity

Use provider and sender telemetry, not only a contractual maximum. Include warmup, reputation, destination throttles, and concurrent traffic.

### 4. Enter a local preference

Use historical evidence or a concrete audience hypothesis. Do not copy a generic benchmark without testing relevance.

### 5. Inspect the dispatch manifest

Review UTC start, local start, queue delay, finish, and allowed-window status for every cohort. Share the CSV with the sending-operations owner.

### 6. Configure the provider

Verify whether the ESP accepts:

- one absolute UTC timestamp per campaign;
- send-in-recipient-timezone behavior;
- account-local timestamps;
- delayed or rate-limited delivery;
- timezone fallback rules;
- recurring schedules across DST.

Test with seeded accounts in multiple zones.

### 7. Run a controlled timing test

Randomize inside cohorts, preserve content, instrument the declared outcome, and monitor guardrails.

### 8. Reconcile planned and actual delivery

After sending, compare planned start with accepted, delivered, deferred, clicked, converted, or replied timestamps. Use delivery time, not only campaign job creation time, when estimating exposure.

### 9. Update the evidence

Promote a new preferred hour only when the result is practically and statistically credible. Keep uncertainty and cohort coverage with the decision.

## Provider handoff checklist

Before scheduling:

- confirm all timestamps are UTC instants;
- retain the intended local time and IANA zone;
- verify timezone-data freshness;
- define DST gap and overlap policy;
- confirm provider account timezone;
- confirm rate-limit and concurrency behavior;
- separate urgent transactional traffic from campaigns;
- validate recipient eligibility immediately before send;
- seed representative zones;
- monitor deferrals and queue drift;
- preserve unsubscribe and complaint controls;
- record the exact template and audience query.

The JSON export contains assumptions, summary, dispatches, experiment sizing, and warnings. The CSV contains one dispatch row per cohort for operations. The copied brief gives a reviewable human handoff.

## Limitations

The planner does not:

- discover recipient time zones;
- inspect historical engagement;
- connect to an ESP;
- schedule or send messages;
- model receiver-domain throttling;
- predict delivery or inbox placement;
- predict opens, clicks, conversions, or replies;
- account for every DST ambiguity;
- prove an experiment is randomized;
- compute a final p-value or confidence interval;
- optimize several business outcomes simultaneously.

The browser runtime provides timezone behavior. A production scheduler may use a different tz database release and resolve a future local time differently after a political rule change. Reconcile the exported plan with the production environment.

## Frequently asked questions

### What is the best time to send email?

There is no universal answer. Define the message goal, audience, named zones, acceptable windows, and outcome. Use historical evidence to choose candidates and randomized experiments to learn.

### Is Tuesday at 10 AM a reliable benchmark?

It can be a hypothesis, not a guarantee. Benchmark studies reflect their samples, messages, geographies, metrics, and collection periods. Your audience can behave differently.

### Should the campaign use recipient-local delivery?

Use it when timing is flexible, zones are reliable, and operational capacity can preserve the window. Do not delay urgent or synchronized messages merely to optimize engagement.

### Why not optimize opens?

Recorded opens can include automatic image loads, privacy proxies, bots, and client-specific behavior. Prefer a stable event closer to business or recipient value when possible.

### Can I use a fixed UTC offset?

Use a named zone for future civil-time schedules. Fixed offsets do not carry daylight-saving or political changes.

### Why is the actual local start later than the preferred hour?

The queue applies the shared capacity limit. Earlier dispatches can consume the available throughput and delay later cohorts.

### What does weighted fit mean?

It is a transparent heuristic measuring proximity to supplied preferred hours and windows, weighted by cohort recipients. It is not a probability or industry score.

### Does the global comparison include delivery duration?

The global candidate score compares start instants before provider duration. A true global blast can still roll out over hours. Inspect capacity and provider behavior before using it.

### Can a timing test run across multiple campaigns?

Yes, with a design that handles repeated recipients, calendar effects, message differences, and carryover. The simple sends-needed estimate does not make those observations independent.

### What if the required sample is too large?

Consider a larger practical effect, longer test program, broader eligible audience, more frequent valid observations, or a higher-rate outcome closer to the message. Do not lower statistical standards merely to obtain a result.

### Does the tool upload audience data?

No. Calculations remain in the browser. Enter aggregate cohort counts, not recipient records.

## Primary technical references

- [IANA Time Zone Database](https://www.iana.org/time-zones)
- [IANA: Theory and pragmatics of the tz code and data](https://www.iana.org/time-zones/theory)
- [IANA: Time zone and daylight saving data](https://www.iana.org/time-zones/tz-link)
- [ECMA-402 Internationalization API specification](https://tc39.es/ecma402/)
- [NIST: Proportion confidence intervals](https://www.itl.nist.gov/div898/software/dataplot/refman1/auxillar/propconf.htm)

## Related Email Bump tools and guidance

- [Email A/B test calculator](https://emailbump.com/tools/email-ab-test-calculator.md)
- [Email list growth calculator](https://emailbump.com/tools/email-list-growth-calculator.md)
- [SaaS email ROI and payback calculator](https://emailbump.com/tools/saas-email-roi-calculator.md)
- [Email UTM campaign builder](https://emailbump.com/tools/utm-builder.md)
- [Email word and structure analyzer](https://emailbump.com/tools/email-word-counter.md)
- [Email deliverability readiness audit](https://emailbump.com/tools/email-deliverability-readiness-audit.md)
- [Campaign documentation](https://emailbump.com/docs/campaigns.md)
- [Analytics documentation](https://emailbump.com/docs/analytics.md)
- [Automated flows documentation](https://emailbump.com/docs/flows.md)
- [Click-through rate glossary definition](https://emailbump.com/glossary/click-through-rate.md)
- [Open rate glossary definition](https://emailbump.com/glossary/open-rate.md)
- [Segmentation glossary definition](https://emailbump.com/glossary/segmentation.md)