To help streamline management of your AdWords scripts, we’ve made it easier to preserve scripts created in your AdWords account even after the original author becomes inactive.

In the past, a script in an AdWords account would become unavailable if the script’s original author was no longer associated with the AdWords account. Other users on the AdWords account would need to recreate the script on their own or else risk losing it entirely.

With the new changes we’re launching, scripts from an inactive user will continue to be available in the AdWords account where they were created. To keep these scripts running, the remaining users in the AdWords account will need to log into AdWords and reauthorize the script.

We’ll e-mail the administrators on the AdWords account if the author of a scheduled script goes inactive and here’s what you’ll need to do to get the script running again:
  1. Log in to your AdWords account, and navigate to the Scripts section under Bulk Operations (or the Scripts section of your MCC account).
  2. In the “Script” column, find the relevant script.
  3. Click the "Edit" link.
  4. Click the "Authorize now" button in the yellow bar at the top of the script editor.
  5. Click the “Accept” button.
We are applying this change with an effective date of March 15, 2014. If an author went inactive before that date, his or her scripts will continue to be unavailable. Scripts created in your AdWords account after March 15 will remain available as long as the AdWords account remains open.

If you are running DoubleClick Ad Exchange Real-Time Bidding campaigns, you can now use the Snippet Status Report Generator to obtain a Snippet Status Report for your creatives. The Snippet Status Report contains the approval status of your creatives, as well as the sensitive and product categorization that Ad Exchange automatically detects. The Snippet Status Report Generator produces reports using the Ad Exchange Buyer REST API.

There are three versions of this report available through the generator: a human readable text format, a binary protocol buffer format, and a spreadsheet-friendly CSV format. The text and protocol buffer version of the report can also be obtained via Google Cloud Storage. The CSV version can be used with spreadsheet programs such as Google Sheets, Microsoft Excel or LibreOffice Calc:

The Snippet Status Report Generator is available on GitHub as a python program. You are encouraged to download it and make modifications to generate reports in your desired format.

If you have any questions or feature requests for the Snippet Status Report Generator, please create an issue on the project’s issues page.

For any questions about the Ad Exchange Buyer API, visit us on the forum or our Google+ page.

Starting January 1st, 2015, the PHP Ads client library will stop supporting PHP 5.2:
  • We will no longer test against PHP 5.2, or fix bugs that only affect PHP 5.2 users
  • Newer versions of the library may not work with PHP 5.2
This will impact PHP client library users of the AdWords API, the DoubleClick for Publishers API, and the DoubleClick Ad Exchange Buyer APIs.

PHP 5.2 hasn’t been supported since 2011 and should be upgraded to a current, stable version. Upgrading ensures you’ll receive the latest security updates.

In addition, there are numerous issues when using the PHP 5.2 SOAP client, such as: In particular, custom HTTP headers are required for the DoubleClick for Publishers API starting from DoubleClick for Publishers API v201405 - the OAuth 2.0 access token must be passed via the HTTP headers rather than the URL parameter. In this case, PHP 5.2 users must upgrade in order to use DoubleClick for Publishers API v201405.

As always, if you have any questions, drop us a line on the forums (AdWords API, DoubleClick for Publishers API, DoubleClick Ad Exchange Buyer API) or Ads Developers Google+ page.

We are always striving to make sure the data you fetch from the AdWords API is as meaningful as possible, and in v201406 we've made a few changes to some return values that should be more intuitive.

First, in the TrafficEstimatorService, we used to return 0 for values which we couldn't calculate, for example if a field requires division by zero. However, this could’ve given the false impression that the actual value was 0, rather than that it couldn't be calculated. For this reason, we’ve changed the logic to return null in cases where the value couldn't be calculated at all. This affects the averageCpc and averagePosition fields in StatsEstimate, as these values will not be returned in SOAP responses when they can’t be calculated.

Second, when using the Keyword Performance Report, we formerly returned all negative keywords as having a "pending review" approval status. Since negative keywords don't need to go through the same process as normal keywords, we will now return a null value instead for the ApprovalStatus field for all negative keywords.

This change only affects version v201406 going forward, and doesn’t affect existing versions v201402 or v201309.

As always, we are constantly looking to improve the API. If you have any questions about this or other API features, please feel free to ask on the forum or on our Google+ page.

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:

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.


Imagine for a moment that you're a mobile line item. You've just been initialized locally, and all of a sudden you’re having an existential crisis -- what makes you, you? How are you different from all the other line items? Sure your associated creative might be a bit different from other line items and you might have a few extra impressions allotted to your goal, but what truly makes you... unique? In this series of posts, we'll take you on an incredible journey through a day in the life of a mobile line item -- from how to target mobile to the actual delivery on a device.

Adding mobile specific targeting

It all starts similarly enough: you need a name, an order ID, start and end dates, a goal, and all the usual suspects -- but wait, there's more! Instead of just having custom criteria, ad units, and geo-targeting, you find that you also have TechnologyTargeting fields specified, like:

  • DeviceCategoryTargeting
  • OperatingSystemTargeting
  • MobileCarrierTargeting

Now, say you're being created as a line item to advertise Android tablet cases. It doesn't make much sense for you to be delivered to an iPad or an iPhone, so we need to add technology specific targeting.

To do so using Java, we would first set the DeviceCategory object with the targeting ID of the 'Tablet' category and the OperatingSystem object with the targeting ID of 'Android', both of which we'd pull from the PublisherQueryLanguage service:

    DeviceCategory deviceCategory = new DeviceCategory();
    OperatingSystem operatingSystem = new OperatingSystem();


These would then be set on the DeviceCategoryTargeting and OperatingSystemTargeting objects:

    DeviceCategoryTargeting deviceCategoryTargeting = new DeviceCategoryTargeting();
    OperatingSystemTargeting operatingSystemTargeting = new OperatingSystemTargeting();

    deviceCategoryTargeting.setTargetedDeviceCategories(new DeviceCategory[] {deviceCategory});
    operatingSystemTargeting.setOperatingSystems(new OperatingSystem[] {operatingSystem});

Finally, the Targeting object will have a TechnologyTargeting object set for DeviceCategoryTargeting and also OperatingSystemTargeting:

    TechnologyTargeting techTargeting = new TechnologyTargeting();

    Targeting targeting = new Targeting();

Now what happens? You're a line item that has a bit of technology targeting specified, but where are you off to next? Stay tuned for what happens next in - 'A day in the life of a mobile line item, part 2.'

A new OAuth 2.0 scope for the AdWords API was introduced along with the v201406 client library release. The OAuth 2.0 scope identifies the service that your application can access during the authorization process.

The new scope is: This new scope better aligns with the naming conventions of many of the other Google APIs.

Starting today, use the new scope when authorizing access for the AdWords API regardless of the AdWords API version. All our current AdWords API client libraries use this new scope.

But I have refresh tokens from the deprecated scope...

Don’t worry if your client code is using refresh tokens authorized with the deprecated scope - they will still work. However, new authorizations should specify the new scope.

As always, if you have any questions, drop us a line on the AdWords API forum or Ads Developers Google+ page.