The measurement gap in programmatic
Anyone who has run real-time bidding at scale knows the frustration: two partners look at the same traffic and report two different numbers. A buyer counts one set of impressions, the supply partner counts another, and the invoice sits somewhere in between. Some gaps are normal as every platform in the chain counts independently, with its own filters, but when the difference grows, it costs time, trust, and clean billing.
A large part of that gap comes down to how events are counted. The long-standing default across the industry is the client-side pixel: a tracker fired by the rendered ad in the browser. It works well most of the time, but it depends on the browser actually firing and delivering that call and modern browsers, especially on mobile, don’t always cooperate. When a browser optimizes navigation and collapses steps, a pixel that should have fired never reaches the counting server, and an event that genuinely delivered goes uncounted.
Discrepancies show up for a handful of recurring reasons:
- Modern mobile browsers optimizing navigation so a client-side pixel never fires.
- Platforms filtering invalid and duplicate clicks differently.
- Client-side measurement differences such as Client Hints and sendBeacon behavior
- Format-specific counting differences.
- The simple fact that every platform in the chain counts independently, with reconciliation only ever happening between adjacent partners rather than end to end.
How EXADS fixes RTB discrepancies: Billable Event Counting (BURL)
BURL lets an EXADS RTB zone count impressions, and clicks on CPC formats, from the billable server-to-server event instead of the client-side pixel. For impressions, it builds on the OpenRTB billing-notice URL (burl): when a winning bid becomes billable, a server-to-server call is made, and that call is what counts the impression. For clicks on CPC formats, EXADS uses its own server-to-server click notice, which is an EXADS mechanism rather than standard OpenRTB. In both cases, counting follows the pricing model.
Because the count happens server-to-server, it no longer depends on the browser firing a pixel, which removes one of the biggest and least controllable sources of discrepancy.
How BURL works
- Enable it per zone. BURL counting is a toggle on the RTB zone (OpenRTB 2.4 and 2.5 templates), disabled by default. Turning it on simply changes how that zone counts impressions and clicks, from the pixel to the billable event.
- Counting follows the pricing model. For CPM formats the billable event is an impression; for CPC formats it’s a click, per the pricing model (signalled in the EXADS bid.ext.btype extension).
- It’s a server-to-server signal. When the bid becomes billable, the billing-notice URL is called server-side, no reliance on a browser pixel making it back.
Transparency built in: “Served” metrics
Switching to billable-event counting doesn’t mean losing sight of what is actually rendered. Alongside the billable counts, EXADS keeps parallel “Served” metrics, Served Impressions and Served Clicks, which are always counted from the rendered pixel, regardless of the BURL setting.
That gives both sides a clear, visible comparison between what was rendered and what was counted as billable. The relationship between rendered and billable counts, tracked as a Served Impressions Ratio and a Served Clicks Ratio, is a simple, practical health check: when rendered and billable counts track closely, things are healthy; when they diverge, it’s a signal to investigate rather than a number hidden inside a black box.
What BURL does and what it doesn’t do
BURL is a measurement and reconciliation tool, not a silver bullet. It aligns how the billable event is counted between two partners, server-to-server, which closes the gap created by unreliable client-side tracking. It does not magically erase every discrepancy. Differences in invalid-click filtering, format-specific behavior, and genuine client-side losses still exist, and reconciliation always happens between adjacent partners in a chain rather than end to end.
That’s exactly why the Served metrics matter: they keep BURL honest. Used together, billable counts and Served metrics give a far clearer, more trustworthy picture than a pixel alone, which is what makes invoicing smoother and partner conversations easier.
Recommendations for EXADS RTB partners
- DSPs bidding into EXADS supply: include burl in your bid response (alongside nurl) so impressions can be counted from the billable event. EXADS fires it server-to-server when the impression becomes billable.
- SSPs receiving EXADS bid responses: EXADS now includes burl in its outgoing OpenRTB 2.4 and 2.5 responses and fires it server-to-server when the impression becomes billable.
Important: if a zone has BURL enabled and the partner doesn’t include or fire burl, that demand source will count Impressions = 0. On BURL-enabled zones, including and firing the billable event is required for impressions to register.
Full technical detail, the zone setting, the counting logic, and partner expectations are documented here (opens in a new tab).
What’s an acceptable level of RTB discrepancy?
Some discrepancy is always expected. As a rough guide:\
These bands are guidance for spotting when a partnership needs a closer look, not contractual thresholds.
The bottom line
BURL brings server-to-server counting to the moment that matters most. When an impression or click becomes billable and pairs it with transparent Served metrics so everyone can see rendered versus billed. It’s a meaningful step toward the thing every RTB partnership wants: numbers both sides can agree on.
Frequently Asked Questions
What is BURL in RTB advertising?
BURL (Billable Event Counting) is a server-to-server mechanism that counts impressions and clicks at the moment they become billable, rather than relying on a client-side browser pixel. It is built on the OpenRTB billing-notice URL (burl) standard for impressions, and uses an EXADS-specific server-to-server click notice for CPC formats.
Why do impression discrepancies happen between RTB partners?
Discrepancies occur because every platform in the chain counts independently. The most common causes are modern mobile browsers failing to fire client-side pixels, differences in invalid and duplicate click filtering, client-side measurement variations such as Client Hints and sendBeacon behavior, and format-specific counting differences.
How does BURL reduce RTB discrepancies?
By moving the count server-to-server, BURL removes the dependency on the browser successfully firing and delivering a pixel. When a winning bid becomes billable, a server-to-server call is made and that call is what registers the impression or click — making the count far more reliable than client-side tracking.
Does BURL eliminate all discrepancies?
No. BURL closes the gap caused by unreliable client-side tracking, but differences in invalid-click filtering, format-specific behavior, and genuine client-side losses still exist. It is a measurement and reconciliation tool, not a complete solution to all discrepancy sources.
What are Served Impressions and Served Clicks in EXADS?
Served Impressions and Served Clicks are parallel metrics that are always counted from the rendered pixel, regardless of the BURL setting. They sit alongside billable counts and allow both partners to compare what was rendered versus what was counted as billable — providing transparency and a built-in health check on the relationship between the two.
What is an acceptable level of RTB discrepancy?
As a general guide: under 5% is acceptable, 5% to 10% is worth monitoring, and over 10% warrants investigation. These are practical benchmarks for identifying when a partnership needs a closer look, not contractual thresholds.
How do I enable BURL on EXADS?
BURL is a toggle on the RTB zone level, available on OpenRTB 2.4 and 2.5 templates. It is disabled by default. Enabling it changes how that zone counts impressions and clicks from the pixel to the billable event. Full technical details are available at docs.exads.com (opens in a new tab).
What do DSPs need to do to support BURL on EXADS supply?
DSPs bidding into EXADS supply need to include burl in their bid response alongside nurl. EXADS will then fire it server-to-server when the impression becomes billable. If a zone has BURL enabled and the partner does not include or fire burl, that demand source will count zero impressions.
What pricing models does BURL support?
BURL counting follows the pricing model. For CPM formats the billable event is an impression; for CPC formats it is a click, signalled via the EXADS bid.ext.btype extension.
