The Trouble with Ad Beacons

The measurement of ad views, or impressions, makes use of something called “beacons.” These are notifications (just URLs containing lots of data) sent to a beacon receiver, declaring that an ad has been partially or completely viewed. The beacon URL (containing the beacon receiver location) is returned with the original ad decision: When an ad fills an ad slot, beacons are sent.

These beacons do not have a tranquilizing effect on the human nervous system. In fact, quite the opposite: It’s not uncommon for each ad to include tens of beacons. For example, there’s the impression beacon; the five beacons representing quartiles of ad playback (start, first quarter, middle, three-quarters, and completion); the error beacons; and the custom beacons. 

Further complicating matters, all beacons are sent to multiple ad decision partners in the ecosystem. An ad for fried chicken? A bucket of beacons for all ad servers involved. A flower ad? A bouquet of beacons for any SSPs involved. Ad for family show reruns on TV? A Brady Bunch of beacons for any DSP involved, etc. 

So, who sends these beacons? With Server-Side Ad Insertion (SSAI), the beacons are often triggered on the server-side. (Though in some cases, the beacons are forwarded to the playback devices, which then send the beacons out.) There’s a lot of back and forth about whether client-side or server-side beaconing is better, and we’ll avoid that completely here. But, either way, there are a lot of beacons that need to be sent out, and that’s a ripe opportunity for things to go awry – and they sometimes do. 

One simple way beacons go amiss is their length. Beacons are URLs, and URLs have length limits, typically 2K bytes for GET URLs (the typical way to send beacons). Beacons get long because ecosystem players want to pack them full of data: Which creative ad is the beacon referencing? When was the ad requested? What campaign is being referenced? Which actual auction or ad request is being referenced? What kind of beacon is this? 

When beacons get very long and receivers can’t digest them, the beacons are not registered. That’s an example of an ad hole that didn’t start as an ad hole: The ad played, but it looks like it didn’t, because no one will get paid for that ad view if no beacons announce that the ad received an impression. At Wurl, we’ve seen very long beacons, over 4K bytes in length, that caused temporary unhappiness.  

A more subtle way that beacons go bad is by getting stale. When an ad is served, beacons for that ad can’t come in too late. At some point, everyone wants an accounting, and on top of that, when reconciling many ads with many beacons, you don’t want to maintain huge lists of ads to match with incoming beacons. It’s painful and expensive, not to mention unprofessional. 

At the same time, you can’t insist on too short a latency between the ad view and the beacons. One reason for being relaxed about latency is Video On Demand (VOD). In many VOD deliveries, all the ads for the VOD asset (e.g., long movies, like Star Trek) happen at the playback start. But the viewing of the ad may only happen an hour or more later when the ad is inserted near the end of the movie. So beacon receivers have to accept some latency, typically two hours. 

Another reason for latency is related to the processes that send beacons have to do a lot of work quickly. Imagine one million viewers getting four ads in a two-minute break. Each ad has roughly 40 beacons. The component sending out beacons now has to process (4 ads) x (40 beacons) x (1 million viewers) = 160 million beacons. At 100,000 beacons per second (which is a fair clip!), processing the beacons will require 26 minutes! That means the next ad break will happen before the beacons from the last break are processed. So beacon receivers simply must find a balance between latency and accuracy. 

Can this beaconing lead to ad holes? Yes, if the beacon sender takes too long and the beacon receiver has closed the reconciliation window for some ads, impressions aren’t counted, checks are smaller, frustration ensues, emails are sent, and Wurl figures out the issue. 

Reasons to keep latency short:

• Fraud mitigation
• Near real-time reporting
• Efficiency of matching ads to beacons

Reasons to allow longer latency:

• Processing of VOD
• Sympathy for hard-working beacon senders

The truth is that beacon timeouts are much rarer these days. But you don’t want to miss the opportunities.

---

If you missed the previous posts in the series about unfilled ad slots – or ad holes – check out the previous posts describing what ad holes are and the impact CTV viewing:

• Intro to Ad Holes
• Bad VAST Response
• Changing Ad ID and Ad Transcoding Issues
• It’s Not All Bad News – Some Ad Holes Aren’t Real!
• When the Ad Holes Are Your Own Darn Fault
• Timeouts
• Zombies! (Really!)
• The Impact of Content on Ad Holes