Life after the open rate

A retention team showed us a dashboard where the open rate had risen for eight consecutive quarters. Revenue per email over the same period was flat. Both numbers were accurate, and together they described nothing at all.

The rise was not engagement. It was Apple Mail fetching images on the recipient's behalf, whether or not a person ever looked at the message. Mail Privacy Protection has been on by default long enough that a large share of a consumer list now registers an open the moment mail lands.

That would be survivable if the open rate were a secondary metric. In most programmes it is load-bearing. It decides who counts as active, when a sunset flow fires, which subject line wins, and what gets reported upwards. All of it now rests on a number the sender no longer controls.

What the open rate actually measures now

An open is a request for a tracking pixel. It was always a proxy and always wrong at the edges: image blocking undercounted, preview panes overcounted. The difference is that the error used to be small and roughly stable, so the trend still meant something.

Pre-fetching turns that error from noise into a structural bias that varies by audience. Two segments with different Apple Mail shares are no longer comparable on opens. Neither is the same segment across two years, as adoption grew underneath the chart.

You cannot correct for this in a way you can defend. Filtering on user agent gives an estimate, not a clean read, and the estimate decays as proxying becomes more common. We do not build measurement on a correction factor nobody can audit.

Keep the open rate as a one-directional diagnostic. A sudden fall still tells you something, usually that delivery has broken. A rise tells you nothing.

Pick measures that survive a proxy

The replacement is not a single metric. It is a short stack, ordered by how close each one sits to money.

• Orders and revenue per message sent. Per sent, never per delivered and never per opened. A denominator that moves with deliverability hides the problem you are trying to see.
• Clicks per message sent, with bot filtering applied. Security scanners click too, so exclude the ones that hit every link within seconds of delivery.
• Sessions attributed to the send, for programmes where the action follows a visit rather than a direct click.
• Unsubscribes and complaints per message sent, read as a pressure gauge on frequency.
• Delivered rate by mailbox provider, which is where inbox trouble shows up before anything else moves.

Each has its own flaws. Clicks shift when a template changes, and revenue attribution depends on a window somebody chose. The point is that none of them is manufactured by a machine that never showed the message to a human.

Complaint rate is now the number that decides delivery

Since the bulk sender requirements took effect in February, the complaint rate is not a health metric. It is a gate. Gmail publishes a threshold of 0.3 per cent reported spam and advises staying below 0.1 per cent, and crossing it affects whether mail arrives at all.

That reframes the reporting stack. The open rate was a thing you optimised. The complaint rate is a constraint you stay inside, and everything else is optimised within it.

In practice:

• Report complaints per send, split by mailbox provider, on the same page as revenue. A blended average lets Microsoft volume hide a Gmail problem.
• Treat one-click unsubscribe as a feature rather than a leak. Someone who unsubscribes has not complained.
• Set an internal ceiling below the published one, and give the campaign team authority to pause a send that breaches it without asking permission.

The authentication side of this should already be finished. If your sending domain has moved to a reject policy, as we argued in the case for going to p=reject, the requirements are a checklist rather than a project.

Rebuild engagement segments before you sunset anyone

Most inactivity policies read "no opens in 180 days". Under pre-fetching that rule now suppresses the wrong people in both directions. Someone who ignores every message but uses Apple Mail keeps registering opens and stays in the file. Someone who reads everything in a client that blocks images looks dead.

Rewrite the definition around actions the recipient has to take themselves:

1. Clicked any message in the window, after bot filtering.
2. Visited the site or app from any source in the window.
3. Purchased, booked or logged in.
4. Changed a preference, updated a profile, or replied.

Run the new definition alongside the old one for a full cycle before you switch anything off. Look at how many people change category, and in which direction.

If the two definitions disagree wildly, that disagreement is the finding. In the programmes we have migrated it usually points at a tracking gap on site or app, not at the customers.

Redesign the tests that used opens as the read

Subject-line testing is the obvious casualty. An A/B test read on opens is now measuring which line reached more Apple addresses, which is a property of the random split rather than the copy.

Move the read to the click, or better to the order. That costs sensitivity, because conversion rates are small and the sample needed to reach significance grows accordingly. Some of the small weekly tests are no longer worth running.

This is a good outcome dressed as a loss. Four tests a quarter with a real read beat a weekly winner that never survived contact with revenue.

For programme-level questions the answer was never a subject-line test anyway. Does this journey earn its place, is the extra weekly send additive, would these people have bought regardless. Use a holdout group and compare revenue per eligible customer over a fixed window. That method never depended on opens, so none of this touches it.

What to do this week

• Change the headline metric on every recurring CRM report to revenue per message sent, with complaint rate by mailbox provider beside it.
• Audit every automation with an open-based entry, exit or branch condition, and rewrite the condition on clicks, visits or purchases.
• Re-run your inactivity definition on behaviour rather than opens, compare the two populations, and decide which is closer to the truth before anyone is suppressed.