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.

Posted:
Last year, we announced that you have until February 1st, 2017 to upgrade from ExperimentService to the new campaign drafts and experiments introduced in v201603. After this date, you’ll no longer be able to use ExperimentService.
  • API calls to ExperimentService across all API versions will result in an error
  • All experiments running via ExperimentService will be stopped
  • All ExperimentService experiments will be deleted and their stats will be unavailable
Check out our Campaign Drafts and Experiments guide for examples while upgrading your code. If you have questions while you’re upgrading, please reach out to us on the AdWords API forum.