We're pleased to announce that the AdWords API Workshops are coming back for another round in October and November of 2013. Registration is now open.

Workshop topics include:
  • The latest on the AdWords API and newly released features
  • AdWords API Best practices and OAuth migration
  • In-depth coverage of reporting, billing, feed services, and more
  • Drop-in tools you can use to enhance your platform
  • Building landing pages optimized for mobile devices

The workshops are a great way for you to meet with and ask questions of the Google AdWords API team in person. This is also a key occasion for members of the community to bring their feedback directly to us. It’s also a great opportunity for you to exchange ideas and best practices with fellow developers.

Register now and join us at a workshop in one of the following cities:
  • Paris, France, October 28 (in English)
  • Hamburg, Germany, October 30 (in English)
  • London, UK, November 4 (in English)
  • New York City, USA, November 4 (in English)
  • San Francisco, USA, November 8 (in English)
  • Moscow, Russia, November 8 (in Russian)
  • Tokyo, Japan, November 11 (in Japanese)
  • Buenos Aires, Argentina, November 22 (in Spanish)
  • São Paulo, Brazil, November 26 (in Portuguese)

The workshops in the USA and Europe are technical in nature and best suited to developers. Those in Argentina, Brazil, and Japan will have additional sessions accessible to a broader audience, including non-developers.

For more information on the agenda, location and logistics, please visit the Q4 2013 AdWords API Workshop website.

 - Marc Wandschneider, AdWords API Team


We've recently made several enhancements to version v1.3 of the DoubleClick Ad Exchange Buyer REST API. To make it even easier for buyers to work with the DoubleClick Ad Exchange, our team is improving the functionality of our APIs. Today we would like to let you know about some recent enhancements to version v1.3 of the Ad Exchange Buyer REST API. Below are the details of the new features and stay tuned for more releases over the coming year.

Performance Report Resource

A new resource, performanceReport, has been added. This resource is an improvement on the existing CSV performance reports. You can now use the API to view these reports in JSON format and without having to interface with Google Cloud Storage. These reports are aggregated over 5 minute intervals rather than the 1 minute intervals that the CSV reports use.

Creatives Resource

We’ve improved the creatives resource with the addition of two new sets of fields: filtering reasons and corrections. The filteringReasons are intended to give you better insight into why some snippets have been filtered out of the auction. The Buyer REST API will show you the metrics for the previous day. If you’d like to see longer term filtering metrics, they can be found in the Snippet Status Report.

The corrections field is intended to help you correctly submit creative declarations. We recommend using our corrections as feedback to update your application to submit the right attributes, ensuring your ads serve correctly and on time.

You can always find a listing of the latest updates on our release notes page. Your feedback and questions are welcome on our forum or Google+ Page. Let us know what you think!

Version 1.1 of the Ad Exchange Seller REST API is now available, and with it comes three new features:
This version is fully backwards-compatible with v1, so the changes required to upgrade are minimal, but we've prepared a migration guide to help you through the process.

Give the new version a try, and be sure to take a look at our Google+ Page for Ads Developers!

As previously announced, the old Java library for AdWords and DFP APIs have now been deprecated and support for new API releases won’t be added after the end of 2013.

We’d like to remind you of some important features you will benefit from by migrating to the new Java library.

OAuth2 support
The new Java library supports OAuth2, which is the recommended authentication mechanism at Google. As we mentioned in our previous post, there are many benefits to using OAuth2 and ClientLogin will be eventually sunset.

Maven support
The new Java library is hosted on Maven, which manages jar dependencies through its pom.xml instead of managing a lot of jars manually.
Note: See this pom.xml for AdWords or this pom.xml for DFP for a complete example.

You can check out the QuickStart guide including how you can get started with OAuth2 and Maven with the new Java library and MigrationGuide on how you can migrate from the old library.

If you find any bugs or feature requests, feel free to file an issue on our issue tracker.
As always, please feel free to ask any questions on the AdWords API forum or DFP API forum or our Google+ page.

We recently enhanced the documentation site for Google scripts by including more content and improving site navigation. The major changes are:
  • A new and improved introduction to AdWords scripts.
  • A new section named “Solutions” that consolidates existing tutorials with 10 new ready-to-use scripts.
We are constantly striving to improve our documentation to make getting started with AdWords scripts even easier. If you have ideas for enhancing the documentation, let us know on our official forum or through the feedback link on each document page.

We are glad to announce support for Google Drive in AdWords scripts. The functionality is exposed through the DriveApp bean that allows scripts to create, find, and modify files and folders in Google Drive. Scripts uses OAuth2 as the authentication mechanism to determine which files the current user has access to on Google Drive.

One of the potential use of Drive is as an intermediary data storage between your application and your script. A couple of hypothetical use cases are:

Manage ads by inventory
  • First, install a Google Drive client locally on your computer and map a local disk folder to your “My Drive” folder in Google Drive.
  • Write an internal script to query the inventory database and dump results into an XML file to your local Google Drive folder.
  • Write an AdWords script that reads that same file using DriveApp and pauses or enables ads accordingly.
Importing stats to a local database
  • Install a Google Drive client locally on your computer and map a local disk folder to your “My Drive” folder in Google Drive.
  • Write an AdWords script that fetches daily stats and dumps them into a CSV file on Drive daily.
  • Create a local cron job to read that file and push its data into a local database.
DriveApp gives you certain advantages over SpreadsheetApp and UrlFetch APIs when exchanging data with your local server.
  • Google Spreadsheets have size limitations, and is not the format of choice for all our developers.
  • UrlFetch is more flexible than DriveApp, but it requires you to set up your own local server to exchange data with Scripts in a secure manner.
We hope you enjoy this new feature. If you have questions or feedback, please visit us on our official forum.


A few months ago, we launched version 1.20 of the DFA API. Now that version 1.20 has been out for some time, we are recommending it as the primary version for all new development. Version 1.19 remains the minimum for upgrading to DCM.

We are glad to announce support for upgraded ad extensions in AdWords scripts. Ad extensions give potential customers more reasons to click your ad by including additional business information upfront such as your address and phone number or more website page links.

We currently support sitelinks, call extensions, and app extensions in Scripts. You can refer to our documentation to learn more about this feature as well as get sample code snippets.

We currently support the following capabilities in AdWords scripts:
  • Create various ad extensions at account level.
  • Associate ad extensions with campaigns and ad groups.
  • Modify existing ad extensions.
  • Remove an ad extension’s association with a campaign or ad group.
  • Retrieve stats for various ad extensions at account, campaign or ad group level.
Keep in mind that
  • We only support ad extensions in Feeds created by the AdWords system. If you created a Feed using the AdWords API, then these items won’t be retrieved by AdWords scripts.
  • You may not delete ad extensions at the account level. You can only delete its association with a campaign or an ad group.
We hope you enjoy this new feature. If you have questions or feedback, please visit us on our official forum.

ClientLogin support has been deprecated across Google in favor of the security enhanced OAuth2 authentication mechanism.

AdWords and DFP will be sunsetting ClientLogin support in all API versions to be released, starting in 2014. To ensure uniform, and high, standards of privacy and security for our advertisers and publishers, we will support only OAuth2 in the future.

All current AdWords and DFP API versions, and those released during rest of year in 2013 will continue to support ClientLogin. The client libraries will retain support for ClientLogin authentication until 2013 API versions are sunset.

2013 AdWords API versions are expected to be sunset in June 2014. We will have a follow up announcement for DFP APIs.

For uninterrupted use of the APIs, please migrate to OAuth2 as soon as possible. To help you migrate, we’ve put together a comprehensive set of OAuth2 information including a video overview, links to documentation and a full list of client library resources.

With so many users already migrated, most questions have been answered in either the AdWords API forum or the DFP API forum. To get face-to-face assistance, attend one of our upcoming Office Hours sessions focusing on ClientLogin to OAuth2 migration.

Recently we announced how ad inventory shouldn’t be tied to a specific device and how inventory in DFP will be able to accommodate any campaign for any device. In this post we discuss how this affects the API.

API users are strongly encouraged to start using unified target platform enums when creating line items or ad units. For line items, this is the TargetPlatform.ANY enum (available in v201302 and onwards) and for ad units, the TargetPlatform.WEB enum.

Target platforms on existing line items and ad units will remain unchanged. You have the option to update existing line items and ad units to use unified target platforms, but you can’t switch back once you update. You may also still create line items with TargetPlatform.MOBILE or TargetPlatform.WEB and ad units with TargetPlatform.MOBILE through the API. They will work as previously but are deprecated and should not be used. Keep in mind that all new line items and ad units created via the web UI will have unified target platforms.

If you have questions or concerns regarding how DFP’s inventory unification affects API usage, please post them on our DFP API forums.


As previously announced, the AdWords API does not allow you to retrieve data with a large start index.

If you issue a request with a start index is larger than 100,000, the API will return a START_INDEX_IS_TOO_HIGH error.

When you need to retrieve a large set of results, we recommend using one of these approaches:

  1. Narrow the query as much as possible using predicates. Group queries by Campaign and AdGroup to retrieve only required data and to fit all results into one response.
  2. Use AdHoc reporting to obtain data. With reports, you can still retrieve most fields available.

As always, please feel free to ask any questions regarding the AdWords API on our forum.

Today we are launching v201308 of the DFP API, which brings many new and exciting features and a glimpse of the API’s future. This release improves report stability, offers a brand new way to fetch line items through a Publisher Query Language table, the ability to create first party audience segments, and the ability to see contending line item in forecasts. A detailed list of these features and what’s changed can be found on our release notes page.


First off, we heard you loud and clear - reports are very important to you and when a report fails for no apparent reason, it’s incredibly frustrating. Starting today, we are taking major steps towards our goal to fix this. You’ll now notice that large reports, which would otherwise time out or fail with a 502 HTTP status code while fetching the download URL, will now spend more time preparing the report in the runReportJob stage. Some reports may still be too large to run, but any report that runs in the UI will now work via the API as well. We've also made this change behind the scenes, so you’ll start seeing improvements right away without having to switch to v201308. While we know there is still more work to be done, we hope this is a clear sign that we take this issue seriously and are working hard to improve it.

In addition to stability improvements, in v201308, we are launching two highly requested features: targeted criteria reporting and ActiveView (a.k.a. viewability metrics) columns. These features are not available in all networks yet, but you or your third-party will be able to use them as soon as they are rolled out, if your network is eligible.

Publisher Query Language

We are launching two major PQL features today - the LIKE keyword and the Line_Item table, both of which will be made available in all versions.

The LIKE keyword allows you to do wildcard matching for fields. For example, if you pass the filter statement “WHERE Name LIKE 'my order%'” to the OrderService.getOrdersByStatement method, it will match all orders that have a name beginning with ‘my order’ (like ‘my order 1’, ‘my order 2’ and ‘my orders’).

The other exciting feature of this release is the experimental Line_Item table. With this new table, you’ll be able to select only the fields you want for line items using the PublisherQueryLanguageService. For example:

SELECT Id, Name FROM Line_Item WHERE IsMissingCreatives = TRUE LIMIT 1000 OFFSET 0

This allows for extremely efficient synchronization; tasks that would take hours with LineItemService, will now take minutes. We think this will be a great fit for pulling “match tables” and we’ll have a follow-up blog post soon about how to do this. Although we are launching this with a limited set of fields, we have made it a priority to add more in upcoming releases and we’d love to hear your feedback on our forum or Ads Developer Google+ page. If you want to get started playing with these new features now, you can always visit the dfp-playground. Try using the Publisher Query Language section with a query like “SELECT Id, Name FROM Line_Item WHERE name LIKE 'Line Item #%' LIMIT 100”.

Last, but not least

Starting in v201308, we are adding support for creating first party audience segments with the AudienceSegmentService as well as retrieving contending line items with the ForecastService. We know the latter has been a long time coming, so we are looking forward to any feedback.

As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our Ads Developer Google+ page.

 - , DFP API Team

Auto-tagging is an AdWords feature that can help you track your ad performance using custom software or website tracking programs like Google Analytics. When enabled, it automatically creates custom destination URLs with a parameter called gclid added to your landing page URL.

This value is now available to you in the Click Performance Report as the “GclId” field. This means you can now use auto-tagging and easily combine this data with information from other sources, like web analytics or webserver logs, when analyzing conversion performance and optimizing your campaigns.

Auto-tagging is available to all AdWords users, and can be enabled via the User Interface only. It’s a per-account setting available on the My Account -> Preferences page.

Feel free to reach out to us via the G+ page or the forum if you have any questions regarding this feature.