If you programmatically manage and report on DoubleClick Campaign Manager (DCM) campaigns, you know that trafficking and reporting tasks have traditionally been handled by separate APIs. We realize that this can be inconvenient so today we're introducing a unified solution: the DCM/DFA Reporting and Trafficking API!

This release constitutes a new major version (v2.0) of what was previously known as the DFA Reporting API, adding functionality previously only available in our dedicated trafficking API. While older versions of our dedicated reporting and trafficking APIs will continue to remain available until September 30th, 2015, we recommend that you adopt this updated version as early as possible to take advantage of all of its new and enhanced features.

Unified trafficking and reporting experience

This release combines the trafficking functionality of the DFA API with the reporting functionality of the DFA Reporting API to create a simplified end-to-end experience. It's now possible to manage your DCM campaigns and report on their performance without switching APIs or reauthenticating. In addition, a unified object model allows you to pass data seamlessly between these two systems.

New trafficking functionality

This API expands the feature set of the DFA API to add new and improved trafficking functionality. A few highlights of this expanded functionality include:

• Event tags
• New creative formats
• Tracking ads
• SSL workflow
• Richer search criteria

Updated project quota limits

In addition to increasing the functionality of the API, we've also increased the default project quota limit. All projects can now make 50,000 requests/day (up from 10,000), to support a combined trafficking and reporting workflow. As always, requests for additional quota can be made via the Google Developers Console, should the need arise.

Learn more

This API is built on the same RESTful, standards-based technology stack previously employed by the DFA Reporting API. This means that you have access to all sorts of useful tools for trying it out, such as the APIs explorer (which is also built into the documentation for each method) and our generic, cross-API client libraries. The getting started guide is also a great reference for users who are just starting out.

Give it a try and let us know if you have any questions!

 - Jonathon Imperiosi, DFA API Team

Are you using the Google Ads API Java Client Library and Java 5 (1.5)? If so, we have important news: starting April 2015, all releases of the Google Ads API Java Client Library will only be compatible with Java 1.6 and higher.

Why this change is happening
The primary reasons for this change are:

• Starting with version 18.0, Guava will no longer release 1.5 backports. The Google Ads API Java Client Library uses Guava's precondition checks, I/O helpers, and other utilities extensively.
• Java 5 is a bit outdated -- it was first introduced in May 2004, and Oracle's support for Java 5 is approaching some key end dates.
• Usage of Java 5 among Google Ads API Java Client Library developers is rapidly declining.

Next steps
If you are using Java 6 or higher, then you're all set -- all releases of the client library on github already support your runtime.

If you are still using Java 5 and need to migrate to Java 6 or higher, check out the following adoption guides from Oracle:

• Java 5 to 6
• Java 6 to 7

Still have questions? Feel free to file an issue on the library's issues page or contact us via our Google+ page.

- Josh Radcliff, AdWords API Team

As you may know, we announced the release of our new Python client library—googleads—in March, 2014. Since then, we’ve received a lot of feedback that has helped us further improve the library. Given the positive reception we’ve had with googleads, along with the improvements we’ve made to it over the past few months, the time is right for us to give our legacy Python client library—adspygoogle—a proper send-off. The legacy ads APIs Python client library has been deprecated and will be sunset on January 5th, 2015.

Between now and the sunset date, all upcoming API releases will be supported. The legacy client library will no longer be available on GitHub or PyPI after the sunset date. You can continue to use it while supported versions of the APIs are available, but it will eventually become obsolete and won’t be supported if any new issues are discovered. In order to smoothly transition to the new client library and have uninterrupted access to the newest versions of the APIs, we suggest you migrate to googleads as soon as possible. To help you migrate, we’ve prepared a migration guide.

If you discover any bugs, would like to contribute, or have feature requests for googleads, feel free to let us know via the library’s issue tracker. If you have any questions or feedback for us, you can reach us on the Google Ads Developers Google+ page.

 - Mark Saniscalchi, Ads Developer Relations Team

Do you use any of these products?

• AdWords API
• DoubleClick for Publishers API
• DoubleClick Ad Exchange Buyer SOAP API
• DoubleClick for Advertisers API

Then here’s your chance to tell us what you think about the corresponding client libraries, even if you don’t use one of them! Your feedback is very important for us and it helps us to prioritize the most wanted features. If you have any suggestions, feature requests or ideas—it's a great time to let us know!

 - Danial Klimkin, AdWords API Team.

We have made a few changes to the Ads API .NET client library to allow better maintenance and support.

Unified repository

For ease of maintenance and to reduce duplication, we have combined the AdWords, AdXBuyer, DFP and DFA API .NET libraries into one repository: https://github.com/googleads/googleads-dotnet-lib

Going forward, please use the new repository for downloading Ads API .NET client library releases, reporting issues, requesting features, and providing source contributions.

We have updated wiki articles, consolidated open issues, and imported source code of past releases.

New runtime requirement

We have increased the runtime requirement for the client library to Microsoft .NET Framework 4. This upgrade allows us to enhance the library using features available in newer versions of the Microsoft .NET framework, while moving away from .NET 2.0, which is past its mainstream support period.

In case you are still using Microsoft .NET Framework 2.0, you may continue using the legacy library until July 1st, 2015, at which time we will stop providing bug fixes and enhancements to the library. Major feature enhancements and support of newer versions of the APIs will be limited to the newer library that uses Microsoft .NET Framework 4.

Updates to version numbers

We have updated the version number of the Ads API .NET client library to 18.0.0. The Common library version has been updated to 3.0.0. Going forward, all the API-specific client library assemblies will share a single version number, while the Common library will continue to maintain its own version number.

The legacy library assemblies will only have minor releases, and will use the following versioning scheme on both Github and Nuget:

• Google.Ads.Common: 2.x
• Google.AdWords: 17.x
• Google.Dfp: 7.x
• Google.Dfa: 5.x

If you have questions or feedback, let us know on our forum or our Google+ page.

Anash P. Oommen, Ads Developer Relations

We have moved all our client libraries to GitHub. Here’s a complete list of all our client libraries, with their new locations:

	AdWords and DoubleClick Ad Exchange Buyer	DoubleClick for Publishers	DoubleClick for Advertisers
Java	googleads-java-lib	googleads-java-lib	googleads-java-lib
.NET	googleads-adwords-dotnet-lib	googleads-dfp-dotnet-lib	googleads-dfa-dotnet-lib
PHP	googleads-php-lib	googleads-php-lib
Perl	googleads-perl-lib
Python	googleads-python-lib	googleads-python-lib	googleads-python-lib
Ruby	google-api-ads-ruby	google-api-ads-ruby

We have also moved all Wiki pages and open issues to the corresponding GitHub projects. You can find downloads for a project under its releases page. All future client library releases will be published on GitHub only, so make sure you follow us on GitHub to keep track of new releases and report issues. If you tracked the git repository on code.google.com for a client library, you should update your master branch to point to the GitHub repository instead.

If you have any questions about the client libraries, you can post them on our forums. Check out our Google+ page for client libraries and Ads APIs updates.

- Anash P. Oommen, Ads Developer Relations

The AdWords, DFP, and DFA APIs can take a user agent string in the SOAP headers, and the client libraries all allow you to set this string in their configuration files. This post explains why it’s in your own best interests to set this value to something unique and useful for each of your applications. We will be enforcing this soon in the Client Libraries - you won't be able to leave it as the default setting, or set an empty string. So, come up with a fitting string for your application and start using it in your headers now, if you’re not doing so already!

Here at Google we have the means to check our logs to see the SOAP requests you make, the responses we send you, and any internal error messages that might have been generated if something went wrong. If something appears wrong from your side, you can contact us, and tell us what happened and when, and we can search these logs for your developer token, network code, or specific features of the request that went wrong. In many cases that can be enough for us to be able to help you diagnose and solve that problem.

But many of you are developing more than one product. And sometimes the problem you’re trying to diagnose doesn't come down to a particular single event. Sometimes there’s a behavior over time we’re trying to pin down. And there are a lot of requests and responses in our logs.

If you can tell us the UserAgent or ApplicationName string you set for a particular version of a particular product that appears to be misbehaving, we can much more quickly and easily tell you how many of each request type it made, and when, and what the success rate for those requests were.

Likewise, if you’re trying to migrate from one version of the API to another, we can tell you if you are still making requests using the old API release, and also exactly which version of which application.

Supplying a useful UserAgent or ApplicationName string also enables us to proactively reach out to you when we see something going wrong or notify you of upcoming API changes that may affect you. We could then tell you exactly which behavior of what product and release will be impacted.

We suggest you use the format <CompanyURL>:<AppName>:<Version> so for example:

        example.com:ReportDownloader:V3.2

Here’s where to look and what to set for each Client Library:

Client Library	Product	Props File / setup method	Setting Name
Java	AdWords	ads.properties	api.adwords.userAgent
Java	DFA	ads.properties	api.dfa.applicationName
Java	DFP	ads.properties	api.dfp.applicationName
PHP	AdWords	auth.ini	userAgent
PHP	DFP	auth.ini	applicationName
Perl	AdWords	adwords.properties	userAgent
.Net	AdWords	App.config	UserAgent
.Net	DFA	App.config	ApplicationName
.Net	DFP	App.config	ApplicationName
Ruby	AdWords	adwords_api.yml	user_agent
Ruby	DFP	dfp_api.yml	application_name
Python	AdWords	run the "config.py" script	userAgent
Python	DFP	run the "config.py" script	applicationName

And if you’re generating your own SOAP and not using a Client Library, please set the string directly in the headers yourself.

So why not make this simple change, if you aren't making use of it already, and set the UserAgent or ApplicationName string for each of your application releases? You never know when it will mean the difference between hours of digging or a quick fix.

Feel free to ask questions or give us feedback via the G+ page.

We've aimed to make transition from DoubleClick for Advertisers to DoubleClick Campaign Manager as seamless as possible for our API users. These two systems differ in a requirement for using In-App creatives - in DFA these creatives can be assigned to any standard placement, while in DCM they must be assigned to a placement with an In-App type. We want to make your transition as painless as possible, so we've added a way for you to handle this situation from either platform.

We've patched 4 new placement types into the DFA API version 1.20:

Placement Type	Placement Type ID Number
Agency Paid In-App	14
Agency Paid In-App Interstitial	15
Publisher Paid In-App	16
Publisher Paid In-App Interstitial	17

These types exist in both upgraded and pre-upgrade accounts, with one important difference. Since DFA doesn't actually support In-App placements, using these new placement type identifiers will result in the creation of standard placements instead. For example, saving a placement of type “Agency Paid In-App” (type ID number 14) will result in the creation of an “Agency Paid regular” placement with type ID number 3.

We will never return placements with these new types to pre-upgrade users, and you may continue to traffic In-App creatives to standard placements until you upgrade. During your account's migration to DCM, we will automatically correct the type of any existing placement trafficking In-App creatives as part of your upgrade process. After the upgrade, you will no longer be allowed to traffic In-App creatives to standard placements. To better future-proof your application for your upgrade, create placements intended for In-App using these new type codes even before upgrading to DCM.

We've added this change to our DCM upgrade guide. Feel free to update your applications with these new types as soon as possible. If you have any questions about these new placement types, we're always available at our forum and our Google+ page.

- Joseph DiLallo, the DFA API Team

We've noticed a lot of interest in having the Google Ads APIs Python Client Library made available on PyPI, so we're happy to announce that we've recently added support for it. If you use a tool such as pip, you can now install or update to the latest version of the library with all its dependencies using one simple command, for example:

pip install [--upgrade] adspygoogle

This feature was added based on community feedback, so if you have additional feature requests or a bug to report, feel free to let us know about it by creating an issue on our issue tracker or contacting us on our Google+ page.

- Mark Saniscalchi, Ads Developer Relations

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.

- Joseph DiLallo, the DFA API Team

We’re pleased to announce the newest DFA Reporting API release, version 1.3. This version adds an often requested feature: the ability to retrieve the dimensions and metrics that are available for selection.

Compatible Fields

DoubleClick for Advertisers allows you to restrict the visibility of certain metrics and dimensions for individual users based on the permissions granted to the user role and filters applied to the user profile. Additionally, certain dimensions and/or metrics cannot be used in combination with one another. For these reasons it can be difficult to determine which metrics and dimensions are available. The new reports.compatibleFields resource allows you to programmatically tackle this problem, returning a listing of fields available to the current user based on the report being created.

Additional details are available in our developer documentation release notes. We’re always available to answer your questions on our forum, or you can reach out to us on our Google+ Page.

- Joseph DiLallo, the DFA API Team

We’re pleased to announce the newest DFA Reporting API release, version 1.2. This version’s main additions include paid search dimensions and a way to view all reports and files in your account, not just those that you own.

Paid Search

Paid search dimensions have been added to the API with this release. We also added support for these new dimensions to version 1.1, but only version 1.2 contains the new matchType field in the DimensionValue resource allowing you to filter paid search dimensions by one of the following:

• EXACT
• CONTAINS
• BEGINS_WITH
• WILDCARD_EXPRESSION

Report Sharing

We have added the ability to list all reports and files in your DFA account (in addition to those owned by you). You may also optionally list just those files that have been shared with you using the Files resource. You can find this option in the scope parameter in the input to the respective list methods.

Refer to the release notes in our developer documentation for more details. We’re always available to answer your questions on our forum, or you can reach out to us on our Google+ Page.

- Joseph DiLallo, the DFA API Team

We’re pleased to announce the availability of version v1.20 of the DFA API. This latest release exposes many new properties on the objects in our API. These new fields are useful for customers interested in generating match tables. A full listing of these additions can be found in our release notes page.

Version v1.20 can be thought of as an optional release. Since v1.20 is an optional release, it and v1.19 will both remain usable once your account is upgraded to use DDMM. If you don’t require access to the new fields exposed in this version, you do not need to update your application at this time. Please remember that v1.18 has been sunsetted.

Questions or comments about this release, performing updates, or anything else related to using our API are always welcome on our forum.

- Joseph DiLallo, the DFA API Team

The sunset of DFA API version v1.18 has been pushed back to April 16th, 2013. This version of the API has been deprecated since November, 2012 and was previously scheduled to be retired on February 28th, 2013.

If you’re still using v1.18, please be sure to update your applications before April 16th. Our release notes will help you identify differences in v1.19, the most important one being the necessity to use HTTPS connections. We are available on our forum to help you with any questions you have.

- Joseph DiLallo, the DFA API Team

You spoke and we listened; we like to do that in Developer Relations! We've heard your comments regarding Google Developer Live (GDL) events and we understand that they are often key to solving complex questions you have. In order to keep up with your demand we've scheduled another round of Hangouts for all of our products over the next few months.

In the upcoming Hangouts you'll notice that we are experimenting with some new formats. On some products you'll see engineer interviews, third party product discussions, or the typical Office Hours. You can view the newly scheduled hangouts on the Google Developers events page. Please RSVP by clicking the “I’ll be there” button if you plan on attending.

In case you haven’t joined us before, you'll need four things to join the hangout:

• A Google+ account (sign up here)
• The Google voice and video plugin installed on your computer
• A quiet place to hangout so we can hear you. 
• A microphone is required and a video camera is preferred.

These hangouts are informal and conversational, which make them a great place to ask questions or give us feedback. If you have questions about our GDLs, reach out to us on the forums.

 - Paul Rashidi, DFP API Team

The new sunset date of DFA API version v1.18 has been set for February 28th, 2013. This version of the API has been deprecated since November, 2012 and was originally scheduled to be retired in December, 2012. We pushed back this sunset during the holiday season, but the time has come for this version to be laid to rest.

If you’re still using v1.18, please be sure to update your applications before February 28th. Our release notes will help you identify differences in v1.19, the most important being the necessity to use HTTPS connections. We are available on our forum to help you with any questions you have.

- Joseph DiLallo, the DFA API Team

One of the more exciting features in the DFA Reporting API is synchronous reporting - the ability to run smaller reports right when you request them. Synchronous reporting is great for fetching metrics when you need them quickly, such as in a GUI environment. To help you understand how to take advantage of this feature, we’ve added a synchronous reporting guide.

If you have any questions on this topic, please bring them to our forum. We’d be happy to answer them for you and add them to our guide.

- Joseph DiLallo, the DFA API Team

On February 9th, 2013, we will be sunsetting all versions of the Java DART API prior to 13.4.8. This change has been planned since August. We extended the deadline for this change from its original date to February, and now this deadline is quickly approaching.

We will continue to support the current as well as the three previous versions of the Java DART API. You can expect to update your applications once a year under this new policy. Version 13.4.8 is currently the earliest version supported, but another release is on the horizon in March, 2013. To better future-proof yourself, we strongly recommend that you use at least version 13.6 or consider upgrading to the DFA Reporting API.

After February 9th, requests from a version prior to 13.4.8 will begin returning errors. You can find the latest download for this API in our help center. Please ensure your applications are updated. You can reach out to us with questions and concerns on our forum.

- Joseph DiLallo, the DFA API Team

We recently announced that the Java DART API now has version limitations placed upon it. Going forward, we are going to only support the 4 most recent versions of this API. With a release cycle of approximately 3 months, this translates into one required update per year. Now that you may need to migrate to a newer version, we will be posting release announcements on this blog to keep you up to date.

Java DART API Releases Version 14.2

A new version of the Java DART API is now available: 14.2. There are no changes pertinent to DFA developers in this release. Since this is now the fourth officially supported version, no one needs to migrate to a newer version of the Java DART API at this time.

We strongly recommend you migrate from the Java DART API to the DFA Reporting API, our new reporting platform, at your earliest convenience.

DFA API v1.18 Sunset Pushed Back

We previously announced that version v1.18 of the DFA API would be sunset in December. This sunset has been pushed back until after the holiday season. You should still migrate to v1.19 as soon as possible in order to future-proof yourself, but no immediate action is required at this time. The new sunset date for v1.18 will be announced on this blog at a later date.

All of your questions are always welcome on our forum.

- Joseph DiLallo, the DFA API Team

With November on the horizon, we’d like to remind DFA API users of two important upcoming changes. Both of these changes were previously announced in August.

Java DART API Version Enforcement

To give you the best experience connecting to ReportCentral, it has become necessary to stop supporting older versions of the Java DART API. Starting November 3rd, 2012, we will only accept requests from the 3 latest versions, which are currently 13.4, 13.6, or 13.8. We have continued to improve our DFA Reporting API and still recommend all users switch to this new offering as soon as possible.

Removal of our Deprecation Policy

Also on November 3rd, 2012, our deprecation policy will no longer be in effect. Our commitment to our APIs and our users remains strong, and we will strive to announce all changes to our APIs long before they launch.

Please feel free to post any questions or concerns you may have on our forum.

- Joseph DiLallo, the DFA API Team