Google Ads Developer Blog: december 2014

Deprecation of active view NOT_* report columns in the DFP API

fredag 19 december 2014

In the coming weeks, we will be deprecating all ACTIVE_VIEW_NOT* report columns in v201405, v201403, v201311 and v201306 of the DFP API. These columns are no longer supported in the DFP query tool, and the DFP API is following suit. The following columns will be affected:

Column.TOTAL_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.TOTAL_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.AD_SERVER_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.AD_SERVER_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.ADSENSE_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.ADSENSE_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.AD_EXCHANGE_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.AD_EXCHANGE_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Migration
Normally all features are supported until the API version is sunset. This deprecation is a rare case where these report metrics are being disabled for existing versions due to product changes related to viewability. If you are using v201408 or later, you will not be affected by this deprecation. If you are currently using these columns in v201405 or earlier, you can replace them with their logical opposites. Alternatively, to retain the same metrics, you can calculate them from the logical opposite and the rate. For example, Column.TOTAL_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS is equivalent to

Deprecation errors
If you do not migrate, your reports will return the following error:

ReportError.COLUMNS_NOT_SUPPORTED_FOR_REQUESTED_DIMENSIONS

If you have any questions or migration troubles, please reach out to us on our developer forum.

- Chris Seeley, DFP API Team

Introducing the DCM/DFA Reporting and Trafficking API

måndag 15 december 2014

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!

- Jonathon Imperiosi, DFA API Team

Introducing Builders in AdWords Scripts

torsdag 11 december 2014

We are introducing Builders as the standard way to create entities in AdWords scripts. You can use Builders in either synchronous or asynchronous mode. You can also check whether the operation was successful or not, and take appropriate actions depending on the operation’s outcome. The following code snippet shows how to create a keyword using builders.

// Retrieve your ad group.
var adGroup = AdWordsApp.adGroups().get().next();

// Create a keyword operation.
var keywordOperation = adGroup.newKeywordBuilder().
    .withCpc(1.2)
    .withText("shoes")
    .withDestinationUrl("http://www.example.com/shoes")
    .build();

// Optional: examine the outcome. The call to isSuccessful()
// will block until the operation completes.
if (keywordOperation.isSuccessful()) {
   // Get the result.
   var keyword = keywordOperation.getResult();
} else {
   // Handle the errors.
   var errors = keywordOperation.getErrors();
}

The current release adds builder support for ads and keywords. The existing builders for ad groups and Ad Extensions - phone number, site links and mobile apps have also been standardized. The addSitelink, addPhoneNumber, and addMobileApp methods of AdGroup and Campaign classes will now return the resulting operation.

We are also deprecating the following creation methods. These methods will work fine for now, but they will be sunset in the future.

You can learn more about this new feature on our guide. If you have questions or feedback about this feature, let us know on our forum.

Anash P. Oommen, AdWords Scripts Team

Announcing v6.5 of the Google Mobile Ads SDK for Android

onsdag 10 december 2014

Today we’re announcing the release of v6.5 of the Google Mobile Ads SDK! It’s listed as Google Play services 6.5 (Rev. 22) in the Android SDK manager, and is available for download right now. Those of you using Android Studio should download Google Repository (Rev. 14) to get the latest Gradle artifacts.Under the hood improvements (greater stability, more efficient use of resources) make up most of the changes, but we’re pleased to note that this will be the first version of the SDK to support a split jar architecture. Previously, the SDK was compiled as a single, all-encompassing JAR file. Beginning with this release, however, it’s also built into separate JARs, each covering a specific domain of functionality. Interactive Media Ads (IMA) and Mobile Ads developers can now reference part of the Play Services SDK without needing to import the whole thing. This in turn reduces the APK size and memory footprint of your applications.Taking advantage of the new architecture is easy -- you just need to change how you’re incorporating the SDK in your build process. Here’s an excerpt from a typical build.gradle file for an app that uses the SDK to display mobile ads:dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.google.android.gms:play-services:6.+' } And here’s one that targets the ads library specifically, new in v6.5:dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.google.android.gms:play-services-ads:6.+' } That’s it! Gradle will now incorporate the new, smaller JAR into your application. If your app consumes other services from the SDK, simply add the relevant JARs (play-services-games or play-services-location, for example) to your build file as well.IMA developers can make this change now. If you’re a Mobile Ads developer, one important thing to note is that the new split jar architecture currently works only with projects that configure banner ads in Java code, and not in XML. We plan to support XML configurations in the future, but for now if you’re defining and configuring your AdViews in an XML layout file, you should continue to reference Play Services in the existing manner.You can read the Google Play Services Announcement on the Android Developers Blog for a summary of what’s new with this release. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

- Andrew Brogdon, Mobile Ads Developer Relations

Filtering report data by custom targeting key ID in the DFP API

fredag 5 december 2014

A lot of our DFP API developers have been asking recently about how to filter report data by custom targeting key ID. Currently the DFP API allows you to filter report data by custom targeting value ID only. Until we have official support for filtering by custom targeting key ID in reports, you can use the CustomTargetingService and the ReportService together to achieve this goal.Step 1: Use CustomTargetingService to get your keys and valuesgetCustomTargetingValuesByStatement WHERE customTargetingKeyId IN (17, 18, 19)If you have a lot of keys and values in your network, a better approach is to store these in a local database and do nightly syncs. Use getCustomTargetingKeysByStatement to obtain all the keys in your network, and then iterate through them, calling getCustomTargetingValuesByStatement for each key to obtain their values. Our client libraries all have examples of this. For instance, the Java example can be found in our ads Java client library GitHub repository. This way, you can look up the values associated with a custom targeting key more quickly and not do an additional API call.Step 2: Use the values in a report queryReportQuery.statementINCUSTOM_TARGETING_VALUE_ID WHERE CUSTOM_TARGETING_VALUE_ID IN (3211, 88990, 123456)However, please be aware that if you have a lot of custom targeting value IDs to filter on, you should batch them by querying for no more than 500 IDs at a time in the PQL IN clause. For example, you will run your report filtering on the first 500 IDs you’ve collected and save that report. Then you will run the same report on the next page of 500 IDs you’ve collected and so on until you have no more IDs. You can then combine the reports locally so that you have all the data for those custom targeting IDs.If you have any questions about this, feel free to drop us a line on the DFP API forums or Ads Developer Google+ page.

- Vincent Tsao, DFP API Team

IMA SDK for iOS Beta 10 Release

torsdag 4 december 2014

Last week we released beta 10 of the IMA SDK for iOS. This release comes with a few new features including the following:

Ad rendering via the new WKWebView in iOS 8

Addition of calling classes in delegate methods

New TAPPED event for tracking user taps on the ad container

The most important thing to know about this release is that you will now need to include the WebKit framework as an optional framework in your implementation and build for 64-bit support. If you are a Cocoapods user, this will be done for you in the generated xcworkspace when you upgrade to beta 10 via pod install.Ad rendering via the new WKWebView in iOS 8Addition of calling classes in delegate methodsrelease notesNew TAPPED event for tracking user taps on the ad containerkIMAAdEvent_TAPPED - (void)adsManager:(IMAAdsManager *)adsManager didReceiveAdEvent:(IMAAdEvent *)event { if (event.type == kIMAAdEvent_TAPPED) { // Handle TAPPED event } }This event will be fired any time a user taps on a non-clickable part of an ad (taps on the "Learn more" or "Skip" buttons will not result in a TAPPED event).As always, if you have any questions feel free to contact us via the support forum.

- Shawn Busolits, IMA SDK Team

Announcing the Budget resource for the DoubleClick Ad Exchange Buyer REST API

onsdag 3 december 2014

We’ve just released the Budget resource for the DoubleClick Ad Exchange Buyer REST API, which can be used to set a daily budget for your real-time bidding campaigns. Each PretargetingConfig will have an associated Budget that it is mapped to via the billingId. Once a PretargetingConfig meets or exceeds the budgetAmount set by its Budget, it will no longer receive bid requests for the remainder of the day. Additional information about this resource can be found in the guide.

The Budget resource in the REST API and the BudgetService in the SOAP API can be used interchangeably; however, we recommend that you use the REST API for managing the budgets of your real-time bidding campaigns.

If you have any questions or comments about the Budget resource, please contact us via the forum or our Ads Developer G+ page.

- Mark Saniscalchi, Ad Exchange Team

AdWords scripts integrates with more Google services

tisdag 2 december 2014

We’re excited to announce the integration of AdWords scripts with even more Google services, dubbed “Advanced APIs”, allowing you to make use of these Google services directly from your scripts. The current release allows you to connect with:

Google Analytics: Update your account based on your website’s performance.
Youtube Analytics: Update your account based on your videos’ performances.
YouTube: Use YouTube trends or other channels stats to update your account.
Big Query : Manage, upload and query big data sets to better optimize your account.
Fusion Tables: Store, share and query your data information.
Calendar: Set campaign check reminders, enable/pause ads based on events.
Task: Manage and read from your Gmail tasks to optimize your account.
Prediction: Create, train, and query prediction models on your campaign’s performance data as well as external data sets.

To learn more about advanced APIs, refer to our code snippets and guide.

We encourage you to give this new feature a try and tell us what solutions you would like to have or other API you would like us to add.

As usual please let us know your feedback on the forum - bug reports and suggestions to improve the API usability are most welcome.