Pause Ads

How to implement Pause Ads using the BannersIn2 out-of-band trigger mechanism

Pause Ads are non-linear ads displayed when a user pauses the stream. They are powered by the BannersIn2 out-of-band trigger mechanism: unlike in-band non-linear ads — which are inserted as a result of signals in the stream or the ad server response — Pause Ads are initiated from the client side and have no fixed duration.

❗️

Version requirements

Pause Ads require SmartLib ≥ 06.00.04 and SIMID controller ≥ v0.7.0.

The open-source reference SIMID controller includes a Pause Ads demo on the demos/pause-ads branch (Web/CTV and Android).

📘

This page covers only the aspects specific to Pause Ads. It assumes familiarity with the standard BannersIn2 client-side integration described in Client-side Implementation, including SmartLib session setup, SIMID controller attachment, and the onPrepareAd / onAdBegin / onAdEnd event flow.

Requesting a Pause Ad

The pause ad workflow is triggered when the app detects that the user has sent a pause event to the player. A specific SmartLib API is used to initiate the out-of-band ad request:

session.requestOutOfBandAds("pause", 0, true, {})
ParameterTypeDescription
namestringMust be "pause".
durationnumberMust be 0 or left undefined — Pause Ads have no fixed duration.
autoBeginbooleanWhen true, SmartLib automatically triggers ad events (onPrepareAd, onAdBegin, etc.) as soon as ad data is available.
additionalQueryParamsobjectKey/value pairs sent to broadpeak.io in addition to the query parameters passed on the URL in session.getURL(). broadpeak.io remaps them onto the request to the ad server, as defined by the configured Ad Server source. See Ad Macros for details.

As soon as a suitable ad is received, the standard flow takes place: onPrepareAd, onAdBegin, etc.

Recommended delay

A grace period between the user pressing pause and the requestOutOfBandAds() call is recommended. This ensures accidental triggers don't waste ad impressions or degrade the user experience. A typical threshold is in the 3–5 second range.

The easiest approach is to have the application wait before making the requestOutOfBandAds() call. Alternatively, the call can be made immediately with autoBegin set to false, and the display delayed by calling beginOutOfBandAdBreak() — though this is less preferable, as the ad will already have been served from the ad server regardless.

Preparing and Displaying the Ad

Once ad data is available, the standard BannersIn2 event sequence applies. Loading the SIMID creative and displaying it follow the same logic as for in-band non-linear ads — see Client-side Implementation for full details.

A non-linear ad break always contains a single ad. The adData.adtype field will be "nonlinear".

When the SIMID controller has been correctly attached to the session, SmartLib automatically fires the impression and creativeView trackers. Alternatively, the application can instruct SmartLib to fire them explicitly:

session.sendTracker("impression", adData.adId);
session.sendTracker("creativeView", adData.adId);
💡

Visual transitions — such as a fade-in as the ad appears and a fade-out as it disappears — are the responsibility of the application, as the SIMID protocol does not support them. They are easily implemented with CSS transitions on the iframe, and equivalent techniques on web views in native apps.

Resuming Playback

Pause Ads have no duration of their own. The application must keep track of whether a pause ad break is active and its identifier, in order to end it at the right time.

There are two ways the ad can be dismissed and playback resumed:

Interaction with the creative

If the SIMID creative includes a button to resume playback, the creative sends SIMID:Creative:requestPlay to the SIMID controller. The application reacts by sending SIMID:Player:adStopped back to the creative (via the controller), then calls endOutOfBandAdBreak(adBreakId).

Interaction with the player

Alternatively, the user interacts with the application directly — such as by pressing the play button on a remote or a player control overlay — without interacting with the creative. The application calls endOutOfBandAdBreak(adBreakId).

In both cases, endOutOfBandAdBreak(adBreakId) triggers the standard end-of-ad flow (onAdEnd, onAdBreakEnd), which terminates the ad and resets the controller.

Dismiss without resuming

A SIMID creative may also offer a dismiss button that allows the user to close the ad without resuming playback. In this case, the creative sends SIMID:Creative:requestSkip to the SIMID controller, which triggers the mechanism for removing the ad.

Additional Control Options

  • If autoBegin is set to false, the ad break must be started explicitly with beginOutOfBandAdBreak(adBreakId).
  • The AdBreakData object contains an ooba field with the parameters originally sent to requestOutOfBandAds(), which can be used to identify the break type.
  • An additional onOufOfBandAdData(AdBreakData) event can be registered via session.setAdDataListener(). It fires as soon as ad data is returned by broadpeak.io — including if no ad was returned, in which case it contains an empty array.

Ad Rotation

Usually a single ad is shown for the duration of the pause. It is however possible to rotate between ads. The easiest mechanism is to call requestOutOfBandAds() periodically, and when successful, end the previous break with endOutOfBandAdBreak() and begin the new one with beginOutOfBandAdBreak(). The ad server should always return a single ad per request.

Combining with Other Ad Breaks

When content is monetised with other forms of advertising — such as linear or other non-linear in-band ads — you may want to avoid showing a Pause Ad if the user presses pause during another ad. It is the application's responsibility to determine whether and when to call requestOutOfBandAds() and/or beginOutOfBandAdBreak().

If using broadpeak.io's DAI solution (including BannersIn2) to insert in-band ads, you can rely on SmartLib's ad lifecycle events to track whether ads are currently being shown, and make the Pause Ad call conditional on that.

Platform Support

SIMID compatibility

PlatformSIMID supportBannersIn2 without SIMID
Web / Desktop✅ via iframe
Web / CTVs✅ via iframe
Android TV✅ via WebView
iOS✅ via WKWebView
Apple TV (tvOS)✅ JPEG/PNG fallback
Roku✅ JPEG/PNG fallback

Mobile: full-screen playback

On mobile devices, application developers must intercept any full-screen request before it reaches the native player. Native full-screen mode does not permit SIMID overlays to remain visible and interactive. Instead, the application should implement simulated full-screen: expanding a container element to fill the viewport, so that the SIMID creative stays within the same rendering context as the player.

Apple TV and Roku: native overlay fallback

tvOS and Roku do not allow WebViews to load HTML pages and are therefore not compatible with a SIMID-based solution. However, BannersIn2 provides a fallback: the raw image and parameters are exposed through AdData.nonLinearStaticResources, allowing the application to implement a native overlay and associated interactions.

📞

Contact your customer success representative if you need guidance implementing the native overlay fallback on Apple TV or Roku.