Open and Click Tracking Mechanics

Before you trust an open rate or a click rate, it helps to know how the number was produced. Every engagement metric an email service provider (ESP) reports, whether open rate, click rate, click-to-open rate or read rate, is derived from two changes made to the message when it is sent: a tracking pixel and rewritten links.

Below is how platforms implement and count these events, how they define unique and total counts, and exactly what each number can and cannot prove. The privacy features and scanners that distort these counts (Apple Mail Privacy Protection (MPP), Microsoft Safe Links, link detonation by security gateways, image proxies) are covered in depth in Tracking and Measurement Distortion. The thresholds these metrics feed are in Metrics and Benchmarks.

Open tracking: the pixel

An open is inferred, never observed. The ESP places a transparent 1×1 image (a "tracking pixel", "beacon" or "web bug") in the HTML body. Its URL, on a tracking domain, encodes the recipient's unique identifier. When the mail client displays the message and loads remote images, the request reaches the tracking server, which records an open with the requesting IP address, user agent and time.

Because the event is an image request, some facts hold on every platform:

• No image load means no open. Clients with images turned off, plain-text reading panes and text-only clients produce false negatives. An "open rate" is really a pixel-load rate.
• Any image load counts as an open, including the sender's own previews, a campaign forwarded or posted on the web, and a template that reuses a tracking code.
• Plain-text parts cannot be tracked. A pixel only exists in HTML, so a message displayed as text produces no open. For this reason Pardot calls an open detected by the pixel an "HTML open": there is no such thing as a text open.
• Total and unique counts differ. Raw pixel requests are total opens, so a recipient who reloads the message counts each time. ESPs remove duplicates to get unique opens for each recipient, because they know which identifier belongs to which subscriber. Benchmarks and comparisons between platforms should always use the unique rate.

The click-to-open fallback

Several platforms record an open when a click arrives from a recipient with no earlier open. The reasoning is that a click proves the message was viewed, even if the pixel never loaded because images were off.

• Eloqua states this explicitly: "If a clickthrough occurs without a recorded email open for that RecipientID, Oracle Eloqua automatically records an email open along with the clickthrough." Eloqua therefore detects opens in two ways: when the pixel loads, and when a click implies an open.
• Customer.io builds it into its definition: an open is counted "when the recipient's email client loads an invisible image (tracking pixel) or when the recipient clicks one of the links in the email."

This fallback is why audiences that click a lot but keep images off (much of B2B) still show opens. It is also why, since MPP, a click is the only signal that shows a genuine human open by an Apple Mail recipient whose pixel loaded automatically (see distortion).

Click tracking: link wrapping

Click tracking rewrites every href in the message at send time so that it points to the ESP's redirect domain (often called the "tracking", "click" or "links" domain), with the destination and the recipient encoded. When someone clicks, the redirect server records the request and sends an HTTP redirect to the real URL. Only the sending platform can do this, because the links must be rewritten before the message leaves. That is why analytics-only tools cannot offer click tracking, and why link wrapping belongs to the ESP.

Clicks are a stronger signal than opens for these reasons, but not a clean one:

• The redirect domain carries a reputation. URL blocklists and content filters evaluate the link domains in the body, so a shared redirect domain spreads reputation, good or bad, across every sender that uses it. Tracking hostnames branded for each customer keep reputations separate. Bird serves click and open tracking from a branded tracking hostname on your own domain: a CNAME under the sending domain (by default links.yourdomain.com), over HTTPS, through which it rewrites the visible links.
• Scanners inflate clicks. Security gateways (Safe Links, Proofpoint, Mimecast) "detonate" wrapped links by requesting them seconds after delivery, and each request registers as a click no person made. For details and ways to tell bots from people, see Tracking and Measurement Distortion.
• Unique and total counts work in the same way as for opens. Total clicks count every request; unique clicks count one for each recipient (some platforms also show unique clicks for each link).

Tracking must be switched on before it runs

A message does not get tracking automatically just because it has links. Bird tracks a send only when all three of these conditions are true:

1. the flag on the send (track_opens or track_clicks, true by default) is true. A false on a send always turns tracking off, whatever the domain settings;
2. tracking is enabled for the domain;
3. the tracking CNAME has been verified: "Click and open tracking only run once that CNAME has verified; until then nothing is rewritten or pixelled."

Bird reports whether the tracking CNAME is ready separately from whether the domain can send (capabilities.tracking and capabilities.sending). A domain can therefore send mail while recording no engagement, without any warning. In practice, when a customer's open and click data suddenly drops to zero, the cause is often a broken or unverified tracking CNAME, not a change in the audience.

Bot and non-human filtering built into the count

Scanners request pixels and wrapped links as well as people do, so mature platforms filter out machine activity before it reaches the main metric, instead of simply reporting raw requests.

• Customer.io shows both sides explicitly. Since 2025-03-20, a Human Opened metric excludes Apple MPP, Gmail prefetching, bots and scanners. Since 2025-04-20, a Human Clicked metric excludes security scanners, bots, proxies and other non-human patterns. The matching Machine Opened and Machine Clicked metrics capture the automated events that were excluded. Nothing is counted twice: "if a single email was opened by both a machine and a human, that counts as one in the aggregate metric." All opens in Apple Mail are counted as non-human, and an open is counted as human again only if the recipient also clicks, so human opens are undercounted.
• Pardot (Account Engagement) includes Metrics Guard in all accounts. It detects bursts of opens or clicks from one IP address, using thresholds. The thresholds are "conservative averages of peak email activity within a certain time frame across the Account Engagement ecosystem", and when an IP address goes over one, "activity tracking on that location is paused until the activity level falls back below the threshold." It filters out most scanner activity without blocking legitimate visitors, but it cannot catch every bot: activity below the thresholds is still recorded.
• Eloqua stores automatic opens and clicks from email scanning tools, and automatic opens from Apple's privacy features, separately from real contact engagement, instead of counting them as engagement.
• Bird marks opens requested by a proxy with is_prefetched: true, and defines its open rate as "unique non-prefetched opens over delivered". Prefetched opens are removed from the main rate, not just labeled.
• Braze offers reports that "either exclude or include machine opens (like Apple's MPP)."

If you run an ESP, never compare an unfiltered open rate with one filtered for bots, and know which of the two your platform's default dashboard shows. On lists with many Apple users, the gap between "opens" and "human opens" is often 30–70%.

What the platforms actually name and expose

Watch the base of each rate. Customer.io and Bird calculate engagement rates against delivered messages, and Bird attributes engagement to the time of the event, so a click today on last week's send appears in today's numbers. Two platforms can report different "open rates" for identical behavior only because they choose different denominators and time attribution. Before comparing, always confirm the numerator (unique? filtered for humans?) and the denominator (delivered? sent?).

Read rate: a different measurement entirely

"Read rate" is not a pixel metric. It measures how long a message stayed open in the foreground, or in focus, before the reader moved on, sorted into tiers. Pardot reports deleted (< ~2 s), skimmed (~2–8 s) and read (> ~8 s). The data comes from a different source than opens:

• According to oimetrics, read rates come from a panel of monitored inboxes. They are estimated rates, not direct measurements, so expect them to differ from your own opens.
• They are unique rates, not total rates. They are calculated by observing when a subscriber marks or keeps a message as read, not by loading a pixel, so they mostly avoid the effect of Apple MPP. MPP inflates pixel opens, but it does not invent time spent reading.
• Their value for deliverability: "read rates use the same methodology as ISPs, like Gmail and Outlook," so they "more accurately estimate what ISPs are calculating" for engagement scoring. Read rate is therefore closer than any pixel open to the engagement signal the mailbox provider calculates itself.
• Compare read rate only with the unique open rate, not the total open rate; "higher is better."

A panel read rate estimates how a list performs as a whole; it says nothing reliable about any single recipient. Its value is as a check on pixel opens and as a proxy for the provider's own engagement calculations. A healthy read rate alongside a collapsing open rate points to distortion of the pixel by MPP, not to a real fall in engagement.

Opens as a deliverability signal: the honest reading

Braze states the current position plainly: a pixel load is "more likely to indicate inbox placement as opposed to a human being actually selecting your message and choosing to read it." That is the useful way to see opens when you run an ESP:

• A unique open rate that excludes machine opens and is over ~25% indicates widespread inbox placement. Below ~20% suggests placement in the spam folder, and a steady downward trend often comes before deliverability problems (Braze). Bird's dashboard marks an open rate above 35% as "Healthy", and a delivery rate above 95% as healthy. Treat these specific numbers as calibrated by each vendor, not as universal. They are ranges that exclude machine opens. A benchmark on raw opens that include machine opens, such as Klaviyo's ≥33%, cannot be compared with them. The canonical threshold table sorts the open rate figures by whether they include or exclude machine opens.
• Mailbox providers judge engagement on data that senders cannot see: "time-to-open, time-to-click, forwards, replies, deleted, etc." (Braze). Your open metric is a rough shadow of the provider's real model, and read rate is a slightly less rough one.
• So, to judge how engaged an audience is, and to decide on sunset and re-engagement, rely on clicks and conversions rather than opens. To judge placement, the trend of the aggregate open rate is still a legitimate early warning: a drop means messages stopped reaching the inbox. The rule in practice is to use opens for the direction of placement, and clicks and conversions for decisions about engagement.

What each metric does and doesn't tell you

Related articles

• Tracking and Measurement Distortion, on how MPP, Safe Links, link detonation and image proxies break these counts
• Metrics and Benchmarks
• List Hygiene and Sunset Policies, on engagement definitions that depend on which events you trust
• Content and Design for Deliverability, including tracking domain reputation and link handling
• Customer Domain Authentication, including branded tracking CNAME setup for customers