One of the most used services in the DFP API is the LineItemService. Many of you are already utilizing the Line_Item table in the PublisherQueryLanguageService to create match tables on fields like Status or ExternalId, but with newer API versions, more and more fields are available as columns. Did you know that as of v201411 the Line_Item table includes a column for Targeting? With so many line item fields now accessible through PQL, the Line_Item table might be a viable replacement for your read operations.

What's the advantage? Faster response times. As an example, I pulled 5,000 line items from a network using both the LineItemService and the Line_Item PQL Table, printing page offsets as the results arrived. Take a look at the results:

* Actual response times may vary. Line item fields only available in participating PQL Tables.

Using the PublisherQueryLanguageService shaved off 17 seconds for a respectable speed increase of 15%.

However, if your application doesn't need some of the heavier fields, you'll see a much bigger gain. Check out what happens when we leave out Targeting:

The sparse selection offered by the PublisherQueryLangugeService means our data size is smaller, cutting the total time by a whopping 45%!

If you're looking for a performance boost in your LineItem read operations, give the Line_Item table a try. We've got example code in each of our client libraries to get you started. If you have any questions, don't hesitate to reach out to us on our API forums.


If you read Quality Score metrics programmatically from the AdWords API, please be aware that the values reported by the API, starting from around 11am PT on March 26, 2015, may have been artificially low. Correct values are currently being restored, and should be fully stabilized within 24 hours.

This issue is limited to Quality Score reporting only. Auction time signals of quality, which are the signals actually used within the auction for computing Ad Rank and serving ads, are unaffected.

- Adam Ohren, AdWords API Team


Today we're releasing Beta 10 of the IMA Android SDK. This is primarily a service release to address performance and bug fixes, but the release also includes some API changes to be aware of.

Changes in Beta 10

  • Added ImaSdkSettings.getMaxRedirects and ImaSdkSettings.setMaxRedirects.
  • IMA API classes are now final.
  • The following AdError.AdErrorCode values have been removed:
    • API_ERROR - instead use UNKNOWN_AD_RESPONSE.
    • REQUIRED_LISTENERS_NOT_ADDED - was not being raised by the SDK.
  • Bug fixes.

Download IMA Android SDK Beta 10

You can get this latest release of the IMA Android SDK from our IMA SDK downloads page.

Check out the release notes page to stay up to date on IMA Android SDK releases.

Other questions?

As always, feel free to drop us a line on the IMA SDK forum and follow our Google+ page for other announcements and updates.

We are excited to announce two new features for AdWords scripts:

AdWords API v201502 reports

AdWords scripts now support AdWords API v201502 reports. The new version introduces two new reports: USER_AD_DISTANCE_PERFORMANCE_REPORT and LABEL_REPORT. We also introduced several new columns, renamed some columns to make them consistent with the AdWords UI, and removed some duplicate columns. See the AdWords API release notes for more details.

If you use API versioning in your reports, you’ll need to modify your code to use v201502 as shown:
var report =, {
    apiVersion: 'v201502'
If you don’t use API versioning, your scripts will now default to v201502 reports. If your scripts access one of the removed or renamed columns, you may need to fix that column name in your scripts.


JDBC allows your scripts to connect to external databases through the JDBC service, a wrapper around the standard Java Database Connectivity technology. In Apps Script, the JDBC service supports Google Cloud SQL, MySQL, Microsoft SQL Server, and Oracle databases. See our guide for more details.

If you have any questions about these features or AdWords scripts in general, you can post them on our developer forum.

We've got good news for Java developers using the AdWords API to manage Shopping campaigns: the Java client library now has a set of utilities that greatly simplifies the process of setting up your product partition trees.

The utilities let you focus on your use case, avoid boilerplate code, make your code more readable, and reduce the amount of code needed for common actions.

For example, the updated AddProductPartitionTree code sample that uses the utility is 65% shorter than the previous version.

Intrigued? Check out the product partition utility guide on github, and let us know what you think!

If you would like to have a similar utility in a different client library, register your interest by opening a github issue on that library's issues page.

Learn more

If you haven't started using Shopping campaigns, the following resources are a great place to start: Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.


Today we’re announcing the release of v7.0 of the Google Mobile Ads SDK! It’s listed as Google Play services (Rev. 23) in the Android SDK manager, and is available for download right now. Those of you using Android Studio can download Google Repository (Rev. 16) to get the latest Gradle artifacts. This release contains a number of stability and performance improvements, as well as some new features.

DFP developers can take advantage of two other new methods in PublisherAdRequest.Builder: addCustomTargeting and addCategoryExclusion.

Previously, developers had to add custom targeting information to a request by creating a Bundle and passing it to addNetworkExtrasBundle. This can now be done with a simple call to the addCustomTargeting method:

PublisherAdRequest newRequest = new PublisherAdRequest.Builder()
        .addCustomTargeting("some_key", "some_value")
        .addCustomTargeting("some_other_key", aListOfStringValues)

The new addCategoryExclusion method makes setting a slot-level category exclusion label for a request just as straightforward:

PublisherAdRequest newRequest = new PublisherAdRequest.Builder()

Another new feature is the setRequestAgent method that’s been added to AdRequest.Builder and PublisherAdRequest.Builder. Third party libraries that reference the Mobile Ads SDK should call this method to denote the platform from which the ad request originated. For example, if a third-party ad network called "CoolAds" mediates requests to the Mobile Ads SDK, it should call this method with "CoolAds":

AdRequest newRequest = new AdRequest.Builder()

This SDK release coincides with version 7.0 of Google Play services, which was recently announced on the Android Developer blog. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

We’re pleased to announce that the AdWords API Workshops are back, and registration is open. Visit the workshop website to access the registration forms and take a look at the agendas:

Choose a location and type of event that best works for you and register soon! Wait for the confirmation email from our side.

This round we are hosting three variations of workshops:
  1. The Technical workshops are targeted for experienced API users, and we are going to talk about advanced use cases at a very technical level. If you are a developer, you are going to enjoy this event.
  2. The Introductory Technical workshop is similar to the technical workshops, but we are going to start with a use cases overview, and also talk about available tools on the market and best practices on API usage. This is still a technical workshop, but should be easy to consume by new developers and team managers. This round we will only be hosting this type of event in London (April 13th).
  3. The Business workshops are the new type of workshop. No technical content in terms of code, but instead we are going to talk about possible API use cases, and how to make your business work together with the AdWords API, or AdWords scripts. This is aimed at a business audience, so everyone can enjoy the event.
We're looking forward to seeing you at these events!

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

AdWords API v201406 will be sunsetted on April 6th, 2015, after which all v201406 API requests will fail.

This version was deprecated on October 8th, 2014. There are less than 4 weeks left before the sunset, so make sure to migrate to v201502 (recommended) or v201409 as soon as possible to ensure that your access to the API is unaffected.

We have prepared various resources to help the transition to a newer version of the API: As always, if you have any questions about this migration, please contact us via the forum or the Ads Developers Plus Page.

AdWords scripts now support Upgraded URLs. Upgraded URLs provide a smarter way for you to manage URLs in AdWords by specifying which part of your URL specifies the landing page, and which part is used for tracking. You can learn more about this feature here.

Here is an example of how to create a new text ad that specifies the final URL instead of destination URL:
var adOperation = adGroup.newTextAdBuilder()
    .withHeadline("headline of ad")
    .withDescription1("first line of ad description")
    .withDescription2("second line of ad description")
var ad = adOperation.getResult();
You can retrieve the Upgraded URL fields of an entity using the urls() method for that entity. If you run reports, the Upgraded URL fields are also available through various performance reports.

Migrating to Upgraded URLs

We encourage all advertisers to upgrade to the new system by July 1, 2015. This involves two parts:
  1. Update your scripts to handle Upgraded URL fields.
  2. Migrate the existing entities in your accounts to Upgraded URLs.
Upgrade scripts

For any new entities that you create using AdWords scripts, we recommend that you set the final URLs instead of destination URLs.

When dealing with existing entities, keep in mind that you may encounter both upgraded and non-upgraded entities in your accounts. If your script reads destination URLs, then make sure it checks both the destination URL and final URL fields of any entity it retrieves. If your script updates destination URLs, use either setFinalUrl() or setDestinationUrl(), depending on whether the entity has been upgraded or not. AdWords scripts will raise an error if you attempt to set both final URL and destination URL for an entity.

Migrate existing entities

You should migrate existing entities to use Upgraded URLs by 1 July, 2015. Refer to our migration guide for upgrading your existing entities to the new URL framework. If you wish to use the Basic upgrade option, you can use the bulk upload feature. If you choose to use the Advanced upgrade option, then you can use Scripts.

If you choose not to upgrade now, and your destination URL does not contain a different domain than the display URL, your destination URL will be updated automatically starting on 1 July 2015. If your destination URL does contain a different domain than the display URL, you will need to manually upgrade the URL or the ad will stop serving shortly after the July 1 deadline.

If you have questions or feedback about these features, let us know on our forum.

Today we're announcing the release of AdWords API v201502. Here are the highlights:
  • Ad extension services. We heard your feedback about Feed Services being overly complex for many cases. To help simplify ad extension management, we've added new ExtensionSetting services. Existing Feed Services are still supported so you can continue using them. Should you decide to migrate to the new services, we've prepared a migration guide.
  • Account labels. We've expanded support for labels to MCC manager accounts. Now you can tag your accounts with text labels programmatically.
  • In-place URL upgrade for ads. The AdGroupAdService now supports upgradeUrl method which simplifies the Upgraded URLs migration.
  • Updates to reporting. Two new reports have been added: UserAdDistance performance and Label. Reporting now supports skipColumnHeader HTTP header which removes column headers from the produced report. We've also added several new columns across reports, see the release notes for the full list.
  • Shared sets. These are now available to all AdWords API users. Check out this feature if you often need to attach large sets of negative keywords or placements to many campaigns.
  • Support for application deep links. You can now create ads linking to specific activities in your application using AppUrlList.
  • Additional controls on Local Inventory Ads. You can now enable local inventory as well as set product channel / channel exclusivity.
  • Cross-account as well as system-defined conversion trackers are now easy to identify. Look at the conversionTypeOwnerCustomerId in ConversionTracker. Accounts using cross-account conversion tracking can be identified using the effectiveConversionTrackingId.
  • Account-level remarketing tags can now be retrieved using CustomerService RemarketingSettings.
  • The new TargetOutrankShare bidding strategy is now supported.

If you're still using v201406 of the AdWords API, please note that it's being sunset on April 6th, 2015. We encourage you to skip v201409 and migrate straight to v201502. If you're using v201409, be aware it's now marked deprecated and will be sunset on July 14th, 2015.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201502 migration guide. The updated client libraries and code examples will be published shortly. With this release, we've also updated the Required Minimum Functionality document to include some of the newly added features. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.


When announcing version 7.0.0 of the Google Mobile Ads SDK for iOS, we mentioned that developers could roadblock creatives and prevent competing ads in mobile apps.

The launch of the roadblocks feature in version 7.0.0 had an unintended side effect for DFP reservations. By default, ad requests from the same device were getting frequency capped for 30 seconds unless the app called the updateCorrelator method between requests.

To restore the default behavior, we have rolled back the roadblocks feature. What this means is that updateCorrelator effectively does nothing in version 7.0.0. We will relaunch support for roadblocks and competitive exclusions in a future iOS SDK release after improving the feature to preserve the default behavior.

If you have any questions about this change, leave us a note on the forum.