Your newsletter analysis counts a server fetching an image as an open, and nothing marks which ones had a reader. You still report it, because it moves and feels like a score. Which of your metrics survives if that column vanishes?
AdvisorStream's help centre, in a doc called About Newsletter Reports, tells financial advisers how their newsletter is doing. Under the heading "Financial industry benchmark averages" it publishes two figures: a 20.97% unique open rate and a 2.73 unique view rate. Both are undated. Neither carries a methodology. Nothing on that page warns that more than half of the opens it counts were recorded by a proxy rather than a reader.
That page is doing what your team does every month: take the number the dashboard hands you, compare it with something, write a sentence about it. The number at the centre stopped being a measurement in September 2021, when Apple changed how Mail loads images. The pixel that meant "someone opened this" now fires whether anyone opened it or not, and nearly every dashboard still reports it as though it meant something.
The Number That Broke in 2021
Apple describes the mechanism better than any vendor, because Apple wrote it. Its legal page for Mail Privacy Protection, dated 12 December 2025 in the footer, says:
"When you receive an email in the Mail app or Mail on iCloud.com rather than only downloading remote content when you open an email, Protect Mail Activity downloads remote content in the background by default — regardless of whether you engage with the email."
The same page adds that Mail routes that content "through two separate relays operated by different entities." Two relays mean the IP address is gone too, so opens cannot be de-duplicated by network either. An event survives. Evidence that a person was behind it does not. That is the whole problem in two sentences, written by the company that caused it.
Litmus puts a size on the exposure. Its State of Email Client Market Share report, July 2026 data current as of 1 August 2026 and calculated from more than a billion opens, states that MPP affects "roughly 55-60% of all email opens." The same page is blunt about where those land: opens detected in Apple Mail on iOS 15 or later "are classified as privacy-impacted opens", and those "are included in Apple Mail opens". They sit inside the number you report, blended with the ones that had a human on the other end. Apple Mail's share of that data set is 62.26%, which is why the exposure figure runs as high as it does.
I looked for a published, methodologically documented figure for how many points MPP adds to a particular list, and found none. Sources agree on the direction; none quantifies the inflation list by list. Treat 55-60% as exposure, not as a correction factor. You cannot clean the number, which leaves one option: stop leaning on it.
A Caveat Is Not a Recalculation
The comfortable version of this piece would say the guides ranking for this query ignore the problem. That is false, and the page disproving it is one click away. Letterhead's newsletter metrics guide, dated 19 March 2026 in the search listing, says it plainly:
"Due to privacy changes like Apple's Mail Privacy Protection, open rates can be inflated and are no longer a perfectly reliable measure of engagement."
Correct diagnosis. Now watch what the guide does with it. Open rate stays the first metric in the engagement section, and click-to-open is still defined as clicks divided by opens, which puts the compromised count in the denominator of the next metric down. The remedy offered is to watch trends over time rather than the exact figure. Five years of a consistently padded series tells you how Apple's proxy behaves, not how your audience behaves. The caveat is not the failure. Leaving the metric in column one is.
The rest of the field is further back. A SmartBrief guide from March 2024 lists open rates, click-through rates and conversion rates as the most common newsletter KPIs. RetailGear tells you to act on "which subject lines lead to higher open rates", and in the text I read MPP never comes up once.
Letterhead has heard of the problem. RetailGear and the SmartBrief guide have not. None of the three recomputed anything. A caveat paragraph costs nothing to add; changing which number sits in column one does, and that failure runs through most marketing measurement: the caveat gets added, the metric stays, and the figure that reaches the budget conversation still has a proxy in it.
The field also matters for what it does not contain. When I pulled this query in early November 2026, the top ten held a Reddit thread titled "How do you do newsletter competitive analysis?", a vendor analytics product page, a user-forum post and two editorial guides. That is a signal about the query, not a promise about rankings. Nobody I could read in that list answers the arithmetic question.
Three Layers That Survive the Pixel
Remove the pixel and what remains sorts into three layers by how hard each number is to fake. The ordering tells you which figure to trust when two of them disagree.
Reach is delivery, not attention
A bounce comes from the receiving server, and Apple's proxy never touches it. Delivery rate says the list is addressable; it says nothing about whether anyone saw the issue. Keep it, because when delivery drops, every other number that week is contaminated.
Engagement is a click, with the denominator named
No proxy preloads a click, which is why click data survived 2021 and open data did not. Clicks per recipient and clicks per open are different metrics, and plenty of dashboards call both "click rate". If the divisor is opens, the number inherits the distortion you were escaping. Ask next time a click rate lands in your inbox: divided by what?
Consequence is what happened next
Replies, forwards, conversions, the traffic that arrives after a send. Costliest to fake, thinnest in volume: a list of 4,000 might produce four replies on a good issue, and four is one quiet Tuesday from three.
The same three layers, by what each one can and cannot support:
Layer | What it proves | What it cannot prove |
|---|---|---|
Reach: delivered | the list is addressable | that anyone saw the issue |
Engagement: clicks per 1,000 delivered | something in the issue caused an action | that the email was read, or read in full |
Consequence: replies, forwards, conversions | the issue changed behaviour | much on a single issue, because volumes are small |
I could not find that separation published anywhere in the results for this query, which is odd, because the argument is mostly arithmetic.
Per-Issue vs. Per-Subscriber: Two Verdicts From One Send
A newsletter report answers "how did Tuesday go?" The question that decides budgets is "is the audience I have worth more or less than a quarter ago?" Conflating the two is how a healthy list gets cut, and it is the most common mistake in newsletter analysis.
The same newsletter, read both ways. The numbers illustrate the point rather than benchmark anything:
Issue | Delivered | Opens | Open rate | Clicks | Clicks per 1,000 delivered | Replies |
|---|---|---|---|---|---|---|
1 | 10,000 | 4,400 | 44% | 91 | 9.1 | 4 |
2 | 9,850 | 4,040 | 41% | 91 | 9.2 | 5 |
3 | 9,700 | 3,780 | 39% | 93 | 9.6 | 5 |
Per issue, this reads as decline: five points of open rate across three sends, which in a monthly report becomes "engagement down 11%". Meanwhile clicks per 1,000 delivered rose from 9.1 to 9.6. Nothing downstream of the pixel moved the way the open rate claims.
Read the same sends by subscriber and the picture inverts. The engaged core, subscribers who clicked at least once in the previous 60 days, went 1,240, then 1,180, then 1,150. Clicks per hundred engaged readers went 7.3, then 7.7, then 8.1. Both readings are true: the list is smaller, the core is smaller, and the people still reading click more. A per-issue report cannot see the second half of that sentence.
So report per issue for the send, per subscriber for the audience, and never compute a subscriber claim from an issue-level export.
Is the List Dying, or Finally Working?
A falling engaged base has two opposite explanations, and a standard dashboard renders them the same way. Subscribers flat or up. Opens down. Clicks per recipient down.
Either the newsletter is decaying, or it is shedding people who were never going to buy. One is a failure. The other is the healthiest thing that can happen to a list, because every rate you compute was diluted by people who had already left in every sense except the subscription record. The dashboard draws the same shape either way.
Two published pages will help you spot fatigue, and neither will help you tell it from pruning. Benchmark Email recommends segmenting by subscription date and comparing newer subscribers, the last 90 days, against older ones, 12 months and up: if older segments "are dramatically underperforming newer ones, fatigue is likely the primary driver". Tenon names a different tell, engagement falling while website visits, app usage and purchases hold steady. Both assume the numbers are trustworthy, which is the assumption MPP took away.
What decides the fork is downstream behaviour. Four checks, and they are my reasoning rather than a published method:
- Does downstream hold while the base shrinks? If clicks per remaining engaged reader are flat or rising, the audience is narrowing. If they fall alongside the base, it is decaying.
- Do the leavers look like buyers? If they never converted, never replied and never clicked twice, their exit is pruning. If they were your best segment, you have a problem.
- Is the loss concentrated at a tenure boundary? Check the Apple share inside each cohort before calling it a decay curve: a cohort comparison run on open rates is partly a comparison of which phone each group bought.
- Do replies and forwards move at all? These are immune to proxying. Flat replies beside a collapsing engaged count point to pruning, or to a tracking fault, not to a newsletter that stopped working.
Two of those four pointing to pruning is enough to stop treating the decline as an emergency. Three pointing to decay means the problem is in the content and the promise, and no dashboard change fixes it.
The Newsletter Analysis Scorecard: Four Numbers, One Deletion
Four numbers hold the picture, provided each carries a denominator you can defend.
Number | What it answers | Denominator |
|---|---|---|
Delivered, hard and soft bounces split | did the send reach the list | the list at send time |
Clicks per 1,000 delivered | did the issue earn an action | delivered |
Replies plus forwards, eight-issue rolling average | did the issue change behaviour | none; report the count |
Engaged subscribers, clicked in the last 60 days | is the audience worth what it was | share of delivered, plus the count |
That leaves the line to delete. Not open rate in general. One specific line: the single-issue open rate, as a performance number in a recurring report. Keep a 90-day open trend somewhere, because a sudden collapse in opens is still the earliest signal of a deliverability fault: broken authentication, a blocklist, a bad send. That is an alarm, not a performance metric, and alarms do not belong in a weekly table where someone will compare them to last week and draw a conclusion.
Specificity matters. "Stop reporting vanity metrics" is advice you can nod at and ignore, and it is already the standard line in this field. "Remove the per-issue open rate column from the Tuesday report and put the 90-day trend in the deliverability runbook" is a change someone can make on Monday morning.
Then run a denominator audit: write the divisor beside every figure left on the page. A rate without one is a number someone will misread in a meeting, and the misreading is the version that gets repeated. Our guide to marketing KPIs covers the wider reporting layer this sits inside.
What to Log Per Issue
None of this can be reconstructed afterwards. A newsletter analysis run next quarter is only as good as what you wrote down this week. The dashboard will show you last month. It will not tell you which links got clicked in issue 41, or what share of that send went to Apple Mail. Those details are captured at send time or they are gone for good.
Field | Why it must be logged at send time |
|---|---|
Send timestamp and list size at send | every rate needs a denominator, and the list moves between sends |
Delivered, hard and soft bounces split | separates a reach problem from an engagement problem |
Unique clicks, total clicks, top five links | total clicks hide a dead issue with one live link |
Clickers by source and signup month | makes the per-subscriber view possible six months later |
Replies and forwards, raw counts | the only consequence data most senders have, and the least reconstructable |
Unsubscribes and complaints, by tenure | the fastest way to tell pruning from decay after the fact |
Share of recipients on Apple Mail | otherwise a change in client mix reads as a change in interest |
One row per issue, in a sheet you own, because interfaces change and exports get redefined.
Reporting tools solve the easy half: they show you the send. What you need next quarter is the join, the newsletter click beside the landing-page session and the signup that came out of it. That is why we build reporting at Allable that pulls connected sources into one file rather than one dashboard per channel. The export still comes from your email platform; it should land beside the web data. Most of what gets filed under marketing measurement is that decision, made in advance, about what sits next to what.
What I Would Say in the Meeting
I have presented numbers I did not fully trust and watched a room accept them because they moved in the right direction. Much of newsletter reporting is theatre with a spreadsheet, and the audience is usually whoever signs off on the budget.
What fixes it is a shorter report with denominators printed on it, plus one sentence about what the numbers cannot see. Pick the number you would defend in front of someone who asks how it was measured; if you cannot answer in one sentence, that is the column to delete.
A newsletter analysis is supposed to be a claim about reality. The pixel stopped making that claim for you five years ago.
Frequently Asked Questions
Does Apple's Mail Privacy Protection inflate my open rate?
Yes, and the mechanism is Apple's own wording: Mail downloads remote content in the background regardless of whether you open the email, so the pixel fires without a reader. Litmus's July 2026 data puts MPP at roughly 55-60% of all email opens and counts privacy-impacted opens inside Apple Mail opens. You cannot subtract them from your reported figure.
Should I stop reporting open rate entirely?
No. Remove the single-issue open rate from performance reporting and keep a 90-day open trend as a deliverability alarm. A sudden collapse in opens catches authentication faults, blocklist entries and broken sends faster than anything else.
What is a good open rate for a newsletter in 2026?
I looked for a dated, methodologically documented benchmark and did not find one. The figures circulating for this query are mostly undated vendor numbers with no stated methodology; the most visible, a 20.97% unique open rate, sits on a page with no privacy caveat. Judge your own trend against your own history.
How do I tell a shrinking list from a decaying one?
Check four things: whether clicks per remaining engaged reader hold while the engaged base falls, whether the people who stopped engaging ever converted, whether the loss sits in a tenure band whose client mix changed, and whether replies and forwards moved at all. Two signals pointing to pruning means the list is narrowing, not dying.
