Does Send Time Optimisation Work?

Send time optimisation models are trained on when recipients opened messages, and open timestamps now include machine activity that has nothing to do with when anyone was reading.

Privacy protection pre-fetches message content on its own schedule, regardless of whether the recipient opened it. Security gateways fetch content during pre-delivery scanning, which happens before the recipient has seen anything at all.

A model learning "this person opens at 8:47am" may be learning when a proxy fetched images. And because the machine and human events are not separable from outside, neither you nor the vendor can say which it learned.

That is the central problem with the feature, and it is rarely stated on the pages selling it.

---

What the feature claims

Two versions, and they fail differently.

Per-recipient send time. The platform holds each contact's message and delivers it at their individual predicted best moment. This is the version most affected by the timestamp problem, because it depends entirely on per-person open history.

Aggregate best time. The platform recommends one send time for the whole list based on pooled behaviour. Less broken, and also less useful — a single time for a whole list is a weak claim even with clean data.

---

What can still be said about timing

Three things hold, and none of them requires a model.

1. Timing relative to an action beats timing relative to the clock. A message sent because somebody did something — abandoned a cart, finished onboarding, hit a usage threshold — outperforms one sent at an optimal hour. This is the real finding hiding underneath the send time conversation, and it is available to anyone with triggers.

2. Time zones matter and are not optimisation. Sending at 9am in the recipient's own time zone is straightforwardly better than 9am in yours, and it requires no prediction — just their location, which most platforms hold.

3. Consistency has value. A newsletter that arrives at a predictable time gets a habit built around it. Predictability is a real effect and it is the opposite of per-recipient optimisation, which deliberately varies delivery.

---

What the evidence actually looks like

Published "best time to send" figures come almost entirely from platform vendors analysing their own customers' sends.

Three problems with that class of evidence:

• No control group. The comparison is between sends that happened, not between a send and its counterfactual
• Selection effects. Senders who schedule carefully differ from those who do not in ways that are not timing
• The metric is opens, which is the thing that broke

And they disagree with each other, which is the practical tell. Different vendors publish different optimal hours from the same underlying question, which is what you expect when the effect is small relative to the noise.

I have not found an independent controlled study establishing a meaningful send time effect. That is not proof there is none — it is a reason not to spend attention on it. Why vendor statistics are a weak source class.

---

Where the effort is better spent

The things that demonstrably affect whether a message is read, in order.

1. Whether it reaches the inbox at all. Authentication, reputation, complaint rate. A perfectly timed message in the spam folder is not timed at all — and this is where most of the available improvement sits for most senders. What determines placement
2. Whether it is relevant. Segment-level topic matching, which beats every timing consideration
3. Whether it was triggered by something they did
4. Whether the subject line says something. What that means
5. Whether you send at a sensible hour in their time zone, consistently

Send time optimisation, if you use it at all, sits below all five.

---

If you want to use it anyway

Two conditions make it defensible.

It costs you nothing. If it is included and requires no configuration, using it is not a mistake — it is a small unverifiable effect.

It does not fragment your sending. Per-recipient delivery spreads one campaign across many hours, which changes your sending pattern from a defined burst into a long tail. On a young domain or an unwarmed subdomain, a consistent, predictable sending pattern is worth more than a timing gain you cannot measure. Why sending patterns matter.

And do not evaluate it on opens. If you want to know whether it did anything, hold back a portion of the list from it and compare replies, purchases and sign-ups. Almost nobody does this, which is why the feature has survived without evidence.

---

Frequently asked questions

Does send time optimisation actually work?
The evidence is weak and the mechanism is compromised. These models train on open timestamps, which now include privacy pre-fetches and security gateway scans that have nothing to do with when a person was reading — and the machine events cannot be separated out from outside.

What is the best time to send marketing emails?
Published figures come from platform vendors analysing their own customers' sends, with no control group, strong selection effects, and opens as the metric. They disagree with each other, which is what you expect when an effect is small relative to noise. A sensible hour in the recipient's time zone, consistently, is the defensible answer.

Does time zone matter for email sending?
Yes, and it is not prediction — it is arithmetic. Sending at a reasonable local hour rather than a reasonable hour in your own time zone requires only the recipient's location, which most platforms already hold.

Is it better to send at a consistent time?
For recurring sends like newsletters, consistency lets recipients build a habit around it, which is a real effect. It is also the opposite of per-recipient optimisation, which deliberately varies delivery — so the two approaches cannot both be pursued.

Does per-recipient send time affect deliverability?
It can, by spreading one campaign across many hours and turning a defined sending burst into a long tail. On a young domain or an unwarmed subdomain, a consistent and predictable sending pattern is generally worth more than an unmeasurable timing gain.

How would I test whether send time optimisation helps?
Hold back a portion of the list from it and compare outcomes at the destination — replies, purchases, sign-ups — not opens. Almost nobody runs this test, which is a large part of why the feature persists without evidence.