Tag Archives: ima_sdk

Register now for the March 2016 Display Ads API Workshops

We're pleased to announce that we’ll be holding a series of Display Ads API Workshops in March 2016. These workshops are a half-day of tech talks, group discussions, and office hours geared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.

These API workshops are a great way for you to meet with the display ads API team and ask questions in person. The workshops are also a great opportunity for members of the community to bring their feedback directly to us, and exchange ideas and best practices with fellow developers.

The workshops will be held in the following cities:

For more information on the workshops’ agenda and a preview of our talks, please see our workshop page.

As always, if you have any questions, feel free to drop us a line on the DFP API forums, IMA SDK forums, Mobile Ads SDK forums, or the Ads Developer Google+ page.

Important changes for gaming publishers using the IMA HTML5 SDK

In the coming weeks, we’ll be making changes to the way the IMA HTML5 SDK handles AdSense and Ad Exchange non-linear and full slot ads. To facilitate these changes, we’re adding a new API: AdsRequest.forceNonLinearFullSlot. Gaming publishers are required to set this parameter to true to ensure that all ads returned to your player are correctly rendered as full slot ads. This change is planned to go live the week of November 30th. Keep an eye on our release notes for the exact date as the change is released.

As always, if you have any questions, feel free to contact us via the support forum.

IMA HTML5 – changes to non-linear and full slot ads for AdSense and Ad Exchange

In the coming weeks, we’ll be making changes to the way the IMA HTML5 SDK handles AdSense and Ad Exchange non-linear and full slot ads. You should be aware of these changes to ensure that your video player behaves as expected once the changes have taken effect.

Definitions

A non-linear ad is a static or animated ad that displays over the video content during content playback. These are also sometimes referred to as “bottom-third” ads, because they typically take up the bottom third of the video player.

A non-linear ad.

A full slot ad is a static or animated ad that usually appears before or after the content, occupying the entire view area. It renders a close button that when clicked closes the ad and, if rendered before the content, triggers the content to start.

A full slot ad.

Current behavior

Currently, non-linear ads are rendered as expected, but full slot ads are also rendered as non-linear ads. So instead of pausing, the video continues to play underneath them while they take up a large portion of the video display.

New behavior

With the new behavior, any non-linear AdSense or Ad Exchange ad greater than 90 pixels in height will be rendered as a full slot ad. This means it will take up the entire video display. When the user clicks the close button, the content will start.

We will also be adding a new UI to these full slot ads which includes a countdown timer and a skip button. You should remove any custom UI elements you’ve added for full slot ads to ensure there are no conflicts with this new UI.

Lastly, to ensure that your ads are rendered properly, make sure your AdDisplayContainer is rendered on top of everything else and takes up the full size of your video player.

Full slot ad with the updated UI.

Testing the changes

If you’d like to test these changes, you can load the test version of our SDK by replacing your load of ima3.js with ima3_test.js. This is a watermarked test binary that changes frequently and without notice; it is not intended for use in production.

As always, if you have any questions, feel free to contact us via the support forum.

New ad UI and click behavior for IMA HTML5 SDK

Starting this week, we’re going to incrementally roll out a change in the way the IMA HTML5 SDK handles an ad’s UI.

We will be adding a Learn More button to Ad Exchange and AdSense ads on both desktop and mobile. Clicking on the button will take the user to the advertiser’s site, while clicking elsewhere on the ad will pause or resume it. This is a change from the existing behavior, where clicking anywhere on the ad opens the advertiser’s site.

The new ad UI.

This change will also be rolling out to all mobile web ads that do not use custom click tracking. Note that ads that have no UI before the change will gain a UI with this change. This will allow our mobile web behavior to be consistent with native mobile behavior.

If you have any questions about these changes, feel free to contact us via the support forum.

Manual Ad Break Playback Part Deux: Welcome Back!

Today we’re expanding on our earlier blog post, Manual ad break playback in the IMA SDKs. One of the major benefits mentioned in that blog post is the ability to let your users skip ads they’ve already seen when they resume a video stream they previously suspended. We’re going to show you how to implement that functionality. For the purposes of this demo, we’ll be using the HTML5 SDK, but the principles outlined here can be used to achieve the same functionality in all four of our SDK flavors.

Prerequisites

If you’d like to follow along with these samples, you’ll need to first:

  1. Get a copy of our simple sample for HTML5.
  2. Modify that sample to disable automatic playback of ad breaks, as outlined in this guide. Be sure to remove the original call to adsManager.start() in onAdsManagerLoaded!
  3. Change the ad tag to a playlist with multiple mid-rolls (like this one) so you can see the behavior in action.

Step 1: Saving the user’s progress

The first step towards our ultimate goal is to save the current time of the video when the user leaves the page. For simplicity’s sake, we’re going to be using HTML5’s built-in localStorage object. We’re going to override window.onbeforeunload to grab the current time of the video element when the user leaves the page and save it in local storage.


function init() {
videoContent = document.getElementById('contentElement');
playButton = document.getElementById('playButton');
playButton.addEventListener('click', requestAds);

window.onbeforeunload = onUserExit;
}

function onUserExit() {
if (videoContent) {
localStorage.setItem('watched_time', videoContent.currentTime);
}
}

Step 2: Restoring the user’s progress

Now that we’re saving the user’s progress, we’ll want to restore the video to that point when the user returns to the page. We’re going to add some code to the init method to grab the stored current time (if it exists) and seek to that time when our video loads.


function init() {
videoContent = document.getElementById('contentElement');
playButton = document.getElementById('playButton');
playButton.addEventListener('click', requestAds);

window.onbeforeunload = onUserExit;

watchedTime = localStorage.getItem('watched_time') || 0;
videoContent.addEventListener('loadedmetadata', function() {
videoContent.currentTime = watchedTime;
});

}

Step 3: Skipping previously viewed ads

Now that we’re keeping track of the user’s progress and restoring that progress when the user returns, we can skip and ad breaks they watched in a previous visit. To do that, we’ll modify our adBreakReadyHandler to call adsManager.start() only when the loaded ad break is set to play after the user’s most recent saved progress. To ensure the video starts after the skipped ad breaks, we’ll also add a call to videoContent.play() when we decide to skip an ad break.


function adBreakReadyHandler(event) {
if (event.getAdData().adBreakTime >= watchedTime ||
event.getAdData().adBreakTime == -1) { // -1 ensures we play post-rolls

adsManager.start();
} else {
videoContent.play();
}

}

That’s all there is to it! Try starting your video and watching the first mid-roll break. When you leave the page and come back, clicking the play button will result in the video playing from where you left off. The first ad break you’ll see is the second mid-roll break.

As always, if you have any questions feel free to contact us via the support forum.

IMA HTML5 SDK custom playback changes

On September 16th, 2015, the IMA HTML5 SDK will change how it handles custom playback. In order to provide a more seamless ad experience, custom playback on Android 4.0+ devices will be disabled.

As per a previous change, the SDK only selects custom playback when necessary. Since Android 4.0+ devices support standard rendering, it is no longer necessary to use custom playback on these devices.

What must I do to prepare for this change?

  1. Double check to make sure you’re always passing in your content video element as the custom playback element. Custom playback will still be used in pre-4.0 Android environments.
  2. On mobile, be sure you’re calling AdDisplayContainer.initialize() as a result of a user action. This method is not necessary in custom playback, but it must be called to play ads using standard rendering. Otherwise your ad video will not play. We recommend you always call this method on mobile, so your implementation will be ready for any future devices that support standard rendering.
  3. If your code requires a reference to the <video> element playing the ad, then this change might break your implementation. Instead, check the return value of AdsManager.isCustomPlaybackUsed(). If the value is true, the content video reference will be the same as the ad video reference.

If you have any questions about these changes, feel free to contact us via the support forum.

Manual ad break playback in the IMA SDKs

We recently launched manual ad break playback across our iOS, Android, HTML5, and Flash SDKs. For more info on what this means and how to use it, read on!

What is manual ad break playback?

Under a standard IMA SDK implementation, when an ad rules or VMAP response is returned, the SDK will automatically play each ad break at its cue point. With manual ad break playback, the SDK will instead fire an event when it’s time to play an ad break, and let you decide if or when you’d like to play it.

What are the implications of this change?

If you’re happy with your current ad rules or VMAP performance, this change doesn’t require you to do anything - your implementation will continue to work just as it does now. If you’d like more fine-tuned control over ad break playback timing, then we recommend using this feature.

What are the benefits of this change?

We see two major areas in which this change will help publishers. The first is when a user starts a stream somewhere in the middle of the content instead of at the beginning. (The most common scenario is that the user watched part of the video previously, left the app or page, and returned to continue watching the rest of the video). With a standard implementation, the user will be greeted by (in some cases) a pre-roll, followed by the most recent mid-roll that they watched previously, then the content. By using manual ad break playback you can prevent the pre- or mid-roll (or both) from playing so that the user can go straight to the content, and then resume mid-rolls when the user sees their first mid-roll break for the new session.

The second major use case is misaligned ad breaks. If you’re playing long form content with mid-rolls, and your video fades in and out for mid-roll breaks, you want to make sure that your ad breaks properly align with those fades. In some cases, publishers have told us that the ad break scheduling changes slightly between pieces of content, causing the ad to cut off content for some streams. With this new system, if you know exactly when an ad break should play, you can listen for the AD_BREAK_READY event and delay the ad break playback until the exact time your stream is ready for it.

How do I implement this new feature?

We have guides for each of the SDKs on implementing this new feature:

As always, if you have any questions feel free to contact us via the support forum.

What’s new with IMA iOS SDK Beta 15?

Last week, we released beta version 15 of the IMA SDK for iOS. This release includes two new features:

  • Ad buffer events via IMAAdsManager delegates
  • Debugging mode

Ad buffer events

We’re providing more information on ad buffering by introducing new buffering events via the following optional IMAAdsManagerDelegate methods:

  • adsManagerAdPlaybackReady:
  • adsManagerAdDidStartBuffering:
  • adsManager:adDidBufferToMediaTime:

Collectively, these delegate methods provide more transparency into buffer events, giving you more control over the user’s ad experience. For more detailed information on these new methods, take a look at the reference documentation.

Debugging mode

We’ve introduced a new debugging mode setting to allow for more verbose logging to the console. You can now set IMASettings.enableDebugMode to YES to enable debug mode. This should not be used in production, as it will show a watermark on the ad player.

A note about CocoaPods

If you’re using CocoaPods with the IMA SDK, please make sure to use at least version 0.38.

As always, if you have any questions, feel free to contact us via the support forum.

IMA HTML5 Rendering

The HTML5 SDK has two main ways to render ads: what we call “standard” rendering and “custom ad playback.” To avoid confusion and to keep you all informed, here’s a breakdown of those rendering modes and how the SDK decides which to use.

Standard Rendering

If you're using the HTML5 SDK you probably have a web page playing your content in a <video> element. In standard rendering, the SDK will create another <video> element and render it in the ad display container div you provided, which should be placed on top of your video player. The ads will then play in this SDK-owned video player on top of your content player. To the user, it looks like one video player switching from content to an ad, but in reality it’s another video player appearing on top of your content to play an ad and then disappearing. For a visual representation of what’s going on, see the image below.

Why use standard rendering?

The main benefit to this standard rendering involves buffering. Using a separate video player to render ads allows us to preserve your content buffer while ads are playing. If you’re playing a pre-roll, you can start loading your content when the ad starts and buffer the content the whole time the ad is playing. For mid-rolls, the separate player allows you to preserve your content buffer while ads are playing - if your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they won’t lose the content in the buffer for 00:05:00-00:10:00.

Custom Ad Playback

As avid blog readers will know, we recommend always passing in your content video element as the custom playback element. If you’re not already doing this, check out our guide to custom ad playback. The HTML5 SDK will intelligently use custom ad playback only when it deems necessary, as described below. When it’s not necessary, it will use standard ad playback.

What is custom ad playback?

When the SDK decides to use custom playback mode, it renders video ads in the same player as your content. This means you lose the buffer-related benefits of standard rendering. If your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they will lose the content in the buffer beyond the ad. Certain ad formats (such as AdSense) require an SDK-owned player and can't play in your content player.

Why use custom ad playback?

Simply put, some platforms do not support multiple, simultaneous, active video elements. On those platforms, the SDK can’t create its own ad player because the one allotted video player slot per page is already occupied by your content player. If the SDK tries to play an ad in a second video player, it will either fail to play (freezing the player) or make it impossible for the content to restart after the ad is finished (again freezing the player). Thus we must show the ad and video content in the same player.

How does the SDK know when to use custom ad playback?

The HTML5 SDK looks at the UserAgent string of each browser on which it’s loaded. When it sees a browser that it knows has trouble with multiple video elements, it uses custom ad playback. Currently those browsers are limited to Android and iPhone. We’re in the process of phasing out custom ad playback on Android 4.0+ to bring the benefits of standard playback to users.

Now you know all there is to know about HTML5 video ad rendering. As always, if you have any questions feel free to contact us via the support forum.

New Swift Samples for the IMA SDK

We’re excited to announce the addition of Swift samples to the IMA SDK! To view these samples check out our GitHub repo. Along with these new samples we’ve also added Swift snippets to our quick start guide.

As always, if you have any questions feel free to contact us via the support forum.