A tracking pixel cannot tell you someone read your email

An email open is not a measurement. A tracking pixel records that a piece of software fetched an image, and on Gmail the first fetch usually arrives within a minute of sending, before anyone has looked. Any tracker reporting a single "opened" flag is reporting that fetch as a person.

A tracking pixel is a one-by-one image embedded in an email. When the recipient's mail client renders the message, it requests that image from a server, and the server logs the request. That is the entire mechanism. Every claim built on top of it, "opened", "read", "seen", is an inference about a human being layered onto the fact that some piece of software made an HTTP request. The inference is often right. It is never guaranteed, and two specific things about how modern mail actually moves make it wrong often enough that reporting it as a plain yes or no is a rounding error dressed up as a fact.

Gmail fetches the image itself, not your recipient's computer

Since 2013, Gmail has proxied every image in an incoming message through its own infrastructure at googleusercontent.com, rather than letting the recipient's browser or mail client fetch it directly from your server. Google says this is for privacy and malware scanning, and it is probably both. The side effect for tracking is that your server never sees the recipient's IP address or their mail client's user agent, and that Google fetches the image once per reader and then serves its own cached copy: the same person opening the message again, or on a second device, produces no request at all. You are not measuring the recipient's computer. You are measuring Google's proxy, once removed.

The fetch often happens before anyone has looked at anything

The proxy does not wait for the recipient to open the message. Gmail, and several other mail clients, prefetch images at delivery time, as part of rendering the message into the inbox list or preparing it for offline reading. In practice this means the first image request your tracking pixel generates frequently arrives within a minute of sending, often while the message is still unread. If your dashboard reports that as an open, it reported a fact, the image was fetched, wrapped in a lie, a person read this. The same prefetch is why a brand-new tracking domain needs a warm-up before it carries anything at volume.

So what does a fetch actually prove?

It proves that a request happened, at a known time, through a known channel, and the channel says a great deal. Gmail's delivery-time fetch arrives with one fixed, recognisable signature. Google's proxy, fetching for a reader, arrives with another. Apple's Mail Privacy Protection relay arrives from Apple's published address ranges. Onmindo reads those facts and records three different things, none of them a guess:

You will not find "read for 42 seconds" anywhere in Onmindo, and you will not find a device or a city next to a Gmail reader's open, because Google's proxy fetched that pixel from a Google datacentre. Tools that print "Mountain View, California" there are printing Google's address.

Why most trackers still show you a single checkmark

Not because the vendors do not know the proxy exists; every mail tracking product deals with the same Gmail infrastructure. A single green checkmark is a simpler thing to put in a product screenshot than a "delivered" state and a note next to an open, and admitting that a fetch was Gmail's and not a person's reads, to a buyer skimming a pricing page, as a weaker product rather than a more honest one. The cost of that simplicity lands on the sender: a checkmark is wrong exactly as often as the assumption behind it is wrong, and for a message delivered to Gmail, where prefetching on arrival is common rather than rare, that is not a rounding error.

The two windows Onmindo throws away entirely

Some fetches are so predictable that keeping them would only add noise, so Onmindo discards exactly two, and no others. A direct fetch, not through a proxy, within ten seconds of sending is your own mail client rendering the message you just sent, the same way it renders any message in your sent folder. That is not a reader opening anything; it is your own software drawing a copy of what you wrote. And a repeat direct fetch within two minutes of the first is, almost always, the same client redrawing, not a second reading. A proxied fetch is never discarded: Google fetches once per reader, so a second fetch through Google's proxy is a second person, and dropping it would lose them. Everything else is kept, because a fetch that is merely early is still the only evidence that exists. Discarding it would not make the tracking more honest. It would just make it blind.

What this means for the numbers you actually read

In practice, a message to a Gmail address shows delivered within a minute of sending, because Gmail prefetched it, and shows an open when the person looks, with "Gmail" next to it. Your own re-read of the sent copy is not counted. A message to three people carries one pixel, so an open on it can only ever say "one of the three"; send a copy to each and every open has a name. None of that needs a probability. It needs the fetch read for what it is. A tool that reports one checkmark on every message has the same evidence Onmindo has; it has chosen not to tell you which fetches were Gmail's. See the labels on the Onmindo product page.