Category Archives: Google Ads Developer Blog

The blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs.

Announcing v201409 of the AdWords API

Today we're announcing the release of AdWords API v201409. Here are the highlights:
  • Mobile campaigns for search and display. Search Mobile App and Display Mobile App campaign subtypes are now available via CampaignService. These new subtypes are a simplified way of creating campaigns focused on mobile app promotion.
  • Ad Customizers. Ad Customizers previously available for Test Accounts only are now enabled in production. With this feature you can include dynamic values in your ads based on feed data.
  • Currency support for conversions. Conversion trackers (including offline conversions) now support currency specification. You can also set default currency per tracker.
  • Website call conversion tracker. This tracker allows the collection of conversion stats for calls made on a script-generated phone number placed on your website.
  • Rule-based remarketing lists. The new API version allows you to create and manage rule-based remarketing lists. This feature allows you to use simple rules to better target the people who visited your website.
  • Better Labels handling. LabelIds column is now available in all relevant reports. We've also added both Labels and LabelIds columns to the Criteria Performance report.
  • Updates to reporting. A new Extension Placeholder report is now available for retrieving consistent extension stats. Reporting interface was extended to allow you to control the presence of report headers and footers in the response.
There's also an important API-level change in v201409. Starting this version, the clientCustomerId header is now a required header for calls to all services except CustomerService. If your application relies on a default account identified by authorization credentials, you need to update it to send a valid customer ID for every request. You can obtain the customer ID via a get call to the CustomerService.

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

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201409 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 that are now required in third-party tools. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

Accounts.name changes in the AdSense APIs

We recently deprecated the default namespace in the AdSense Management API so now you should show an account picker to your users and add an account ID to all requests.

The Accounts resource offers both a name and an ID but for most accounts these were showing the same string (something like "pub-12345678901234"). To make the process more intuitive for users, we are improving the logic behind the name.

From now on, the account.name property will have the company name or, in its absence, the contact name. If you still want to show the account ID, just use the id field.

This also applies to the Host API, although the default namespace can still be used.

As always, if you have any questions, feel free to drop us a line on our API forums.

Custom Playback Changes Now Live for the IMA HTML5 SDK

We previously announced changes to the way the IMA HTML5 SDK handles custom playback and custom click tracking elements. Starting today, October 2, 2014, those behavior changes will be rolling out.

Custom playback changes


Effective today, custom playback will now be used only when necessary (e.g., on devices such as iPhones or pre-4.0 Android phones) rather than whenever a custom playback video element is passed in.

We recommend all implementations now pass in the custom playback element so that ads will be rendered via a more seamless playback experience across different environments. For more info on the change and code snippets to help you upgrade, see upgrading to the new custom playback.

Custom click tracking element changes


Custom click tracking elements will now only be used in certain video environments. To determine whether or not a custom click tracking element is being used, check ima.AdsManager.isCustomClickTrackingUsed in an AdEvent such as ima.AdEvent.STARTED. Additionally, please do not render your custom click tracking element over your video player as it will break the ad experience by preventing clickthroughs on the ad and skip button. For more information on the custom click tracking element changes, see "a note about custom click tracking elements" on our custom playback guide.

As always, if you have any questions about these changes or other IMA SDK questions, feel free to contact us via the support forum.

Announcing report download limits for the AdWords API

Starting October 8th, 2014, if you're using the AdWords API without a Standard Access developer token, you will be limited to 1,000 report downloads per day. Previously, there were no daily operational limits applied to report downloads for the Basic Access level. The new limit is being introduced to ensure consistency and high-quality AdWords API platforms for advertisers.

If your developer token already has the Standard Access level, then this limit will not be applied.

If your developer token has the Basic Access level and you currently download more than 1,000 reports per day, then you'll be impacted. To minimize the impact:

  1. The AdWords API Compliance Team has already temporarily upgraded your developer token to Standard Access level.
  2. The AdWords API compliance team contacted you on September 24th, 2014 asking you to apply for permanent Standard Access prior to the temporary Standard Access level expiration on October 24th, 2014.

Important: The AdWords API compliance team will contact you using the developer contact email on file in your MCC's API Center. It's important to ensure the email is up-to-date.

If you currently have Basic Access, but at a later time feel you will need more than 1,000 report downloads per day, feel free to apply for Standard access.

Migrating off the Login field in the AdWords API

On November 5, 2014, we'll be sunsetting the login field in the ManagedCustomer class. We understand this may impact your applications and are recommending the following options to account for this change:

Maintaining customer contacts

You should not use the login field to manage your clients' contacts and email addresses. You should always maintain your own client contacts. If your application currently relies on the login field, you can use ManagedCustomerService.get() to create a mapping between customer IDs and login emails before November 5, 2014.

Identifying client accounts

CustomerId should be used instead of the login field to uniquely identify an account. To provide a friendly name for an account, you can use the name field. You may set the name field when creating a new account using the ManagedCustomerServer.mutate() method.

AdWords allows users to invite multiple users to manage their applications as well as change their AdWords sign-in information. However, the login field is not updated to reflect changes in AdWords sign-in information. So relying on the login field makes your application error prone if a user changes their AdWords sign-in information.

Determining the access level of a user

Your application runs with the same access levels as the user whose OAuth2 access token you send in your API calls. To determine if a user is authorized to make a particular change, you can make API calls with the validateOnly header set to true. If the user isn’t authorized to make changes, the call will fail with an AuthorizationError.

Login field information doesn't convey the access level the user has within AdWords. If you rely on a user’s login email to determine their access level, your application may run into errors if the user’s account access levels change.

If you have questions or feedback about this change, or encounter a use case we’ve missed, let us know on our developer forum or Google+ page.

Support for VPAID 2 JavaScript creatives in the IMA HTML5 SDK

We're pleased to announce that the IMA HTML5 SDK now supports VPAID 2 JavaScript creatives. Enabling support is as easy as including the following line before initializing your AdDisplayContainer:

    google.ima.settings.setVpaidAllowed(true);
...
var adDisplayContainer = new google.ima.AdDisplayContainer(adContainerElement);
var adsLoader = new google.ima.AdsLoader(adDisplayContainer);

VPAID 2 Support caveats

There are two differences to be aware of between the VPAID 2 spec and the way the IMA SDK supports VPAID 2. These differences do not impact player or SDK implementation code, but they are important for VPAID 2 JavaScript creative authors, as creatives may throw errors or not work as expected when rendered by the IMA HTML5 SDK.

  • IFrame security: The IMA SDK uses a secure iframe instead of a friendly iframe (same domain) or an in-page script to render VPAID 2 JavaScript creatives. This means that if a creative expects to access the DOM of the parent page, it could potentially cause an error.

  • Video player proxy element: For security and proper mobile functionality, the IMA SDK doesn't provide the actual video element to the ad; instead, it provides a proxy element that mimics much of the functionality of the normal video element. For ad creatives that only access supported video APIs available on the proxy element, there should be no behavior changes in the rendering of the creatives. See our guide to VPAID 2 creatives for a list of supported APIs on the video proxy element.

Learn more

For more information, including a listing of what API methods are supported in the video player proxy element, check out our guide to VPAID 2 creatives.

As always, if you have any questions, feel free to contact us via the support forum.

Sunsetting Login email in AdWords Scripts

We recently announced that we will sunset the login email field in AdWords API. To keep our APIs consistent, we will also sunset the getLoginEmail() method in AdWords scripts on November 5, 2014. We have identified some of the common use cases for this field and have come up with some possible workarounds.

Identifying accounts

When retrieving client accounts, use their Customer IDs instead of login emails to identify the accounts. You can use the getCustomerId() method to retrieve an account’s Customer ID. When available, you may also use the getName() method to retrieve the account’s friendly name. To set an account’s name,
  • Login to your My Client Center account and navigate to My Client Center tab
  • Click on the pencil logo in the corresponding Account’s the Client column
  • Provide a new name, and click the Save button to update the account name
Maintaining customer contacts

You should maintain your customer contacts going forward. If you were relying on the login email field to manage your client contacts, then you can use the getCustomerId() and getLoginEmail() methods to create a mapping from your customer ids to their login emails before November 5, 2014.

Determining access levels of a user in an account

Scripts run with the same access levels as the user who authorized the script. You shouldn’t rely on a login email to figure out a script’s access levels--this is a bad programming practice that makes your script error prone if the user’s account access level changes. Instead, make sure that the script is authorized by a user who has enough access levels as required by the script.

If you have questions or feedback about this change, or a use case we missed, let us know on our developer forum or our Google+ page.

Launching v6.1 of the Google Mobile Ads SDK for Android

Greetings developers!

We're happy to launch a new version of our Google Mobile Ads SDK for Android. You should see Google Play Services 6.1 (rev 20) available for download in your SDK manager.

This version includes the following changes:

  • Added a getLocation method to com.google.android.gms.ads.MediationAdRequest.
  • Added a content description for the interstitial close button.
  • Removed logging of "Google Play resources not found" when the library project is linked correctly.
  • Added getMediationAdapterClassName to AdView for getting the class name of the ad network mediation adapter currently showing an ad.

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 SDK changes, check out our release notes. For technical questions, post them on our forum.

The IMA SDKs now support VAST 3

We're taking VAST 3 support out of beta and launching it as a supported feature of the IMA SDKs for Flash, HTML5, iOS, and Android. VAST 3 adds support for a host of new features, including:

  • Enhanced reporting metrics and error codes.
  • Customizable skip times.
  • Ad podding.
  • Enhanced support for adaptive bitrate creatives (e.g., HLS).
  • Alternative companion creatives in HTML5 and iOS.
  • Icons in HTML5.
  • Companion adSlotId attribute in HTML5.

There are still a few features of VAST 3 that we will continue to add over time. Those include:

  • Alternative companion creatives in Flash and Android.
  • Companion adSlotId attribute in Flash, iOS, and Android.
  • Standardized fallback with the fallbackOnNoAd attribute.

Your IMA SDK integration already supports VAST 3 without any code changes on your end, but you will need to adjust your serving settings. To start serving VAST 3 check out the DFP help center articles for Small Business or Premium, depending on your account type.

For more information on the features and benefits of VAST 3, check out the IAB documentation. As always, if you have any questions feel free to contact us via the support forum.

Using LINQ with the DFP API

By now you're probably familiar with using PQL in the DFP API. The SQL-like filtering provides an expressive way of working with DFP, but occasionally you'll want to filter on a field that isn't supported by PQL. Luckily, if you're using the .NET library, you can utilize LINQ to augment your filtering capabilities.

Filter on any field

Similar to PQL, LINQ provides a friendly syntax for filtering iterables. As you page through entities from DFP, you can leverage LINQ to add that extra filtering with just a few lines of code.

This example finds all ImageCreatives that are missing altText - a field specific to the subclass and not filterable with PQL.

    CreativePage page = new CreativePage();
var creativesMissingAltText = new List();

// Create statement to select image creatives.
StatementBuilder statementBuilder = new StatementBuilder()
.Where("creativeType = :creativeType")
.OrderBy("id ASC")
.Limit(StatementBuilder.SUGGESTED_PAGE_LIMIT)
.WithBindVartiableValue("creativeType", "ImageCreative");

// Page through all creatives and select those that are missing the
// altText property with LINQ.
do {
page =
creativeService.getCreativesByStatement(statementBuilder.ToStatement());

creativesMissingAltText.AddRange(
from ImageCreative creative in page.results
where creative.altText == ""
select creative);

statementBuilder.IncreaseOffsetBy(StatementBuilder.SUGGESTED_PAGE_LIMIT);
} while (statementBuilder.GetOffset() < page.totalResultSetSize);

Console.WriteLine("Found {0} ImageCreatives missing altText",
creativesMissingAltText.Count);

While LINQ offers a way to extend filtering, it's important not to ignore PQL. You'll notice this example used PQL to pre-filter on the creative type. Working with smaller result sets will save you network overhead and processing cycles.

Filtering with regular expressions

Now let's take a look at a more complex example. In this scenario, your application needs to validate the htmlSnippet of CustomCreatives. LINQ allows you to use regular expressions while filtering to extract the matches. Here we'll use a regular expression to make sure URLs in the htmlSnippet point to a certain subdomain.

    // Make sure any URLs to mydomain go through the CDN.
Regex subdomainRegex = new Regex(@"https?://(?!cdn\.).*?mydomain.com");
var errors =
from CustomCreative creative in creativesToValidate
let matches = subdomainRegex.Matches(creative.htmlSnippet)
where matches.Count > 0
select new {
creativeId = creative.id,
matchedUrls = from Match match in matches select match.Value
};

foreach (var error in errors) {
Console.WriteLine("Invalid urls found in creative {0}: {1}",
error.creativeId, error.matchedUrls.Join(","));
}
LINQ also supports common functions like Average and Max, making it easy to interact with DFP entities. For more LINQ examples, check out 101 LINQ Samples. You just might find the missing link you need for your DFP application.