Why do impression counts differ between platforms, and how big is too big?
Part of Curated deals and PMPs
The short answer
Impression counts differ because each system records a different event at a different moment: the exchange books a billable event under its own policy, the buying platform counts a win or billing notice, and the ad server counts when its tag fires. The standard terms treat a gap above 10 percent per invoice period as a reconciliation trigger.
Key takeaways
- OpenRTB separates the win notice, which is not necessarily a billable ad, from the billing notice, which marks when spend should be applied.
- The 4A's and IAB standard terms name one controlling measurement for invoices and require reconciliation when it is more than 10 percent lower than the other count.
- The MRC and IAB Tech Lab desktop display guidelines set no acceptable gap; the 10 percent figure is a contract trigger, not a measurement standard.
Why do impression counts differ between platforms?
One ad passes through several systems, each with its own log. The publisher's ad server fills the slot, the exchange runs the auction and bills the buyer, the buying platform bids and books spend, and the agency's ad server records when its tag loads. A verification tag may record a further event. None of them shares a counter.
The OpenRTB 2.6 specification (opens in a new tab) builds the split into the protocol. It defines the win notice URL as called by the exchange if the bid wins, adding that it is not necessarily indicative of a delivered, viewed or billable ad. It defines a separate billing notice URL, called when a winning bid becomes billable based on exchange specific business policy. The specification says the win notice informs the bidder's pricing algorithms of a success, whereas the billing notice indicates that spend should actually be applied.
| System | Counting point | What can make it higher or lower |
|---|---|---|
| Publisher ad server | The ad server's own impression event for the line item | Its filtering rules and whether it counts before or after rendering starts |
| Exchange or SSP | The event its business policy treats as billable, signaled to the buyer by a billing notice | Policy choices such as delivery or viewability as the billing basis |
| Buying platform (DSP) | A billing notice, a pixel in its markup or the win, depending on the integration | Win counts run ahead of delivered ads; pixels can miss loads |
| Agency or third party ad server | Its tag loading in the browser or app | Network loss, slow pages and redirects between servers |
| Video player | The VAST Impression event | Player errors or ads that start buffering but never play |
What causes impression discrepancies?
Section 7.8 of the OpenRTB implementation guide (opens in a new tab) compares the counting methods in use and is candid about their weaknesses. It lists a pixel in markup as widely supported but prone to discrepancies, and the billing notice as the best alignment between buying platforms and exchanges with minimal discrepancy. For video and audio it says the VAST Impression event is the official billable signal and discourages billing notices for those formats.
| Cause | What happens | Source |
|---|---|---|
| Pixel timing and network loss | The exchange's and buyer's pixels load at different times, and a noisy connection can fire one but not the other | OpenRTB implementation guide, section 7.8 |
| Mobile app prefetch | Markup is fetched in advance and may never display if the user leaves the app | OpenRTB implementation guide, section 7.8 |
| Creative auditing | Markup loaded to scan for malware can create spurious events, even for unwon auctions | OpenRTB implementation guide, section 7.8 |
| Delayed billing notices | Caching or prefetched video can delay the billable event by minutes | OpenRTB implementation guide, section 7.2 |
| Caching | An ad rendered from a device cache may go unrecorded unless cache busting is used | MRC and IAB Tech Lab desktop display guidelines, caching guidelines |
| Invalid traffic filtering | Each system removes the invalid activity it detects, under its own methods | MRC and IAB Tech Lab desktop display guidelines, filtration guidelines |
| Redirect latency | More redirects between servers in rich media reduce counting accuracy | MRC and IAB Tech Lab desktop display guidelines, rich media scope |
Two more causes are operational: reports cut in different time zones, and reports pulled before one side has finished its filtering adjustments. Neither is a measurement error, but either can widen a daily gap.
What discrepancy is considered normal?
The measurement guidelines set no single tolerance. The MRC and IAB Tech Lab desktop display impression measurement guidelines (opens in a new tab) set how an impression is counted, including client initiated counting, cache busting and filtration, and ask for counting methods to be disclosed. They set no acceptable percentage gap between two compliant systems.
The 10 percent figure comes from contracts. Section XIII(d) of the 4A's and IAB Standard Terms and Conditions, Version 3.0 (opens in a new tab) says that if the difference between the controlling measurement and the other measurement exceeds 10 percent over the invoice period and the controlling measurement is lower, the parties will facilitate a reconciliation. If the gap cannot be resolved after a good faith effort, the agency may treat it as under delivery and seek a makegood, or pay on the controlling count plus a 10 percent upward adjustment to delivery.
Which count is used for billing?
Whichever count the agreement names. In direct buys under the standard terms, section XIII(b) sets an order of preference for the controlling measurement when both sides track delivery. In programmatic buying, the exchange's billable event under its own policy drives what the buyer is charged, and the buying platform books spend when the billing notice or its equivalent arrives.
| Situation | Controlling measurement |
|---|---|
| Only one ad server is compliant with the IAB and AAAA guidelines | The compliant ad server |
| Both are compliant, and the agency's ad server offers an automated, daily reporting interface the publisher approved and can access in time | The agency's third party ad server |
| Neither is compliant, or the automated interface condition is not met | The publisher's ad server, unless both agree otherwise in writing |
Section XIII(c) adds that the party holding the controlling measurement gives the other side online or automated access to its statistics within one day of launch, or the other party may invoice from its own numbers. Write the controlling count into the order or deal terms before launch.
How do you investigate a large impression discrepancy?
The shape of a gap points to its cause. A steady gap of the same size every day suggests a counting method difference; a gap on one format, environment or day suggests something changed.
| Pattern | Likely cause | What to ask for |
|---|---|---|
| Buyer's tag count lower by a steady margin on web display | Pixel timing and network loss between counting points | Each side's counting point, in writing |
| Gap concentrated in mobile app inventory | Prefetched markup that never displayed, counted by one side | Whether the exchange bills on markup load or on display |
| Gap concentrated in video | One side counts a request or player load, the other the VAST Impression event | The event each side uses for video |
| Gap appears on one day and stays | A tag, creative or setup change | The change log for that date on both sides |
| Gap disappears when the same time zone is used | Report cut, not measurement | Reports in one agreed time zone |
| Gap shrinks over several days | Delayed filtering or late billing events | Final, not provisional, figures for the period |
Before raising a discrepancy with a seller
- Both reports cover the same deal ID or line item, creative, dates and time zone.
- The gap is calculated over the invoice period, not only on the worst day.
- You know which side holds the controlling measurement under the agreement.
- Each side's counting point for each format is written down.
- Invalid traffic adjustments are final on both sides for the period.
- Any tag, creative or setup changes during the flight are listed with dates.
How do discrepancies affect deal reporting?
On a private marketplace or guaranteed deal, the seller reports delivery against the deal ID and the buyer reports against its line item, so a gap between them becomes a question about the deal. For a guaranteed deal it decides whether the volume was met and whether a makegood is owed. The standard terms say a makegood that follows an unresolved discrepancy is measured by the agency's ad server.
Counting delays also change how a deal paces. The OpenRTB implementation guide says buyers use the billing notice to book progress toward spend goals and frequency caps and to drive pacing, and that significant delays can seriously impair those functions. Agree with the seller which count the deal's delivery targets use, and treat daily figures as provisional.
What does a discrepancy review look like on a real deal?
Fictional example
A live music venue's guaranteed deal in Tennessee and Kentucky
An unnamed live music venue promotes its fall concert calendar with display and online video beside music, nightlife and local events coverage in Tennessee and Kentucky, focused on Nashville, Louisville and Knoxville, in English. Its agency runs a guaranteed deal with a regional entertainment publisher, and the order names the agency's ad server as the controlling measurement.
At the end of the first invoice period the agency's count is more than 10 percent below the publisher's. The agency splits the gap by format first. Display is close on both sides; nearly all of the gap sits in video served inside the publisher's mobile app.
The publisher confirms that its app reports count the ad when the player loads it, while the agency's ad server counts the VAST Impression event. The two sides agree to report video on the VAST Impression event, reconcile the period on that basis, and add the counting point for each format to the deal sheet for the next flight.
How does PlacementGraph help keep deal records consistent?
Frequently asked questions
Does an impression discrepancy mean someone is committing fraud?
Not on its own. Gaps can come from different counting points, timing and filtering, as the OpenRTB implementation guide and the MRC guidelines describe. Invalid traffic is one possible contributor, because each system filters what it detects. A gap is a reason to compare methods, and fraud needs its own evidence.
Can the buyer's count be higher than the publisher's?
Yes. A buying platform that counts wins, or a tag that fires on markup loaded for creative scanning or prefetching, can record more events than the publisher bills. The current standard terms require reconciliation when the controlling count is more than 10 percent lower than the other, whichever side that is.
Why can video counts differ more than display counts?
Video adds steps between the request and the ad playing: the player, the VAST response, buffering and playback. OpenRTB names the VAST Impression event as the official billable signal for video and discourages billing notices there, so any system counting at another step of the player sequence will drift from the others.
Should a discrepancy be checked daily or only at invoice time?
Both. A daily view in the first days of a flight catches setup errors while they can still be fixed. Whether reconciliation is needed is judged on the invoice period total, the basis the standard terms use for the 10 percent trigger.
Sources
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab, OpenRTB repository
- OpenRTB 2.x implementation guide (opens in a new tab)IAB Tech Lab, OpenRTB repository
- Desktop Display Impression Measurement Guidelines (opens in a new tab)MRC and IAB Tech Lab
- Standard Terms and Conditions for Internet Advertising for Media Buys One Year or Less, Version 3.0 (opens in a new tab)4A's and IAB
- Education Guide to the Standard Terms and Conditions, Version 3.0 (opens in a new tab)4A's and IAB
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.