In August, we announced that returned Productstatuses would include any validation issues. Unfortunately, the way validation issues used the severity field differed from data quality issues, which led to confusion.

To clarify which validation issues are serious and which are just warnings, we will use the same mapping for validation issues as we do for data quality issues. In addition, we have published an accompanying guide, API Issue Severity and Diagnostics Issue Prioritization, which discusses how to compare the issue prioritization used in the Diagnostics section of the Merchant Center to the issue severity provided in the responses from the Productstatuses and Accountstatuses services.

As always, if you have any questions about these changes or any other questions or feedback about the Content API for Shopping, please let us know on the forum!

Since we introduced expanded text ads (ETA) earlier this year, we’ve recommended that advertisers create and test multiple ETAs to determine what messages perform best for their business. To help you do this at scale, we’ve created the ETA Transition Helper, a powerful tool that allows you to easily create ETAs in bulk using AdWords Scripts and Google Sheets.

This tool helps you save time by using your existing standard text ads (STAs) as a blueprint for your new ETAs. The ETA Transition Helper ensures your expanded text ads are formatted according to the new character limits and that their display URLs use the final URL's domain. After creating the new ETA, the tool displays your current STA and the new ETA side-by-side in a Google Sheet so you can easily compare the two ads. Please note that the tool's interface is only offered in English at this time, but it supports exporting STAs and creating ETAs in all languages.

As a reminder, starting January 31st, 2017, you will no longer be able to create or edit STAs, though existing STAs will continue to serve alongside ETAs.

Get started by checking out the user guide. You can also contribute to the ETA Transition Helper project on GitHub today. If you have any questions or would like to provide feedback, feel free to contact us on the AdWords Scripts Forum.


On February 1, 2017, we will implement a new deprecation policy for the IMA SDKs for iOS and Android. The Flash and HTML5 SDKs are unaffected by this policy because they are downloaded at runtime, so all developers are always using the latest version.

Each release will be deprecated 12 months after its successor is released.

As of February 1, 2017, the following SDK versions will no longer be supported:

  • IMA Android prior to version 3.1.3
  • IMA iOS prior to version 3.1.0

If you are currently on one of these versions, we strongly suggest upgrading to the latest version before the new policy takes effect.

Once an SDK version is deprecated, we cannot guarantee that version will continue to work. If we receive reports of crashes related to a deprecated version of the IMA SDK, we may discontinue serving ads to that version. We will also no longer field support requests for these versions on the IMA SDK support forum.

To maintain support, publishers on the latest version of an SDK will have 12 months to move to a new version once its successor is released. To "support" an SDK means we will investigate bugs in that SDK version and work on fixes. If a bug fix requires a change to the library itself, the fix will be applied to the newest version.

For a list of supported SDK versions and their deprecation dates, see the new deprecation schedule pages for iOS and Android. As always, if you have any questions, feel free to contact us via the support forum.

Over the next month, AdWords is rolling out to all accounts two new ways to customize your ads.
  • Default values in Ad Customizers give you an option of providing a default value when referencing a custom value from a feed. This means that you will no longer be required to provide a static ad in your ad group when using ad customizers. Woohoo!
  • IF functions let you insert a customized message in your ad based on who’s searching and what device they’re searching on, all without using a feed.
Default values in Ad Customizers
  • What’s changing? The existing syntax for inserting a custom value from a feed is {=FeedName.AttributeName}. The new syntax allows for an optional default value {=FeedName.AttributeName:default value}, but you can still use the existing syntax if you don’t want to specify a default value. Check out the Customizing text ads guide to learn more about setting up an ad with ad customizers.
  • How does this affect me? If you have colons in your or in your, then add a backslash before the colon to escape the colon. Having a colon without a backslash causes anything after it to be interpreted as a default value when used in an ad customizer. If you no longer want to have a static ad in your ad group, then start adding default values to your ad customizers and delete the static ad.
IF functions
  • What’s changing? The new IF function allows text to be specified in a text ad based on device or audience, with the default text being optional. If default text is not specified, then a static ad is required in the ad group. The syntax is:
    • {=IF(device=mobile,text to insert):optional default text}
    • {=IF(audience IN(<userlist1>,<userlist2>),text to insert):optional default text}
  • How does this affect me? If you want to add customized text to your ad based on device or audience, start adding the IF functions to your text ads. For examples, check out the Customizing text ads guide.
Questions? Visit us on the AdWords API Forum or our Google+ page.


Integrating with the IMA SDK for Android has historically meant implementing the VideoAdPlayer interface and playing video ads in your content player. While this approach offers maximum flexibility, it also requires a lot of extra work to get up and running. In our mission to make developers' lives easier, we are proud to offer an alternative: SDK-owned ad playback, added in our newest release, v3.5.2.

Using SDK-owned ad playback, the SDK takes care of playing ads in its own player, allowing you to focus on content playback and the normal ad request flow in your player. With SDK-owned playback, you no longer have to implement a VideoAdPlayer, or worry about VideoAdPlayerCallbacks. Enabling SDK-owned playback is straightforward: simply omit the setAdPlayer call on your AdDisplayContainer.

With the new, simplified integration flow using SDK-owned playback, integrating with the IMA SDK for Android is easier than ever! For a step-by-step guide, head over to our revamped Get Started guide or download the BasicExample project from GitHub and try it out.

SDK-owned ad playback allows publishers to simplify their IMA implementation, but using it is not required. If you already have a VideoAdPlayer implementation or want to use a single video player for both ads and content, you can keep using custom playback. SDK-owned playback merely gives you the option to let the SDK handle some of the implementation complexity for you.

If you have any questions about SDK-owned playback, feel free to contact us via the support forum.

Earlier this year, we added support for managing price extensions to the AdWords API. This included the addition of PriceFeedItem to extension setting services in v201607, and placeholder type ID 35 to feed services in all versions of the AdWords API. At that time, both supported only English price extension type, price qualifiers and price units.

Starting today, we are rolling out support for additional languages in price extension types, price qualifiers and price units. Price extensions’ headers and descriptions will be reviewed in the context of the specified language, and those written in languages other than the specified one will be disapproved.

How to use this feature Note: All PriceTableRow entries must have the same currencyCode or you will get the ExtensionSettingError.INCONSISTENT_CURRENCY_CODES error.

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

In July we announced that starting in August 2016, all versions of the DFP API would return HTTP 401 errors instead of SOAP AUTHENTICATION_FAILED errors. We have learned that some developers have been relying on catching an AUTHENTICATION_FAILED error to know when to refresh an access token. This is not the recommended way to determine when your access token needs refreshing and is not supported.

The change described above will break code that relies on catching an AUTHENTICATION_FAILED error. We have temporarily rolled back the change to give developers who haven’t migrated more time to update their code and will roll this change out again on November 30, 2016 and ask that you update your code before then.

Note: If you’re taking advantage of our client libraries, no change is required; our client libraries handle refreshing an access token with our recommended approach.

Instead of relying on an AUTHENTICATION_FAILED error, the recommended way is to calculate how soon the access token is going to expire before making an API call, and refresh it if it’s about to expire soon.

  • Whenever you obtain a new access token, calculate the token’s expiration time by adding the expires_in time returned with the access token to the current time.
    • For example, if you received an access token on Oct 21, 16:05 EDT and the access token lasts for 3600 seconds, the token would expire on Oct 21, 17:05 EDT.
  • Then, before every DFP API call, check when the access token will expire before using it: if it is going to expire within a certain time window (say, in the next 60 seconds), you should refresh it before making the API call.
    • To calculate this, subtract the current time from the token’s expiration time that you calculated above.
You can see an example of how this is done in our Java client library and use it as a reference to help you implement the above.

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