Yahoo Deliverability and Performance Feeds in 2020: Provider-Derived Analytics

Anil Jalela · Published Feb 21, 2020 · 11 min read

On February 18, 2020, Yahoo Postmaster announced privacy-conscious email deliverability and performance feeds for trusted senders. Yahoo argued that panel and pixel-based tracking could be inaccurate and could compromise user privacy, while a mailbox provider could produce aggregated evidence directly from its mail servers. Current documentation describes two distinct products: the Placement Feed and the Campaign Performance Feed. The first reports where messages were delivered and includes errors and complaints. The second reports aggregate campaign delivery and engagement events. These feeds provide receiver-side evidence unavailable to a normal tracking pixel, but their schemas, grains, access rules and denominators must be preserved before anyone turns them into a dashboard or optimization decision.

The dated mailbox-provider change

Email performance reporting traditionally combined sender SMTP logs, a remote image request, redirect clicks and a web conversion system. Each source observed a different event. A pixel saw resource retrieval, not necessarily a person reading, and panels observed a sample rather than the full provider population.

Mailbox providers possess delivery-folder and client-action evidence. They can know whether their system placed a message in inbox, spam or another folder and whether a client recorded selected actions. Sharing that evidence at user level would create unacceptable privacy exposure, so Yahoo designed aggregated feeds for approved relationships.

The February announcement framed the program as a move away from invasive tracking toward trustworthy aggregated insights. It did not declare tracking pixels technically impossible, nor did it make every provider metric universally available. Access was directed through the postmaster program for trusted senders.

Current Sender Hub documentation makes the distinction concrete. Placement and Campaign Performance use different dimensions, delivery grains, latency and metric families. Combining them without a data contract creates plausible but false rates.

How the system worked before the change

Before provider feeds, a sender inferred Yahoo placement from seed accounts, engagement changes, complaints and SMTP outcomes. A delivered SMTP response did not say whether the message reached inbox, spam or a folder.

Pixels attempted to measure opens, but caching, image blocking, proxying, scanners and client behavior distorted the event. A campaign could be read without an image request or generate an image request without deliberate attention.

Panel data provided directional placement estimates from participating accounts. Coverage, sampling and cohort composition limited its ability to represent the provider population, especially for small campaigns.

Sender dashboards often joined these sources as if they had one denominator. “Delivered” might mean accepted by SMTP, observed in a panel, or recorded in campaign analytics. Complaint rates could divide by sent, accepted, all delivered, or inbox delivered, producing different values.

What changed on the provider side

The Placement Feed exposed aggregate counts including inbox, spam, folder and error deliveries plus complaints. Current schema dimensions include DKIM domain, From sender domain, connecting IP and an approved campaign x-header name and value.

The Campaign Performance Feed exposed delivered, opened, clicked, deleted, marked-read, forwarded, starred, archived, moved, push-notification-opened, replied, marked-spam and dwell classifications such as read, skim and glance. It also carries declared template identity, goal, sender, client and delivery type.

Yahoo documents privacy aggregation rather than user-level rows. The feeds are filtered to allowlisted domains or IPs, use UTC and Avro, and have explicit reporting, delivery, SLA and retention characteristics. Placement and campaign data are not guaranteed to arrive simultaneously.

The result was a new evidence layer, not a complete marketing attribution system. Yahoo can report events inside its mail estate; the sender still owns consent, campaign cost, site conversion, revenue, refunds and long-term customer outcomes.

Message path before and after

Before

Sender SMTP logs + pixel requests + redirect clicks + panel sample
    |
    +----> different populations and event meanings
    +----> inconsistent denominators
    |
    v
Sender estimates Yahoo placement and engagement
    |
    v
Optimization may confuse retrieval, reading and conversion

After

Yahoo mail-server and client events
    | privacy aggregation + allowlisted identities
    +----> Placement Feed: inbox, spam, folder, errors, complaints
    +----> Campaign Performance Feed: delivery and aggregate actions
    |
    v
Validate Avro -> preserve UTC grain -> deduplicate -> reconcile late data
    |
    v
Join sender campaign cost and conversion only at governed aggregate keys

Who and what the change affected

Effect on delivery, placement and recipient visibility

Placement counts can distinguish an SMTP acceptance problem from a folder-placement problem. If error deliveries rise, examine exact transport or policy evidence. If spam delivery rises while acceptance remains stable, focus on permission, complaint, authentication, reputation and campaign quality.

Provider folder data does not guarantee that every individual message followed the aggregate distribution. Do not use a campaign-level inbox percentage to claim a specific recipient received inbox placement. Aggregation protects users and limits diagnosis to the reported cohort.

Complaint metrics require a declared denominator. Current Yahoo guidance explains that its complaint rate can use messages delivered to the inbox, which may differ from a sender calculation using all accepted or delivered messages. Store numerator and denominator fields separately.

Campaign identifiers must be stable and bounded. Reusing one x-header value across unrelated sends collapses evidence; creating recipient-specific values defeats aggregation and can create privacy risk. Use a non-personal template or campaign identifier governed across the ESP and analytics platform.

Feed absence is not proof of zero activity. It can reflect access, allowlist, volume threshold, pipeline delay, expired retention, schema change or ingestion failure. Monitor expected file arrival and coverage before interpreting business trends.

Effect on measurement and diagnosis

Maintain separate fact tables. Placement uses its documented hourly reporting and delivery grain with a published delivery SLA; Campaign Performance has its own hourly reporting, daily delivery grain and longer SLA. Join only after aligning the intended window and waiting for completeness.

Store provider metrics as counts, not precomputed universal rates. Calculate inbox share from appropriate placement counts; calculate complaint rate with the explicitly chosen provider or local denominator; calculate click or dwell ratios only within the Campaign Performance population represented by the row.

Preserve dimensions before aggregation: DKIM domain, sender domain, connecting IP, x-header, declared template, campaign goal, delivery type, client and UTC time. Dropping identity makes a shared-platform incident impossible to attribute.

Yahoo’s campaign schema includes provider-defined open, marked-read and dwell categories. Treat those definitions as provider events, not direct proof of human comprehension. Compare them with clicks, replies, conversions and complaints rather than renaming all as engagement.

Use a late-data ledger. Record source object, schema version, produced time, received time, event window, row count, checksum and processing status. Reprocess idempotently and keep raw Avro through the available retention and internal governance period.

Advantages for email marketers

Disadvantages and operational risks

What email teams needed to do at the time

1. Request access through the provider program. Document approved domains, IPs and use cases.
2. Define campaign identity. Use stable non-personal x-header and template keys.
3. Build separate ingestion paths. Preserve Placement and Campaign Performance grains.
4. Validate Avro schemas. Quarantine unknown versions and retain raw files.
5. Normalize UTC windows. Avoid local-time joins before canonical storage.
6. Document denominators. Name the exact population behind every rate.
7. Protect aggregation. Prevent recipient-level reconstruction or cross-tenant leakage.
8. Reconcile with sender evidence. Keep SMTP, complaints and site outcomes distinct.

What email teams should do now

1. Use current Sender Hub documentation. Monitor schema and access changes.
2. Version every field definition. Provider terms such as read, skim and glance have specific meanings.
3. Retain provenance. Store object checksum, schema, window and processing history.
4. Track freshness and coverage. Alert on missing, late or unexpectedly sparse data.
5. Calculate rates at query time. Preserve raw numerators and denominators.
6. Separate current Insights. Do not assume dashboard statistics equal partner-feed populations.
7. Map DKIM and tenant ownership. Keep shared-platform evidence attributable.
8. Apply privacy thresholds. Do not expose small cohorts or derive user behavior.
9. Use provider data for diagnosis. Retain sender conversion systems as business truth.
10. Audit optimization decisions. Require causal tests rather than correlation alone.

Worked deliverability scenario

An ESP receives both feeds and builds a single hourly table by joining on sender domain and hour. Placement data arrives sooner, while Campaign Performance delivery is daily and arrives later. The first dashboard divides partial clicks by complete inbox deliveries and reports a sudden engagement collapse.

The same x-header value is reused for newsletters and triggered offers. One customer also shares the platform DKIM domain with many tenants. The aggregate row cannot identify which program caused a complaint rise.

The ESP separates fact tables, retains each source grain and waits for published completeness windows. It requires a governed campaign identifier and preserves both platform and customer signing dimensions. Rates are calculated from named populations, and late files revise the correct partition idempotently.

The corrected dashboard shows that placement remained stable; the apparent collapse came from an incomplete campaign feed. A genuine complaint increase is traced to one acquisition source through campaign and tenant dimensions. The sender changes permission practices, not creative merely because a partial open ratio moved.

Evidence and diagnostics

• Access: approved partner, allowlisted DKIM domains, sender domains, IPs and x-header.
• Object: feed name, URI, checksum, size, schema version, produced and received time.
• Window: UTC event start, end, reporting grain, delivery grain and expected SLA.
• Identity: DKIM, From, IP, x-header, template namespace, campaign, goal and tenant mapping.
• Placement: inbox, spam, folder, error and complaint counts.
• Performance: delivered, opened, clicked, read, skimmed, glanced, deleted and other documented actions.
• Quality: missing partitions, duplicates, late rows, negative or impossible counts and schema drift.
• Join: aggregate key, denominator, completeness state and privacy review.
• Outcome: sender conversion, revenue, reply, unsubscribe and retention evidence kept separate.

Failure modes and incorrect conclusions

• Calling pixel events provider opens. Their collection and definitions differ.
• Joining hourly and daily delivery blindly. Partial data creates false rates.
• Using file count as message count. One object can contain many aggregate rows.
• Inferring an individual recipient path. The feeds provide aggregated counts.
• Mixing Yahoo Insights with partner feeds. Access, metrics and populations differ.
• Dropping DKIM and campaign identity. Shared-platform causes disappear.
• Treating late data as zero. SLA and pipeline state must be explicit.
• Optimizing for opens alone. Provider events do not replace business or permission outcomes.

Current status and superseding changes

Yahoo currently documents the Placement Feed and Campaign Performance Feed on Sender Hub. The page publishes field definitions, delivery and reporting grain, SLA, UTC, retention and Avro format, while directing interested senders to contact Yahoo about program requirements.

Current Sender Hub Insights is a separate dashboard capability for verified DKIM domains, initially exposing delivered counts and a complaint rate based on inbox-delivered messages. Its denominator clarifies why local complaint calculations can differ.

The feed schema also carries View Time Optimization delivery types, connecting later provider capabilities to campaign measurement. Analysts must retain optimized, drained and regular distinctions rather than pooling them without review.

Data governance must include revocation and offboarding. If a customer, signing domain or IP leaves an approved scope, remove access mappings without rewriting retained historical evidence. Verify that shared ESP teams cannot query another tenant’s aggregates, and keep export destinations, encryption, service accounts and audit logs inside the provider agreement and internal privacy policy.

Schema monitoring should be proactive. Compare every received Avro schema fingerprint with the approved registry, quarantine unknown fields or incompatible types, and alert before a silent cast changes a metric. A pipeline that finishes successfully while dropping a new dimension is more dangerous than a visible failure because dashboards remain plausible.

The durable principle is evidence contracts. Provider-derived aggregation can improve placement and engagement diagnosis, but every metric needs identity, grain, coverage, latency, privacy boundary and denominator. It should complement, not overwrite, consent and business-outcome systems.

Operator checklist

• Record February 18, 2020 as the feed announcement date.
• Keep Placement and Campaign Performance as separate fact models.
• Preserve documented UTC grain, SLA, retention and schema version.
• Retain DKIM, From, IP, campaign and delivery-type dimensions.
• Use stable non-personal campaign identifiers.
• Store raw Avro and process every object idempotently.
• Monitor expected arrival, coverage, lateness and schema drift.
• Name numerator, denominator, population and window for every rate.
• Never infer user-level behavior from aggregated rows.
• Keep Sender Hub Insights and partner feeds distinct.
• Join provider evidence to sender conversions only at governed aggregate keys.

Primary and contemporaneous references

• Yahoo Postmaster: Announcing New Engagement Feeds: Primary February 18, 2020 announcement.
• Yahoo Sender Hub: Deliverability and Performance Feeds: Current schemas, metrics and feed attributes.
• Yahoo Sender Hub: FAQ: Current Insights access and denominator guidance.
• Yahoo Postmaster: Sender Hub Insights: Current provider dashboard announcement.

Related NitWings guides

• Yahoo View Time Optimization
• Email Attribution Models
• Campaign Performance Analysis
• Sender Reputation Signals
• Improve Yahoo Deliverability