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.


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.


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:

    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.

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.


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


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.


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")
        .WithBindVartiableValue("creativeType", "ImageCreative");

    // Page through all creatives and select those that are missing the
    // altText property with LINQ.
    do {
      page =

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

    } while (statementBuilder.GetOffset() < page.totalResultSetSize);

    Console.WriteLine("Found {0} ImageCreatives missing altText",

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\.).*?");
    var errors =
        from CustomCreative creative in creativesToValidate
        let matches = subdomainRegex.Matches(creative.htmlSnippet)
        where matches.Count > 0
        select new {
          creativeId =,
          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.