We’ve all had the frustrating experience of watching a VOD show and seeing the same ad run multiple times. It’s a well known problem with a few causes. As a result, frequency capping and transparency are two hot topics in the CTV space right now. However, I’d like to talk about this topic from a slightly different perspective. Advertisers often use Server Side Ad Insertion (SSAI) to mitigate these ad repetition issues. However, the mechanics and buying behavior of this can cause other problems for publishers.
A common refrain heard from both VOD publishers and ad stitchers is that ad responses to VOD requests are unevenly distributed across the pods. The key drivers behind this are lack of transparency/visibility and the effect it has on buying behavior in order to manage frequency caps/reduce duplication. Essentially, when a VOD stream starts, all of the ad pods for that stream (when using SSAI) are called simultaneously and prior to when playback begins. Advertisers see all of these requests, but have little context about what they are buying (e.g. 2 hr movie, 15 min clip, etc) nor the ability to manage the interplay between ad pods. The result is that advertisers run the risk of exceeding frequency caps and running duplicate ads, both of which are undesirable outcomes.
For example, if an advertiser bids on ad pod numbers 1, 2 and 3 they may win all, some, or none of those placements. If they win all of them, they are likely to exceed frequency caps and run duplicate ads. As a result, advertisers will tend to bid on only 1 or 2 of these pods, typically the 1st or 2nd pod, which causes the distribution of ad responses described above.
No publisher wants to deal with long start-up delays that cause abandonment and loss of revenue. Because of this, and how SSAI in VOD works, the ad pods are offered simultaneously, as individual entities, to reduce user wait times. In this scenario, advertiser don’t know if they won and individual pod (eg. pod 1) before they have to bid on another pod (e.g. pod 2). When combined with the frequency capping behavior described above, this results in overfill of some pods and underfill/no fill of other pods. In other words, you might see 20 advertisers bidding on 4 slots in pod 1, but no advertisers bidding for the 4 slots in pod 3. Given that an excess advertiser has bid on a specific pod, publishers and/or their ad stack are restricted from reallocating them to subsequent pods.
Since ad decisions are made one time, at the beginning of the process (e.g. when a user presses “play” on an asset), it is not possible to re-offer the overfill advertisers the opportunity to be placed in a different pod.
Finally, the practice of publishers using multiple Supply Side Platforms (SSPs) causes additional headaches for advertisers. When publishers use multiple SSPs the advertiser will often see the same inventory offered in multiple places but may have a difficult time identifying it as being the same. This creates the scenario where an advertiser could be bidding against itself for a placement and/or win placements (via 2 different SSPs) that result in duplication. As such the advertisers need to be cautious. Some of this complexity can be addressed by Supply Path Optimization, through which advertisers will also tend to restrict bidding to one or a very limited number of SSPs. In the real world where not all SSPs will have the same access to inventory, these buyers will end up migrating to specific pods within a stream, and therefore produce the uneven distribution of ads seen by publishers.
To address all of this, ad servers and other companies have built systems that do some pretty advanced pod manipulation. However, this approach is more efficient at dealing with direct sold campaigns and can be limited in terms of their ability to shift overfill from one pod to another for programmatic buying. Ultimately, pod reallocation is highly dependent on how the advertiser has purchased the inventory. Advertisers, publishers and tech providers are working to improve the situation. Exciting times indeed.
Comments