We are marking the ClickType column in AdWords API and Scripts reports as incompatible with the following engagement and video-related fields in version v201607 and earlier:
  • AverageCpe
  • EngagementRate
  • VideoQuartile25Rate
  • VideoQuartile50Rate
  • VideoQuartile75Rate
  • VideoQuartile100Rate
  • VideoViews
  • VideoViewRate
  • AverageCpv
These fields refer to engagement and video view interactions, and aren’t compatible with the ClickType column, a click interaction metric. This restriction is already enforced in v201609 reports, see our migration guide for more details.

Starting Dec 1, 2016, you will get a ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT error if ClickType column is requested with any of these fields.

Questions? Visit us on the AdWords API Forum or our Google+ page.

What's changing?
As of today, the getServiceLinks() and mutateServiceLinks() methods on CustomerService are available to all AdWords API users. Previously, these methods were only available to whitelisted users.

Using this functionality and the Content API for Shopping, you can now fully automate the process of linking Merchant Center accounts to your AdWords account. Previously, you could send a link invitation using the Content API for Shopping, but you could not accept or reject the invitation using the AdWords API.

What do the new features do?
I thought you'd never ask! :)
  • getServiceLinks() retrieves the status of links between your AdWords account and Merchant Center accounts.
  • mutateServiceLinks() accepts or rejects links between your AdWords account and Merchant Center accounts.
What should you do?
If you're interested in automating the linking process between Merchant Center and AdWords, check out the updated shopping campaigns guide.

If you have any questions or need help, please post on the forum or the Ads Developers Plus Page.


AdWords scripts now fully support responsive ads, image ads, HTML5 ads and multiple Gmail ad formats. See our guide on ad types and related code snippets to learn more about using these ad formats in Scripts.

This update also introduces a media service which can be used to upload and query media for use in ads. See our ad media guide for a more detailed overview of media support.

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


We are making two changes related to how various conversion-related stats are retrieved in AdWords Scripts.

New methods for Conversion stats

We are reintroducing two methods in the AdWordsApp.​Stats and MccApp.​ManagedAccountStats classes to work with Conversions.

Note: Since Conversions is a stat of type Double, the equality operators (= and !=) won’t work with these new methods when using the withCondition filters or comparing values in code. Instead, you need to use comparison operators like < and > or round Conversions off to an Integer.

Sunsetting ConvertedClicks

As part of sunsetting Converted clicks in AdWords, we are deprecating the getConvertedClicks() and getClickConversionRate() methods in the AdWordsApp.​Stats and MccApp.​ManagedAccountStats classes. These methods will be sunset on February 21, 2017.

If your scripts use these methods, update them to use the new Conversion stats methods if applicable before February 21, 2017 to ensure they continue to work.

If you have any questions about these changes please reply to this email or post them on our developer forum and we'll be glad to help you.

Authentication with the DFP API is probably something you had to set up once and then never thought about again. Well, that may be true until there's a scope change, or your credentials suddenly stop working, or the developer who created the credentials leaves to open their own yoga studio in the Andes.

Understanding some of the finer details of DFP's OAuth2 flows can come in handy when the unexpected happens.

Access tokens

When using the DFP API, you can authenticate on behalf of a user in your network or as an application. For the DFP API we call these two choices Web Application flow and Service account flow (server-to-server), respectively. Each choice has a different set-up, but both are used to generate access tokens.

All DFP API requests are authenticated using access tokens. You can think of these as short-lived (about one hour) passwords. When making a request, you include the access token in the HTTP header:

  Authorization: Bearer ACCESS_TOKEN

Every access token is tied to a specific user and one or more API scopes. The scopes control which Google APIs the access token is valid for. The scope for DFP is:

Access Control

Because every access token is associated with a user, the DFP API enforces the same exact access controls as the DFP UI. This means that all the teams, roles, and permissions that restrict the user are in effect.

When authenticating as a dedicated API user like a service account, make sure that user is configured with your desired teams and role in DFP. There's no requirement that API users have administrator access.


If you ever need to verify the scope or who the access token was issued to, you can easily do so using the OAuth2 API explorer. Enter the access token you're using, and the API will provide a JSON response with the details:
    "issued_to": "",
    "audience": "",
    "scope": "",
    "expires_in": 3496,
    "access_type": "offline"

Refresh Tokens

Although we now recommend using service accounts for server-to-server flow, many integrations still use an installed application flow. This flow uses a refresh token to generate access tokens.

If your refresh token stops working, there are a few possible causes:

  • The user you're authenticating as no longer has access to the DFP network.
  • Too many refresh tokens were generated for the OAuth2 client.
  • The user you're authenticating as has revoked access for your application.

The simplest solution to all of these is to create a new client and generate a new refresh token for a current DFP user. Remember that the refresh token is tied to the account that authorizes the application, and not the user who created the OAuth2 client. When accepting the OAuth2 authorization prompt, verify that the user in the top right corner that is logged in is correct:

If OAuth2 still gives you a headache, we're happy to troubleshoot with you. Just reach out to us on our developer forum.

In accordance with our deprecation schedule, we will be sunsetting v2.4 of the DCM/DFA Reporting and Trafficking API on November 30th, 2016. On this date, all requests made against v2.4 of the API will begin returning HTTP 403 errors.

If you're still working with this version, we strongly encourage you to begin migrating to the most recent release to avoid an interruption in service. If you're not sure, or would like to know more about the migration process, refer to the migration guide.

As always, feel free to reach out to us with any questions that you have. To receive future updates like this directly in your inbox, join the DCM API Announcements group and adjust your notification settings.


Following its launch at the 2016 Game Developer’s Conference, AdMob’s mediation support for rewarded video ads has been a hit with publishers and users alike, with rapid adoption on both Android and iOS platforms.

Our growing list of mediation partners includes eight different ad networks. Choosing AdMob for your rewarded video mediation platform gives you access to ad content from all of them, while you develop against a single API from AdMob. Now, with the launch of custom events for rewarded video, you can also request and display rewarded videos from ad networks that are not directly supported by AdMob.

Our implementation guide for rewarded video adapters (Android | iOS) outlines how to implement an adapter that can serve rewarded video ads from a third party ad network. Special attention should be paid to steps specific to custom events that are summarized below:

Adding a custom event to your ad unit

To define a custom event, you must first create it in the AdMob interface at You can find instructions for creating a custom event in this help center guide.

Retrieving server parameters

The optional server parameter passed to your custom event is accessed via a special key. Here’s an example showing how to access the value in a rewarded video adapter:


String parameter = serverParameters.getString(


NSString *parameter = [self.connector.credentials

You can find additional documentation on rewarded video ads in our Get Started guides (Android | iOS), and more information about mediation is available in our mediation guides (Android | iOS). For any other questions about rewarded video mediation, you can reach us through our developer forum.