The AudienceVerify Standard

Version 1.0.0-draft · Status: Draft · Last updated 2026-08-30

A public, versioned specification for attesting the reach and engagement of an email publication in a way that survives Apple Mail Privacy Protection.

This document is the specification. It is deliberately citable, deliberately boring, and deliberately public. Anyone may implement it.

1. Why this exists

Newsletter sponsorship is priced off the open rate, and the open rate has been structurally broken since Apple Mail Privacy Protection (MPP) began pre-loading tracking pixels. An MPP-protected recipient registers an open without a human ever seeing the message. A reported 55% open rate may represent 30% real attention, and the size of the gap varies per publication with the share of Apple Mail readers — a figure the publisher cannot see and the sponsor cannot audit.

Every verification scheme currently in market attests the open rate. Attesting a broken number accurately produces an accurate record of a broken number.

This standard refuses to certify a raw open rate as a standalone figure. That refusal is the point of the document.

2. Scope

In scope: email publications that send to a subscriber list through an Email Service Provider (ESP) with a machine-readable analytics API.

Out of scope in v1: web traffic, podcast, video, social. The attestation model generalises; the metric definitions here do not.

3. Definitions

The key words MUST, MUST NOT, SHOULD, and MAY are used as in RFC 2119.

Publication — a single email list under one editorial identity, sending from one verified domain.

Send — one campaign delivered to some or all of a Publication's list. Automated sequences and transactional mail MUST be excluded.

Window — the trailing 90 days ending at the last successful Sync. All aggregate metrics are computed over the Window unless stated otherwise.

Sync — one authenticated read of the ESP API by a Verifier.

Verifier — a party that performs Syncs and publishes attestations under this standard.

4. Attestation levels

Every published field MUST carry exactly one attestation level. This is the core mechanic of the standard: a number is meaningless without its provenance.

A Verifier MUST NOT upgrade an attestation level. A proxy never becomes attested by being copied.

5. Metrics

5.1 Verified Delivered (VD)

Sum of messages accepted by recipient mail servers across all Sends in the Window. Bounces MUST be excluded. Where the source reports only messages sent, VD is unavailable and Recipients MAY be published as a proxy.

VD, not subscriber count, is the denominator for everything below. Subscriber count includes addresses that never receive mail.

5.2 Verified Unique Clicks (VUC)

Count of distinct recipients who clicked at least one link, summed across Sends in the Window. Total click volume MUST NOT be substituted; one recipient clicking six links is one unique click.

Where the source exposes a bot-filtered unique click figure, the Verifier MUST prefer it and MUST record which figure was used.

Where the source exposes only total clicks, VUC is unavailable. It MUST NOT be estimated.

5.3 Verified CTR (VCTR)

VCTR = VUC / VD

derived. Publishable only when both VUC and VD are attested. This is the headline number of the standard: the honest replacement for the open rate.

5.4 Open rate — restricted

A Verifier MAY publish a reported open rate. If it does, it MUST:

1. label it attested (unadjusted);
2. render it visually subordinate to VCTR — never as the headline;
3. attach the MPP Exposure Note (§5.5);
4. never use it in a ranking, filter, or sort.

A Verifier MUST NOT publish an "MPP-adjusted open rate" as a single number. The adjustment factor is not knowable from ESP data, and a corrected-looking figure is more misleading than an obviously broken one.

5.5 MPP Exposure Note

Machine-readable qualifier attached to every open-rate figure:

Reported opens include automated pre-fetches by Apple Mail Privacy
Protection and similar proxies. The true human open rate is lower by an
amount this standard cannot determine. Do not price on this number.

5.6 List Velocity

Net change in list size over the Window, as an absolute figure and a percentage. attested where the ESP exposes historical counts; otherwise computed from the Verifier's own Sync history and labelled derived, with the observation start date published. Catches purchased lists and undisclosed churn.

5.7 Freshness

UTC timestamp of the last successful Sync. MUST appear on every rendering of every attestation, including embedded badges. An attestation older than 35 days MUST be rendered as stale.

A badge without a date is not an attestation.

6. Verification tiers

Assigned per Publication from what its source can actually attest.

A Partial attestation MUST NOT be presented in a way that reads as Full. Publications MUST NOT be ranked across tiers.

7. Source requirements

A Verifier MUST:

• authenticate with read-only credentials where the ESP offers scoped OAuth, and MUST prefer such sources over full-access API keys;
• persist only the aggregates defined in §5. Raw API responses MUST be discarded after computation. Subscriber records, email addresses, and per-recipient event data MUST NOT be persisted under any circumstances;
• encrypt credentials at rest under a key held outside the application database;
• verify control of the Publication's sending domain before first issuance;
• retain an immutable snapshot per Sync so that revisions to history are visible.

8. Integrity

Outlier review. Metrics deviating materially from a Publication's own history or its cohort MUST be held for review before publication.

Bot filtering. Where the source does not filter, the Verifier SHOULD filter datacenter-origin, sub-second, and duplicate-user-agent click clusters, and MUST disclose whether filtering was applied by the source or the Verifier.

Revocation. A Verifier MUST publish a public revocation list stating the Publication, date, and reason. A certification that cannot be lost is not a certification.

Independence. A Verifier MUST NOT take a percentage of any transaction it attests. An attestation issued by a party earning a commission on the deal it certifies is a conflict of interest and non-conformant with this standard.

9. Conformance

An implementation conforms to AudienceVerify Standard 1.0 if it satisfies every MUST in §4–§8. Conformance claims MUST cite the version.

10. Versioning

Semantic. Metric definition changes increment MAJOR. Historical attestations retain the version under which they were issued and MUST NOT be recomputed silently under a newer version.

Appendix A — Source capability register

Normative record of what each ESP can attest. Maintained alongside the spec; changes to this table are MINOR version bumps.

Kit's click_rate is attested but of unpublished basis; this standard does not treat it as VCTR and does not display it as one.