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 requirementsPause 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-adsbranch (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/onAdEndevent 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, {})| Parameter | Type | Description |
|---|---|---|
name | string | Must be "pause". |
duration | number | Must be 0 or left undefined — Pause Ads have no fixed duration. |
autoBegin | boolean | When true, SmartLib automatically triggers ad events (onPrepareAd, onAdBegin, etc.) as soon as ad data is available. |
additionalQueryParams | object | Key/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
autoBeginis set tofalse, the ad break must be started explicitly withbeginOutOfBandAdBreak(adBreakId). - The
AdBreakDataobject contains anoobafield with the parameters originally sent torequestOutOfBandAds(), which can be used to identify the break type. - An additional
onOufOfBandAdData(AdBreakData)event can be registered viasession.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
| Platform | SIMID support | BannersIn2 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.
