Gateway ads, also known as Prerolls, play when listeners go to a website and open the stream. Most gateways are video files served in a device based manner to the player and play from the player before the listener is connected to the stream. Based on the fact that the file plays before the stream connects, many people expect the number of prerolls available to be sold to be the same as the number of session starts.
This would be mostly correct if prerolls were served instream as part of the stream. But this is seldom the case in most current deployments.
And due to that fact, Session Starts will most seldom completely equal preroll avails.
In fact, in many cases the number of prerolls available to be filled is far less than the number of session starts.
This is due to the simple fact that not every started session comes from a device that can call a preroll or show a preroll because, curretnly, most prerolls are not Instream but rather delivered on demand via player based calls for files.
Stream aggregators such as iTunes and TuneIn don’t allow for the needed on demand code to be executed. So, no sessions started from those devices can play a preroll since the aggregators don’t allow for the needed code to be executed.
Different types of new “radios” (IP radios, smart TV’s, direct URL connections, and a multitude of other devices including many mobile devices) don’t have a player window to display the file nor do they have the needed HTML code parsing tools needed for the execution of the “display” code. So additionally, no session started by any of these non-web player devices (aka User Agents) can actually call or display a preroll.
And as more non-browser devices make it into the market, the number of player based prerolls that can be displayed continues to decline - which has been the trend over time and as new listening devices fragment the listenening market.
Even if a player can make the needed on Demand call (AKA RunSpot), the listener’s device must also be able to physically display the preroll video file.
So, the device will need to have a window to play the file and the device itself will need to run the needed “display” code (usually javascript) on the end user's device. Even in a world where all devices used web browsers to connect to streams many web based devices (on average about 15-20%) ran, or run, firewall settings, pop-up blockers, or various security settings that prevent the execution of the display code; essentially preventing player based prerolls from playing in the first place.
So, in short, the typical station only has, at most, about 50% of the session starts avails for device based prerolls.
In this regard, the introduction of Instream Prerolls will allow for users on non web devices to be able to receive prerolls as part of the stream! With the addition of this feature in CM3 stations WILL be able to monetize almost all session starts with either a video preroll served to the player or an audio preroll served in stream should they choose to do so. If you would like more information about the Instream Preroll functionality availble in Campaign Manager 3, please reach out to your Account Manager for more details.