Theme

Tracking

Mimeo measures its own opens and clicks rather than trusting the provider's numbers. That's what makes engagement data consistent no matter who delivers your mail — and yours to keep if you switch.

How it works

At send time, Mimeo rewrites the compiled message in two ways.

Endpoint What it is
GET /o/:token The open pixel. Mimeo injects a 1×1 GIF into the message; the mail client requesting that image is what registers an open.
GET /l/:token The link redirect. Links in your email are wrapped so clicks pass through your instance, which records the click and then issues a 302 to the real destination.

Both tokens are generated per send, so a hit identifies the person, the email, and the specific send it came from. You never construct or call these URLs yourself — Mimeo creates them, and the reader's mail client is what requests them.

Because the redirect happens on your own domain, a wrapped link is one extra hop before the destination. Recipients land where you sent them.

Bot filtering

A large share of email "engagement" isn't human. Security scanners, spam filters, and link-preview services fetch every image and follow every link in a message before anyone reads it. Left unfiltered, that inflates open rates and makes click data useless.

Mimeo applies two filters.

Known scanners

Hits from user-agents that identify as known scanning infrastructure are flagged on arrival.

Click-burst detection

Scanners that don't announce themselves still behave unmistakably: they open everything at once. If 3 or more distinct URLs from a single sent email are clicked within 10 seconds, the whole burst is flagged. No human reads an email and clicks four different links in eight seconds.

What flagging does

Flagged hits are kept, not deleted. Specifically:

Keeping them matters when you're debugging. "Did that link work?" is answerable when a scanner's successful fetch is still on the record — it's just not counted as a customer clicking.

Because scanner traffic is filtered out, your Mimeo open rate will usually read lower than the same sends measured elsewhere. That's the numbers getting more honest, not engagement dropping.

Acceptance is not delivery

The send log records that your provider accepted the message. That is not proof it reached an inbox. A provider can accept a send and then drop it — most commonly because the address is on the provider's own suppression list — without reporting an error.

The truth about bounces and suppressions reconciles separately, through provider suppression sync. With Bento, which has no webhooks, that sync runs lazily when you open a recently-emailed person and nightly for everyone else.

So when you read a person's record, read the three signals as distinct facts: the send log says the provider took it, suppression state says whether the address is deliverable, and tracking says whether a human engaged. A send that was accepted, is now suppressed, and never registered an open tells a coherent story — the message was dropped.

What tracking is authoritative for

Mimeo's own tracking is the source of truth for engagement inside your instance. Your provider may report its own open and click numbers from its own instrumentation — Bento does — and those numbers won't match. Mimeo's are the ones its features act on, and the ones that stay with you when the provider changes.