Whenever a stream starts at the point where the user left off, it skips the first (few) adBreak(s). We want to choose to only play the last skipped ad break, but not all.
For example:
- VMAP includes ad breaks at pre-roll (00:00) and at 20:00
- User starts item at 25 minutes.
We don’t want to skip all ads, but don’t want the user to see all previous ads. Therefore we want to choose to only play the last skipped ad break. In the web SDK there is a RestrictStrategy.shouldPlaySkippedAdBreaks callback on the config. This is not the case in the Android and iOS SDKs. Our product is available on all devices, and this inconsistency could be confusing for the user. Sometimes ad plays, sometimes not.
We’d like feature parity, where we can choose wether to play or skip ad breaks when necessary, on any platform.
2 Likes
Hi @mart.zonneveld
Firstly, welcome to Bitmovin Community! Appreciate your contributions!
Secondly, thanks for your feature request and also for the level of detail you’ve provided, it’s much appreciated. I have noted this for consideration on our roadmap, so I will come back to this thread when we make moves forward here.
Many thnaks,
Jacob
Hi @mart.zonneveld,
While the Android SDK doesn’t have a direct equivalent of Web’s shouldPlaySkippedAdBreaks, the Android player allows any ad break to be skipped using playerConfig.advertisingConfig.shouldPlayAdBreak: (AdBreak) -> Boolean.
Let us know if this API isn’t enough to fit your needs.
Thanks,
Kevin
Hi @kevin.rocard ,
To my knowledge the .shouldPlayAdBreak callback will fire only after the SDK already made the network request to check if the ads are served and can be fired. The strategy on web .shouldPlaySkippedAdBreaks tells us which breaks were already skipped, and if we want to retroactively try to play them. Only after this return the SDK will make the network request to check if the ads are served and playable.
Our goal is to prevent the network calls to be fired when we eventually are going to skip them.
Hope this info helps.
Kind regards,
This is correct, shouldPlayAdBreak is called just before the ad break would play. Any VMAP and VAST manifest network request has indeed already been done.
As the Player resolve VMAP and VAST urls before the ads starts, a network request doesn’t necessarily imply that the ad will be played as the user could seek back, close the app or seek to the next item in the playlist.
We recommend to use VAST tracking events to track the playback state of your ads.
Player only resolves main VMAP with ad break positions, but doesn’t check all ad breaks individually on stream start, correct? So it should be technically possible to give the client apps control on wether to resolve them or not.
Could you elaborate the use of VAST and how it could help us?
The recommended way to track ad events is to use VAST tracking events. They are URLs in the VAST manifest that are called by the player when it reaches the corresponding ad playback state.
For example, to call an URL on ad start:
<Tracking event="start" ><![CDATA[https://example.com/tracking/start]]></Tracking>
Find the full documentation in the vast specification, section 3.14 Tracking Event Elements, and a complete example here.
You can also chose to use the impression tag, which will be called for each ad of the ad break (3.4.4 Impression).
The other alternative is for your app to manually schedule ad breaks using player.scheduleAd, which allows complete control as to which ad break is played when.
Player only resolves main VMAP with ad break positions, but doesn’t check all ad breaks individually on stream start, correct? So it should be technically possible to give the client apps control on wether to resolve them or not.
When using the Google IMA SDK, it will handle loading VMAP manifests. The Player cannot control its network requests. As for VAST, while it is technically possible to allow skipping them before they are resolved, it is currently not implemented.
We have noted this feature request and will come back to you when it is implemented. Nevertheless we strongly recommend using Vast tracking events or player.scheduleAd instead.
@mart.zonneveld
Does the suggestions solve your issue? If not, could you please clarify the impact of fetching VAST manifest before shouldPlayAdBreak is called, potentially discarding them?
Is fetching a VAST manifest without playing a significant cost in your infrastructure?
Thanks
Hi @kevin.rocard ,
Sorry for a somewhat longer period of silence. We’ve discussed the issue internally. The Admanager we use is smartx Ad server, which is quite a big competitor in the market. They create all reporting for us according to their and industry standards. For the reports regarding our issue they use the requests to the VAST files to calculate fail rate, not only the tracking URLs from the VAST manifest itself. Our ads also get sold whenever the VAST gets requested, so whenever this happens and they won’t get shown, it impacts our business.
Painting above picture, together with the info that the Web SDK already does the thing we want, we really would like Bitmovin to see the viability and priority of this feature parity.
We’re always open for a call when necessary.
Thanks
Hi Mart,
Thank you for this detailed explanation. This greatly helps us to understand the issue and prioritize it.
The Bitmovin Player uses Google’s IMA SDK to schedule VMAP ads. It currently resolves VAST urls automatically. We will investigate if it allows skiping an ad break without resolving it’s VAST manifest first.
We will decide internally the best course of action and come back to you when we move forward.
Gracefully,
Kevin Rocard