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

• Batch job support for shopping BatchJobService in all versions of the AdWords API now supports AdGroupCriterionOperations that modify shopping ProductPartitions. Check out the updated Batch Processing guide for details.
• Current attribution model reporting Several fields were added to reports to allow you to view historical stats using your current choice of attribution model.
• Message extensions You can now create message extensions via extension setting services to let customers send you a text message from your mobile ads.
• Affiliate location extensions You can now create affiliate location extensions to include the locations of stores where your product is sold in your ads. The updated Location Extensions guide has step-by-step instructions to help you get started.
• More policy details The new policySummary field of AdGroupAd provides additional details behind the approval status of your ads. For example, you can now differentiate between Approved (limited) and Approved ads.
• Showcase Shopping ads The AdWords API now supports Showcase Shopping ads which help customers discover what to buy and where to buy it. More details are in the updated Shopping Campaigns guide.
• Enhanced CPC for maximize clicks bidding strategies You can now opt in or out of enhanced CPC on standard TARGET_SPEND bidding strategies.

If you’re using v201605 or v201607 of the AdWords API, please note that they are now deprecated and will be sunset on March 28, 2017 and June 27, 2017, respectively. We encourage you to skip v201609 and migrate straight to v201702.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201702 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff on behalf of the AdWords API Team

At the moment, location extensions in AdWords can be sourced from two different places: a Google My Business account that is linked to your AdWords account or - for legacy users - manual location extensions created as feed items in AdWords.

What’s changing?
We’ll sunset manual location extensions on May 20, 2017 for all legacy users. You’ll no longer be able to manually create and manage Feed and FeedItem with a corresponding FeedMapping of placeholderType 7 (location extensions) and placeholderType 77 (location targeting) after this date. Instead, create your locations in Google My Business and link them to your AdWords account as outlined in our Location Extensions guide. You can use the Google My Business API to manage your business locations at scale.

What you should do
Please migrate your code before May 20, 2017 to avoid being impacted by this transition. See our guide for managing location extensions for further details, including an end-to-end code example. We recommend migrating your existing legacy locations alongside your code in order to have full control over your Google My Business account structure, test your setup, and avoid any downtime in location extension management. If you're not concerned about downtime, let us migrate your existing manual location extensions for you (you still have to migrate your code).

Auto-migration
All unmigrated manual location extensions stored in AdWords will be gradually auto-migrated starting from May 22, 2017.

• For each Customer Account with unmigrated manual location extensions, we'll pick all Manager Accounts at the lowest level of the manager hierarchy.
• For each such Manager Account, we'll create a single Business Account in Google My Business managed by the administrative users of the original Manager Account and its managers. The name of this Business Account will be ‘AdWords (<cid>)’, where <cid> is the AdWords Customer ID of the original Manager Account.
• We’ll also create Business Accounts in Google My Business for Customer Accounts not linked to any Manager Account. Those will be managed by the administrative users of the Customer Account.
• For each unmigrated location in the Customer Account, we'll create a new unverified business location in that Business Account and label it with its AdWords Customer ID. The original manually created feed items representing that location in AdWords will be removed.
• We'll replace all unmigrated location extension and location targeting feeds with new feeds linked to the shared Business Account created in Google My Business. In each feed, we'll set up a labelFilter based on the Customer ID to map each location to its original account.
• Any existing CampaignFeed and AdGroupFeed will be recreated to match the original setup, including their matching functions.

If you have questions while you’re upgrading, please reach out to us on the AdWords API forum.
- Timo Bozsolik, AdWords API Team

Starting in March, DoubleClick Campaign Manager (DCM) will be undergoing scheduled maintenance to make important updates to our systems. Every DCM account will be assigned a single maintenance window. However, these windows may be on different days for different accounts. More information about how this will affect the DCM product can be found in our help center.

How will this affect API users?

Maintenance is expected to last up to 8 hours per account. During that time DCM Trafficking will be read-only. While in read-only mode, all API delete, insert, patch, and update methods requiring the DCM Trafficking scope will be disabled. See the Scheduled Maintenance page on our developer site to learn more about the methods that will be impacted and the errors you may encounter.

What can API users do to prepare?

If your application accesses a single DCM account, we recommend simply planning ahead to avoid running workflows that use affected API methods during your account's maintenance window. Details of when this window will occur will be communicated in advance via in-product notification.

If your application accesses multiple DCM accounts, you may be subject to multiple maintenance windows. If it's not possible to plan around these windows, you should prepare your application to catch and handle maintenance related errors. Recommended error handling strategies include:

• For user initiated requests, return an error to the user along with instructions to wait up to 8 hours before retrying the request.
• For server initiated requests, retry automatically using an exponential backoff strategy. For example: pause 30 seconds before the first retry, 1 minute before the second, 2 minutes before the third, and so on up to a maximum of 8 hours. This strategy helps ensure you're not calling the API too aggressively and that your request quota is not being wasted.

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

- Jonathon Imperiosi, DCM API Team

Today we're pleased to announce the v201702 release of the DFP API. This release adds a new PublisherQueryLanguageService table: Change_History. This table contains entries for changes to entities in your network. This allows for the long-awaited ability of querying for DFP entity changes programmatically.

Additionally, v201702 adds the NativeStyleService, which allows you to read, create, and update native styles.

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

With each new release comes a new deprecation. If you're using v201605 or earlier, it's time to look into upgrading. Also remember that v201602 will be sunset at the end of February 2017.

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.

 - Chris Seeley, DFP API Team

One of the most important factors in keeping users on your page or in your app is latency - the lower your latency, the more likely your users are to stick around. With this in mind, we'd like to remind you about our best practices for reducing latency with the IMA SDKs. In general, you can reduce latency by doing as much IMA set-up work as possible on page or app load, before your user tries to play a video. The following can be done in all of the SDKs before the user attempts to play a video:

• Creating your ads loader.
• Creating your ads request.
• Requesting ads.
• Obtaining the ads manager.
• Registering ads manager event handlers.

You can find more information on optimizing latency in each of our SDKs at the links below:

• HTML5
• Android
• iOS
• Flash

As always, if you have any questions, feel free to contact us via the support forum.

 - Shawn Busolits, IMA SDK Team

What’s happening?
In March 2017, we will stop supporting the Budget Optimizer and Conversion Optimizer bidding strategies in AdWords. These strategies have long been unavailable for user opt in. We will migrate existing campaigns that use these legacy strategies to use their replacement counterparts which offer identical features:

• Budget Optimizer -> Target Spend
• Conversion Optimizer -> Target Cpa or Manual CPC

There will be no change in performance after the migration.

What do I need to do?
If you are satisfied with your current Budget Optimizer or Conversion Optimizer setup, then you don't need to do anything to your existing campaigns -- Google will automatically migrate them for you.

If you prefer manually migrating your campaigns before the automatic migration begins, you may refer to the automatic migration steps below. Refer to our bidding guide and help center articles on target CPA and target spend strategies to learn more about the new bidding strategies.

What will the automatic migration do for Conversion Optimizer campaigns?

• Convert the campaign's bidding strategy to standard target CPA.
• Identify all ad groups of the campaign and their CPA bids, calculate the most common CPA bid value, and set the campaign's target CPA value to this value. If no CPA bids exist, Google sets the campaign's target CPA to the minimum billable unit.
• Pause any ad groups that do not have a CPA bid. This prevents previously inactive ad groups from inheriting the campaign's new target CPA value and inadvertently serving.

What will the automatic migration do for Budget Optimizer campaigns?

• If no ad group level bidding strategy overrides exist, update the campaign’s bidding strategy to a standard target spend strategy. If the enhancedCpcEnabled field is set to true for the budget optimizer strategy, set it for the target spend strategy also.
• If some--but not all--ad groups have overrides, update the the campaign’s bidding strategy to a new portfolio target spend strategy. This preserves the ad group level bidding strategy overrides.
• In the rare case that all ad groups have overrides, update the campaign’s bidding strategy to standard manual CPC. The campaign level bidding strategy doesn’t matter in this case since all the ad groups have overrides. However, changing the campaign’s bidding strategy to manual CPC helps us avoid creating portfolio target spend strategies for each ad group in the campaign.

As always, if you have any questions about this change or other API features, please post on the forum.
- Mike Cloonan, AdWords API Team

In accordance with our deprecation schedule, we'll be sunsetting versions 2.5 and 2.5beta1 of the DCM/DFA Reporting and Trafficking API on February 28th, 2017. On this date, all requests made against these versions will begin returning HTTP 403 errors.

If you're still working with these versions, 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.

- Jonathon Imperiosi, DCM API Team