The Email Metrics That Predict Revenue, and the Ones That Lie
Apple's Mail Privacy Protection quietly broke the open rate as a trustworthy number. Here is which email metrics still tell an agency the truth about what a campaign actually did.

Open rate used to be the first number anyone looked at in an email report, and it is now the number least likely to mean what it appears to mean. That is not a minor asterisk, it is a structural problem with the metric that agencies reporting on client email need to account for explicitly, because the client asking why opens look strong while revenue looks flat is asking a completely reasonable question about a number that stopped measuring what they think it measures.
Why open rate stopped being trustworthy
Apple's Mail Privacy Protection, enabled by default for Apple Mail users, pre-fetches every email's images, including the invisible tracking pixel that open-rate tracking depends on, the moment the message is delivered rather than when a person actually opens it. According to Litmus, Apple Mail accounts for roughly half of all email opens tracked industry-wide, which means close to half the open signal in a typical send is now a proxy server firing a pixel automatically, not a person reading an email. Postmark's own analysis puts it plainly: a list with a heavy Apple Mail concentration can show a 100% open rate regardless of whether anyone actually opened anything.
The practical effect compounds beyond just an inflated headline number. Because false opens generated by Apple's proxy never click through, they quietly drag down click-to-open rate as a side effect, making a genuinely engaged list look worse on that derived metric even as raw opens look artificially better. A report built around open rate as the primary signal is measuring server behavior mixed in with human behavior, with no reliable way to separate the two from the open number alone.
What still tells the truth
Click rate is not perfect, but it requires an actual person to act, which a prefetch request does not do. Click-through rate as a share of delivered sends, not opens, becomes the more reliable engagement signal once open rate is compromised, since dividing clicks by an inflated open number just launders the same distortion into a second metric. Revenue per send and conversion rate tied to an actual purchase or lead event go a step further, because they are anchored to something that happened outside the inbox entirely and cannot be inflated by a mail client prefetching an image.
List growth versus list decay is the metric most reports leave out entirely, and it is one of the more reliable predictors of whether a program is actually healthy. A list that is growing from genuine opt-ins, with unsubscribe and complaint rates held low, is compounding reach every send. A list padded with old, disengaged addresses can show flat or even improving vanity metrics for months while quietly eroding deliverability in the background, since sender reputation is judged against engagement, not list size. Spam reports, unsubscribes, and bounces, the metrics Postmark specifically points to as more reliable than opens, double as an early-warning system for exactly that kind of decay before it shows up as a revenue problem, and they carry a second, harder consequence: Google's own bulk sender guidelines treat a rising spam complaint rate as grounds to block a sender outright, which means a metric an agency might otherwise file under vanity reporting is also a compliance signal worth watching for its own sake.
Revenue per send should also be broken out by send type, not blended into one program-wide figure, because the two most common types of email behave very differently against it. Klaviyo's own benchmark data found that automated flows, welcome series, abandoned cart, post-purchase, generate nearly 41% of total email revenue from just 5.3% of total sends, with revenue per recipient on flows running roughly eighteen times higher than one-off campaigns. A report that blends flow and campaign performance into a single revenue-per-send number is averaging together two channels with wildly different efficiency, which hides exactly the kind of underinvestment in automated flows that a client would want flagged.
- Report click rate and revenue per send as the primary performance signal, not open rate
- Track list growth and unsubscribe rate together, since one without the other hides list decay
- Watch spam complaint rate and bounces as leading indicators, not just a compliance checkbox
- Keep open rate in the report for context, but label it clearly as directionally unreliable post-MPP rather than dropping it silently
Building a metrics hierarchy instead of a flat list
A report that lists ten metrics with no ranking between them leaves a client to decide for themselves which number matters most, and most clients will default to whichever one is largest or easiest to understand, which is usually open rate. A more useful structure sorts the same numbers into three tiers instead of one flat list. The primary tier is revenue per send and conversion rate, the numbers tied to an event that happened outside the inbox and cannot be inflated by a mail client prefetching an image. The secondary tier is click rate and list growth, reliable directional signals that still require interpretation alongside the primary tier rather than standing alone. The contextual tier is open rate, deliverability rate, and spam complaint rate, numbers worth including for a complete picture but explicitly framed as supporting context rather than headline performance. Building a report template around that hierarchy, rather than a flat table where every metric gets equal visual weight, does more to fix the open-rate problem than any amount of caveat text buried in a footnote.
Segmenting the report by lifecycle stage, not just by send
A blended, program-wide revenue-per-send number hides as much as a blended open rate does, just for a different reason. A welcome series sent to a subscriber three days into the relationship, a win-back campaign sent to someone who has not opened anything in six months, and a standard promotional campaign sent to an actively engaged segment are three completely different audiences with three different baseline expectations, and averaging their performance into one program-wide number obscures which piece of the program is actually carrying the results. Reporting revenue per send broken out by lifecycle stage, new subscriber, actively engaged, lapsing, win-back, shows a client where the program is genuinely strong and where it is coasting on a few high-performing segments while a larger lapsing segment quietly drags the average down without ever showing up as its own line item.
- Rank metrics into primary, secondary, and contextual tiers in the report template, rather than presenting every number with equal visual weight
- Break revenue per send out by lifecycle segment, not just by campaign, so a strong welcome flow cannot mask a decaying lapsed-subscriber segment
- Pair every open-rate figure shown with the click or revenue figure for the same send, so the two numbers get read together rather than the open number standing alone
Explaining the shift to a client without losing their confidence
The MPP conversation goes wrong most often when it gets introduced defensively, after a client has already noticed a gap between opens and revenue and asked about it. The stronger version of this conversation happens proactively, in the first report after Apple Mail share is confirmed to be a meaningful slice of the list, framed plainly: a large share of reported opens now come from Apple's servers checking a message automatically rather than a person reading it, which is why the report leads with click and revenue numbers instead. Clients who hear that framing before they notice the gap themselves treat it as useful context. Clients who have to ask first tend to hear the same explanation as an excuse, even when the underlying facts are identical, which is the clearest argument for building this reframing into the report structure from the start rather than waiting for a client to raise it.
What this changes about how a program gets tested
Subject line and send-time testing built around open rate is testing a number that no longer isolates the variable it is supposed to measure, since a chunk of the opens in any test cell are Apple's proxy firing automatically regardless of the subject line underneath them. Litmus's own guidance on the shift notes that clicks are becoming the more reliable input for both subject line optimization and send-time optimization precisely because a click still requires a real person to act on the message, something a prefetch request cannot fake. An agency still running A/B tests scored on open rate is optimizing toward noise in any list with a meaningful Apple Mail share, which in most consumer programs is close to half the list.
The practical fix is not complicated, it is a matter of changing which column a test gets scored against: build test cells large enough to reach a reliable click sample, not just an open sample, and let revenue per recipient settle any test where click volume alone is too thin to call confidently. That is a slower testing cadence than open-rate testing allowed, since click samples take longer to accumulate than open samples did, but it is testing something real instead of something fast.
Why this reframing protects the relationship, not just the report
A client who sees open rate climb while revenue stays flat and gets no explanation starts to distrust the whole report, reasonably. A client who understands upfront why open rate is unreliable and sees the report built around metrics that still hold up reads a flat revenue quarter as a real signal worth acting on, rather than a contradiction between two numbers that were never measuring the same thing. That distinction, more than any single tactic, is what keeps reporting credible once a platform-level change quietly breaks a metric everyone used to trust by default. Conduit's white label email marketing program reports against click, revenue, and list-health metrics as the default structure specifically because of this shift, not as an optional upgrade for clients who ask for it.
Services mentioned








