Why we count opens differently

We could have shipped the easy version of analytics. Every cold-email platform before us did: drop a tracking pixel in the email, count every fetch as an open, put a percentage on a dashboard, move on. It’s one query. It’s what customers expect to see. And it’s been quietly wrong for years.

This is the build-note version of why we didn’t ship that, what “counting opens differently” actually means at the engineering level, and what we gave up to do it honestly.

The pixel was never measuring what everyone assumed

An open tracking pixel is a one-by-one transparent image with a unique URL, embedded in the email body. When a mail client renders the email and requests that image, the server logs a hit and calls it an open. This worked reasonably well for a long time, because for most of email history, rendering the image required a human to open the message first.

That assumption broke, quietly, over the last several years — not through some dramatic single event, but through three separate, unrelated changes that each had the same side effect: making the pixel fire without a human present.

None of these systems are doing anything wrong. Apple built Mail Privacy Protection specifically to stop senders from inferring behavior from opens — that’s a deliberate privacy feature, not a bug we’re working around. Gmail’s proxy exists for legitimate performance and security reasons. Security gateways scanning links before delivery is exactly what they’re supposed to do. We’re not fighting adversarial actors here. We’re trying to measure something real in an environment where the measurement itself has been quietly obsoleted by systems built for entirely different, good reasons.

Why we couldn’t just ignore it

The tempting response is: does it matter? If everyone’s open rate is inflated by roughly the same amount, the numbers are still comparable to each other, right?

No — and this is the part that made us actually build the filtering layer instead of shrugging it off. The inflation isn’t uniform. It depends on your audience’s mail client mix, which providers they’re on, and whether their employer runs a security gateway. A list skewed toward iPhone users gets a different inflation rate than a list skewed toward corporate Outlook users behind Proofpoint. That means:

• A/B tests stop measuring what you think they’re measuring. If variant A happens to reach more Apple Mail users than variant B, it can “win” on opens purely from prefetch rate, with zero difference in how humans responded to the actual copy.
• List health becomes unreadable. A dead segment that nobody’s engaging with can still show a healthy open rate if enough of its addresses sit behind a security gateway that opens everything automatically. You’d keep sending to a graveyard because the dashboard says it’s alive — and continuing to send to genuinely dead addresses is exactly what damages sender reputation.
• The one number that can’t be faked gets buried. Replies are the metric no automated system produces, because replying requires reading, understanding, and choosing to respond. Every dashboard that leads with open rate instead of reply rate is optimizing attention for the wrong number.

We didn’t build this because open rate inflation is offensive in the abstract. We built it because we watched what happens when a team makes a real decision — which subject line wins, which segment to prune, whether a campaign is working — on a number that’s silently 40 to 60% machine noise.

There’s also a quieter, longer-term cost that’s easy to miss in the moment: trust in your own dashboard erodes gradually. The first time a sales team crows about a great open rate and then can’t explain why nobody’s replying, they stop believing the open number. The second time it happens, they stop believing the whole dashboard, including the parts that were accurate. Once a team decides its analytics are fiction, they stop using analytics to make decisions at all, and you’re back to gut feel — which is a worse outcome than just building the filter in the first place.

What we actually built instead

The engineering answer isn’t “delete the pixel.” Tracking pixels and click events are still the raw material — we just refuse to treat every fetch as equivalent. Each open and click event gets evaluated against the signals available at the moment it happens: how quickly it fired relative to delivery, what the request pattern looks like, whether it matches known proxy or scanner behavior, whether a burst of clicks landed on every link in the email within the same second (a real reader clicks one link; a security scanner clicks all of them).

Events that look automated don’t get deleted — that would just be lying in the other direction, and it would make the filtering unverifiable. They stay visible in the activity trail, labeled as filtered, so the smaller “human” number has receipts sitting right next to it. If a client or a teammate asks why the open rate looks lower than the number their last tool reported, the answer isn’t “trust us” — it’s “here’s exactly what got filtered out and why.”

That design choice — keep the noise visible instead of hiding it — is the part we’re most stubborn about. A filtering system nobody can audit is just a different kind of dashboard fiction. Ours has to be checkable, or it’s not actually more honest than the pixel-counting it replaced.

The trade we’re making, out loud

Here’s the uncomfortable part we don’t get to avoid saying: this makes our numbers look worse in a side-by-side demo. A prospect comparing our dashboard to a competitor’s will usually see a lower open rate from us on the same list, because we’re reporting fewer, more accurate opens instead of every pixel fire. In a sales conversation, that’s a real disadvantage in the first thirty seconds.

We’ve decided that’s the right trade anyway, for one reason: the number that matters isn’t the one that looks best in a demo, it’s the one you can build a decision on without it quietly lying to you later. A 41% human open rate that predicts replies is more useful than a 65% raw rate that predicts nothing. We’d rather lose the comparison on vanity metrics and win it on whether the platform actually helps you run a campaign that works.

If you want to see the actual mechanics — the waterfall from raw tracked events down to the human number, event by event — that’s what Norbelys analytics is built to show, not just claim. And if you want the fuller research behind the “half your opens are robots” framing that started this whole engineering decision, we wrote that up separately.

We didn’t build a smaller number to be humble. We built it because it’s the one that’s actually true.