Posted:

As you may have heard, universal ads are launching to DCM accounts throughout November and December 2015. The centerpiece of these new ads is a set of unified compatibilities that remove the distinction between in-app and in-page environments. To learn more, visit our DCM user or partner support sites.

What does this mean for DCM/DFA Reporting and Trafficking API users?

Currently, the API does not expose these new compatibilities, although full support is coming in a future release. Until then, the in-app and in-page compatibilities you currently use will remain available. This means that there are no immediate changes necessary to your applications, but you may notice some discrepancies between the values presented by the API and UI:

API compatibility
New UI compatibility
APP
In-app
APP_INTERSTITIAL
In-app interstitial
IN_STREAM_VIDEO
In-stream video
WEB
Display
WEB_INTERSTITIAL
Display interstitial

What can API users do to prepare?

To make your future transition to universal ads easier, we recommend that API users begin transitioning off of in-app placements now. Be aware that it will no longer be possible to traffic in-app placements once universal ads support is added to the API, and existing in-app placements will not be automatically converted to use the new unified compatibilities.

Instead, newly trafficked placements should be created using in-page compatibilities. These placements will be mapped directly to the new unified compatibilities (as seen in the table above), making them immediately eligible to serve in both environments.

Questions about this or anything else DCM API related? Contact us via our support forum.

 - , DCM API Team

Labels:

Posted:

Today we're releasing v2.3 of the DCM/DFA Reporting and Trafficking API. This release brings a number of enhancements, such as:

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.1, which will sunset on February 29th, 2016.

As a reminder, February 29th is also the end of the extended migration window we've provided to users of v2.0 and earlier versions of the API. The current schedule is as follows:

API Version
Deprecation Date
Sunset Date
v1
3 Aug 2015
29 Feb 2016
v1.1
v1.2
v1.3
v2.0
v2.1
4 Nov 2015

To avoid an interruption in service, all users are required to migrate off of these versions by the sunset date.

Learn more

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the Release Notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

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

 - , DCM API Team

Labels: ,

Posted:
Today we are releasing v2.2 of the DCM/DFA Reporting and Trafficking API. Highlights of this release include:
  • User requested enhancements: You asked and we listened! Based on your feedback, new fields--such as computed click-through URL for ad creative assignments--have been added.
  • Placement search improvements: You can now search for placements and placement groups by start and end date.
  • Ins tag support: When the new ins tag is enabled for your account, requests for iframe and javascript tags will return an updated tag format. We've introduced 4 new legacy tag values you can use to access the older versions of these tags, to ensure a smooth transition to the upgraded format. You can begin requesting these legacy tag values today, even if your account hasn't upgraded yet.
Retiring older API versions

Along with this release, we're introducing a new deprecation schedule and announcing the deprecation of all versions prior to v2.1. Moving forward, we will generally only support 3 versions of the API and sunset the oldest version 4 months after a new release. In order to help developers adjust to this new schedule, we're providing an extended migration period for users of these newly deprecated versions:

API Version
Deprecation Date
Sunset Date
v1
3 Aug 2015
29 Feb 2016
v1.1
3 Aug 2015
29 Feb 2016
v1.2
3 Aug 2015
29 Feb 2016
v1.3
3 Aug 2015
29 Feb 2016
v2.0
3 Aug 2015
29 Feb 2016

These versions will remain active and supported until the sunset date, and we encourage you to use this time to update your applications.

Learn more

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the Release Notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

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

 - , DCM API Team
Labels: ,

Posted:
As we announced in December 2014, with the release of the DCM/DFA Reporting and Trafficking API, we will be sunsetting the legacy DFA API on September 30th, 2015. To avoid an interruption in service, all DFA API users are required to update their application to use our new API by this date. If you haven’t yet started migrating, we strongly encourage you to do so.

If you’re new to the DCM/DFA Reporting and Trafficking API, you can use our Get Started guide to get up and running quickly. You can also reference our Migration Guide to help in transitioning legacy DFA API applications to the new API. If you have any other questions, feel free to reach out to us on the developer forum.

 - , DCM API Team
Labels:

Posted:
Today we're pleased to announce v2.1 of the DCM/DFA Reporting and Trafficking API. This release introduces some exciting new functionality, including: All users are encouraged to adopt this new version and begin making use of its enhanced feature set. If you're still working with the legacy DFA API, please note that it will be sunset on September 30th, 2015. We recommend that these users skip v2.0 and migrate straight to v2.1.

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the release notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the getting started guide is a great reference to help you get up and running quickly.

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

 - , DFA API Team
Labels:

Posted:
Starting today, the DCM/DFA Reporting and Trafficking API is available as an advanced Google service in Google Apps Script. This service allows users to easily integrate their DCM reporting and trafficking data with Google Docs and Sheets, schedule updates using triggers, and much more.

Accessing the API from Apps Script is simple: just enable the service and it's ready to use. Authentication is handled automatically and editor conveniences such as autocomplete make it easy to start writing code right away. As an example, here's a snippet of code that shows how to list all user profiles available to your Google account: 
function listUserProfiles() {
  // Retrieve the list of available user profiles
  var profiles = DoubleClickCampaigns.UserProfiles.list();

  if (profiles.items) {
    // Print out the user ID and name of each
    for (var i = 0; i < profiles.items.length; i++) {
      var profile = profiles.items[i];
      Logger.log('Found profile with ID %s and name "%s".',
        profile.profileId, profile.userName);
    }
  }
}
To get started, check out the service documentation, which contains additional examples, as well as the full API reference documentation. If you have any questions, visit the API forum or reach out to Google Apps Script support.

 - , DFA API Team
Labels: ,

Posted:
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:
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!

 - , DFA API Team
Labels: ,

Posted:
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: 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: 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
Labels: , , ,

Posted:
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.

 - , Ads Developer Relations Team
Labels: , , , ,

Posted:
Do you use any of these products?
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!

 - , AdWords API Team.
Labels: , , , ,

Posted:
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
Labels: , , , ,

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



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
Labels: , , , ,

Posted:
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.
Labels: , ,

Posted:

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 TypePlacement Type ID Number
Agency Paid In-App14
Agency Paid In-App Interstitial15
Publisher Paid In-App16
Publisher Paid In-App Interstitial17

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
Labels: ,

Posted:

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
Labels: , , , ,

Posted:

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
Labels: ,

Posted:

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
Labels: ,

Posted:

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
Labels: ,

Posted:

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
Labels: ,

Posted:

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
Labels: ,