Confirmation truth

The heart of yumipop is a trustworthy impression count. Most of programmatic gets this wrong; we make it correct by construction.

A win is not an impression

Two signals that people wrongly treat as delivery:

• Win notice (/track/win) — the auction was won. It says nothing about whether the ad rendered. It never confirms.
• nurl — the win-notice URL in OpenRTB. Also never an impression (OpenRTB §4.2.3).

Counting either of those inflates delivery. yumipop does not.

Multi-signal, exactly-once

An impression confirms when a trustworthy signal actually fires — any of:

• the VAST <Impression> beacon,
• the media fetch (the creative bytes were requested),
• a quartile <Tracking> event.

Whichever arrives first confirms the impression, once. Later signals for the same impression are recorded but never re-count and never re-bill. The ledger is a strongly-consistent per-impression record, so this holds even under concurrent signals.

Why this matters

Because we only bill confirmed impressions, and because we bill on our own count, the count has to be inspectable. Every confirmed impression writes an immutable row (who / how / when-collected); a buyer can export the per-impression ledger for any media buy and reconcile it against the billed spend:

curl -s "https://api.yumipop.com/v1/media-buys/$BUY/impressions" -H "authorization: Bearer $YP"
# → { impressions, spend, ledger:[{iid,ts,price,fee,net,signal}], reconciles: true }

reconciles: true means the row count equals the delivered-impression counter and the per-row prices sum to the billed spend. Not “trust us” — checkable.

Honest scope

yumipop confirms what actually arrives; it does not fabricate delivery for signals that never fire. If your player or stitcher fires nothing, the impression stays pending (unbilled). That is the point.