In the coming weeks, we will be deprecating all ACTIVE_VIEW_NOT* report columns in v201405, v201403, v201311 and v201306 of the DFP API. These columns are no longer supported in the DFP query tool, and the DFP API is following suit. The following columns will be affected:






Normally all features are supported until the API version is sunset. This deprecation is a rare case where these report metrics are being disabled for existing versions due to product changes related to viewability. If you are using v201408 or later, you will not be affected by this deprecation. If you are currently using these columns in v201405 or earlier, you can replace them with their logical opposites. Alternatively, to retain the same metrics, you can calculate them from the logical opposite and the rate. For example, Column.TOTAL_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS is equivalent to

Deprecation errors
If you do not migrate, your reports will return the following error:


If you have any questions or migration troubles, please reach out to us on our developer forum.

If you programmatically manage and report on DoubleClick Campaign Manager (DCM) campaigns, you know that trafficking and reporting tasks have traditionally been handled by separate APIs. We realize that this can be inconvenient so today we're introducing a unified solution: the DCM/DFA Reporting and Trafficking API!

This release constitutes a new major version (v2.0) of what was previously known as the DFA Reporting API, adding functionality previously only available in our dedicated trafficking API. While older versions of our dedicated reporting and trafficking APIs will continue to remain available until September 30th, 2015, we recommend that you adopt this updated version as early as possible to take advantage of all of its new and enhanced features.

Unified trafficking and reporting experience

This release combines the trafficking functionality of the DFA API with the reporting functionality of the DFA Reporting API to create a simplified end-to-end experience. It's now possible to manage your DCM campaigns and report on their performance without switching APIs or reauthenticating. In addition, a unified object model allows you to pass data seamlessly between these two systems.

New trafficking functionality

This API expands the feature set of the DFA API to add new and improved trafficking functionality. A few highlights of this expanded functionality include:
Updated project quota limits

In addition to increasing the functionality of the API, we've also increased the default project quota limit. All projects can now make 50,000 requests/day (up from 10,000), to support a combined trafficking and reporting workflow. As always, requests for additional quota can be made via the Google Developers Console, should the need arise.

Learn more

This API is built on the same RESTful, standards-based technology stack previously employed by the DFA Reporting API. This means that you have access to all sorts of useful tools for trying it out, such as the APIs explorer (which is also built into the documentation for each method) and our generic, cross-API client libraries. The getting started guide is also a great reference for users who are just starting out.

Give it a try and let us know if you have any questions!

We are introducing Builders as the standard way to create entities in AdWords scripts. You can use Builders in either synchronous or asynchronous mode. You can also check whether the operation was successful or not, and take appropriate actions depending on the operation’s outcome. The following code snippet shows how to create a keyword using builders.

// Retrieve your ad group.
var adGroup = AdWordsApp.adGroups().get().next();

// Create a keyword operation.
var keywordOperation = adGroup.newKeywordBuilder().

// Optional: examine the outcome. The call to isSuccessful()
// will block until the operation completes.
if (keywordOperation.isSuccessful()) {
   // Get the result.
   var keyword = keywordOperation.getResult();
} else {
   // Handle the errors.
   var errors = keywordOperation.getErrors();
The current release adds builder support for ads and keywords. The existing builders for ad groups and Ad Extensions - phone number, site links and mobile apps have also been standardized. The addSitelink, addPhoneNumber, and addMobileApp methods of AdGroup and Campaign classes will now return the resulting operation.

We are also deprecating the following creation methods. These methods will work fine for now, but they will be sunset in the future. You can learn more about this new feature on our guide. If you have questions or feedback about this feature, let us know on our forum.


Today we’re announcing the release of v6.5 of the Google Mobile Ads SDK! It’s listed as Google Play services 6.5 (Rev. 22) in the Android SDK manager, and is available for download right now. Those of you using Android Studio should download Google Repository (Rev. 14) to get the latest Gradle artifacts.

Under the hood improvements (greater stability, more efficient use of resources) make up most of the changes, but we’re pleased to note that this will be the first version of the SDK to support a split jar architecture. Previously, the SDK was compiled as a single, all-encompassing JAR file. Beginning with this release, however, it’s also built into separate JARs, each covering a specific domain of functionality. Interactive Media Ads (IMA) and Mobile Ads developers can now reference part of the Play Services SDK without needing to import the whole thing. This in turn reduces the APK size and memory footprint of your applications.

Taking advantage of the new architecture is easy -- you just need to change how you’re incorporating the SDK in your build process. Here’s an excerpt from a typical build.gradle file for an app that uses the SDK to display mobile ads:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile ''

And here’s one that targets the ads library specifically, new in v6.5:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile ''

That’s it! Gradle will now incorporate the new, smaller JAR into your application. If your app consumes other services from the SDK, simply add the relevant JARs (play-services-games or play-services-location, for example) to your build file as well.

IMA developers can make this change now. If you’re a Mobile Ads developer, one important thing to note is that the new split jar architecture currently works only with projects that configure banner ads in Java code, and not in XML. We plan to support XML configurations in the future, but for now if you’re defining and configuring your AdViews in an XML layout file, you should continue to reference Play Services in the existing manner.

You can read the Google Play Services Announcement on the Android Developers Blog for a summary of what’s new with this release. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.


A lot of our DFP API developers have been asking recently about how to filter report data by custom targeting key ID. Currently the DFP API allows you to filter report data by custom targeting value ID only. Until we have official support for filtering by custom targeting key ID in reports, you can use the CustomTargetingService and the ReportService together to achieve this goal.

Step 1: Use CustomTargetingService to get your keys and values

You will first need to use getCustomTargetingValuesByStatement and filter by the custom targeting keys you’re interested in to obtain all the corresponding values. For example:

    WHERE customTargetingKeyId IN (17, 18, 19)

If you have a lot of keys and values in your network, a better approach is to store these in a local database and do nightly syncs. Use getCustomTargetingKeysByStatement to obtain all the keys in your network, and then iterate through them, calling getCustomTargetingValuesByStatement for each key to obtain their values. Our client libraries all have examples of this. For instance, the Java example can be found in our ads Java client library GitHub repository. This way, you can look up the values associated with a custom targeting key more quickly and not do an additional API call.

Step 2: Use the values in a report query

Once you have the values for the custom targeting key you’re interested in, you can then use the ReportQuery.statement with the PQL IN clause to filter on the CUSTOM_TARGETING_VALUE_ID dimension. For example, say you were interested in filtering on custom targeting key ID of 7777. You look up the values of 7777 in Step 1, which gives you three value IDs: 3211, 88990, 123456. You can then use the IDs to effectively filter your report data by custom targeting key ID 7777.

    WHERE CUSTOM_TARGETING_VALUE_ID IN (3211, 88990, 123456)

However, please be aware that if you have a lot of custom targeting value IDs to filter on, you should batch them by querying for no more than 500 IDs at a time in the PQL IN clause. For example, you will run your report filtering on the first 500 IDs you’ve collected and save that report. Then you will run the same report on the next page of 500 IDs you’ve collected and so on until you have no more IDs. You can then combine the reports locally so that you have all the data for those custom targeting IDs.

If you have any questions about this, feel free to drop us a line on the DFP API forums or Ads Developer Google+ page.


Last week we released beta 10 of the IMA SDK for iOS. This release comes with a few new features including the following:

  • Ad rendering via the new WKWebView in iOS 8
  • Addition of calling classes in delegate methods
  • New TAPPED event for tracking user taps on the ad container

The most important thing to know about this release is that you will now need to include the WebKit framework as an optional framework in your implementation and build for 64-bit support. If you are a Cocoapods user, this will be done for you in the generated xcworkspace when you upgrade to beta 10 via pod install.

Ad rendering via the new WKWebView in iOS 8

We’ve moved ad rendering from UIWebView to the new WKWebView in iOS 8 implementations. This should fix a number of issues we saw with the old web view in iOS 8, including skip button unresponsiveness and delayed tracking event firings. As a side effect of this change, you’ll need to include the WebView framework as an optional framework in your project and build for 64-bit support. If you’re a Cocoapods user, this will be done for you when you run pod install to get the latest version of the SDK.

Addition of calling classes in delegate methods

After the beta 9 release, we noticed that a few of our delegate methods were missing a reference to their calling class, which put them out of line with iOS standards. We’ve resolved this issue in beta 10 and marked the old methods (without a reference to the calling class) as deprecated. You can see a list of the new methods in our release notes.

New TAPPED event for tracking user taps on the ad container

Since launch, one of our most requested features has been to add the ability to respond to user taps on the ad container while an ad is playing. We’re happy to announce that Beta 10 fulfills this request by adding kIMAAdEvent_TAPPED to the list of AdsManager events. You can start listening to this event by setting up your AdsManager delegate as follows:

  - (void)adsManager:(IMAAdsManager *)adsManager
      didReceiveAdEvent:(IMAAdEvent *)event {
    if (event.type == kIMAAdEvent_TAPPED) {
      // Handle TAPPED event

This event will be fired any time a user taps on a non-clickable part of an ad (taps on the "Learn more" or "Skip" buttons will not result in a TAPPED event).

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

We’ve just released the Budget resource for the DoubleClick Ad Exchange Buyer REST API, which can be used to set a daily budget for your real-time bidding campaigns. Each PretargetingConfig will have an associated Budget that it is mapped to via the billingId. Once a PretargetingConfig meets or exceeds the budgetAmount set by its Budget, it will no longer receive bid requests for the remainder of the day. Additional information about this resource can be found in the guide.

The Budget resource in the REST API and the BudgetService in the SOAP API can be used interchangeably; however, we recommend that you use the REST API for managing the budgets of your real-time bidding campaigns.

If you have any questions or comments about the Budget resource, please contact us via the forum or our Ads Developer G+ page.

We’re excited to announce the integration of AdWords scripts with even more Google services, dubbed “Advanced APIs”, allowing you to make use of these Google services directly from your scripts. The current release allows you to connect with:
  • Google Analytics: Update your account based on your website’s performance.
  • Youtube Analytics: Update your account based on your videos’ performances.
  • YouTube: Use YouTube trends or other channels stats to update your account.
  • Big Query : Manage, upload and query big data sets to better optimize your account.
  • Fusion Tables: Store, share and query your data information.
  • Calendar: Set campaign check reminders, enable/pause ads based on events.
  • Task: Manage and read from your Gmail tasks to optimize your account.
  • Prediction: Create, train, and query prediction models on your campaign’s performance data as well as external data sets.
To learn more about advanced APIs, refer to our code snippets and guide.

We encourage you to give this new feature a try and tell us what solutions you would like to have or other API you would like us to add.

As usual please let us know your feedback on the forum - bug reports and suggestions to improve the API usability are most welcome.

We're excited to announce that you can now create and manage rule-based user lists using the AdWords API starting with v201409. With just one account-wide remarketing tag you can now create different user lists. This has been a frequently requested feature from the AdWords API developer community.

What is a rule-based user list?
A rule-based user list lets you target users based on rules triggered by your account-wide remarketing tag, such as pages viewed on your site or the dates on which your site was visited. The rules in a list can be combined into logical AND/OR expressions, allowing you to fully express the exact audience you want to target.

Once your rule-based user list is in place and you've added the corresponding tag to your site, you can target users in the list and even modify your bids for those users.

Where do I start?
To start integrating rule based lists into your application, take a look at the new Rule Based User List Guide, which will walk you through creating a list with some code examples.

Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

In response to your feedback, we are enhancing the MccApp.accounts() method. Starting December 3, 2014, the MccApp.accounts() method will return all accounts (e.g. Express, Video, etc.) that you see when logging in to your MCC account through the AdWords UI instead of just the ordinary AdWords accounts.

Note that once this change is live, your MCC scripts may start getting more accounts when calling the MccApp.accounts() method. You should check your MCC scripts to ensure they can handle the possible extra accounts. You can restrict the accounts that AdWords scripts return by applying an appropriate filter condition in your account selector.

Note that this change doesn’t affect the way other selectors work. For example, you cannot retrieve an AdWords Express campaign by calling AdWordsApp.campaigns() on an AdWords Express account.

If you have questions or feedback about this change, let us know on our developer forum or our Google+ page.


Today we are releasing v201411 of the DFP API. This release supports creating and updating VideoRedirectCreatives, enhances cross-sell via the new SharedAdUnitService, and adds an experimental Targeting field to the Line_Item PQL table. There are also new Sales Manager enhancements, including derived custom criteria on proposal line items and PQL filtering for Product.lastModifiedDateTime. A detailed list of these and other changes can be found on our release notes page.

Creating VideoRedirectCreatives

You can now use the DFP API to create and update externally hosted and YouTube hosted VideoRedirectCreatives. Simply set the VideoRedirectAsset.redirectUrl to the YouTube or third party URL hosting your ad:


You will also need to set the VideoMetadata information for both externally hosted and YouTube hosted ads. For streaming videos, set the minimumBitRate and maximumBitRate; for progressive videos, use the static bitRate.

Custom targeting filter changes

In DFP API v201411 CustomTargetingService.getCustomTargetingKeysByStatement and CustomTargetingService.getCustomTargetingValuesByStatement will return INACTIVE keys and INACTIVE values, respectively. You can filter them by supplying a where clause in a PQL statement:

    WHERE status = 'ACTIVE'

LineItem status changes

To better match the UI, ComputedStatus.NEEDS_CREATIVES has been renamed to ComputedStatus.INACTIVE. Use LineItem.isMissingCreatives to determine if the line item needs creatives.

Cross selling features

If your network is connected to a cross selling host, you can manage your shared ad units with the SharedAdUnitService. To determine if an AdUnit is shared, use the new isSharedByDistributor and crossSellingDistributor fields. We've also added a skipCrossSellingRuleWarningChecks field to the LineItem object so you can override any cross selling warnings.

Experimental targeting PQL column

We've heard your feedback and are adding an experimental PQL column for line item targeting. Fair warning: experimental means we may make breaking changes as we get your feedback and make improvements. The targeting column will be returned with a Value.Type of "TargetingValue", and the value itself containing a Targeting object:


If you've been waiting for a faster way to retrieve line item targeting, try it out and let us know what you think. Head over to the API forum and tell us what works for you, and how we can improve.

We are pleased to announce that the Merchant Center API Dashboard will now also include errors from Content API for Shopping v2. The errors from Content API v1 and v2 are displayed separately, and you can choose either one from the dropdown menu at the upper-left of the Dashboard. Note that if you’ve been using v2 of the API, your dashboard by default will show the Content API v2 errors.

As a friendly reminder, if you haven’t migrated to the Content API for Shopping v2, please start migrating now; v1 will only be available until the end of February 2015. We also have a handy migration guide that can assist you in the process.

If you have any other questions or comments, please don’t hesitate to head over to the developers forum.


This is a reminder that starting from January 1, 2015, new releases of the ads PHP client library will only support PHP 5.3 or later versions. This will allow us to implement namespacing and autoloading, which aren’t available in PHP 5.2. Please see our original blog post announcement for more information. If you have any questions about this, feel free to drop us a line on the DFP API forums, AdWords API forums, or Ads Developer Google+ page.

Today we’re announcing the deprecation of v1 and v1.1 of the DoubleClick Ad Exchange Buyer REST API, both of which are scheduled to be sunset on December 1st, 2014. These versions are becoming increasingly less relevant as we expand on the latest and greatest version of the API—currently v1.3. We recommend that you migrate to v1.3 before this date in order to take advantage of the newest functionality and also to continue having uninterrupted access to the API. If you have not migrated from these deprecated versions by December 1st, calls against the API will return an error response.

The vast majority of users have already migrated to newer versions of the API, but if you’re among the few who haven’t, we expect it to be an easy upgrade because newer versions still support all of the resources you’re familiar with. The only changes that could cause a code break when migrating from v1 to v1.3 are in the Creatives resource; the adgroup_id field was removed and the disapprovalReasons field is no longer a list of strings. You can use the following resources to help you with your migration:
  • Release Notes: A listing of all changes between versions of the API.
  • Code Examples: Examples demonstrating how to use the client libraries with the most recent version of the API.
  • Developer Guides: Guides covering the most recent version of the API.
Of course, if you have any questions or need help with the migration, feel free to reach out to us via the forum or the Ads Developers G+ page.

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.


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

We have added the following new features in AdWords scripts.

Ad customizers
AdWords scripts now support ad customizers, a more advanced version of ad params. Ad customizers adapt your text ads to the full context of a search or the webpage someone's viewing, by inserting a customized parameter within the ad. Ad customizers let you customize your ads for each query without having to create a separate ad for each variation.

AdWords scripts allow you to create ad customizer sources, add or update items in the sources, and create parameterized ads. You can also target an ad customizer item to a specific campaign, ad group or keyword, and track the performance of ad customizers using the PLACEHOLDER_FEED_ITEM_REPORT.

To learn more about ad customizers, refer to our code snippets and guide. Also, check out the brand new ad customizers solution that shows how to use this new feature in your account.

v201409 reports
We now support AdWords API v201409 reports in AdWords scripts. See blog post for more details.

Product ads
You can now retrieve your product ads using the ads() method of the ShoppingAdGroup. You can create new product ads using the newAdBuilder() method of ShoppingAdGroup.

We hope you enjoy these new features. If you have any questions about these features or AdWords scripts in general, you can post them on the developer forum.

We are announcing support for AdWords API v201409 reports in AdWords scripts. The new version introduces PLACEHOLDER_REPORT, a new report type that allows for retrieval of extension stats.

If you use API versioning in your reports, then you need to modify your code to use v201409 as shown below. If you don’t use API versioning, no code changes are required.
var report =, {
   apiVersion: 'v201409'
If you have any questions about this feature or AdWords Scripts in general, you can post them on our developer forum.

Are you using the Google Ads API Java Client Library and Java 5 (1.5)? If so, we have important news: starting April 2015, all releases of the Google Ads API Java Client Library will only be compatible with Java 1.6 and higher.

Why this change is happening
The primary reasons for this change are: Next steps
If you are using Java 6 or higher, then you're all set -- all releases of the client library on github already support your runtime.

If you are still using Java 5 and need to migrate to Java 6 or higher, check out the following adoption guides from Oracle: Still have questions? Feel free to file an issue on the library's issues page or contact us via our Google+ page.


As an avid reader of this blog, you have undoubtedly already seen the announcement that our dear old friend, the client library known as ‘AdsPyGoogle,’ will be sunset on January 5, 2015. Yes—we too at Google are very sad about this.

Fret not! In its place, we have a more than capable replacement in the form of our new GoogleAds Python client library which is more lightweight, has far fewer dependencies, boasts improved utilities and functionality, and perhaps most importantly, supports Python 2.7 as well as 3.x.

If you need a starting point on how to perform this switch, we have a blog post detailing the differences between the two, as well as a nifty migration guide on Github.

As usual, if you have any questions, feedback, or comments, please don’t hesitate to reach out on the DFP or AdWords forums.

We recently updated the iOS and Android quick starts for IMA to make them more streamlined and informative. The new quick starts are done in the style of a code lab - we first provide a sample video player app with no ad integration, then walk you through the steps of adding the IMA SDK to the app. We also provide a completed example if you just want to follow along. If you haven’t yet tried the IMA SDKs for mobile, give our new quick starts a spin and let us know how you like them via our forum.

In Part I, Chris showed you how to create and traffic a video ad. In Part II, you’ll learn how to get that ad displayed before your video content in Flash, HTML5, iOS, or Android.

The IMA SDK requires you to have an ad tag that points to your ad. An ad tag is a URL that returns a VAST response. The VAST (or VMAP) response contains information about your ad, including tracking URLs, clickthrough destinations, and the media files for the video ad. For more information about VAST, see the IAB website.

If you’re using DFP, the UI can generate an ad tag for you based on your line item and ad unit criteria. To generate the ad tag for your line item, follow these steps.

Now that you have your ad tag, let’s take a look at some of the parameters. We’ll use one of our standard sample tags for this exercise:

The size of the video ad that you’re requesting.
Your “inventory unit” - the ad unit you created in Part I. This is in the format <network_code>/<ad_unit_code path>.
If your ad unit has associated companion ads, their sizes will be listed here.
The request mode. Here, “s” for “sync”.
The environment. Here, “vp” for “video player”. 
Indicates that this is a DFP request rather than the legacy Google Ads Manager.
The type of output you want from your ad request. Typical values are “vast” or “vmap”.
Enables delayed impressions for your ad. This ensures that an impression isn’t counted until the ad starts playing.
The URL of the page requesting ads. This will also be automatically filled in by the SDK.
This randomly-generated value will be filled in by the SDK. It’s used for a number of things, but they all boil down to detecting ad requests that come from the same instance of a page load.
Like the correlator, but refreshed when your video stream changes rather than when the page refreshes. Used to detect ad requests that come from the same video stream instance.
For more info on these parameters, see this DFP help center article.

Now that you have a basic understanding of your ad tag, it’s time to plug it into your IMA SDK implementation. If you’d like to use a video player with the SDK pre-integrated, we have pre-baked solutions for HTML5, iOS, and Android. If you want to do your own SDK integration, check out the quick start guide for Flash, HTML5, iOS, or Android. In each of the sample implementations, you’ll find a reference to at least one ad tag.

For example, the HTML5 ad tag reference is in ads.js and looks like this:
adsRequest.adTagUrl = “YOUR_AD_TAG_HERE”;
Now fire up the sample and request an ad. Voila! You’ll now see the ad you trafficked in Part I serving as a pre-roll to your video content!

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


Update: This integration is specifically for the Cocos2d-x branch developed by Chukong Technologies.

With more than $1 billion paid to app developers in the last two years, AdMob is committed to supporting industry growth. So we are happy to announce that Cocos2d-x developers can now easily monetize their games with AdMob!

AdMob has integrated with the AnySDK platform, which means Cocos2d-x developers who use the AnySDK Ads System can now easily include AdMob when publishing their Android and iOS apps. If you haven’t checked out Cocos2d-x before, you can learn more here.

Getting started with the AnySDK Framework and AdMob

  1. If your app isn’t already integrated with AnySDK, download the AnySDK Framework.
  2. Follow the getting started guide to import the framework.
  3. Update your app to integrate the AnySDK Ads System. AdMob supports the AD_TYPE_BANNER and AD_TYPE_FULLSCREEN ad types. The games guide discusses the calls that are relevant for AdMob.
  4. Use the AnySDK package tool so specify AdMob as your desired ad system.

AnySDK package tool

Once you’ve configured your app for ads, the AnySDK package tool is where the magic happens. In the SDK Management section of your app configuration, specify AdMob as your ad provider.

In the Parameter Config section, configure your ad unit IDs for banners and/or interstitials, as well as the size and position for banner ads.

When you reach the Publishing section, simply Browse for your app and select Start.

That’s it! This step will generate the new version of your app with AdMob included!

Where to get help

For help integrating AnySDK into your apps, consult the contact link on AnySDK’s homepage.

We’d also love to get your feedback! Please let us know your experience integrating AdMob into your Cocos2d-x apps on our developer forum.

We'd like to remind you that the AdWords API v201402 was deprecated on July 9th and will be sunset on November 6th, 2014. With the sunset deadline only a few weeks away, if you haven't already migrated to v201406 or v201409, please do so as soon as possible.

As with each sunset, we have the following resources available for you:
If you have any questions or need help with the migration, please post on the forum or the Ads Developers Plus Page.


Your DFP network is already serving thousands of image, text, and custom ads. But now you want to start monetizing your video content. This two-part blog post will get you started with video ads. We'll start with creating and trafficking your ad using the DFP API, and then show you how to display it using the IMA SDK.

Before you start

If you're new to video ads, check out this help center article for a little more background. This post shows how to use a VAST redirect creative, so you'll need to host a VAST tag and your video ad before making the creative in DFP. If you just want an example VAST tag to get up and running, you can use the XML here.

Note that this example tag will only return VAST for the first request. Subsequent requests will need to update the correlator timestamp in the URL. The IMA SDK will handle this for you, so there's no problem using this as your example URL.

Creating the video ad unit

If your network doesn't have a video ad unit already, you'll need to create one. Set the fields as you would for any other ad unit, but use a size appropriate for video and the VIDEO_PLAYER environment type.

    Size videoSize = new Size();

    AdUnitSize videoAdUnitSize = new AdUnitSize();

Making a video creative

Beginning in v201403, you can create and update VAST redirect creatives with the DFP API. If video features are enabled on your network, creating VAST redirect creatives takes just a few lines of code. Let's start by setting some standard creative fields:

    VastRedirectCreative vastRedirectCreative = new VastRedirectCreative();
    vastRedirectCreative.setName("My first VAST redirect creative");

Now set the size of your video to match your AdUnit:

    Size size = new Size();

Finally, you need to set your VAST XML. For this example, we'll use VAST XML with a linear advertisement. Linear video ads are analogous to television commercials and can play before, after, or in the middle of your content.

    Creative[] creatives =  creativeService.createCreatives(new Creative[] { 
    Creative masterCreative = creatives[0];

This is your master creative. When working with video, DFP uses CreativeSets which have master and companion creatives. Companion creatives are typically displayed alongside the content video, and tie in with the video ad. The line items you create for video will be associated with a creative set, so you need to create one using your VAST redirect creative as the master. For simplicity, we won't use any companions here.

    CreativeSet creativeSet = new CreativeSet();
    creativeSet.setName("My VAST Redirect Creative Set");
    creativeSet.setCompanionCreativeIds(new long[] {});
    CreativeSet createdCreativeSet =

Creating a video line item

Now we need a line item to serve the video creative set. We'll just highlight the differences for video line items here, so if you aren't familiar with creating line items, check out our complete example on GitHub.

In addition to the usual line item fields, you have the option to set position targeting. Using VideoPositionType.PREROLL will target videos where ads can play before the content starts.

    VideoPosition videoPosition = new VideoPosition();
    VideoPositionTarget videoPositionTarget = new VideoPositionTarget();
    VideoPositionTargeting videoPositionTargeting = new VideoPositionTargeting();
        new VideoPositionTarget[] {videoPositionTarget});

Video line items can also target content in a variety of ways with ContentTargeting. If your network is connected to a content source you can use your content hierarchies to target a genre, season, or any other hierarchy you configured. If you're unsure of how to get the content metadata hierarchy key IDs, take a look at this example.

    // Create content targeting.
    ContentMetadataKeyHierarchyTargeting contentMetadataTargeting = 
        new ContentMetadataKeyHierarchyTargeting();
        new long[] {contentCustomTargetingValueId});
    ContentTargeting contentTargeting = new ContentTargeting();
        new ContentMetadataKeyHierarchyTargeting[] {contentMetadataTargeting});

Now add these to the line item's targeting object. Don't forget to set the environment type to VIDEO_PLAYER.

    Targeting targeting = new Targeting();
    // Target your video AdUnit
    LineItem lineItem = new LineItem();

Make sure to set all the required fields as you would for any other line item, and then create it.

Wrapping things up

Let’s do a quick recap. We now have an AdUnit for a standard video size, our VastRedirectCreative of a matching size in a CreativeSet, and our video LineItem targeted the AdUnit. If your network has a content source connected, you may have targeted certain content as well.

The last step is to create a LineItemCreativeAssociation to connect the CreativeSet with the LineItem.

    LineItemCreativeAssociation lica = new LineItemCreativeAssociation();
    LineItemCreativeAssociation[] licas =
            new LineItemCreativeAssociation[] {lica});

Finally, your video ad is ready to serve. The next question is, how do you actually serve it? Stay tuned for the exciting conclusion: Life of a Video Line Item Part II.

We have made the following improvements to labels in AdWords scripts based on your feedback:
  • You can now create and remove account labels using AdWords scripts. You can also apply or remove labels on child accounts under an MCC account.
  • You can now retrieve IDs for labels within an AdWords account. This feature comes in handy when you want to limit report results to entities with specific labels, since labels are filtered by label ID. You can see a code snippet here.
We have added new code snippets and updated our labels guide to explain these new features in more detail. If you have questions or feedback about these changes, let us know on our developer forum or our Google+ page.

Today we're announcing Beta 9 of the IMA Android SDK. This release includes important new API changes to support upcoming alternate IMA SDK ad playback. These changes will prevent your app from compiling so you'll need to make a few code updates using the following guide.

Required Changes

  1. Pause and resume ads with AdsManager

    Previously, the SDK did not provide a method to pause/resume the current ad. Beta 9 of the SDK introduces AdsManager.pause() and AdsManager.resume() to control these events. You should no longer directly control the pause/play/resume of ads via your video player. Instead, use the AdsManager methods. In the future, the IMA SDK may play ads with a video player other than your content video player, so utilizing the AdsManager methods now will ensure that ad pause and resume calls are called on the appropriate player.

  2. Change getProgress() to getAdProgress()

    The VideoAdPlayer.getProgress() signature has changed; it now explicitly states it's returning the progress of the current ad:

        VideoProgressUpdate getAdProgress()

    When implementing this method, return VideoProgressUpdate.VIDEO_TIME_NOT_READY if an ad is not playing (for example, if content is playing). Here's a sample getAdProgress method:

    public VideoProgressUpdate getAdProgress() {
      if (currentVideoIsAd() && currentVideo.getDuration() > 0) {
        return new VideoProgressUpdate(
            video.getCurrentPosition(), video.getDuration())
      } else {
        return VideoProgressUpdate.VIDEO_TIME_NOT_READY;

  3. Return content progress with ContentProgressProvider

    For the SDK to automatically schedule ad breaks when ad rules (for DFP) or VMAP playlists are returned in an ad tag, your player should provide the playback progress of your content video. The ContentProgressProvider interface has been introduced to allow the SDK to check on actively playing content. Pass an implementation of ContentProgressProvider to your AdsRequest object via:


    This method should return VideoProgressUpdate.VIDEO_TIME_NOT_READY if content is not playing (for example, if an ad is playing). Here's a sample ContentProgressProvider implementation:

    public VideoProgressUpdate getContentProgress() {
      if (currentVideoIsContent() && currentVideo.getDuration() > 0) {
        return new VideoProgressUpdate( 
            video.getCurrentPosition(), video.getDuration());
      } else {
        return VideoProgressUpdate.VIDEO_TIME_NOT_READY;

Why should I update to Beta 9?

In addition to bug fixes, Beta 9 of the SDK introduces important changes to clarify some API intentions and to, in a later release, allow the SDK to use an SDK-managed video player to play ads when it would improve the ad viewing experience for certain environments and ad types.

Beta 9 is an optional upgrade; new SDK integrations should use Beta 9 (check out our quick start guide), but your existing apps can upgrade at your discretion. The API changes introduced in Beta 9 will carry over to later IMA Android SDK releases, so if you wish to minimize code changes when the next version of the IMA Android SDK is released, you can make these app code changes now.

Other changes in Beta 9

Download IMA Android SDK Beta 9

You can get this latest release of the IMA Android SDK from our IMA SDK downloads page.

Other questions?

As always, feel free to drop us a line on the IMA SDK forum and follow our Google+ page for other announcements and updates.

This week we released Beta 8 of the IMA SDK for iOS (not to be confused with support for iOS 8 -that was added in the previous release, Beta 7). This release adds a new object, IMAUIElements, which allows you to customize which parts of the ad UI are shown while an ad is playing. Currently, this customization is limited to the countdown timer and ad attribution. By default, all available UI elements will be displayed by the SDK. We anticipate another iOS SDK release shortly; unless you plan on taking advantage of this new functionality immediately, we recommend hold off on upgrading until we release Beta 9 in the coming weeks.

To configure the ad UI, modify the members of the uiElements property on the adsRenderingSettings like so:

- (void)adsLoader:(IMAAdsLoader *)loader 
    adsLoadedWithData:(IMAAdsLoadedData *)adsLoadedData {
  self.adsManager = adsLoadedData.adsManager;
  // …
  self.adsRenderingSettings = [[IMAAdsRenderingSettings alloc] init];
  // Show no attribution or countdown timer.
  self.adsRenderingSettings.uiElements = @[];
  // Or, show only ad attribution.
  self.adsRenderingSettings.uiElements = @[kIMAUiElements_AD_ATTRIBUTION];
  // Or, show both countdown timer and ad attribution.
  self.adsRenderingSettings.uiElements =
      @[kIMAUiElements_AD_ATTRIBUTION, kIMAUiElements_COUNTDOWN];
  // ...
  [self.adsManager initializeWithContentPlayhead:self.contentPlayhead

This configuration will not always be honored; some ad formats (e.g. AdSense and YouTube-hosted ads) require that certain UI elements be displayed. Also note that displaying the countdown timer requires ad attribution - if you want to display a countdown timer, you must also display ad attribution. You can check which UI elements are being displayed by using the uiElements property of the IMAAd object tied to the STARTED event.

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


This is a friendly reminder that, on February 27, 2015, we will sunset DFP API versions v201311, v201308, and v201306. At that point, requests to these versions will fail. We'll also remove them from our online documentation and the client libraries. If you are currently using one of these versions, this is an excellent time to begin migrating to a supported version. See the release notes for a list of the many new features in our recent API versions.

Going forward, all DFP API versions will follow a consistent deprecation schedule: versions will be supported for one year, deprecated for one quarter, then sunset. This means each of our quarterly API versions will be available for 15 months from the time of release. This deprecation schedule enables us to spend more time improving the latest versions with new features.

Note that v201311 is the last version that supports ClientLogin, which was officially deprecated across all of Google on April 20, 2012. If your application is not yet using OAuth2, you must migrate before Feb 27, 2015.

If this task seems daunting, don't fret, we have you covered. On our Developer page, we have a helpful OAuth2 guide to make sure the transition is as smooth as possible. As an added reason to switch, the DFP API now supports OAuth2 service accounts. You can add service account users directly in the DFP UI. For more information, see here for a guide on how to use a service account user with the DFP API.

If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum.

Do you save your AdWords API reports to a database? Do you have code that detects and skips header and summary rows? If the answer to these questions is "why yes, I do!", then you'll be happy to hear that in AdWords API v201409 you can modify your report requests so that the returned results will not include these rows.

Excluding the report header

Prior to v201409, the output of each AdWords report included a header that gave the name of the report and the date range in your predicates:

"KEYWORDS_PERFORMANCE_REPORT (Sep 21, 2014-Sep 27, 2014)"

If you do not want this row in your report results, include the new skipReportHeader HTTP header with a value of true.

Excluding the report summary

Similar to the header, each AdWords report for versions prior to v201409 returned a summary row with totals in its final row of output:

Total, --, --,44700

If you don't want this row in your report results, include the new skipReportSummary HTTP header with a value of true.

Note: If you do not include these headers or specify a value of false for both headers, your report results will include the header and summary rows, just as they did for prior versions of the AdWords API.

For more details, check out our updated Reporting Basics guide. Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.