Read More

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.


-- AdWords API Team

Read More

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.

- Michael Cloonan, AdWords API Team

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.

Read More

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.

 - Chris Seeley, DFP API Team

Read More

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.

-- Dean Lukies, Ads Developer Relations

Read More

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.

- Michael Cloonan, AdWords API Team

Today we’re releasing v7.0.0 of the Google Mobile Ads SDK for iOS. For this release, we focused on making the SDK easier to use, including distributing it as a framework. We’re also showing our DFP publishers some love by launching new first-class APIs to support the common DFP features they’re already using with Google Publisher Tag. A detailed list of these and other changes can be found on our release notes page.

Read More

Today we’re releasing v7.0.0 of the Google Mobile Ads SDK for iOS. For this release, we focused on making the SDK easier to use, including distributing it as a framework. We’re also showing our DFP publishers some love by launching new first-class APIs to support the common DFP features they’re already using with Google Publisher Tag. A detailed list of these and other changes can be found on our release notes page.

SDK as a framework

The SDK is being distributed as a framework in this release. This comes with the following benefits:

• You only have to add one item to your project. No more worrying about adding headers separately!
• The SDK automatically links frameworks it depends on. No more manually adding framework dependencies!
• Classes that use the SDK can now automatically import the necessary headers files with a single line of code:

  @import GoogleMobileAds;

  Previously, you had to import header files separately.

  #import "GADBannerView.h"
  #import "GADBannerViewDelegate.h"
  #import "GADRequest.h"
  

If all that wasn’t awesome enough, we also removed the need to include the -ObjC linker flag in your project! Just drag in the library to start using it.

If you’re using CocoaPods, you automatically get all of these changes by referencing version 7.0.0 of the Google-Mobile-Ads-SDK podspec. Since this is a major release, make sure you update your Podfile to grab major version 7:

pod 'Google-Mobile-Ads-SDK', '~> 7.0'

Introducing new friendly DFP APIs

Version 7.0.0 also adds first-class support for custom targeting and category exclusions in a brand new DFPRequest object.

DFPRequest *request = [DFPRequest request];
request.customTargeting = @{
  @"gender", @"male"
};
request.categoryExclusions = @[@"cars", @"sports", @"pets"];

New to 7.0.0 is the ability to roadblock creatives and prevent competing ads in mobile apps. The SDK does this by adding an updateCorrelator method with similar functionality to the same method in GPT:

[DFPRequest updateCorrelator];

All subsequent DFP ad requests will use the new correlator value until the correlator is updated again. Requests with the same correlator are capable of being roadblocked, and will not serve competing ads.

For more information on the DFP API improvements, see the developer docs.

Dropping support for iOS 5

With this release, we are also dropping support for iOS 5. We’ve noticed that almost all users are running iOS 6 or higher, and dropping support for older versions means the library can take advantage of the newer iOS APIs and offer more stability for you and your users. The SDK now supports only iOS 6.0 and up.

Sounds great! Where can I download the SDK?

As always, the latest SDK can be found on our downloads page. If you have any technical questions about these updates, drop us a line on the forum.

 - Eric Leichtenschlag, Mobile Ads Developer Relations