We have added support for AdWords API v201603 reports in AdWords scripts. The major changes in this release are: See the AdWords API release notes for more details.

Starting from this release, we will not switch to the latest reporting version on the day of the release by default. Instead, we will keep the previous report version as the default version for a while before switching to the latest reports version. This will give you enough time to verify your scripts and make sure it works with the latest report version.

If you use API versioning in your reports, you need to modify your code to use v201603 as shown below.
var report =, {
   apiVersion: 'v201603'
If you don’t use API versioning, no code changes are required. Your reports will continue using v201601 for now, and switch to v201603 when we make v201603 the default version on May 17, 2016.

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.


As you may have heard, streamlined creative types are coming to DCM. The centerpiece of this effort is the new display creative, which supports HTML5, images, and Flash. To learn more, visit our DCM user support site.

How does this affect DCM/DFA Reporting and Trafficking API users?

Part of this streamlining effort involves renaming some existing creative types. To minimize disruptions to our API users we will not be modifying any Creatives service types for currently released API versions. These types will only be updated for future API versions, beginning with the the v2.5 release. Due to this, current users may notice the following discrepancies between values returned by the DCM API, DCM UI, and DDM Reports:

API type Old UI & Report type New UI & Report type
CUSTOM_INPAGE Custom in-page Custom display
CUSTOM_INTERSTITIAL Custom interstitial Custom display interstitial
ENHANCED_BANNER Enhanced banner Display
ENHANCED_IMAGE Enhanced image Display image gallery
REDIRECT Redirect Display redirect
RICH_MEDIA_EXPANDING Rich media expanding Rich media display expanding
RICH_MEDIA_INPAGE Rich media in-page Rich media display banner
RICH_MEDIA_INPAGE_FLOATING Rich media in-page with floating Rich media display banner with floating
RICH_MEDIA_INTERSTITIAL_FLOAT Rich media floating Rich media display interstitial
RICH_MEDIA_MULTI_FLOATING Rich media multi-floating Rich media display multi-floating interstitial
VPAID_LINEAR Rich media VPAID linear VPAID linear video
VPAID_NON_LINEAR Rich media VPAID non-linear VPAID non-linear video

What can API users do now to prepare?

As you may have spotted in the table above, display creatives are actually an extension of an existing creative type: enhanced banner. In fact, all current and newly created enhanced banner creatives will map directly to this new type. Thanks to this, existing API versions already have full support for display creatives!

As display creatives replace the need to use HTML5 banner, Image, and Flash in-page creative types, support for inserting these legacy types will be removed in an upcoming API release. To prepare for this, API users are strongly encouraged to begin transitioning to the new display type now. We've updated our code examples to illustrate how current API versions can use display creatives to begin replacing these legacy types today:

Language Examples
.NET HTML 5 Banner Image Flash In-page
Java HTML 5 Banner Image Flash In-page
PHP HTML 5 Banner Image Flash In-page
Python HTML 5 Banner Image Flash In-page
Ruby HTML 5 Banner Image Flash In-page>

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

If you submit AdWords API exemption requests for policy violations, then you may need to modify your application as a result of these recently announced policy changes.

What is changing?
For some policy violations, the values of the externalPolicyName, externalPolicyUrl, and externalPolicyDescription fields on PolicyViolationError will change.

What is not changing?
The policyName field value on PolicyViolationError.key will not change.

Could you remind me what a PolicyViolationError looks like?
Absolutely - glad you asked! In the following sample, after the policy changes go live, the content in externalPolicyName, externalPolicyUrl, and externalPolicyDescription may change, but the policyName field will stay the same.
<errors xmlns:xsi="" xsi:type="PolicyViolationError">
  <externalPolicyName>Non-standard punctuation</externalPolicyName>
  <externalPolicyDescription>Google ads aren't allowed to have excessive or unnecessary punctuation or symbols such as the following:
    &lt;a href="" target="_blank"&gt;See the full policy&lt;/a&gt;
What should you do?
If your application looks for specific values of externalPolicyName, externalPolicyUrl, or externalPolicyDescription to decide if a failed AdGroupAdOperation should be resubmitted with one or more ExemptionRequests, please make the following changes:
  1. Modify your application to use the policyName instead of one of the externalPolicy fields. The values for policyName are non-localized constants, so this is a more reliable field for this use case.
  2. In early June, 2016, monitor your logs for occurrences of PolicyViolationError. Look for any new policyName values that you may want to incorporate into your application's logic for submitting exemption requests.
If you have any questions or need help, please post on the forum or the Ads Developers Plus Page.

We’re pleased to announce the second round of workshops for AdWords scripts in 2016. The workshops will be held at the following locations: This round of workshops will cater to both novice and experienced scripters. We'll have code labs where you’ll build your own scripts from scratch with help from the Scripts team. Bring your laptop and some scripting ideas, and we’ll turn them into reality!

Whether you’re an advertiser who wants to learn about how scripts can automate your account management tasks, a developer who wants to polish your scripting skills, or a scripts enthusiast who wants to bounce around some ideas, you can find it all in these workshops.

Visit our website to check out the full agenda and sign up.

If you have any questions about the workshops, you can post them on our forums. Check out our Google+ page for AdWords Scripts updates.


Registering for banner and interstitial ad events is a handy way for Unity developers using the Google Mobile Ads Unity Plugin to track ad lifecycle events -- things like when an ad is loaded or when an ad click causes the app to be backgrounded. For Unity developers deploying to the Android platform, though, it's important to be aware that ad event handler methods are not invoked on the main thread. As a consequence, Unity methods that must be called on the main thread cannot be executed within ad event handler methods.

Consider the following example:

AudioSource audio = GetComponent<AudioSource>();
public void HandleInterstitialClosed(object sender, EventArgs args)
    audio.mute = false;

The code above, which modifies the volume of an audio source from within an ad event handler method, results in the following error:

ArgumentException: set_volume can only be called from the main thread

To get around this, we recommend setting a flag when an event happens, and polling for a state change within the Update() method of your Unity script.

For actions required to be performed on the main thread after showing an ad, set a flag on the OnAdClosed ad event. The update method can poll the value of this flag and perform actions as necessary. The code below illustrates how to implement this approach.

private bool interstitialClosed;

void Start()
    InterstitialAd interstitial = new InterstitialAd("YOUR_AD_UNIT_ID");
    interstitial.OnAdClosed += HandleInterstitialClosed;
    interstitialClosed = false;

void Update()
    if (interstitialClosed)
        // Perform actions here.
        audio.mute = false;

public void HandleInterstitialClosed(object sender, EventArgs args)
    interstitialClosed = true;

If you have any questions about Unity integration, you can reach us on our forum. You can also find our quick-start guide here. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.


The Mobile Ads Garage has returned with its second episode. In this video, you'll see screencasts and detailed breakdowns of how to implement banner ads for both iOS and Android. Plus, you'll get links to guides, samples, and other great resources.

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.


In our ongoing efforts to make developing with the IMA SDK easier, we’re pleased to announce that as of version 3.2.1, the IMA SDK for Android is now available on JCenter.

With this release, it's now quicker than ever to integrate with the IMA SDK. Simply make sure you include JCenter in your list of repositories:

repositories {

Then, in your build.gradle's dependencies, include the following compile directive:

compile ''

If you're modifying an existing sample, make sure to remove the IMA SDK JAR file from your libs folder. This directive includes the SDK, and if you already have the SDK JAR in libs, you’ll get errors for having two copies of the same library.

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