Open and Click Tracking Mechanics

Every engagement metric an ESP reports — open rate, click rate, click-to-open, read rate — is a derived number built on two send-time modifications to the message: a tracking pixel and rewritten links. This article documents how platforms actually implement and count those events, how they define unique vs total, and precisely what each number can and cannot prove. The privacy features and scanners that distort these counts (Apple MPP, Microsoft Safe Links, gateway detonation, image proxies) are covered in depth in Tracking and Measurement Distortion; the thresholds these metrics feed into live in Metrics and Benchmarks. This article is the mechanics layer beneath both.

Open tracking: the pixel

An open is inferred, never observed. The ESP embeds a transparent 1×1 image ("tracking pixel", "beacon", "web bug") in the HTML body, on a tracking-domain URL that encodes the recipient's unique identifier. When the mail client renders the message and fetches remote images, the request hits the tracking server, which logs an open with the requesting IP, user-agent, and timestamp.

Because the event is an image fetch, the structural truths are the same on every platform:

• No image load → no open. Images-disabled clients, plain-text reading panes, and text-only clients produce false negatives. An "open rate" is a pixel-load rate.
• Any image load → an open, including sender previews, a campaign forwarded/posted to the web, or a template that reuses a tracking code.
• Text/plain parts cannot be tracked. A pixel is an HTML construct; a message rendered as text produces no open. Pardot labels a pixel-detected open specifically an "HTML open" for this reason — there is no text open.
• Total ≠ unique. Raw pixel hits are total opens (a recipient who reloads counts each time); ESPs dedupe to unique opens per recipient because they hold the subscriber↔ID mapping. Benchmarks and cross-platform comparisons should always use the unique rate.

The click→open fallback

Several platforms record an open when a click arrives without a prior open for that recipient, on the logic that a click proves the message was viewed even though the pixel never fired (images off).

• Eloqua makes this explicit: "If a clickthrough occurs without a recorded email open for that RecipientID, Oracle Eloqua automatically records an email open along with the clickthrough." Eloqua thus has two open-detection paths — pixel load, and click-implied.
• Customer.io folds it into the 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 click-heavy, images-off audiences (much of B2B) still show non-zero opens, and why in the MPP era a click is the only signal that recovers a genuine human open from an Apple-Mail recipient whose pixel fired automatically (see distortion).

Click tracking: link wrapping

Click tracking rewrites every href in the message at send time to point at the ESP's redirect ("tracking", "click", "links") domain, with the destination and recipient encoded. On click, the redirect server logs the hit and issues an HTTP redirect to the real URL. Only the sending platform can do this — it must rewrite links before the message leaves — which is why analytics-only tools cannot offer click tracking, and why link wrapping is inseparable from the ESP.

Consequences that make clicks a stronger signal than opens, but not a clean one:

• The tracking/redirect domain carries reputation. URL blocklists and content filters evaluate the link-domain in the body; a shared redirect domain spreads reputation (good or bad) across every sender on it. Branded per-customer tracking hostnames isolate this. Bird serves click and open tracking from your domain's branded tracking hostname — a CNAME under the sending domain (default links.yourdomain.com), over HTTPS — and rewrites the visible link through it.
• Clicks are inflated by scanners. Gateway "link detonation" (Safe Links, Proofpoint, Mimecast) fetches wrapped links seconds after delivery; each fetch registers as a click no human made. Detail and bot-vs-human heuristics: Tracking and Measurement Distortion.
• Unique vs total applies identically: total clicks count every hit; unique clicks count one per recipient (some platforms also expose unique-per-link).

Tracking must be armed before it runs

Tracking is not automatic just because a message has links. Bird gates it on three conditions, all of which must be true for a given send:

1. the per-send flag (track_opens / track_clicks, default true) is true — a per-send false always suppresses tracking, overriding domain settings;
2. domain-level tracking is enabled;
3. the tracking CNAME has verified — "Click and open tracking only run once that CNAME has verified; until then nothing is rewritten or pixelled."

Bird tracks the tracking CNAME's readiness separately from sending (capabilities.tracking vs capabilities.sending), so a domain can be able to send while silently recording no engagement. Operationally: a sudden zeroing of open/click data across a customer is often a broken or unverified tracking CNAME, not an audience change.

Bot / non-human filtering built into the count

Because pixels and wrapped links are fetched by scanners as well as humans, mature platforms filter machine activity before it reaches the headline metric — a distinct approach from simply reporting raw hits.

• Customer.io exposes both sides explicitly. Since 2025-03-20 a Human Opened metric excludes Apple MPP, Gmail prefetch, bots, and scanners; since 2025-04-20 a Human Clicked metric excludes security scanners, bots, proxies, and non-human patterns. Complementary Machine Opened / Machine Clicked capture the excluded automated events. It does not double-count: "if a single email was opened by both a machine and a human, that counts as one in the aggregate metric." All Apple-Mail opens are counted as non-human; a human open is only re-attributed if the recipient also clicks (so human opens are undercounted).
• Pardot / Account Engagement ships Metrics Guard in all accounts: threshold-based detection of open/click bursts from an IP. Thresholds are "conservative averages of peak email activity within a certain time frame across the Account Engagement ecosystem"; when an IP exceeds one, "activity tracking on that location is paused until the activity level falls back below the threshold." It filters most scanner activity without blocking legitimate visitors, but cannot catch every bot — activity below the thresholds still records.
• Eloqua stores auto-opens/clicks from email-scanning tools and Apple privacy auto-opens separately from actual contact engagement rather than in the engagement count.
• Bird flags proxy-fetched opens with is_prefetched: true and defines its open rate as "unique non-prefetched opens over delivered" — prefetch is filtered out of the headline rate, not just labeled.
• Braze offers reports that "either exclude or include machine opens (like Apple's MPP)."

The takeaway for an operator running an ESP: never compare an unfiltered open rate to a bot-filtered one, and know which one your platform's default dashboard shows. The gap between "opens" and "human opens" is frequently 30–70% on Apple-heavy lists.

What the platforms actually name and expose

Platform	Open counted when…	Click→open fallback	Bot handling	Notable metric definition
Pardot / Account Engagement	HTML pixel loads ("HTML open"); no text open	—	Metrics Guard: per-IP burst thresholds pause tracking	Also reports read rate (time-in-message tiers, see below)
Eloqua	Pixel loads, or a clickthrough with no prior open for that RecipientID	Yes, explicit	Scanner/Apple auto-opens stored separately from engagement	Pixel is <img …?elq=…> at message bottom by default
Bird	Non-prefetched pixel load	(open on any tracked event)	is_prefetched:true excluded from open rate	Open rate = unique non-prefetched opens ÷ delivered; rates computed on event time, not send time
Customer.io	Pixel load or link click	Yes, in definition	Human vs Machine Opened/Clicked (2025); no double-count	Metrics default to a delivered base (configurable); ignores events on messages > 6 months old
Braze	1×1 pixel load (proxy for open)	—	Reports can include/exclude machine opens	Positions unique open rate as an inbox-placement proxy (see below)

Note the base-rate trap: Customer.io and Bird compute engagement rates against delivered, and Bird attributes engagement to event time (a click today on last week's send lands in today's numbers). Two platforms can report different "open rates" for identical behavior purely from denominator and time-attribution choices. Always confirm numerator (unique? human-filtered?) and denominator (delivered? sent?) before comparing.

Read rate: a different measurement entirely

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

• Per oimetrics, read rates come from a panel of monitored inboxes, so they are estimated rates, not direct measurements — expect variance vs your own opens.
• They are unique rates, not total rates, and are computed by observing when a subscriber marks/holds a message as read rather than by firing a pixel, so they largely sidestep Apple MPP (MPP inflates pixel opens; it does not fabricate dwell time).
• The deliverability value: "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 a closer proxy for the engagement signal the mailbox provider itself computes than any pixel open.
• Comparison discipline: compare read rate only to the unique open rate, not total open rate; "higher is better."

Panel read rate is an estimate of list-level performance, not per-recipient truth. Its worth is as a sanity check on pixel opens and a proxy for the provider's own engagement math — a healthy read rate against a collapsing open rate points at pixel/MPP distortion, not a real engagement drop.

Opens as a deliverability signal — the honest reading

Braze states the modern 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 reframing is the useful one for running an ESP:

• A unique (machine-excluded) open rate over ~25% indicates widespread inbox placement; below ~20% suggests spam-folder placement; a steady downward trend often precedes deliverability problems. (Braze.) Bird's dashboard marks open rate "Healthy" above 35% and delivery rate healthy above 95%. Treat the specific numbers as vendor-calibrated, not universal. These are machine-excluded bands; a raw (machine-included) benchmark such as Klaviyo's ≥33% is not comparable — the canonical threshold table sorts the open-rate figures by machine-included vs machine-excluded basis.
• Mailbox providers judge engagement on data senders cannot see — "time-to-open, time-to-click, forwards, replies, deleted, etc." (Braze). Your open metric is a coarse shadow of the provider's real model; read rate is a slightly less coarse shadow.
• Therefore, for judging audience engagement and driving sunset/re-engagement, prioritize clicks and conversions over opens; for judging placement, an aggregate open-rate trend is still a legitimate early-warning signal (a drop means messages stopped reaching the box). This split — opens for placement direction, clicks/conversions for engagement decisions — is the operating rule.

What each metric does and doesn't tell you

Metric	Proves	Does not prove
Delivered	Receiving MX accepted the message	Inbox vs spam placement
Open (raw pixel)	An image was fetched (client, proxy, or scanner)	A human saw it; when/where; the device
Unique human open	A person's client rendered images at least once	Attention, or that non-openers didn't read (images-off)
Aggregate open trend	Directional inbox-placement change	Absolute placement, or per-recipient interest
Click (raw)	A wrapped link was fetched	It was human (scanners detonate links)
Unique human click	A person acted on the message	The destination was reached (warning pages can block)
Read rate (panel)	Estimated dwell-time distribution, MPP-resistant	Per-recipient truth; it is a sampled estimate
Conversion / on-site	A real session and goal completion	(strongest positive signal; hardest to fake)

Related

• Tracking and Measurement Distortion — how MPP, Safe Links, gateway detonation, and image proxies break these counts, with bot-vs-human heuristics and sunset-policy fixes
• Metrics and Benchmarks — the bounce/complaint/open thresholds these mechanics feed
• List Hygiene and Sunset Policies — engagement definitions that depend on which events you trust
• Content and Design for Deliverability — tracking-domain reputation and link handling
• Customer Domain Authentication — branded tracking/link CNAME setup for customers