Know who opened. Honestly.
One pixel per recipient — so a five-person thread tells you which of the five opened, not just that “someone” did. Every fetch passes six bot layers and earns a verdict, so Apple’s Mail Privacy pre-fetch and Gmail’s proxy can’t masquerade as a real read. We count only signals that actually fire.
pixel + click → 6 bot layers → verdict → recordedRecent verdicts
Reads
0 / 5
The loop
4 stepsSend is instrumented
A unique 1×1 pixel is embedded per recipient, links are wrapped, attachments optionally get their own pixel — all at send time.
Signal fires
A pixel load, a link click, an attachment open, or a honeypot hit lands at the pixel-worker with its raw headers.
Bot filter runs
Six layers: UA blocklist, Cloudflare bot score, header heuristics, IP class (Apple MPP / Gmail proxy / datacenter), timing, honeypot correlation.
Verdict recorded
Each event is tagged HUMAN / MPP_PROXY / GMAIL_PROXY / BOT and stored per-recipient — opened, reopened, clicked, attachment viewed, each with its own verdict. No derived number.
Spec
what you configurePer-recipient pixel (opens), wrapped links (clicks), attachment pixel (best-effort open), honeypot (bot trap). Pixel-only for opens — no CSS/font/DNS beacon theatrics.
Every recipient gets their own pixel token, so on a multi-recipient send you see opens by person — not a single anonymous "opened".
Body pixel is per-recipient. The in-file pixel is per-email (same file for everyone) — so we can confirm the attachment was opened, honestly not by whom.
UA blocklist, Cloudflare bot score, header heuristics, IP class, timing, honeypot correlation. Six independent checks per event.
HUMAN (counts). MPP_PROXY (Apple pre-fetch — excluded, never a read). GMAIL_PROXY (real open via Google's proxy, partial credit). BOT (0).
Opened, reopened, clicked, attachment viewed — each a direct fact with its own bot/human verdict, not a derived 0-100 score or tier. No phantom "API-confirmed" state — the Gmail API can't see a recipient's open, so we don't claim it.
A trap only a scanner fetches. It flags a gateway scan (Proofpoint, Mimecast) and discounts that burst — it does NOT zero the person, so a real open later still counts.
The dashboard never says "opened" for a proxy fetch without a qualifier — e.g. "Loaded by Apple — may not be a real read." Honest by default.
In practice
Real human read
Pixel, then a click from a different IP minutes later. HUMAN on both. Counts, per that recipient.
Apple MPP pre-fetch
Pixel from an Apple proxy seconds after send, nothing after. MPP_PROXY — excluded. We do not call it an open.
Enterprise gateway
Honeypot + pixel fire together at delivery (a security scan). That burst is discounted; the prospect's real open 3 hours later still counts as a genuine read.
Document deep-read
Attachment pixel opens at +20m, then a multi-page read with revisits. Recorded as a genuine attachment view.
Composes with
Try Track free
100 tracked emails + 100 actions per month. Free forever.
Get started