Google Ads Developer Blog: September 2016

Fatal versus non-fatal errors in the IMA SDKs

Thursday, September 29, 2016

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 adsManager:didReceiveAdError
Flash	adsLoadErrorHandler(AdErrorEvent) adsManagerPlayErrorHandler(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.

- Shawn Busolits, IMA SDK Team

Setting up your DFP integration for success

Thursday, September 29, 2016

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 credentialsadd multiple collaboratorsSimilarly, 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 namerequired

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.

- Vincent Tsao, DFP API Team

Google Mobile Ads Unity Plugin v3.0.7

Tuesday, September 27, 2016

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.

- Ram Parameswaran, Mobile Ads Developer Relations

Support for Search Audiences in AdWords Scripts

Wednesday, September 21, 2016

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

- Anash P. Oommen, AdWords Scripts Team

Support for additional audiences in AdWords Search and Shopping campaigns

Monday, September 19, 2016

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.

- Josh Radcliff, AdWords API Team

New dates for quality score changes in AdWords scripts

Friday, September 16, 2016

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.

Anash P. Oommen, AdWords Scripts Team

Use Google Mobile Ads SDK 7.11.0 to update apps for iOS 10

Thursday, September 15, 2016

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.

- Tristan Emrich, Mobile Ads Developer Relations

More time for upgrading your standard text ads

Wednesday, September 14, 2016

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:

You’ll no longer be able to create standard text ads.
The only change you'll be able to make to a standard text ad will be to update the status of its associated AdGroupAd.
Existing standard text ads will continue to serve alongside expanded text ads.

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.

Nadine Sundquist, AdWords API Team

Upgrade to campaign drafts and experiments in the AdWords API

Tuesday, September 13, 2016

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.v201603campaign drafts and experimentsExperimentServicecan run experiments on Display campaignsExperimentServiceAs 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.

- Mike Cloonan, AdWords API Team

Google Ads API .NET client library runtime update

Friday, September 2, 2016

November 2016Google Ads API .NET client libraryWhy are runtime requirements changing?ended supportAdditionally, increasing the runtime requirement allows us to make use of new framework functionality, to further improve and modernize the library. How can you prepare?upgrade to 4.5.2November 2016If you have any questions or concerns, feel free to open an issue on the client library's issue tracker.

- Jonathon Imperiosi, Ads Developer Relations Team

Support for account-level sitelinks in AdWords API

Thursday, September 1, 2016

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.

- Danial Klimkin, AdWords API Team.

Ads Developer Blog