Posted:
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.

Posted:

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.

Posted:

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.

Posted:

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:

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

Posted:
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: 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.

Posted:

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.

Posted:
AdWords offers several different strategies for configuring filters for your Google My Business locations. However, users sometimes choose filters that do not match any locations, which results in no location extensions appearing with ads.

What's changing?
Starting on February 14, 2017, AdWords will perform a daily check to determine if the following location extension feed item filters are not matching any Google My Business locations: If any such invalid filters are found, they will be automatically cleared as outlined in the updated Location Extensions guide.

Please keep the following details in mind:
  • The periodic check will only clear matchingFunction filters on a CampaignFeed or AdGroupFeed for location extensions (placeholderType = 7). It will not clear filters on those objects for location targeting (criterionType = 77).
  • The periodic check will not clear matching functions of the form IDENTITY(false), since these indicate that you want to disable location extensions for a campaign or ad group.
What you should do
  1. To minimize the impact of the periodic check, regularly review your application's location feed setup and ensure that you are choosing filtering options on your PlacesLocationFeedData and matching functions that actually match locations in your Google My Business account.
  2. Make sure that your application will be able to handle the filter changes made by the periodic check.
If you have any questions, please post on the AdWords API Forum.