Two things are wrong with the comparison everybody makes. The number you are holding is not the same measurement as theirs. And a large part of it was never a person.

A share of your opens are machines

Apple shipped Mail Privacy Protection with iOS 15 in 2021. Apple Mail now fetches the images in a message through Apple's own proxy and caches them, whether or not anybody has looked at anything. A tracking pixel is an image. It fires on delivery.

Customer.io, to take the platform I work in most, documents this without euphemism: it counts a significant share of Apple Mail Protected opens as machine opens, warns that your overall open rate overstates real engagement when a lot of them come from that client, and tells you to look at human opens and clicks instead — human opens being the ones it attributes to real people rather than bots, scanners and prefetching.

So the honest reading of a raw open rate is three things added together. Some people. Every Apple Mail recipient the message reached. And whatever security scanner the recipient's employer points at inbound mail before a human sees it. Those three move independently of each other, and two of them move independently of anything you did.

The practical consequence is worse than the inaccuracy. A number that is inflated by a stable amount is still usable for comparison against itself. A number inflated by the share of your list that happens to use Apple Mail moves when your audience mix moves — a campaign that reaches more consumers and fewer work addresses will show a higher open rate for that reason alone.

The published average is an average of somebody else

Look up a benchmark and you get a figure with an industry label on it. What produced that figure is one vendor's own customers over some window: their list hygiene, their send types, their countries, their definition of a delivered message, their rules about what counts as an open.

Inside that one number sit transactional receipts that people genuinely want and promotional blasts they tolerate, lists built by double opt-in and lists bought in bulk, reactivation sends aimed at the dead and welcome emails aimed at somebody who signed up ninety seconds ago. Averaging those produces a number that describes no actual programme, including the ones it was computed from.

Then you compare your figure to it. Your figure comes from a different population, a different measurement and a different mix of send types. Whatever the gap turns out to be, it tells you nothing you can act on.

The same marketer, the same decade, 12% to 75%

I have run email across a job board, an esports product, an info-product business, a streaming service and a B2B software company. Over those years my own open rates covered almost the whole available range.

On a business software product whose customers use it to run their day, regular sends averaged around 75%. On webinar funnels in info-business, the funnel sends averaged about the same, with regular content closer to 51%. In esports, a base of roughly two million took content sends up to 50% and triggered messages to 65%. On a job board, a set of triggers I rebuilt went from 12% to 25% — and 25% was a serious win there. In a mass consumer product, 15% can be a perfectly healthy number.

Same person. Same methods, more or less. A five-fold spread.

The difference was never craft. It was who was on the list and why they were there. People who open a product's mail because the product is how they earn money behave nothing like people who signed up for a discount in 2019. Any benchmark that puts those two groups in one average has thrown away the only variable that mattered.

This is also why the figure is so easy to game without improving anything. Delete the people who never open, and every rate on the dashboard improves while the business underneath it does not. I have described how that one plays out — it is the quietest way to make a programme look healthy while it shrinks.

What to compare against instead

Your own previous number, on like against like. That means splitting the series before you look at it, not after:

By send type. Transactional, triggered and broadcast are three different things and belong in three different series. A password reset and a Tuesday newsletter have no business sharing an average.

By segment. The people who opened something in the last two or three months are a different population from the rest of your list, and the industry's own answer to list fatigue — send the things that matter most to the engaged segment first — only works if you are measuring the two separately.

By geography, where your audience spans several countries. Mail client mix differs, and so does the share of your opens that Apple is manufacturing for you.

Then watch movement rather than level. A series that went 31, 30, 32, 24 is telling you something. A single 24 compared to an industry's 21.5 is telling you nothing.

Where you can, demote the open rate to a supporting role and promote the things further down. Clicks are harder to fake than opens, and a click-to-open ratio at least divides two numbers that came from the same send. Better still is the thing the message was supposed to cause — a return visit, a renewal, a restarted subscription. That number has no proxy problem at all.

Clicks have a ceiling of their own. A send can sit at a click rate of 0.1% and still be followed by a day of conversions big enough to see in the revenue, because the product lives on a screen that is not the one the mail was read on. So the number worth arguing over is the target action itself, counted against the people who received the message as well as against the people who opened it, with post-click attribution kept beside it rather than in place of it. I will come back to that in a later post.

Where the open rate is still worth watching

Not as a measure of how good the campaign was. As an instrument on the deliverability panel.

A sudden collapse across the whole base, every segment at once, is not a content problem and nobody needs a benchmark to interpret it. It means mail has stopped reaching inboxes, and the clock on fixing it starts the moment you notice. I found exactly that once, watching a number drop from normal to 5% overnight, and the number was useful precisely because I was comparing it to the day before rather than to anybody's industry table.

That is the whole honest use of it. A tripwire, not a scoreboard.

If you have to answer the question for somebody this week, the useful version is: show me the same send type to the same segment last quarter, and I will tell you whether this is good. Anyone who answers with a figure from a report has told you about their report, not about your programme.

RecurForge is being built to assemble that comparison for you, because doing it by hand is most of a week and the deciding is an hour. The form below is still the only working part of this site — leave an address if you want to hear when that changes.

That one taught me something inside an hour. The retention mistakes that actually cost money were nothing like it — they took years to surface, and at the time each one looked like a reasonable decision made by a competent person. These are the five, roughly in the order of how long it took me to see them.

I picked the platform on the wrong question

Setting up email from scratch for an online casino, I had to choose a sending platform. I chose one that delivers mail reliably and does very little else, because the thing I was worried about was whether messages would arrive.

They arrived. Then the work moved on to segmentation, the platform had almost none, and we built our own — a service written in-house to do what another product on the market was already doing out of the box. Engineering time went into rebuilding a feature we could have bought. I had not heard of Customer.io yet.

The right question was how much automation the programme would need in two years and whether the platform could carry it. Delivery is the floor. Everything that makes a lifecycle programme worth running sits above it, and you commit to a platform before you know the shape of what you will be running on it.

A rule I treated as a law

Value before the ask. Earn attention with something useful, then ask for the sale. I believed it enough to write content for a gambling audience — where slot machines came from, how the mechanics changed over the decades. The letters were decent. I liked them.

Emails that said deposit now and get a bonus beat them badly enough that there was no point running the comparison again.

The rule holds often enough to be worth teaching. It is a default, and someone along the way forgot to label it as one. Where people arrive with a specific intent and the offer is the thing they came for, the offer is the value, and wrapping it in an article is a slower way of making the same offer. The same goes for most of what gets taught as email principle — one job per email, keep it short, a thousand recipients per variant before you conclude anything. I have broken all of those since, on purpose, and in each case the context was the argument.

The segment that was not a segment

In an esports product I built a segment for a campaign meant to reach a narrow group. The condition did not hold, the platform sent to everyone on the base, and roughly ten times the usual volume left in a single run.

I built that segment, and nobody else was going to catch it, because the programme had no step at which somebody looks at the recipient count and asks whether that number makes sense. A send an order of magnitude larger than every send before it went out exactly like any other.

Google Postmaster had the sending domain at Bad inside a day. Open rate fell to 5%. Mail that had been landing in inboxes for months stopped landing.

What brought it back was that 5%. When a domain has to be rebuilt, the people who opened anyway during the worst of it are the most valuable addresses you own — they are proof, to the providers, that somebody wants this mail. You send only to them, you keep the volume low, and you climb back slowly on the engagement signal they produce. It worked. It took weeks of sending to a fraction of the audience while everything else waited.

The lesson is not that I should write segments more carefully, although I should. Broken conditions are ordinary; a programme where a broken condition reaches the entire base unchallenged is a design choice. A ceiling on recipients per send, set once, would have turned a two-month recovery into a confusing afternoon.

Two years on a number that divided the wrong things

An education company measured a channel's conversion rate by counting every registration that arrived with a UTM tag saying it came from the contact base, then dividing by the number of messages sent in one channel.

It took me longer than it should have to see what is wrong with that sentence, and I only got to look at it because my remit widened. I had email. When the other channels came to me as well, I recalculated by hand, and the fraction fell apart.

The top of it collected conversions produced by every channel the company ran. The bottom counted the sends of a single one. That channel was being credited with work done by all the others, and the less of it we sent, the better it appeared to perform.

Nothing about the number looked broken. It was stable, it went into the monthly report, and it pointed consistently in one direction — so the sending strategy followed it, for at least two years. Volume, build time and attention went where the fraction said the returns were.

No dashboard raises a flag on a formula that has been wrong since the day somebody wrote it. Dashboards check values, and the values were fine. A number that is wrong in a stable way is far more dangerous than one that jumps around, because the jumpy one gets investigated.

Whatever you divide, the top and the bottom have to describe the same population. That is the whole rule, it fits in one sentence, and two years of strategy went past without anybody checking it, me included.

The list nobody had cleaned

A company sends to every address it has ever collected, because nobody there knows that mailbox providers decide where mail lands by watching who engages with it. There is no laziness in this and usually no argument. The knowledge is specialist, the damage is delayed, and for a long stretch nothing looks wrong at all: more addresses, more sends, a bigger number in the report.

Then the dead addresses bounce on every run. The people who stopped caring years ago never open. The providers draw the obvious conclusion about a sender whose mail nobody wants, and the consequence arrives all at once — reputation down in Postmaster, inbox placement gone, mail in spam at scale, and an open rate that collapses across the whole base including the people who did want to hear from you.

I have been brought in on this more than once, most recently at a subscription video product, and by the time I get there the question is no longer whether to clean the list. It is whether the domain can be saved. It usually can. You stop sending to everything, you suppress what has not engaged instead of pretending it might, and you rebuild the reputation on the narrow group that still opens — the same move that got me out of my own mess in the esports product. We did exactly that, and the base came back.

What makes this the most common mistake on the list is that nobody ever experiences it as a decision. Nobody sits in a meeting and chooses to damage the domain. They inherit a list, they send to it, and the bill arrives two years later addressed to whoever is doing the job by then.

There are more of these than fit in one article. The ones about frequency, about benchmarks borrowed from somebody else's business, and about what happens to a programme when the person who built it leaves are separate posts, and I will get to them.

What these five have in common is that none of them was carelessness. Every one was a defensible decision made by a competent person, and every one sent its bill a year or two later, quietly, into a number nobody was watching for that reason. Some I made. Some were already running when I arrived, which changes who to be annoyed at and nothing else about the work.

The one thing that would have caught any of them sooner is a written record of what somebody believed when they decided, and what they expected to see if they were right. That record is the first thing to go when the week gets full.

RecurForge exists because I kept losing it. The form below is still the only working part of this site — leave an address if you want to hear when that changes.

In almost every programme I have inherited there was a trigger that had been firing since before anyone currently on the team joined. Built by someone who left. Still sending. Nobody turned it off, because nobody could say what it would break.

Fourteen years of this, across streaming, gaming marketplaces, edtech, job boards and fitness. The products had nothing to do with each other. The programmes failed the same way.

What it is not

The schedule is not it. A welcome series, a win-back, a monthly digest — those are outputs, and any competent marketer can have all three running by Friday. Plenty of teams do have all three running while retention slides.

Neither is the funnel diagram. Awareness, activation, retention, revenue, referral is a fine way to explain the shape of a business to someone outside it, and no help at all on Monday morning. Redrawing the stages has never fixed anything.

It also does not belong to email, though email usually gets the blame. Email is the cheapest channel and therefore the default one, so it inherits problems it cannot reach: a pricing page that confuses people, an app that asks for a card before showing anything, a retry schedule set once and never looked at again.

The unit of work is a hypothesis

The difference shows up in what a team asks itself at the start of the month. Usually the question is which sends are going out. The version that works is longer and less comfortable: what do we believe about these people, how would we find out we are wrong, and what would we change if we were?

A campaign ends at the send. A hypothesis is not finished until you know whether it was right — which means a number attached before it starts and a written answer afterwards, including when the answer is that nothing happened.

Most of what gets called a lifecycle programme contains no hypotheses at all. It contains a content calendar, a set of triggers with no owner, and a monthly report where open rate moves up and down for reasons nobody looks into.

The order that works

Find where it actually leaks. "Retention is down" is a symptom, and treating a symptom directly produces the send-more-emails reflex. Compare cohorts against each other until you can name a step — the second month, the third message of onboarding, the renewal that fails without telling anyone. A leak you can point at is a leak somebody can fix.

Ask why before you ask what to send. Teams skip this, and skipping it is exactly what produces the calendar. People who leave in month two and people who leave in month nine are leaving for unrelated reasons, and one message will not speak to both. Make the question narrow enough that it can come back wrong: not why do people churn, but what did the ones who left in month two do differently in their first week.

Then decide the change. The channel comes last. Sometimes the answer really is an email. Often it is a push two hours earlier, a different default in the product, a billing retry moved up by three days, or a screen that stops asking for something the person does not have yet. Picking the channel first is how a product problem gets a communications answer and stays unsolved for another quarter.

Measure against something honest. Convenient baselines flatter whatever you just shipped. People who opened the email retained better — they also retained better before the email existed, because opening is a symptom of intent rather than a cause of loyalty. If a change is worth three weeks of building, it is worth withholding from a random slice to find out whether it did anything.

Write down what happened. Failures especially. This step gets dropped first and costs the most, because without it the same test gets run again in eighteen months by somebody new who has no way of knowing.

Where it breaks

Starting at the channel is the most common one. "We need a welcome series" is not a hypothesis, it is a purchase order. It might even be the right thing to build. You will not know, and three weeks will be gone either way.

Then there is the habit of counting billing failures as churn. In the subscription products I have worked on, a serious share of what got reported as people leaving was cards that expired and payments that bounced. Those people made no decision. They received win-back campaigns asking why they were unhappy, which is useless and faintly insulting, when what they needed was a retry schedule and a working card-update link. Fixing the billing side is usually the cheapest retention work available in the whole company, and it almost never sits with the person who owns retention.

Treating engagement as the goal is subtler. Opens and clicks are diagnostics — they tell you whether a message worked as a message, and nothing about whether it changed behaviour. Optimising them directly ends somewhere unpleasant: subject lines that earn the open and spend the trust, a frequency that lifts total clicks while quietly burning the list underneath.

That list, by the way, is the number nobody watches. Not its size — the ratio between how many contacts you remove each month and how many you add. Once removal catches up with acquisition, every metric shaped like a rate keeps looking fine while the absolute numbers fall.

The last one is the most expensive and the hardest to see. Teams keep a folder of campaigns and no record of reasoning. Which tests ran, what came back, what it meant — gone with the last person who did the job. Nothing breaks when this happens. The work just gets done again.

What it looks like on an ordinary Tuesday

Less glamorous than the frameworks suggest.

You pull the numbers for the segment you were suspicious about last week. Most weeks they say nothing. Occasionally one cohort behaves differently enough to be worth an hour, and that hour is the job. Then you spend a second hour deciding whether the difference is real or an artefact of how you built the cohort, and it usually turns out to be an artefact.

When it is real, you write down what you think is causing it, what you would change, and what you expect to happen. Then you build the smallest version of that change that could still work, and you resist the urge to make it bigger.

Assembling the numbers takes most of the week. Deciding takes an hour. That ratio is the real problem with this discipline, and it is why so much lifecycle work never gets past keeping the existing thing alive.

If you are starting from nothing

The instinct is to gather everyone in a room and draw the journey map. A map built that way is a document about your assumptions, and it will be wrong in precisely the places that matter.

Build it out of behaviour instead. Collect the paths people actually take, lay them out in the order things happen, and mark where one action leads to the next. The triggers fall out of that graph on their own — they are the moves between states, not the boxes. Start with one question you cannot currently answer, usually some version of where do people go after this, and the map assembles itself while you answer it.

I am building RecurForge because of the ratio in that Tuesday paragraph. The deciding is the part worth paying someone for, and the assembling eats the week. If that is your week too, the form below is the only thing on this site that does anything yet — leave an address and I will write when there is something to show.