We previously announced on this blog about renaming Status enumeration values in reports for removed objects from DELETED to REMOVED. To keep the rest of the API consistent, we are also renaming the isDeleted method in Campaign and AdGroup objects to isRemoved. The isDeleted method is marked as deprecated, and will continue working until November 30, 2014. To ensure that your scripts continue to work properly, make sure you fix your scripts to use the new method before November 30, 2014.

If you have questions about this change, let us know on our forum. You can also provide feedback via the Google Ads Developers Google+ page.

Update: Corrected enumeration value in the post to "CALLS".

Starting the week of September 29, 2014, we’re changing the way we report mobile click-to-call data in AdWords API reports.

Currently, when you download a CAMPAIGN_PERFORMANCE_REPORT or ADGROUP_PERFORMANCE_REPORT with ClickType segmentation, mobile click-to-call data is reported as two separate click types:
  • A row with ClickType = CALLS contains all the stats related to clicks, like Clicks, Impressions, Cost, etc.
  • A row with ClickType = MOBILE_CALL_TRACKING contains all the corresponding stats related to phone calls, like NumOfflineInteractions, NumOfflineImpressions etc, OfflineInteractionCost, etc.
Based on your feedback, we will combine these two click types into a single click type starting the week of September 29, 2014. The combined data will now show up on a single row: ClickType = CALLS. As a result, you’ll no longer receive data for ClickType = MOBILE_CALL_TRACKING. This change will impact existing mobile click-to-call data, including historical performance.

If your applications use these report types to process mobile click-to-call data, make sure they account for this new data format. If you have questions or comments, let us know on our developer forum. You can also follow our Google+ page for updates about the AdWords API.

Today, we launch v201408 of the DFP API. This release features the addition of a new table to the Publisher Query Language service, some changes to the LineItem.Goal object, a multitude of enhancements to our Sales Manager services, as well as changes to our server endpoint and scope URLs. A detailed list of these features and what’s changed can be found on our release notes page.

New Endpoint URL

Version v201408 of the DFP API changes the endpoint URL for requests from to For example:
All of our DFP API client libraries have been updated to reference this URL starting with the v201408 release. If you are using a supported version of the client libraries, then no changes will be required. Otherwise, please update your code to make requests against this new URL.

Line Item goals, Sales Manager refactorings, and more PQL support

In v201408, we have added the field of Goal.goalType to the LineItem.Goal; this replaces what was formerly lineItem.duration and adds back support to create / update the line item types impacted in v201405 (listed here).

We've also done some significant refactoring of our Sales Manager API services adding premiums to rateCard objects. Prior to this version, there was a RateCardCustomizationService as well as a RateCardCustomizationGroupService; both were required to add a feature premium to an existing rateCard. This has now been replaced with a singular service named PremiumRateService.

In addition, we've also heard you loud and clear that PQL tables make development easier - in v201408, we provide support for the Audience_Segment_Category table.

New OAuth 2.0 Scope

With the release of v201408 of the DFP API, we will be introducing a new OAuth 2.0 scope. This scope identifies the service that your application will access during the authorization process.
This new scope better aligns with the naming conventions of many of the other Google APIs.

Starting from today, you should use the new scope when authorizing access for the DFP API regardless of the DFP API version. All our current DFP API client libraries use this new scope.

But I have refresh tokens from the deprecated scope...

Don't worry if your client code is using refresh tokens authorized with the deprecated scope - they will still work. However, new authorizations should specify the new scope.

Nicholas Chen, DFP API Team

A few weeks ago we announced the new Google Media Framework, which includes a Video.js plugin for HTML5. Today we’ll be diving a bit deeper into that plugin to show you how easy it is to do an IMA integration. Video.js is a JavaScript and CSS library that makes it easier to work with and build on HTML5 video. Combined with the IMA SDK plugin, the Video.js player becomes a fully integrated IMA SDK video player, and all in less than 10 lines of JavaScript!

Creating a player

You can create an IMA-integrated video player in 3 simple steps:

1. Download the video.js source and dependencies

  1. Grab the latest video.js player from
  2. Grab the contrib-ads library from GitHub
  3. Grab the IMA plugin from our GitHub repo
Alternatively, if you’re an npm user, you can install our plugin and the above dependencies with
npm install videojs-ima

2. Declare your video player

Make sure your html file references the required JavaScript and CSS files downloaded in step one (see the example in the README for more complete HTML). Add the following code to load the IMA SDK and declare a video player:
<script type=“text/javascript” 
<video id="content_video" class="video-js vjs-default-skin" controls> 
  <source src="YOUR_VIDEO_SOURCE" type="YOUR_VIDEO_TYPE" />
YOUR_VIDEO_TYPE is the encoding for your video. For more information on supported HTML5 video types, see this Wikipedia article.

3. Initialize the video player and IMA plugin

In a JavaScript block or separate JavaScript file, include the following code:
// Initialize the video.js player.
var player = videojs('content_video'); // your video tag’s id

// Declare options for the IMA plugin.
var options = {
  id: 'content_video',
  adTagUrl: 'YOUR_AD_TAG'

// Additional options available but not required.
// See our README for more info.

// Initialize the IMA plugin.

// Request ads.

// Start video playback (will play ads if there is a pre-roll,
// content otherwise).;

With these few lines of code, you’ve got a complete video player with an IMA integration. For more information and additional documentation, see our GitHub repo README.

If you have any questions, feel free to contact us via the Google Media Framework forum.

Today, we are introducing ad customizers, a new way to insert dynamic information into your ads. Ad customizers work similarly to ad parameters. They allow you to set up a feed with dynamic data, targeted at specific campaigns, ad groups or keywords. Your ads then reference the information in those feeds so that the values are inserted when the ad is served. You can also create ads that dynamically count down to an event, by inserting {=COUNTDOWN(...)} in your ad. Learn more about this new feature here.

Ad customizers are currently supported in AdWords API test accounts. Production accounts need to be whitelisted before you can use this feature. You can sign up for this feature here. Once your account is whitelisted, you will receive a confirmation email and can start using ad customizers in the whitelisted account. We whitelist accounts in batches, so expect some delay between signing up for the feature and getting your account whitelisted.

If you have any questions about this feature or the AdWords API in general, you can post them on our developer forum. You can also follow our Google+ page for updates about the AdWords API.

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.

As previously announced on the AdWords blog, we're improving how exact and phrase keywords match to users' search terms. Starting in late September, all phrase and exact match keywords will begin matching close variants, including misspellings, singular/plural forms, stemmings, accents, acronyms and abbreviations.

Specifically to the API, this means the following:
  • The next API version will no longer accept KeywordMatchSetting for campaigns.
  • Existing API versions will ignore the value sent for the optIn field of KeywordMatchSetting.
  • Regardless of the optIn field value, all exact and phrase match keywords will match close variants.
Close variant matching is already enabled by default for new campaigns, so if you haven't specifically set the optIn field, you won't see any changes in keyword matching behavior.

If you have any questions, please feel free to contact us on the forum or via the Google Plus page.

As you may know, we announced the release of our new Python client library—googleads—in March, 2014. Since then, we’ve received a lot of feedback that has helped us further improve the library. Given the positive reception we’ve had with googleads, along with the improvements we’ve made to it over the past few months, the time is right for us to give our legacy Python client library—adspygoogle—a proper send-off. The legacy ads APIs Python client library has been deprecated and will be sunset on January 5th, 2015.

Between now and the sunset date, all upcoming API releases will be supported. The legacy client library will no longer be available on GitHub or PyPI after the sunset date. You can continue to use it while supported versions of the APIs are available, but it will eventually become obsolete and won’t be supported if any new issues are discovered. In order to smoothly transition to the new client library and have uninterrupted access to the newest versions of the APIs, we suggest you migrate to googleads as soon as possible. To help you migrate, we’ve prepared a migration guide.

If you discover any bugs, would like to contribute, or have feature requests for googleads, feel free to let us know via the library’s issue tracker. If you have any questions or feedback for us, you can reach us on the Google Ads Developers Google+ page.

Today we're releasing beta 7 of the IMA iOS SDK. This release includes an important API change, so you'll need to make a small code revision in your iOS apps that use it. We've introduced the concept of an IMAAdDisplayContainer and changed how companion ads are handled. See our previous blog post for information on changes to the SDK and how to update your application.

We've also updated our iOS sample application so you can see a working implementation of beta 7 of the IMA iOS SDK.

Why do I need to update to beta 7?

Beta 7 of the SDK introduces changes to the way video ads are displayed which will enable continued support of YouTube-hosted ads (including TrueView). Additionally, our restructuring of the SDK's API will eventually allow publishers who require a custom player (similar to the HTML5 SDK) to do so. Stay tuned for an upcoming announcement on this.

You can get this latest release of the IMA iOS SDK from our IMA 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.

Do you use any of these products?
Then here’s your chance to tell us what you think about the corresponding client libraries, even if you don’t use one of them! Your feedback is very important for us and it helps us to prioritize the most wanted features. If you have any suggestions, feature requests or ideas—it's a great time to let us know!