We’ve seen an increase in support questions recently on fatal and non-fatal errors in the IMA SDKs, so we’re here to explain when and why each is fired, and how you should handle one versus the other.

When are fatal and non-fatal errors fired?

Simply put, a fatal error is fired by the SDK when there is no chance for the SDK to play an ad for the remainder of the current video. There are two common scenarios for fatal ad errors. The first is when the SDK itself fails to load. The second (and more common) is when you are requesting one and only one ad, and that ad request fails to return a valid ad.

A non-fatal error is fired by the SDK when something goes wrong with an ad, but the SDK could potentially play other ads. The most common scenario for a non-fatal error occurs when you’re requesting a pod or playlist of ads, and one ad fails to load. Because it could still play other ads in that pod or playlist, the SDK fires a non-fatal error and moves on to attempt the next ad.

How can I tell the difference between a fatal and a non-fatal error?

Fatal errors are what we call “top-level” errors. They trigger one of the following events, depending on your particular SDK:

SDK Triggered event or delegates
HTML5 onAdError(AdErrorEvent)
Android AdErrorEvent.AdErrorListener.onAdError(AdErrorEvent)
iOS adsLoader:failedWithErrorData
Flash adsLoadErrorHandler(AdErrorEvent)

Non-fatal errors are wrapped in a LOG type AdEvent. That event is sent to your AdsManager event listener or delegate. You can access the error message from the LOG event as follows:

SDK Error Data
HTML5 AdEvent.getAdData()[‘adError’].getMessage()
Android AdEvent.getAdData()[‘errorMessage’]
iOS IMAAdEvent.adData[@”logData”]
Flash Error(Event.adData.error).message

How should I handle fatal and non-fatal errors?

When you get a fatal error, you should destroy your AdsManager and play your content video. When you get a non-fatal error, you are not obliged to do anything for video and ad playback to continue - you can log the error message using the snippets shown in the table above for informational purposes.

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


It’s common to have multiple applications access your DFP network(s) when integrating with DFP. How you keep track of these applications and their authentication credentials can be just as important as writing code, particularly if you work with many other developers, or on more than one application. You want to avoid scenarios where you don’t know who or what is accessing your network, or where you can’t determine who owns the Google API Console project from which a set of OAuth2 credentials were generated. Here are some best practices to help mitigate this.

Managing your DFP credentials

It’s important to ensure that the right members of your team have access to the Google API Console project that generates your OAuth2 credentials. You can easily add multiple collaborators to an API Console project. This will help you track who’s integrating with DFP in a central location, rather than having each developer create their own API Console project.

Similarly, when choosing a Google account for DFP API authentication, you may want to consider an OAuth2 service account. That way, all members of an API Console project can easily access this account’s credentials through the console. This is much better than using an arbitrary individual’s account for authentication in case that person leaves your team, or has their account disabled.

Choose a strong application name

Defining an application name is required when making calls to the DFP API. However, we’ve seen a lot of not so useful application names, such as:
  • My DFP integration
  • abcxyz
  • Hello world!

This is particularly troublesome during sunsets when we send out emails identifying which application names are making calls to your network(s) using a deprecated API version. It’s difficult to track down what an application is doing, or who owns it, when it’s named something like "abcxyz". Here are some examples of better application names:

  • Monthly report download job
  • Weekly forecast script
  • Line item viewer

As always, if you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.


We recently launched v3.0.7 of the Google Mobile Ads Unity Plugin. The updated v3.0.7 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Native Ads Express

This release introduces support for Native Ads Express. With Native Ads Express, you can create CSS templates that define how ads are presented in your app (things like image sizes, fonts, colors, and so on). These CSS templates are used to generate ad creatives that complement the native look and feel of your app. You can find more information on integrating Native Ads Express into Unity applications in our developer docs.

Android IL2CPP

The v3.0.7 release resolves compatibility issues with the IL2CPP scripting backend and the Google Mobile Ads Unity Plugin. This allows the use of the the IL2CPP scripting backend, a high-performance alternative to the Mono virtual machine and AOT compiler, in Unity applications with the Google Mobile Ads SDK.

The source code and a sample app for the plugin are available in our GitHub repo, as is a changelog for this release. If you have any questions about Unity integration, you can reach us on our developer forum.

AdWords Scripts now supports Audiences for Search and Shopping campaigns. This release covers all the features you can do through the Audiences Tab in the AdWords UI - target or exclude audiences for an ad group, exclude audiences for a campaign, and apply or adjust bid modifiers. You may also retrieve audiences and their stats associated with ad groups and campaigns. Audience creation is not supported in this release.

See the code snippets to learn how to use this feature. As always, let us know your questions and feedback on our developer forum.

What's changing
Historically, some types of audiences have only been available for targeting and bidding in Display campaigns, as indicated by UserList.isEligibleForSearch = false in the AdWords API.

Starting at the end of September, 2016, both AdWords and the AdWords API will allow you to target additional audiences in Search and Shopping campaigns.

What you should do
  • Make sure that your application does not make assumptions about which user lists are available for Search and Shopping campaigns. Instead, your application should check the value of the isEligibleForSearch attribute of each UserList.
  • You can discover the audiences in your AdWords account and their eligibility for Search, Shopping, or Display campaigns by issuing an AdwordsUserListService get or query request that includes the IsEligibleForSearch and IsEligibleForDisplay selector fields. On an ongoing basis, you should periodically check for user lists where eligibility has changed due to improvements in AdWords.
  • If you'd like to add additional audience targeting to your Search or Shopping ad groups, add a BiddableAdGroupCriterion with a criterion set to an instance of the appropriate type of UserList. Make sure that your application can handle an OperationAccessDenied.OPERATION_NOT_PERMITTED_FOR_CAMPAIGN_TYPE error, which will occur if the particular UserList in your request is not currently available for Search and Shopping campaigns.
Further reading
For an overview of remarketing and audience targeting in the AdWords API, check out the Remarketing and audience targeting guide.

If you have any questions, please post on the forum or the Ads Developers Plus Page.

We recently announced some changes to the way AdWords scripts returns quality score data for keywords. To give developers more time to review their scripts that rely on Quality Scores in preparation for this update, null Quality Scores will now roll out on the the week of October 10th, 2016.

If you need help updating your script, or have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.


With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.

What changed?

With the rollout of iOS 10, the App Store’s privacy policy requires apps to provide a usage description when attempting to access privacy-sensitive data, such as a user’s calendar or Bluetooth. You may have seen the following errors when attempting to upload your app to iTunes Connect:

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."

The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.

Information for MRAID creative designers

To comply with the App Store privacy changes, we removed support for the mraid.createCalendarEvent() and mraid.storePicture() methods. You will now see that the mraid.supports("calendar") and mraid.supports("storePicture") methods always return false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.

If you have any questions regarding these changes, please contact us through our forum.

In a previous blog post, we announced that you would need to upgrade your standard text ads by October 26, 2016 to expanded text ads. To make sure you have ample time to test and iterate your expanded text ads for the holidays, we are giving advertisers more time to upgrade your creatives. You now have until January 31, 2017 to make the transition to expanded text ads (instead of the original date of October 26, 2016).

Starting on January 31, 2017: Please take advantage of this additional time to upgrade your standard text ads. For more details and tips, check out this blog post.

Questions? Visit us on the AdWords API Forum or our Google+ page.

[Update 9/14/2016: The previous version of this announcement indicated that you would be unable to create experiments starting on October 17, 2016. After hearing your feedback, we have decided to continue to allow full ExperimentService functionality in existing API versions up until the final shutoff date.]

In v201603, we introduced campaign drafts and experiments to the AdWords API for Search campaigns, which is a more flexible alternative to the existing ExperimentService. Now that you can run experiments on Display campaigns as well, campaign drafts and experiments do everything the ExperimentService can do and more.

As a result of this expanded functionality, the ExperimentService will be sunset. If you’re still using the ExperimentService, please take the time to update your code to use campaign drafts and experiments instead.

On February 1, 2017, all experiments running via the ExperimentService will be stopped. After this date, all ExperimentService experiments will be deleted, stats will be unavailable, and API calls to the ExperimentService across all API versions will result in an error.

Please move off the ExperimentService before February 1, 2017 to ensure that you are able to continue running experiments.

If you have any questions, please post on the forum.

Beginning in November 2016, all new releases of the Google Ads API .NET client library will target .NET Framework 4.5.2+. Currently released client library versions will not be affected.

Why are runtime requirements changing?

On January 12th, 2016, Microsoft ended support for .NET Framework versions 4, 4.5, and 4.5.1. To ensure the continued security and stability of our client library, we will also stop supporting these legacy framework versions.

Additionally, increasing the runtime requirement allows us to make use of new framework functionality, to further improve and modernize the library.

How can you prepare?

If your application currently targets .NET Framework 4.5.2+, then no action is required. Users of .NET Framework versions <= 4.5.1 will need to upgrade to 4.5.2 in advance of the November 2016 release. Users on non-Windows platforms should similarly ensure that their version of Mono supports the .NET Framework 4.5.2 target.

If you have any questions or concerns, feel free to open an issue on the client library's issue tracker.

Sitelinks in ads let you show additional links to specific pages on your website and are an effective way to drive traffic to your business. Account level sitelinks started rolling out recently in the AdWords user interface.

The AdWords API already supports sitelinks at the account level across all versions without any changes. You can use the CustomerExtensionSettingService to read and mutate the existing extension type SitelinkFeedItem, or associate sitelinks via Feed services.

If you have any questions, please let us know on the forum.