[go: nahoru, domu]

What do I need to do?
Please migrate any existing Flash display ads to HTML5 by January 2, 2017, when Flash ads will stop serving. In May 2016 we announced that you would no longer be able to upload Flash display ads in AdWords by June 30, 2016 with tips on how to migrate.

If you have video ads built in Flash, they will not be affected at this time. You do not need to migrate these ads.

Where can I learn more?
Questions? Visit us on the AdWords API Forum or our Google+ page.

TL;DR: Swiffy will stop converting SWF files from 1st July, 2016.

Recently, we announced that we're transitioning all of our display ads to HTML5. As part of this transition, we're sunsetting our Swiffy Flash conversion service and support for the Swiffy Flash extension on July 1st 2016. After this date, you will no longer be able to use either to convert SWF files to HTML5. We will continue to serve the Swiffy runtimes, so any file you convert before the sunset date will continue to play.

Today more consumers are using the web in HTML5-compatible environments than Flash-compatible environments. In order to reach as large an audience as possible, we encourage everyone to transition to HTML5 authoring.

Developers who currently create Flash SWF files have several ways to switch to HTML5, including Adobe Animate and Google Web Designer. If you need to play an existing Flash SWF file in your browser alone, you may be able to use Mozilla's Shumway.

What is changing?

Starting June 30, 2016, you will no longer be able to upload Flash display ads in AdWords. By January 2, 2017 existing Flash ads will no longer serve on the Google Display Network. In order for your ads to keep serving, you will need to migrate any existing Flash ads to HTML5. If you need help migrating, check out the Help Center Article on updating Flash ads to HTML5 ads.

If you have video ads built in Flash, they will not be affected at this time. You do not need to migrate these ads.

Where can I learn more? Questions? Visit us on the AdWords API Forum or our Google+ page.

Have you ever wished you could experiment with IMA HTML5 SDK features without having to download our samples, modify them for the feature, and host them on your own webserver? Now you can with our new Codepen snippets!

We’ve added codepen snippets to several HTML5 guides. These snippets allow you to modify and execute Javascript right in your browser. To test different aspects of a new feature, you can simply modify the Javascript and re-run the sample, without having to download the files or host them yourself. Codepen snippets are now available for the following guides:

For more information, check out the guides above. We’ll continue to add codepen snippets to new guides as they are released, so keep an eye out! As always, if you have any questions, feel free to contact us via the support forum.

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.

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.

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.

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.

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.

Today we're announcing support for Internet Explorer 11 in the IMA HTML5 SDK. The SDK is now compatible with the desktop versions of Chrome, Firefox, Safari, and Internet Explorer, as well as the mobile versions of Chrome, Safari, and the default Android browser. For more information on the supported platforms of the IMA SDK, check out the supported video player platforms.

Getting started There are no configuration or setting changes to the IMA HTML5 SDK to enable IE11 support. If you already have a player with the IMA HTML5 SDK integrated, you can start serving to IE11 visitors immediately.

If you want to walk through integrating the IMA HTML5 SDK with an HTML5 video player, check out our quick start guide.

Older Internet Explorer versions Currently only IE11 is supported; some publishers are using the IMA HTML5 SDK with IE10 without issues, but it isn't officially supported. SDK support will be focused on on IE11 and subsequent versions given the upgrade rate from IE10 to IE11. Version 9 and earlier of Internet Explorer are not supported by the IMA HTML5 SDK and likely will not correctly serve video ads.

Questions? If you have any questions about Internet Explorer support or other IMA SDK questions, feel free to contact us via the support forum.


We previously announced changes to the way the IMA HTML5 SDK handles custom playback and custom click tracking elements. Starting today, October 2, 2014, those behavior changes will be rolling out.

Custom playback changes
Effective today, custom playback will now be used only when necessary (e.g., on devices such as iPhones or pre-4.0 Android phones) rather than whenever a custom playback video element is passed in.

We recommend all implementations now pass in the custom playback element so that ads will be rendered via a more seamless playback experience across different environments. For more info on the change and code snippets to help you upgrade, see upgrading to the new custom playback.

Custom click tracking element changes
Custom click tracking elements will now only be used in certain video environments. To determine whether or not a custom click tracking element is being used, check ima.AdsManager.isCustomClickTrackingUsed in an AdEvent such as ima.AdEvent.STARTED. Additionally, please do not render your custom click tracking element over your video player as it will break the ad experience by preventing clickthroughs on the ad and skip button. For more information on the custom click tracking element changes, see "a note about custom click tracking elements" on our custom playback guide.

As always, if you have any questions about these changes or other IMA SDK questions, feel free to contact us via the support forum.

We're pleased to announce that the IMA HTML5 SDK now supports VPAID 2 JavaScript creatives. Enabling support is as easy as including the following line before initializing your AdDisplayContainer:

    google.ima.settings.setVpaidAllowed(true);
    ...
    var adDisplayContainer = new google.ima.AdDisplayContainer(adContainerElement);
    var adsLoader = new google.ima.AdsLoader(adDisplayContainer);

VPAID 2 Support caveats

There are two differences to be aware of between the VPAID 2 spec and the way the IMA SDK supports VPAID 2. These differences do not impact player or SDK implementation code, but they are important for VPAID 2 JavaScript creative authors, as creatives may throw errors or not work as expected when rendered by the IMA HTML5 SDK.

  • IFrame security: The IMA SDK uses a secure iframe instead of a friendly iframe (same domain) or an in-page script to render VPAID 2 JavaScript creatives. This means that if a creative expects to access the DOM of the parent page, it could potentially cause an error.

  • Video player proxy element: For security and proper mobile functionality, the IMA SDK doesn't provide the actual video element to the ad; instead, it provides a proxy element that mimics much of the functionality of the normal video element. For ad creatives that only access supported video APIs available on the proxy element, there should be no behavior changes in the rendering of the creatives. See our guide to VPAID 2 creatives for a list of supported APIs on the video proxy element.

Learn more

For more information, including a listing of what API methods are supported in the video player proxy element, check out our guide to VPAID 2 creatives.

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

We've made some changes to the HTML5 SDK's handling of custom playback. Currently if a custom video element is passed into the IMA HTML5 SDK, it’s always used to play video ads. This behavior is now changing; soon we’re going to use custom playback only when necessary (e.g., on devices such as iPhones or pre-4.0 Android phones where UI elements cannot be rendered over a video player) rather than whenever a video tag is passed in. We recommend all implementations now pass in the custom playback elements so that ads are supported in those environments. For more info on the change and code snippets to help you upgrade, see upgrading to the new custom playback.

Upcoming changes to custom click tracking element

The SDK's usage of the custom click tracking element is also changing. Currently, if a custom click tracking element is passed in to the SDK, it will always be wired to handle clicks. Soon, the custom click tracking element will only be used if the ad is a non-AdSense/AdX creative and the environment is iPhone or pre-4.0 Android. Please do not render your custom click tracking element over your video player as it may prevent clickthroughs after this change is put into place because it may intercept clicks on the SDK-rendered elements. We only recommend passing in a custom click tracking element if you are showing non-AdSense/AdX creatives and want a click tracking element in iPhone and pre-4.0 Android devices. See opt_clickTrackingElement under ima.AdDisplayContainer for more information.

What do you need to do now?
  1. Effective immediately, all implementation should pass in the custom playback element to ensure support of IMA video ads across all devices. Please read our guide on Upgrading to the new custom playback.
  2. If you are using a custom click tracking element:
    • Make sure it doesn't render over your video player.
    • In the ad STARTED event, show your custom tracking element if AdsManager.isCustomClickTrackingUsed() is true, and hide it otherwise.
    • In the ad COMPLETE event, hide your custom tracking element if appropriate.

How can I tell if the IMA SDK is using custom playback or custom click tracking?
Release 3.1.62 of the IMA HTML5 SDK introduces AdsManager.isCustomPlaybackUsed() and AdsManager.isCustomClickTrackingUsed() which you can use in your player to see if the SDK is currently using the passed in custom video player or custom click tracking element.

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

[Editor's note: repost from DoubleClick Advertiser Blog. --Stan Grinberg]

Your media plan is only as good as your creative message. Once you reach the right people, are you telling them something they actually want to hear?

- Pete Crofut, Creative Platforms Evangelist, Google


For the past six months, we’ve partnered with iMedia Connection on a series of articles that explore modern storytelling and the ways that new digital technologies are making ad creative more intelligent. We laid out the challenges advertisers face, examined engaging and data-infused creative examples, and discussed how to make these ads captivating across screens, measurable and scalable.

Today, we conclude this series with a final article, “Technology makes creative more intelligent”, which provides new creative examples and explains how the creative imperative fits into Google’s broader perspective on the "what,” "why" and "how" of modern brand building (entitled the Engagement Project.)

The tools and technology are available to help make your stories come to life online. Now’s the time to embrace the opportunity and think about your creative from a cross-screen, digital-first perspective, to craft messages that will engage people wherever they are.

We are pleased to announce the release of version 3 of the IMA HTML5 SDK. This latest release of the IMA HTML5 SDK allows greater flexibility in what kinds of ads you can use in your player and provides support for DFP Video:
  • Ad rules as described in the Help Center
  • Optimized Pods* - TV-style ad breaks consisting of multiple video ads which algorithmically chosen to optimize for line item priority, pacing goals, and revenue
  • Video Fallback* - Option to maximize your overall fill-rate across multiple third-party ad networks and redirects
  • Skippable Video Ads* - Video ads which may be skipped by the user after a minimum duration as configured in DFP
* These DFP Video features are currently in beta.

In addition, the IMA HTML5 SDK is compatible with desktop browsers, Chrome on Android and mobile Safari 5.0+ and has been streamlined to function very similarly to the IMA Flash SDK. Please review the API documentation for the IMA HTML5 SDK. For a detailed description of the features in this release organized by sub-release, refer to the v3 Release History.

Note: Integrating your video player with this latest version of the IMA HTML5 SDK does not require downloading any additional resources. Proceed directly to the integration instructions to begin.

Let us know on the forum if you have any questions about the new release. You can also follow us on our Google+ page for ads-related updates.