Open rates after Apple Mail Privacy Protection

01What MPP did to the open rate

Apple Mail Privacy Protection routes message content through Apple's proxies and pre-fetches every remote image, for every message, whether or not the recipient ever looks at it. An open pixel is a remote image. So the pixel fires on delivery, from an Apple address, for a person who may never open the mail at all.

This did not degrade the open rate — it changed what the number is. Before MPP, an open event was weak evidence that somebody rendered your message: undercounted by images-off clients, but the events you did get mostly corresponded to a human. After MPP, a large share of your open events correspond to a cache being warmed. The metric did not get noisier; it started measuring a different thing, and the share of your list that thing applies to is set by Apple's adoption among your recipients, not by anything you do.

MPP is the largest of these effects but not the only one. Corporate security appliances fetch every image and follow every link in a message before the recipient sees it — which produces opens and clicks, for mail nobody has read yet. Gmail proxies and caches images through its own infrastructure. The design response is the same for all of them: classify the hit at the edge, store everything, and default the headline charts to the one class that plausibly means a person.

02Classifying a hit instead of counting it

Every open and click is stored with an AudienceClass. Nothing is discarded — somebody investigating one specific delivery needs to see the scanner hit too — but only human is in COUNTS_AS_ENGAGEMENT, so only human reaches a headline rate.

Why proxy_prefetch is excluded rather than counted. It is tempting to treat a proxy fetch as an open, since something did request the image. But the fact it establishes — the message arrived — is the one the delivery event already gave you. Counting it would double-count delivery and file the duplicate under engagement, which is the specific way an engagement metric becomes a deliverability metric wearing a hat.

Why mpp is its own class and not just “bot”. Behind an MPP hit there is a real subscriber with a real mailbox, and the message did reach them. Everything about the delivery is fine; only the observation is destroyed. Filing that under bot would imply something bad about the address, and the adjusted rate in the next section depends on being able to count MPP recipients separately in order to remove them cleanly.

03The privacy-adjusted open rate

There are three arithmetics available for MPP opens and two of them are wrong in opposite directions. Count them as opens and the rate inflates. Count them as non-opens and it deflates, because those recipients are in the denominator being treated as people who did not open. The third option is to remove them from both sides and say so.

The function is four lines of arithmetic and one refusal:

privacyAdjustedOpenRate({ delivered, humanOpens, mppOpens })

  denominator = delivered - mppOpens

  // nothing observable is left to compute a rate from
  if (denominator <= 0) → { rate: null, excluded: mppOpens, note: "…" }

  rate     = humanOpens / denominator
  excluded = mppOpens
  note     = "N privacy-protected opens excluded from both sides"

The null matters as much as the division. When every delivery in the window went to a privacy-protected mailbox, the denominator is zero or negative and there is no honest number to show — so the function returns no rate and a sentence explaining why, rather than a zero that reads as catastrophic performance or a silently-clamped percentage that reads as fine. A rate of null is a different claim from a rate of 0, and the type says so.

The excluded count travels with the rate for the same reason. A 22% open rate with 400 excluded and a 22% open rate with 40,000 excluded are not comparable figures, and the second one deserves much less of your confidence. If you export this number into a report, export the exclusion count next to it.

04Which rules fire in production today

Here is the part a vendor would leave out. The classifier contains several rules that are better than user-agent matching, and in production today they never fire — because the tracking endpoint does not pass them the inputs they need. The heuristics are good; the wiring is incomplete. Telling you which is which is the point of this page.

apps/app/src/server/tracking.ts calls classifyHit with exactly four things: the user agent, the connecting IP, the HTTP method, and (on the open path) the country header. It never populates msSinceDelivery, recentLinkHits, cfAsn or cfVerifiedBot. Every rule that reads one of those fields therefore evaluates against an absent value and falls through.

const hit = classifyHit({
  userAgent: request.headers.get('user-agent') ?? '',
  ip:        request.headers.get('cf-connecting-ip') ?? '',
  method:    request.method,
  // …country, on the open path
})

// not passed: msSinceDelivery · recentLinkHits · cfAsn · cfVerifiedBot

What this means for your numbers, concretely. Classification today is user-agent matching plus a HEAD check. That catches the honest actors — Apple identifies itself, security vendors identify themselves, most crawlers identify themselves — and misses anything that presents a plausible browser string from an interesting network. So human is an over-count, by an amount nobody here can quantify for your traffic, and proxy_prefetch is almost certainly an under-count, because both routes into it depend on timing data that is not there.

05What to measure instead of opens

Opens were always the weakest signal in the stack. MPP made that impossible to ignore, which is a favour: the metrics that survive intact are the ones that were more informative anyway, because each of them requires a decision by a person.

The practical consequence is in your segments. A re-engagement or sunset rule built on opens will now retire people who read every message on an iPhone and keep people whose corporate scanner has been opening their mail for a year. Build those rules on clicks instead — and where you have it, on conversion. The segments query language has click_count and last_click_at as first-class columns, plus clicked_last_30d and never_clicked sugar, so the honest version of the rule is about as short as the dishonest one.

Common questions