We are pleased to announce the release of the IMA SDK for iOS v3.1.0. This release contains support for Picture in Picture in iOS 9 and HTML5 companion ads. It also introduces a new API, [IMAAdsManager discardAdBreak], for discarding ad breaks. In addition, we have changed where IMAContentPlayhead is passed to the SDK.

Picture in Picture (PiP) is a feature that was introduced in iOS 9, and now IMA publishers can add it to their existing IMA implementation. For more information, please see our PiP guide.

The IMA SDK now supports HTML5 companion ads. There is no implementation change required to use HTML5 companion ads. The SDK uses the same companion ad slot classes and delegates as before.

We have also introduced a new API for discarding ad breaks. Publishers can use [IMAAdsManager discardAdBreak] to implement timeout policies for their apps and to have more control over ad playback.

IMAContentPlayhead is now passed into IMAAdsRequest instead of the IMAAdsManager. This change will require an update to existing implementations.

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


For Android developers, Context objects can be tricky. To start with, android.content.Context has a zillion subclasses, some of which are really specific (I’m looking at you, NotificationCompatSideChannelService). On top of that, there are a bunch of available calls to retrieve the current Context, all of which seem slightly different. Once you start talking about passing these objects from one part of an app to another, which happens during AdMob mediation, it can get confusing in a hurry. In order to keep things straight, engineers building Android custom events and mediation adapters need to make sure they’re handling Contexts properly.

If you’ve ever built a custom event or mediation adapter for AdMob, you’re probably familiar with these two methods:

requestInterstitialAd(Context context, 
                      CustomEventInterstitialListener listener,
                      String serverParameter,
                      MediationAdRequest mediationAdRequest,
                      Bundle customEventExtras)

requestInterstitialAd(Context context,
                      MediationInterstitialListener listener,
                      Bundle serverParameters,
                      MediationAdRequest mediationAdRequest,
                      Bundle mediationExtras)

They’re from the CustomEventInterstitial and MediationInterstitialAdapter interfaces, respectively, and are used to request interstitial ads from custom events and adapters. Both include a Context parameter that can be used to retrieve information about the execution environment, query permissions, and access user preferences. In most cases, that object ends up being the Activity an app is displaying when its ad request is made (Activity is a subclass of Context), but that’s not guaranteed.

For example, consider an app that switches quickly from one Activity to another, and occasionally shows an interstitial ad during one of the transitions. Requesting a new ad in each onCreate method will likely waste resources, so offloading that work to a separate class that lives outside the Activity lifecycle is a common solution. Because that class isn’t an Activity, though, it can’t use itself as a Context, and instead must request interstitials using the Application object (another Context subclass). If the app uses custom event and adapter classes that were only tested with Activity objects, they might break!

The best practice here is to make sure to test your custom events and adapters with both Activity and Application objects prior to releasing them. A reliable custom event needs to operate the same no matter which is provided, and the same goes for adapters. If, for some reason, the SDK you’re adapting just can’t work with an Application object as the context parameter, you can always trap this using instanceof and log the error:

    Public void requestInterstitialAd(Context context,  
                      CustomEventInterstitialListener listener,
                      String serverParameter, 
                      MediationAdRequest mediationAdRequest,
                      Bundle customEventExtras) {
    if (!(context instanceof Activity)) {
        Log.w(“Example”, “Context not an Activity. Returning error!”);

    // ... code to request an ad using the Activity context ...

If you have technical questions about activities, contexts, or anything else relating to the Google Mobile Ads SDK, stop by our forum.

Starting in January 2016, we’ll be cleaning up some older geo targeting locations in the AdWords API. On January 21, 2016, the targetingStatus of these locations will be changed to PHASING_OUT, and they will be completely removed in an upcoming version of the API.

Most of the targets we're removing are no longer used. However, there are a few with some traffic, and these largely fall into two categories:
  • Criteria that are duplicates of other criteria. You should migrate these as soon as possible for consistency. Any that are not migrated by the time the criteria are removed will be automatically migrated to the new criteria IDs.
  • Criteria that designate places that no longer exist, but previously were meaningful targets.
Please see our developers site for a complete list of IDs affected.

If you have any questions about this change, or other questions about the AdWords API, please contact us via the forum or the Ads Developers Plus Page.


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.


It's been two years since we moved to a regular deprecation schedule. And thanks to developers like you, we've been able to regularly release new versions and features while maintaining code health.

To continue this trend, we'll be simplifying the sunset schedule by tightening our belts a little. Starting with v201511, versions will be sunset one year after release. This will help us reduce the number of out-of-band deprecations. A shorter lifecycle means dated features can ride off into the sunset as intended. Plus, it's easy to remember when the version you're using is about to bite the dust, even if you're not signed up for deprecation announcements or don't obsessively check our deprecation schedule.

We strive to make upgrades easy. If you think they're not, please tell us why on our developer forum so we can make it better.

The DoubleClick Ad Exchange (AdX) Buyer SOAP API and legacy AdX UI will be sunset in January, 2016. After the API is sunset, all static bidding campaigns will be terminated, and requests against any version of the API from AdX accounts will result in an error response. In addition, the legacy AdX UI will no longer be accessible.

As an alternative to the SOAP API, we recommend using the DoubleClick Ad Exchange Hosted Bidding solution. Similar to the static bidding functionality offered by the SOAP API and legacy UI, Hosted Bidding allows you to bid on Ad Exchange inventory without an external real-time bidding platform. At this time, Hosted Bidding is only accessible as a UI that can be found by signing in to your Ad Exchange Account and clicking the Hosted Bidding tab. To learn more, read the Hosted Bidding guide.

These sunsets will not affect real-time bidding applications. All features required to configure real-time bidding campaigns were migrated to the DoubleClick Ad Exchange Buyer REST API when we updated our pretargeting capabilities in July 2014.

If you have any comments or questions about the upcoming sunset, feel free to contact us via the forum or our Ads Developer G+ page.


Did you know that you can reach past website visitors and app users? Let's say you’re a travel brand. You can now reach people who have joined your rewards program as they plan their next trip. For example, when these rewards members search for “non-stop flights to new york” on, you can show relevant ads at the top of their search results on any device right when they’re looking to fly to New York. And when those members are watching their favorite videos on YouTube or catching up on Gmail, you can show ads that inspire them to plan their next trip.

Behind the scenes, this works by adding people to a UserList.

Prior to v201509 there were four different types:

  • BasicUserList: Remarketing to people who took specific actions (such as purchasing shoes) on your website or app.
  • RuleBasedUserList: Remarketing to people who follow advertiser-defined rules. The rule can be as simple as all visitors to your website (which is the easiest way to start remarketing).
  • LogicalUserList: Combining two or more user lists. For example, customers who purchased shoes and/or visited specific pages of your website at specific times.
  • SimilarUserList: Remarketing to people that share similar interests and behaviors with those in other user lists. For example, you can reach new potential customers that share similar interests and behaviors with those who purchased shoes on your website.

A SimilarUserList is automatically created by Google for each UserList based on a variety of factors, such as the number of people on the original list, how recently these people joined the original list, the types of sites that these people browsed and whether the original list is your own. This process may take up to 4 days once the seed list is created.

You can target or exclude user lists at the ad group level, but you can only exclude them at the campaign level.

As a reminder, please have a look at the policy for advertising based on interests and location and the policy for remarketing lists for search ads.

Customer Match

v201509 introduced a new user list type: CrmBasedUserList. It enables you to create a user list using your customers’ email addresses.

Suppose you have an existing database of email addresses of your newsletter subscribers for “people who love shoes”. With a CrmBasedUserList you can reach these subscribers and adjust your bidding accordingly, present different ads, and more. You can use a SimilarUserList of your subscribers list to potentially find new customers who share similar behaviors and interests.

Each CrmBasedUserList must have an optOutLink to provide a link to the page where people can manage their preferences for receiving email messages from the advertiser, including opting out of the advertiser email messages.

Before using this targeting strategy, please take the time to read our policy page.

A CrmBasedUserList can be used for targeting on the Search network, YouTube and Gmail, whereas a SimilarUserList of a CrmBasedUserList can only be used for targeting on YouTube and Gmail.

Keep the following points in mind when using a CrmBasedUserList:

  • Advertisers must collect email addresses as 1st party. For example, an agency can submit email addresses on behalf of an advertiser if the advertiser collected the email addresses directly from its customers.
  • Email addresses can be from Gmail or non Gmail addresses as long as they are associated with a Google account. We recommend adding all available email addresses to maximize the size of the result.
  • Ads will serve only when the user list has at least 1,000 active members. Active members are those who have used Google Search, YouTube, or Gmail at least once over the last 30 days.

If you want to read more about CrmBasedUserList, have a look at our guide and code examples.

As always, feel free to visit us or ask questions on the AdWords API Forum or our Google+ page.

If I asked you "why do you love this time of year?", I might get back a variety of responses ranging from "the fall foliage where all the leaves change color," or "turkey, stuffing, and pumpkin pie," or perhaps the most obvious answer since the advent of steamed milk - "pumpkin spice lattes." For me, it's none of those things. The reason why I get uncomfortably excited every year when November rolls around is because the DFP release & deprecation schedule aligns perfectly so that the last release of the year happens right about now. So without further ado, I present you with the latest and greatest version: v201511.

Trafficking Updates

We've been going back and cleaning up our APIs to make them simpler and easier to use. Remember that target platform unification change we made? Now that you've switched over to using TargetPlatform.ANY (and why should you miss out on that sweet mobile traffic because of a pesky ENUM?) we've removed it entirely from the LineItem and AdUnit objects. On the creatives front, Template and Custom creatives now use CreativeAssets for associated assets.

Sales Manager Updates

On the sales manager front, we've exposed a few reporting dimension attributes: PROPOSAL_FLAT_FEE and PROPOSAL_LINE_ITEM_FLAT_FEE, which represent the billing setting for the flat fee checkbox in the UI. In addition, if setting deliveryRateType and roadblockingType are things that you have been wishing for, consider your wish granted. In v201511, you can now set DeliverySettings on ProductTemplates.

See full release notes here.

As a reminder, with each new release comes a new deprecation. If you're using v201411 or earlier, it's time to look into upgrading. v201408 will be sunset at the end of November 2015, and v201411 will be sunset at the end of February 2016. If you have any questions about upgrading, let us know on the developer forum.

The Shopping Content API now supports the retrieval of invalid product offers. This means that offers such as those with an invalid category or a mismatched URL can now be retrieved and reviewed via the API. This will enable you to more easily view invalid product offers and debug API requests. Going forward, invalid product offers that are newly inserted via the API will be available for review in the Diagnostics tab of the Merchant Center.

How should you go about retrieving your invalid offers from the API? You can do this by using a new optional URL parameter that has been added to the products.list method, called includeInvalidInsertedItems. (Yes, it's a long name; we apologize for the extra keystrokes.) If you set this parameter to true, your response will include products that were invalid at the time of insertion. The default value is false, so if you don't include the parameter in your request, you will not have invalid products in your response. This preserves existing behavior, with the exception that if you have invalid product offers from feeds, they will also not be returned in the response. Note that you can still use the 'get' and 'delete' methods to reference product offers directly by ID, even if they are invalid. No additional parameter is needed for those methods.

We are introducing one new error when inserting product offers, called "The item could not be inserted". An invalid offer is inserted only if it does not overwrite an existing valid offer. When there already is an existing valid offer, an additional error is returned, stating "The item could not be inserted". This also means that the product offer will not be available for review from products.list nor in the Diagnostics tab. Product offers are matched based on the full product ID, of the form channel:languageCode:countryCode:offerId.

It's important to remember that the new includeInvalidInsertedItems parameter will only filter between valid and invalid product offers, as determined at insertion time, ignoring whether they were or not later disapproved. This means that it will return invalid product offers inserted both from the API and from feeds. To distinguish between approved and disapproved product offers, use the Productstatuses Service.

To try out this new parameter, add includeInvalidInsertedItems as a query parameter to your products.list request. If you have more questions or feedback, please head on over to our developer forum.


As you may have heard, universal ads are launching to DCM accounts throughout November and December 2015. The centerpiece of these new ads is a set of unified compatibilities that remove the distinction between in-app and in-page environments. To learn more, visit our DCM user or partner support sites.

What does this mean for DCM/DFA Reporting and Trafficking API users?

Currently, the API does not expose these new compatibilities, although full support is coming in a future release. Until then, the in-app and in-page compatibilities you currently use will remain available. This means that there are no immediate changes necessary to your applications, but you may notice some discrepancies between the values presented by the API and UI:

API compatibility
New UI compatibility
In-app interstitial
In-stream video
Display interstitial

What can API users do to prepare?

To make your future transition to universal ads easier, we recommend that API users begin transitioning off of in-app placements now. Be aware that it will no longer be possible to traffic in-app placements once universal ads support is added to the API, and existing in-app placements will not be automatically converted to use the new unified compatibilities.

Instead, newly trafficked placements should be created using in-page compatibilities. These placements will be mapped directly to the new unified compatibilities (as seen in the table above), making them immediately eligible to serve in both environments.

Questions about this or anything else DCM API related? Contact us via our support forum.


The Google Mobile Ads API Demo apps for Android and iOS are now available. These new apps contain advanced examples for both AdMob and DoubleClick for Publishers (DFP) that demonstrate features of the Google Mobile Ads SDK that can help you improve the user experience and maximize ad revenue. Whether you’re a new publisher or a seasoned veteran of the SDK, the API Demo apps showcase new ways to customize ad requests, experiment with multiple ad sizes, and compare AdMob and DFP technologies.

Download the API Demo apps for Android and iOS today and explore new ways to improve your integration with the Google Mobile Ads SDK!

If you have any questions regarding the new API Demo apps, feel free to contact us through our forum.

We’ve completed the last round of the AdWords API Workshops, and you can check out all the content online by visiting the official website,, and clicking on Resources.

Be sure to also check out our YouTube channel for the recorded presentations.

If you have any questions about the AdWords API Workshops, you can post them on our forums. Check out our Google+ page for Ads APIs updates.


On November 17th, 2015, we'll be updating the Ad Exchange Seller REST API to make it consistent with the user interface. Specifically, we'll remove the ability to download saved reports or retrieve the dimensions we retired in April.

Requests made after this date for these dimensions will result in that dimension being ignored and requests for saved reports will result in an error.

As a reminder, the dimensions we retired in April are:

  • DSP_ID

For a full list of available dimensions, please see the AdX Seller REST API documentation.

Follow our Google+ page for other announcements and updates.

-- Dean Lukies, Ads Developer Relations


When developing with AdMob in Unity, it is a common practice to make your banner ads persist across multiple scenes. This blog post will highlight best practices to accomplish this with the Google Mobile Ads Unity Plugin.

The most straightforward approach is to link the lifecycle of ads to that of the scenes they’re displayed in. When transitioning from one scene to another, existing ads are destroyed before leaving the first scene. New ads can then be created and displayed in the next scene.

The downside of this approach is that every scene transition would result in a new banner request. This may not be desirable if scene transitions are frequent and occur quickly.

An alternative is to use a GameObject as a wrapper for banners or interstitials. By default, each GameObject in a scene will be destroyed once the new scene is loaded (unless you use additive scene loading). However, you can make a GameObject survive across scenes by marking it with DontDestroyOnLoad. You can then use the GameObject.Find method to obtain references to the wrapper GameObject from scripts in other scenes.

Here is an example of how to use a GameObject to wrap banner ads:

// FirstSceneScript.cs
void Start() {       
  // Create a wrapper GameObject to hold the banner.
  GameObject myGameObject = new GameObject("myBannerAdObject");
  // Mark the GameObject not to be destroyed when new scenes load.
The BannerWrapper GameObject is a wrapper for a BannerView.
// BannerWrapper.cs
using System;

using UnityEngine;
using GoogleMobileAds;
using GoogleMobileAds.Api;

public class BannerWrapper : MonoBehaviour {
    public BannerView bannerView;
    void Start()
        bannerView = new BannerView(
                "your_ad_unit_id", AdSize.SmartBanner, AdPosition.Bottom);
        AdRequest request = new AdRequest.Builder().Build();
        bannerView.LoadAd (request);

In SecondSceneScript.cs, which is attached to the second scene, you can find a GameObject by name, get the BannerWrapper component, and access the BannerView:

// SecondSceneScript.cs
void Start () {
    GameObject myGameObject = GameObject.Find("myBannerAdObject");
    BannerWrapper bannerWrapper = myGameObject.GetComponent();

By managing your ads efficiently and seamlessly across scenes, you are sure to provide a better ad experience for your users. If you have any questions about Unity integration, you can reach us on our forum. You can also find our quick-start guide linked here. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.


Today we're releasing v2.3 of the DCM/DFA Reporting and Trafficking API. This release brings a number of enhancements, such as:

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.1, which will sunset on February 29th, 2016.

As a reminder, February 29th is also the end of the extended migration window we've provided to users of v2.0 and earlier versions of the API. The current schedule is as follows:

API Version
Deprecation Date
Sunset Date
3 Aug 2015
29 Feb 2016
4 Nov 2015

To avoid an interruption in service, all users are required to migrate off of these versions by the sunset date.

Learn more

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the Release Notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

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

What’s new?

The validation for AppConversions will become stricter starting on November 9, 2015. If you’re using AppConversions in v201509 or v201506 with AppPlatform: ITUNES, you’ll need to make sure that you’re using the correct AppConversionType.

What was the old behavior?

When v201509 was first released, the API would not throw an error if the incorrect value was sent in a request for an iTunes AppConversion. The API automatically converted to the correct AppConversionType. For example, if the value DOWNLOAD was passed into v201509 for an iTunes AppConversion, then that value would automatically be converted to FIRST_OPEN.

What is the new behavior?

In v201509, AppConversionType DOWNLOAD changed to FIRST_OPEN for iTunes apps. Here’s what you will need to do:
  • For v201506 or earlier, you must pass in AppConversionType DOWNLOAD rather than FIRST_OPEN.
  • For v201509 or later, you must pass in FIRST_OPEN instead of DOWNLOAD.
Passing in the incorrect value will result in the error DOMAIN_EXCEPTION from the API starting on November 9.

Note: This only impacts iTunes conversions. There will be no changes to the validation for AppConversions with an AppPlatform of ANDROID.

Where can I learn more?

For more information on mobile apps and conversions, check out these guides: Questions? Visit us on the AdWords API Forum or our Google+ page.


If you’re an Android developer who uses ProGuard to post-process builds, you already know the improvements it can make to APK size and speed. Just as handy, though, is its ability to obfuscate your compiled code by stripping out debug information and renaming classes, methods, and fields to generic identifiers. It’s a great way to discourage reverse-engineering of your application. If you’re an AdMob publisher who uses mediation, however, you need to take special care when configuring ProGuard in order to avoid obfuscating some of the code used in the mediation process.

AdMob mediation needs two classes to maintain their original names in your final APK: AdUrlAdapter and AdMobAdapter. If either of those has been renamed by ProGuard, it can cause the SDK to incorrectly return “no fill” responses for the AdMob demand in your mediated ad units.

The good news is that it’s easy to avoid this problem. Just add the following two keep options to your ProGuard configuration file:

-keep class {

-keep class {

These options instruct ProGuard to avoid renaming the two classes, and to leave the names of their fields and methods unobfuscated as well. With the original names intact, the mediation system will be able to instantiate them dynamically whenever they’re needed, and your otherwise obfuscated application won’t miss out on any AdMob impressions.

The third-party networks your app mediates may also need certain classes exempted from obfuscation. Be sure to check with those networks to find out if they have recommendations for ProGuard configuration.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

tags: android, admob_mediation, mobile_ads_sdk

AdWords API v201509 introduces some changes to reporting columns, particularly Clicks. Recently, AdWords introduced new columns called Engagements and Interactions. It also added reporting columns related to video campaigns such as VideoViews, which have previously been unavailable via API reporting. AdWords API version v201509 has updated its reporting to match these changes.

The new Interactions field, available in API performance reports, can be thought of as the main action a user takes with the ad format: clicks for text ads, engagements for Lightbox ads, and views for video ads. Previously, views for video ads were not returned in API reporting, so having access to this data is new.

Prior to v201509, the Clicks field always included both clicks and engagements. Starting in v201509, the Clicks field includes only click actions, like clickthroughs to a landing page or clicks to call. This means that clicks on video ads, which are unpaid, will be included in this field. However, engagements for Lightbox ads will not be counted.

If measuring performance across multiple ad formats, you might consider using Interactions to view the total number of primary user actions on ads, all in the same column. Clicks, Engagements, and VideoViews are available as well for more fine-grained reporting by ad format.

The table below summarizes the changes in each field for various ad formats.

Text ads: clickthrough to a landing page

Lightbox ads: hover to expanded ad format
Text ads: clickthrough to a landing page or clicks to call

Lightbox ads: clickthrough to a landing page

Video ads: clickthrough to a landing page
Lightbox ads: hover to expanded ad format
Video ads: view
Text ads: clickthrough to a landing page or clicks to call

Lightbox ads: hover to expanded ad format

Video ads: views

Please note that reporting in v201506 and previous versions is unaffected; they return the same data that they always have, represented the same way. This means that when comparing the data you receive from older versions of the API to user interface reports, or to v201509 reports, the numbers will not directly match up. Video-related stats will still be excluded from v201506. The Clicks column in v201506 will match the Interactions column from v201509 if you subtract out video interactions.

For ease of reporting, it’s recommended to migrate to v201509 as soon as possible.

Keep in mind these aren’t the only reporting changes in v201509 — for more details on conversion-related reporting changes, please see the release notes.

If you have any questions about this or other aspects of the AdWords API, please contact us via the forum or the Ads Developers Plus Page.


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.


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.


In preparation for improvements to CPA bidding in AdWords, starting October 26, 2015, we'll perform a one-time removal of inactive ad group-level CPA bids.

What's an inactive ad group CPA bid, you ask? An ad group-level CPA bid is inactive if the ad group's effective bidding strategy is not a CONVERSION_OPTIMIZER strategy. This includes CPA bids on ad groups whose effective bidding strategy is TARGET_CPA, since the target for such ad groups is specified at the strategy level. The effective bidding strategy is the ad group-level strategy, if specified. Otherwise, it’s the bidding strategy set at the campaign-level.

How this change impacts the AdWords API

After the one-time removal of inactive CPA bids, there are two categories of ad groups you'll want to review:
  • Ad groups from which inactive CPA bids were removed: For these ad groups, the AdGroup object will no longer have a CpaBid in the bids attribute of its ad group-level BiddingStrategyConfiguration. Therefore, if you change the effective bidding strategy of these ad groups back to a CONVERSION_OPTIMIZER strategy, you will have to add a new CpaBid to the ad group’s BiddingStrategyConfiguration for your ads in the ad group to serve. You will only have to make this change once.
  • Ad groups you change from TARGET_CPA to CONVERSION_OPTIMIZER: AdWords will no longer copy the TargetCpaBiddingScheme.targetCpa value to a CpaBid on the ad group's bidding strategy configuration. Therefore, you will not automatically get the TARGET_CPA strategy bid if you transition to CONVERSION_OPTIMIZER. If the ad group's bidding strategy configuration already has a CpaBid, then CONVERSION_OPTIMIZER will use that bid. Otherwise, you will have to add a new CpaBid to the ad group BiddingStrategyConfiguration before ads in your ad group will serve.

How this change impacts bidding

Since the CPA bids being removed are inactive, this change will have no impact on bidding or ad serving.

What you should do

If you are interested in inactive CPA bids for CONVERSION_OPTIMIZER bidding strategies, download the current bids using AdGroupService before the removal date.

More bidding resources

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


We have added support for AdWords API v201509 reports in AdWords scripts.

Changes to conversion columns

This release includes several changes that coincide with the recent announcement on conversion columns. Several reporting columns were removed and new columns were added. See the AdWords API release notes for more details.

Video and multi-channel reporting

We are now including statistics and metrics for AdWords for video and TrueView video campaigns in several reports. This includes a new Video Performance Report. Note that reports will only include data for newly created video campaigns in AdWords campaign management or campaigns that were migrated from AdWords for video.

We have also added new reporting columns that help multi-channel advertisers more easily manage reporting for specific campaign types like Search, Shopping, Display, and Video.

See Video and multi-channel reporting changes for more details.

Miscellaneous reporting changes

  • All columns that have a List or Map return type now return data in JSON format.
  • Shared set type is now returned as an ENUM instead of an Integer in SHARED_SET_REPORT and CAMPAIGN_SHARED_SET_REPORT.
  • Several new columns have been added to existing reports.
  • A few duplicate columns in existing reports were removed.
  • MatchType and MatchTypeWithVariant columns were renamed to QueryMatchType and QueryMatchTypeWithVariant in PAID_ORGANIC_QUERY_REPORT and SEARCH_QUERY_PERFORMANCE_REPORT.

See Miscellaneous reporting changes for more details.

If you use API versioning in your reports, you need to modify your code to use v201509 as shown below. If you don’t use API versioning, no code changes are required.

var report =, {
   apiVersion: 'v201509'
If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

Last year, we announced upgraded location extensions, a more efficient way to manage and use business locations in ads by linking Google My Business and AdWords accounts. To help you manage your business locations more easily at scale, we’re now releasing the Google My Business API.

Google My Business will be the central repository for managing your business locations. The creation of manual location extensions as feed items through the AdWords API has been deprecated and will sunset in Q2 2016. Please update your code before March 31, 2016 to avoid being impacted by this transition.

Supported features
The first version of the Google My Business API allows you to read, create, update and delete unverified business locations. Supported attributes are name, address, contact numbers, URL, categories, and business hours. Unverified locations can be used as location extensions in AdWords, but have to be verified to be eligible to show up on Google Maps.

Future releases of the Google My Business API will support additional functionality that will allow you to fully manage your location data across Google Ads and Maps.

Getting started with the Google My Business API
If you already use the AdWords API and manage more than 50 business locations, you can apply for access to the Google My Business API. Once granted, you will have access to the Google My Business API documentation and you can follow the steps there to get started. For accounts with 50 or fewer locations, please use Google My Business Locations for now.

Linking locations to accounts, campaigns or ad groups as location extensions
Users managing multi-location businesses (chains) must have a separate Google My Business account for each chain for bulk-verification. If you already manage locations under bulk-verified accounts in Google My Business today, you can link those accounts to AdWords to have your location extensions in sync.

For developers managing AdWords accounts with a large number of locations for small and medium businesses, we recommend creating one Google My Business account as a central repository for all locations. Each physical location should be created only once. If different owners and managers are involved per location or for sets of locations, we suggest using Business Accounts.

Once the AdWords accounts are linked to your shared Google My Business account, the locations will be available as feed items in AdWords. You are responsible for creating a CustomerFeed and using an appropriate matching function to make sure only locations that actually belong to the customer are linked to their related AdWords account. You can use CampaignFeeds or AdGroupFeeds for additional filtering based on campaigns or ad groups.

The best way to filter locations from a shared Google My Business account is to create location labels through the Google My Business API and use a matching function that uses these labels for selection. For example, you can label each location with its AdWords Customer ID in Google My Business and use these Customer ID labels for filtering in AdWords. Or you can label each location with a unique ID, as long as you keep track of these IDs.

Please see our guide for managing location extensions for further details, which also includes an end-to-end code example.

Migration of existing location extensions
If you are using manual location extensions through the AdWords API, we recommend migrating your locations to Google My Business before March 31, 2016. After this date, the creation of manual location extensions will sunset. All unmigrated locations stored in AdWords will be auto-migrated to Google My Business at a later date. Further details about the timeline and process will be announced in this blog.

AdWords API v201502 will be sunset on November 12, 2015, after which all v201502 API requests will begin to fail. This version was deprecated on June 25, 2015. If you are still on v201502, we recommend that you migrate directly to v201509 (released last week) and skip v201506. Please be sure to migrate soon to ensure your API access is unaffected.

We have prepared various resources to help with the migration: As always, if you have any questions about this migration, please contact us via the forum or the Ads Developers Plus Page.


On Monday, November 30, 2015, in accordance with the deprecation schedule, v201408 of the DFP API will be sunset. At that time, any requests made to v201408 will return errors.

If you're still using v201408, now's the time to upgrade to the latest release and take advantage of new features like line item level reconciliation (see our guide here). To do so, check the release notes to identify any breaking changes, grab the latest version of your client library and update your code.

Some changes to look out for:

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Deprecation Announcements group and adjust your notification settings.


Today we’re announcing the release of AdWords API v201509. Here are the highlights:

  • Improved batch processing. The new BatchJobService supports all of the same operations as MutateJobService, but offers additional features such as support for creating dependent objects using temporary IDs, better error reporting, improved performance, and a much higher limit on the number of operations per job. Check out the accompanying guide to get started.
  • AdWords for video and TrueView video campaigns in reports. The AdWords API now supports TrueView campaigns that have migrated from AdWords for video, and several reports now include statistics and new metrics for these campaigns. See the release notes for the complete list of changes and additions.
  • New reporting columns for multi-channel advertisers are available on multiple reports making it easier to track interactions vs. clicks.
  • Customer Match. Build and target user lists from email addresses using the new CrmBasedUserList.
  • Structured snippets can now be created using extension setting services.
  • Conversion column changes. Conversion columns have been modified, added, or removed on multiple reports to coincide with the upcoming conversion reporting changes in AdWords. See the release notes for the complete list of changes.
  • HTML5 ads can now be added as TemplateAds using template ID 419. In addition, MediaService now supports uploading media bundles for use with this new template.
  • Geo targeted ad customizers. Target each ad customizer feed item to a specific geographic location.
  • Gmail sponsored promotions. The AdWords API now fully supports the Gmail image, single promotion, and multi-product ad formats via template ads.
  • Dynamic remarketing ads have new placeholder fields for setting upgraded URL attributes such as tracking templates, custom parameters, and final URLs.
  • Active View reporting. New fields for Active View viewable impressions, measurable impressions, measurable cost, and measurability are now available in multiple reports.

If you’re using v201502 of the AdWords API, please note that it’s being sunset on November 12th, 2015. We encourage you to skip v201506 and migrate straight to v201509. If you’re using v201506, be aware it’s now marked deprecated and will be sunset on April 11th, 2016.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201509 migration guide. The updated client libraries and code examples will be published shortly. With this release, we’ve also updated the Required Minimum Functionality document to include some of the newly added features. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.


Smart banners are a handy thing for publishers. You can drop an AdMob smart banner into a layout or storyboard, and it’ll stretch or squeeze itself at runtime until it’s just the right size for the device, then request an ad to match. They’re a great feature with all the extra work hidden under the hood.

If you’re building an Android mediation adapter or custom event, though, things aren’t quite as simple -- after all, you’re under that hood, too! A common rough spot for developers is retrieving a smart banner’s size. Because the Google Mobile Ads SDK uses constants to internally represent a smart banner’s height and width, the getHeight and getWidth methods of a smart banner’s AdSize will return those constants (they’re negative numbers, so they’re quite hard to miss). That means relying on calls to getHeight and getWidth to determine a smart banner’s true size isn’t a workable strategy.

So how should adapter and custom event developers calculate sizes correctly? By avoiding getHeight and getWidth, and instead asking for pixel counts using getHeightInPixels and getWidthInPixels, two other methods offered by AdSize. You can scale their return values according to the device’s metrics and end up with the same kind of DPI values returned by getWidth and getHeight for other ad sizes. Here’s a code snippet that shows how it’s done:

// Get the raw pixel counts.
int widthInPixels = size.getWidthInPixels(context);
int heightInPixels = size.getHeightInPixels(context);

// These metrics include screen density, which is what we’re after.
DisplayMetrics displayMetrics = Resources.getSystem().getDisplayMetrics();

// These are values you can send to your mediated network’s SDK.
int widthInDpi = Math.round(widthInPixels / displayMetrics.density);
int heightInDpi = Math.round(heightInPixels / displayMetrics.density);

Once you finish the math, you’ll have proper DPI values that can be sent to whichever network you’re mediating. The calls to getHeightInPixels and getWidthInPixels require a valid Context, but you can use the one provided as a parameter to the requestBannerAd methods in MediationBannerAdapter and CustomEventBanner.

Now you know the best way to gauge the size of a smart banner! Use this approach and it’ll help keep your mediation running smoothly.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.