Let app be in control wether to skip ads or not - feature parity

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.