How honest is email open tracking, really? 730 real opens, broken down

The number, and exactly how it was checked

730 pixel fetches — the count as of 13 August 2026 — recorded over 6.5 weeks of live production use (2026-06-27 to 2026-08-13), across 96 emails that produced a fetch, out of 109 tracked in the period; 13 were never opened at all. 162 of the 730 — 22% — were never a human reading the email, and Vidi never counted them as a read.

The breakdown, straight off Vidi's own classifier:

Zero Apple Mail Privacy Protection pre-fetches appear in this window. Vidi still detects and excludes them (Apple's relay IPs all start 17., checked before anything else) — none simply occurred in this sample. That is a fact about this dataset, not a claim that MPP never happens; a tool that counted MPP pre-fetches as reads would show 0% impact from them too, for the wrong reason. See Apple Mail Privacy Protection and open tracking for how that check works.

Why the biggest bucket (“ambiguous,” 69%) is more solid than the label sounds

This is the part worth being careful about, because it is where a dishonest version of this study would quietly round up.

Vidi's classifier first sorts every pixel fetch into one of four raw types. Two are mechanically certain either way: a fetch through a different mail provider's proxy than the sender used (Gmail sender, Outlook recipient, say) cannot be the sender's own client — that is the 64 counted directly as the recipient. A fetch matching a known security-scanner signature or arriving from a datacenter IP with no recognised provider proxy is excluded as a scanner regardless of anything else.

Everything left over — same-provider proxy, a direct browser load, or an unrecognised client — gets flagged “ambiguous,” because it could be the sender opening their own just-sent copy from Sent Mail. Here is the part that does not show up in a summary that only names the four buckets: before a fetch is ever labelled “ambiguous” in this table, it has already survived two separate self-open checks, run regardless of the raw classification:

• Sender-IP match. Vidi records the sending device's IP at send time. Any later fetch from that exact IP is rejected outright — 57 of the 730, never counted.
• A 15-second window. A same-provider or unrecognised-client fetch inside 15 seconds of sending is almost certainly the sender's own client rendering the message it just sent, not a recipient reading it a moment later — 37 of the 730, never counted.

The 504 rows this table calls “ambiguous” are what remains after both of those filters, not before. So the honest characterisation of that bucket is not “the sender might have opened these” — it is “these are not the sender's recorded IP, and they did not happen in the fifteen seconds after sending.” The residual uncertainty is real and worth naming plainly: someone can check their own sent mail later than 15 seconds from a second device or a different network than the one they sent from, and that fetch would still land in this bucket. Vidi does not claim to catch that case, and no pixel-based method can, without asking the recipient to confirm identity — which defeats the point of a read receipt. What the data supports is narrower and still true: 69% of all recorded opens are fetches that cleared two independent self-open filters and are not attributable to a scanner or a privacy relay — not “69% might be the sender.”

Why this is worth publishing at all

We have not found another email-open tracker in this category — for Gmail, Yahoo Mail, or Outlook.com — that publishes this breakdown. The implicit claim in every “X% open rate” dashboard is that every pixel fetch is a human read. This dataset says that is off by roughly a fifth, on a fully instrumented, production sample, not a lab test: 22% of what a naive tracker would call an “open” is a security scanner, the sender's own device, or noise — and Vidi does not count any of it.

How Vidi approaches this

Vidi is built for individuals sending important client-facing emails, not for mass marketing. It tells you privately when your message is read, adds nothing visible to the email, and turns the tick green only on a genuine human open. See it running on a real inbox in the interactive demo, or read how the pixel mechanism itself works in how email open tracking actually works.

Bottom line

Open-rate numbers that don't separate a human read from a scanner or a self-check are overstating by roughly a fifth, at least in this dataset. Vidi filters that out before it ever reaches your dashboard, so a green tick means what it says — get started with Vidi.