Protocol: reconciling campaign reports across sends, opens, clicks and bounces

What we would reconcile

We would reconcile four relationships. Sends should equal recipients minus pre-send failures. Delivered should equal sends minus bounces, with hard and soft bounces separated. Opens should reconcile as unique versus total, and clicks likewise, so an inflated total is not read as reach. And every rate, open rate, click rate, bounce rate, should recompute from the raw counts to the same figure the dashboard shows. The point is not to trust a headline percentage until the underlying events sum to it. Any gap between the dashboard number and the log-derived number is the finding, whether it is rounding, a definition difference, or a genuine discrepancy.

The method we would hold constant

The method would be constant across platforms. Send one identical campaign to the same seeded audience wherever possible, then export the raw event log, one row per contact per event, and rebuild every headline metric from those rows. We would compare our rebuilt totals to the dashboard, and compare platforms to each other only after normalising definitions. Seeded contacts let us verify individual events: this address opened once, that one bounced hard, this link was clicked twice. Reconciliation runs from the event log upward, never from one summary screen to another, because two dashboards can agree with each other and both misstate what actually happened.

Why the numbers legitimately differ, starting with opens

Identical campaigns report differently for real reasons, and a reconciliation has to separate those from errors. Unique against total is the first: some views count a person once, others count every open, and a report that mixes the two silently will never close. Bounce classification is the second: what one platform files as hard, another files as soft, so the delivered figure moves with the definition rather than with the send.

The largest one is not a difference between platforms at all. Apple's Mail Privacy Protection loads the tracking pixel when the message arrives rather than when it is read, so an open is recorded for a message nobody looked at. Every platform we checked says so in its own documentation, and each handles it slightly differently.

What each platform publishes about counting opens

Platform	Status	What does the platform document about open tracking once Apple Mail Privacy Protection is in the picture?
Kit	Documented	States it cannot tell a real open from an Apple preload, so an email may be recorded as opened when it was not. For its ads product it excludes automatically opened impressions, which is why impression and open totals disagree in the same account. Source
Mailchimp	Documented	States that Apple Mail preloads the pixel whether or not the contact opened the message, so reported opens are inflated and geolocation and email client data become unreliable for those contacts. Points readers to clicks, bounces, unsubscribes and conversions instead, and ships bot filtering on by default. Source
MailerLite	Documented	States that most mail delivered to Apple Mail is marked opened, so dashboard open rates run higher than reality, while deliverability is unaffected. Recommends turning open tracking off or excluding Apple Mail users from anything that depends on opens, naming A/B tests and auto resend campaigns. Source
ActiveCampaign	Not checked	Not checked in this pass.
Brevo	Not checked	Not checked in this pass.
GetResponse	Not checked	Not checked in this pass.
Moosend	Not checked	Not checked in this pass.
Omnisend	Not checked	Not checked in this pass.
Sender	Not checked	Not checked in this pass.

Apple states that Mail Privacy Protection downloads remote content privately in the background when a message arrives rather than when it is viewed, so a sender cannot tell whether the message was opened, and the recipient IP address is hidden as well. Source.

Read from each provider's own documentation. "Not checked" means we have not read a page covering this for that platform. None of it is a measurement of our own.

Two consequences for a reconciliation. An open rate is not comparable across two platforms unless both count the same way, and on any list with a large share of Apple Mail readers it is not comparable to its own past either. And anything built on opens inherits the problem: MailerLite's own guidance is to exclude Apple Mail users from A/B tests and from auto resend campaigns, which is exactly the feature examined in the resend protocol.

What would count as proof

Proof is a reconciliation that closes. A pass means every headline number rebuilds from the raw log to the same value, unique and total are labelled and both explained, bounces split cleanly into hard and soft, and any platform-to-platform gap is fully accounted for by a documented definition difference. A partial pass is numbers that reconcile internally but cannot be compared across platforms because definitions were not normalised. A fail is a dashboard figure that the underlying events do not sum to, with no rounding or definitional reason: that is a reporting defect. Each platform would be reported with its reconciliation table and the residual, not a single trust-me rate.