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.

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 = AdWordsApp.report(query, {
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

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.

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.

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":

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: www.AdWordsAPIWorkshops.com

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:

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.

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).

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.