Posted:
Today we're announcing the release of AdWords API v201502. Here are the highlights:
  • Ad extension services. We heard your feedback about Feed Services being overly complex for many cases. To help simplify ad extension management, we've added new ExtensionSetting services. Existing Feed Services are still supported so you can continue using them. Should you decide to migrate to the new services, we've prepared a migration guide.
  • Account labels. We've expanded support for labels to MCC manager accounts. Now you can tag your accounts with text labels programmatically.
  • In-place URL upgrade for ads. The AdGroupAdService now supports upgradeUrl method which simplifies the Upgraded URLs migration.
  • Updates to reporting. Two new reports have been added: UserAdDistance performance and Label. Reporting now supports skipColumnHeader HTTP header which removes column headers from the produced report. We've also added several new columns across reports, see the release notes for the full list.
  • Shared sets. These are now available to all AdWords API users. Check out this feature if you often need to attach large sets of negative keywords or placements to many campaigns.
  • Support for application deep links. You can now create ads linking to specific activities in your application using AppUrlList.
  • Additional controls on Local Inventory Ads. You can now enable local inventory as well as set product channel / channel exclusivity.
  • Cross-account as well as system-defined conversion trackers are now easy to identify. Look at the conversionTypeOwnerCustomerId in ConversionTracker. Accounts using cross-account conversion tracking can be identified using the effectiveConversionTrackingId.
  • Account-level remarketing tags can now be retrieved using CustomerService RemarketingSettings.
  • The new TargetOutrankShare bidding strategy is now supported.

If you're still using v201406 of the AdWords API, please note that it's being sunset on April 6th, 2015. We encourage you to skip v201409 and migrate straight to v201502. If you're using v201409, be aware it's now marked deprecated and will be sunset on July 14th, 2015.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201502 migration guide. The updated client libraries and code examples will be published shortly. With this release, we've also updated the Required Minimum Functionality document to include some of the newly added features. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

Posted:

When announcing version 7.0.0 of the Google Mobile Ads SDK for iOS, we mentioned that developers could roadblock creatives and prevent competing ads in mobile apps.

The launch of the roadblocks feature in version 7.0.0 had an unintended side effect for DFP reservations. By default, ad requests from the same device were getting frequency capped for 30 seconds unless the app called the updateCorrelator method between requests.

To restore the default behavior, we have rolled back the roadblocks feature. What this means is that updateCorrelator effectively does nothing in version 7.0.0. We will relaunch support for roadblocks and competitive exclusions in a future iOS SDK release after improving the feature to preserve the default behavior.

If you have any questions about this change, leave us a note on the forum.

Posted:
If you’re using the AdWords API, you’ve agreed to our Terms and Conditions. These are important so we have a common understanding of basic areas like policy, dispute resolution, and liability.

To help streamline things, we’ve shortened the Terms and Conditions and moved some of the detail to a new Policy Center. We’ve also updated some of the provisions in the terms to better unify the language across different countries’ legal frameworks.

What’s New

The updated Terms and Conditions and the new Policy Center are designed to be a more concise and better organized way for you to understand what’s required of you as a user of the AdWords API. We’ve also tried to clarify which policies apply to you and which ones don’t. For example, we’ve included new language and graphics to explain which types of API tools are covered by Required Minimum Functionality and which are not.

Important Action Needed

In the coming weeks you’ll receive an email (sent to the developer contact listed in the AdWords API Center of your MCC) from the AdWords API team with instructions on how to accept the new Terms and Conditions. Once you receive this email, you’ll be asked to log into the AdWords MCC account associated with your API developer token, navigate to the AdWords API Center, and then follow the prompts to review and accept the new terms and conditions.

We’ll also provide alerts in your account and send you email reminders as needed. Please note that if you haven’t accepted the terms within 45 days of receiving our first email, we’ll consider you to have accepted the terms based on your continued use of your developer token.

Not seeing the new terms when you sign into your account?

Don’t worry! If you’re not seeing the new terms when you sign into your account, there’s nothing more for you to do right now. Because we’re updating the new terms on a rolling basis across all countries, you may be scheduled for a later time. Or your terms may already have been accepted by someone you’ve authorized to act on your behalf (for example, an advertising agency, or someone you’ve authorized to be legally or financially responsible for your accounts).

More Information

We encourage you to read through the updated terms and the Policy Center carefully. For more information about the updated Terms and Conditions and the new Policy Center, including a complete list of countries and territories where these changes apply, please visit this Help Article.


Posted:
Call-only ads in AdWords allow you to show mobile-ready ads that feature a click-to-call button and descriptive text, so your customers can call you directly from mobile search results. The AdWords API v201409 release introduced support for call-only ads through a new creative type: CallOnlyAd.

These new CallOnlyAds are set up just the same way as TextAds, with the addition of a few fields useful for the new type. In Ruby, for example, you would set up a new CallOnlyAd with a hash like this:
{
  :xsi_type => 'CallOnlyAd',
  :description1 => 'Visit the Red Planet in style.',
  :description2 => 'Low-gravity fun for everyone!',
  :display_url => 'www.example.com',
  :phone_number => '(555) 555-5555',
  :business_name => 'Universal Cruises',
  :call_tracked => true,
  :phone_number_verification_url => 'www.example.com/landing_page'
}
You can also set the conversionTypeId if you want to measure calls in a specific conversion type. Otherwise, tracked calls will use a default conversion type.

The phoneNumberVerificationUrl is a new field for CallOnlyAds. If included, we will crawl the page you specify to look for the phone number for verification; this can speed up the approval process. Otherwise, we will have to crawl your entire website.

Previously, call-only ads were set up using feeds, specifically with the ONLY field (placeholder ID 4) within the Call placeholder type (placeholder type ID 2). The ONLY field will sunset in June 2015, so you should finish migrating all your existing call-only ads to the new CallOnlyAd creative type before that time. It is recommended that you create new campaigns to house your CallOnlyAds separately from other ad types.

As always, if you have any questions about this change, please contact us on the forum or via our Google+ page.

Posted:

Today we are releasing v201502 of the DFP API. This release includes a revamp of the ForecastService, including support for Delivery forecasts. There are also new video features including GRP settings on line items, GRP breakdowns in forecasts, and new VIDEO_VIEWERSHIP report columns.

Sales Manager gains three new services for Packages, ProductPackages, and ProductPackageItems. Additionally, the ProposalLineItemService will now return ProposalLineItems that were created from Packages. There's also improved support for workflow rules with WorkflowValidationErrors.

Finally, Type fields have been removed from all entities. Please update your code to use xsi:type, class names, or instance of.

A detailed list of these and other changes can be found on our release notes page.

Using the new ForecastService

The ForecastService can now run Delivery forecasts for multiple line items. These forecasts report the number of units that will be delivered to each line item given the goals and contentions from other line items in the request. Pass prospective line items or line item IDs to getDeliveryForecast or getDeliveryForecastByIds as outlined in this Java example:

    DeliveryForecast existingLineItemForecast =
       forecastService.runDeliveryForecastByIds(new long[] {123L, 456L});

    ProspectiveLineItem prospectiveLineItem1 = new ProspectiveLineItem();
    prospectiveLineItem.setLineItem(myFirstLineItem);

    ProspectiveLineItem prospectiveLineItem2 = new ProspectiveLineItem();
    prospectiveLineItem.setLineItem(mySecondLineItem);

    DeliveryForecast prospectiveLineItemForecast = 
        forecastforecastService.runDeliveryForecast(new ProspectiveLineItem[] {
        prospectiveLineItem1, prospectiveLineItem2});

The existing getForecast and getForecastById methods have been replaced by getAvailabilityForecast and getAvailabilityForecastById, respectively. You must now include AvalilabilityTargetingOptions to specify whether you want to include contending line items or the new TargetingBreakdown.

    ProspectiveLineItem prospectiveLineItem = new ProspectiveLineItem();
    prospectiveLineItem.setLineItem(myLineItem);
    AvailabilityForecastOptions options = new AvailabilityForecastOptions();
    options.setIncludeContendingLineItems(true);
    options.setIncludeTargetingCriteriaBreakdown(true);
   
    AvailabilityForecast forecast = 
        forecastService.getAvailabilityForecast(prospectiveLineItem, options);

Handling Sales Manager Workflows with the API

Updating a Proposal with workflow rules may cause a WorkflowValidationError. The WorkflowValidationError will include a message defined by the network's administrator. For more information about detecting and handling specific error types, refer to this blog post.

As always, if you have any questions or feedback, reach out to us on our API forums.

Posted:
The ability to generate saved reports using the API will be retired on April 6th, 2015, along with six dimensions due to low usage. After the sunset, any API calls to Reports.Saved or requests for these dimensions will result an error.

After the introduction of the Query Tool to the UI last year, the ability to create and edit saved reports in the UI was removed--leading to the sunsetting of Reports.Saved in the API.

The dimensions that will be removed are
  • AD_FORMAT_CODE
  • AD_UNIT_EXTERNAL_ID*
  • AD_UNIT_CODE*
  • DSP_BUYER_NETWORK_ENCRYPTED_ID
  • EXPANSION_TYPE_CODE
  • PLATFORM_TYPE_CODE
[*] these dimensions haven't been relevant for 6 months due to the move to Enhanced Inventory Controls and only are retained in the UI for historic purposes.

To find out if you will be affected, search your code for any of the strings above and remove them; they will be associated with a call to Reports.Generate.

For a full list of available dimensions please see the AdX Seller REST API documentation.

Posted:
Today we’re rolling out access to Upgraded URLs for all AdWords API users. Upgraded URLs provide an easier and faster way to manage and track important information about each click on your AdWords ads. This new feature lets you enter the landing page portion of your URL and your tracking information separately in AdWords. Now you have the option to update your tracking information at your account, campaign or ad group without having to reset your ad stats.

For more information, please check out the AdWords blog. We've also put together a guide on how to set up Upgraded URLs via the AdWords API, which includes examples in each of our client libraries.

One final note: Upgraded URLs are intended to replace the old destination URL field in all relevant ad types. We have built tools to help you update your URLs to the new system, and you have a few different upgrade options, depending on your current URL structure. For more information on the sunset timeline and your options for upgrading, see our getting started guide.

If you have any questions or comments about this new feature, please contact us on the forum or via our Google+ page.