Category Archives: Ads Developer Blog

The official blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs

Changes to responsive ads in the AdWords API and Google Ads API

What's changing?
Starting May 15, 2019, AdWords API and Google Ads API requests that attempt to create or modify a responsive ad will fail. Make sure you migrate to the new asset-based responsive display ad before the deprecation date.

Due to changes and improvements to ad types in Display campaigns, keeping track of the names in the UI and APIs can be tricky, so here's a quick overview:
Ad type in the UI AdWords API type Google Ads API type
Responsive ad ResponsiveDisplayAd ResponsiveDisplayAdInfo
Responsive display ad MultiAssetResponsiveDisplayAd Available in an upcoming release

After the deprecation date, behavior of the APIs will change as follows:
  • AdWords API
    • AdGroupAdService requests that attempt to create a ResponsiveDisplayAd will fail with the error AdGroupAdError.CANNOT_CREATE_DEPRECATED_ADS. The API will continue to allow you to remove ResponsiveDisplayAds and modify the status of existing ads.
    • AdService requests that attempt to modify a ResponsiveDisplayAd will fail with the error AdError.CANNOT_MODIFY_AD.
  • Google Ads API
    • AdGroupAdService requests that attempt to create a ResponsiveDisplayAdInfo will fail with the error AdGroupAdError.CANNOT_CREATE_DEPRECATED_ADS. The API will continue to allow you to remove ResponsiveDisplayAdInfos and modify the status of existing ads.
Both APIs will continue to return performance statistics for the deprecated ad types.

Why is this happening?
In October, 2018, responsive display ads replaced responsive ads as the default asset-based ad type for the Display network. To simplify the product suite, we'll be deprecating creation and modification of responsive ads.

What should you do?
Before the deprecation date: If you have any questions or need help, please contact us via the forum.

Upgrade Dynamic Search Ads in AdWords API and Google Ads API by March 6, 2019

Upgrade your AdWords API and Google Ads API ads to use ExpandedDynamicSearchAd (EXPANDED_DYNAMIC_SEARCH_AD) instead of DynamicSearchAd (DYNAMIC_SEARCH_AD) by March 6, 2019. After March 6th, creating these ads through the APIs will fail with an AdGroupAdError.CANNOT_CREATE_DEPRECATED_ADS error, while updating them will result in an AdError.CANNOT_MODIFY_AD error. Existing DynamicSearchAds will continue to serve.

An ExpandedDynamicSearchAd goes beyond automating just headlines and adds the advantage of automating display URLs, so that the subdomain of your ad matches the subdomain of your landing page. In addition, Google Ads will add a path when it expects the path to outperform a plain URL. In order to increase the performance for all our advertisers, Google Ads is moving everyone to the newer format.

If you have any questions while upgrading, please reach out to us on our forum.

Announcing v201902 of the Google Ad Manager API

We're happy to announce that v201902 of the Google Ad Manager API is available starting today. The two main areas that are getting new API functionality are forecasting and video.

In v201902, you can set LineItems to be paced based on their projected traffic instead of their historical traffic by setting DeliveryForecastSource to FORECASTING. This API version also adds the AdjustmentService to manage traffic forecast adjustments. For example, if you’re expecting an increase in traffic for an upcoming holiday, you can manually adjust your forecasts to take that increase into consideration.

There are also several updates to video features in this version of the API. You can now target LineItems by CmsMetadataValues (content targeting) and custom AdSpots (position targeting).

For a full list of API changes in v201902, see the release notes.

For questions about this or any other API changes, reach out to us on the Ad Manager API forum.

Subscribe to our RSS feed to get blog posts via email

(If you want to continue getting email updates about our blog posts, read on. If you don't want email updates from this blog, you can skip this post.)

For some products, the Google Ads Developer team has used Google groups as a way to allow API users to subscribe and get new relevant blog posts delivered to their email address. Starting now, the way you can get email updates about blog posts is changing. We will no longer send an email to the Google group for each new blog post. We will continue to use the Google groups for other important updates, however.

For users who still want email updates, we've introduced new FeedBurner links on the right-hand panel of our blog homepage. You can subscribe to the RSS feed by clicking on the link for the product you're interested in, or subscribe by email by clicking on the [+] link to the right of the product name.

If you use any of the APIs that we discuss on this blog, make sure you subscribe to the feed to keep up with the latest news and updates:

Announcing v3.3 of the DCM/DFA Reporting and Trafficking API

Today we're releasing v3.3 of the DCM/DFA Reporting and Trafficking API. Highlights of this release include:

Details of these and all other changes are covered in our release notes.

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v3.2, which will sunset on August 31, 2019. After this date, any requests made against v3.2 will begin returning errors.

As a final reminder, API version 3.1 will be sunset on February 28, 2019. To avoid an interruption in service, all users are required to migrate to a newer version before 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!

Sunset of XML support in the Content API for Shopping

What's changing?
Starting September 1, 2019, the Content API for Shopping will no longer support requests or responses with XML payloads. All requests with an XML payload will fail after the sunset date.

Why is this change happening?
Version 2 of the Content API for Shopping changed the default request and response format from XML to JSON, and version 2.1 of the API (currently marked experimental) will not support XML. The majority of API requests now use JSON, so we've decided to sunset XML support and instead focus on enriching our JSON APIs with new features and functionality.

What should you do?
Prior to the sunset date, identify the components of your application that are using XML payloads for any of the following impacted services: For each case, modify your application to:
  • Send the request body as JSON.
  • Ensure you have removed the alt=xml parameter from the request.
  • Process the response as JSON.
  • Test your updated application using a separate test account.
Tip: The client libraries for .NET, Dart, Go, Java, JavaScript, Node.js, Objective-C, PHP, Python, and Ruby will send JSON requests and parse JSON responses for you. We strongly recommend that you use one of the libraries so you won't have to write marshalling and unmarshalling code in your application.

When converting a given request, you can use the JSON and XML tabs in the Request body section of the documentation for the method. For example, here's a partial screenshot of the XML tab for Inventory.set:

The corresponding JSON tab for that method is:

Compare the two tabs and use that as a guide when converting your request from XML to JSON.

You can find similar JSON and XML information for the response in one of the following locations:
  • Directly in the Response section for the method.
    Example: The productsCustomBatchResponse for Products.custombatch.
  • In the Resource representations section of the documentation for the resource returned in the response.
    Example: The products resource for Products.insert.
If you have any questions or feedback about this change, or any other questions about the Content API for Shopping, please let us know on the forum.

Register now for the upcoming Google Ads API Workshops!

We're excited to announce that a new series of Google Ads API Workshops are coming this March and April! The technical sessions focus on migration from the current AdWords API so you can migrate quickly and efficiently. New users are welcome and will benefit as well.

The workshops will be presented in English, except for those in Taipei, Tokyo, and Shanghai. Details are listed below. Note that location names link to the registration websites: Workshops in all locations will cover the same topics, so choose a location that works best for you. Once you register, we'll send you an email confirmation.

Stay tuned for more detailed agenda on the workshop websites!

If you have any questions about the workshops, you can post them on our forum.

Update on issue reporting changes in the Content API for Shopping

In August, 2018, we announced that we would stop populating the dataQualityIssues field in Productstatus and Accountstatus resources in December of last year. Due to the recent holiday season, we decided to hold off on that change, but it will now be made starting February 25, 2019.

Please review the previous blog post for important details, including how to use the new and improved itemLevelIssues field in your platform's integration with the Content API for Shopping.

If you have any questions or feedback about this change, or any other questions about the Content API for Shopping, please let us know on the forum.

New Required Header for Google Ads API Requests

Starting February 11, 2019 if you are making Google Ads API requests using OAuth credentials from a manager account and are accessing a related customer account, you will need an additional HTTP request header/grpc metadata field. You will need to set the login-customer-id header to the customer ID of the manager account, removing any hyphens in the ID.

Setting this new header is essentially equivalent to choosing an account in the Google Ads UI after signing in, and it’s configurable in the client libraries. Each library has instructions in its README that explain how to set a login-customer-id in your local configuration. Here are links to all relevant sets of instructions in each library: If this header is not set, you may begin seeing the error: USER_PERMISSION_DENIED.

For more details on request headers, including login-customer-id, see our documentation.

If you have questions, please reach out to us on the Google Ads API forum.

Creating Smart Shopping campaigns with the local inventory ads setting enabled will be rejected

Starting Feb 15, 2019, in all AdWords API versions and in the Google Ads API, we’re going to reject requests that attempt to create a Smart Shopping campaign with the local inventory ads setting enabled. The local inventory ads setting is equivalent to setting enableLocal to true in the AdWords API, and enable_local to true in the Google Ads API. Trying to set those fields to true when creating a Smart Shopping campaign will result in the OperationAccessDenied.OPERATION_NOT_PERMITTED_FOR_CAMPAIGN_TYPE error. Previously, those fields were ignored when passed to the API servers.

Why is this happening?
Throwing an error for the requests described above provides an alert to users that local inventory ads are not supported in Smart Shopping campaigns.

What should you do?
Make sure you do not have code that creates a Smart Shopping campaign with local inventory ads enabled. Specifically, when you create a ShoppingSetting object for a Smart Shopping campaign, take either of the following actions: Follow the guides below for details on how to create a Smart Shopping campaign: As always, if you have any questions or concerns, please post them on our forum.