Subscribe: AdWords API Blog
Added By: Feedage Forager Feedage Grade A rated
Language: English
access  ads  adwords api  adwords scripts  adwords  api  dfp  google  mobile ads  questions  scripts  sdk  team  user 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: AdWords API Blog

Google Ads Developer Blog

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

Updated: 2016-10-21T03:06:04.049-07:00


Changes to ClickType field compatibility in AdWords API & Scripts Reports


We are marking the ClickType column in AdWords API and Scripts reports as incompatible with the following engagement and video-related fields in version v201607 and earlier:
  • AverageCpe
  • EngagementRate
  • VideoQuartile25Rate
  • VideoQuartile50Rate
  • VideoQuartile75Rate
  • VideoQuartile100Rate
  • VideoViews
  • VideoViewRate
  • AverageCpv
These fields refer to engagement and video view interactions, and aren’t compatible with the ClickType column, a click interaction metric. This restriction is already enforced in v201609 reports, see our migration guide for more details.

Starting Dec 1, 2016, you will get a ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT error if ClickType column is requested with any of these fields.

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

Link your Merchant Center and AdWords accounts using the Content API for Shopping and AdWords API


What's changing?
As of today, the getServiceLinks() and mutateServiceLinks() methods on CustomerService are available to all AdWords API users. Previously, these methods were only available to whitelisted users.

Using this functionality and the Content API for Shopping, you can now fully automate the process of linking Merchant Center accounts to your AdWords account. Previously, you could send a link invitation using the Content API for Shopping, but you could not accept or reject the invitation using the AdWords API.

What do the new features do?
I thought you'd never ask! :)
  • getServiceLinks() retrieves the status of links between your AdWords account and Merchant Center accounts.
  • mutateServiceLinks() accepts or rejects links between your AdWords account and Merchant Center accounts.
What should you do?
If you're interested in automating the linking process between Merchant Center and AdWords, check out the updated shopping campaigns guide.

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

Support for new ad formats in AdWords Scripts


AdWords scripts now fully support responsive ads, image ads, HTML5 ads and multiple Gmail ad formats. See our guideon ad types and related code snippets to learn more about using these ad formats in Scripts.

This update also introduces a media service which can be used to upload and query media for use in ads. See our ad media guide for a more detailed overview of media support.

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


Changes to Conversion-related stats in AdWords Scripts


We are making two changes related to how various conversion-related stats are retrieved in AdWords Scripts.

New methods for Conversion stats

We are reintroducing two methods in the AdWordsApp.​Statsand MccApp.​ManagedAccountStatsclasses to work with Conversions.

Note: Since Conversions is a stat of type Double, the equality operators (= and !=) won’t work with these new methods when using the withCondition filters or comparing values in code. Instead, you need to use comparison operators like < and >or round Conversions off to an Integer.

Sunsetting ConvertedClicks

As part of sunsetting Converted clicks in AdWords, we are deprecating the getConvertedClicks()and getClickConversionRate()methods in the AdWordsApp.​Statsand MccApp.​ManagedAccountStatsclasses. These methods will be sunset on February 21, 2017.

If your scripts use these methods, update them to use the new Conversion stats methods if applicable before February 21, 2017 to ensure they continue to work.

If you have any questions about these changes please reply to this email or post them on our developer forum and we'll be glad to help you.


Demystifying OAuth2 in DFP


Authentication with the DFP API is probably something you had to set up once and then never thought about again. Well, that may be true until there's a scope change, or your credentials suddenly stop working, or the developer who created the credentials leaves to open their own yoga studio in the Andes. Understanding some of the finer details of DFP's OAuth2 flows can come in handy when the unexpected happens. Access tokens When using the DFP API, you can authenticate on behalf of a user in your network or as an application. For the DFP API we call these two choices Web Application flow and Service account flow (server-to-server), respectively. Each choice has a different set-up, but both are used to generate access tokens. All DFP API requests are authenticated using access tokens. You can think of these as short-lived (about one hour) passwords. When making a request, you include the access token in the HTTP header: Authorization: Bearer ACCESS_TOKEN Every access token is tied to a specific user and one or more API scopes. The scopes control which Google APIs the access token is valid for. The scope for DFP is: Access ControlBecause every access token is associated with a user, the DFP API enforces the same exact access controls as the DFP UI. This means that all the teams, roles, and permissions that restrict the user are in effect. When authenticating as a dedicated API user like a service account, make sure that user is configured with your desired teams and role in DFP. There's no requirement that API users have administrator access. TroubleshootingIf you ever need to verify the scope or who the access token was issued to, you can easily do so using the OAuth2 API explorer. Enter the access token you're using, and the API will provide a JSON response with the details: POST { "issued_to": "", "audience": "", "scope": "", "expires_in": 3496, "access_type": "offline" } Refresh TokensAlthough we now recommend using service accounts for server-to-server flow, many integrations still use an installed application flow. This flow uses a refresh token to generate access tokens. If your refresh token stops working, there are a few possible causes: The user you're authenticating as no longer has access to the DFP network. Too many refresh tokens were generated for the OAuth2 client. The user you're authenticating as has revoked access for your application. The simplest solution to all of these is to create a new client and generate a new refresh token for a current DFP user. Remember that the refresh token is tied to the account that authorizes the application, and not the user who created the OAuth2 client. When accepting the OAuth2 authorization prompt, verify that the user in the top right corner that is logged in is correct: If OAuth2 still gives you a headache, we're happy to troubleshoot with you. Just reach out to us on our developer forum.  - Chris Seeley, DFP API Team[...]

DCM/DFA Reporting and Trafficking API sunset reminder


In accordance with our deprecation schedule, we will be sunsetting v2.4 of the DCM/DFA Reporting and Trafficking API on November 30th, 2016. On this date, all requests made against v2.4 of the API will begin returning HTTP 403 errors.

If you're still working with this version, we strongly encourage you to begin migrating to the most recent release to avoid an interruption in service. If you're not sure, or would like to know more about the migration process, refer to the migration guide.

As always, feel free to reach out to us with any questions that you have. To receive future updates like this directly in your inbox, join the DCM API Announcements group and adjust your notification settings.


Announcing rewarded video custom event support for AdMob mediation


Following its launchat the 2016 Game Developer’s Conference, AdMob’s mediation support for rewarded video ads has been a hit with publishers and users alike, with rapid adoption on both Android and iOS platforms.

Our growing list of mediation partners includes eight different ad networks. Choosing AdMob for your rewarded video mediation platform gives you access to ad content from all of them, while you develop against a single API from AdMob. Now, with the launch of custom events for rewarded video, you can also request and display rewarded videos from ad networks that are not directly supported by AdMob.

Our implementation guide for rewarded video adapters (Android| iOS) outlines how to implement an adapter that can serve rewarded video ads from a third party ad network. Special attention should be paid to steps specific to custom events that are summarized below:

Adding a custom event to your ad unit

To define a custom event, you must first create it in the AdMob interface at You can find instructions for creating a custom event in this help center guide.

Retrieving server parameters

The optional server parameter passed to your custom event is accessed via a special key. Here’s an example showing how to access the value in a rewarded video adapter:


String parameter = serverParameters.getString(


NSString *parameter = [self.connector.credentials

You can find additional documentation on rewarded video ads in our Get Started guides (Android| iOS), and more information about mediation is available in our mediation guides (Android | iOS). For any other questions about rewarded video mediation, you can reach us through our developer forum.


Sunset of DFP API v201508 and v201511


On Wednesday, November 30, 2016, in accordance with the deprecation schedule, v201508 and v201511 of the DFP API will be sunset. At that time, any requests made to these versions will return errors. If you're still using these versions, now's the time to upgrade to the latest release and take advantage of new features like HTML5 creatives, programmatic support, and retrieving saved report queries. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code. Significant changes include: Flash creatives, template creatives, and custom creatives have been updated to use CreativeAssets.The ApproveSuggestedAdUnit action has been renamed to ApproveSuggestedAdUnits.The reporting format CSV_EXCEL has been renamed TSV_EXCEL to more accurately describe its actual format.Team.companyIds, Team.adUnitIds, and Team.orderIds have been removed. Use Company.appliedTeamIds, AdUnit.appliedTeamIds, and Order.appliedTeamIds instead.Order.programmaticSettings has been replaced by Proposal.ProposalMarketplaceInfo. This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Sunset Announcements group and adjust your notification settings.  - Chris Seeley, DFP API Team[...]

Shopping for a Ruby to Go with new Content API samples


Our Samples and Libraries page has been updated with additional languages: Ruby and Go. For Ruby, the new samples are written in plain Ruby, which should make them easy to integrate into whatever Ruby framework you may be using for your particular project. If you haven't had a chance to try your hand at Go yet, the new Go examples provide the perfect excuse.

If you have questions about the samples or any feedback on how they might be improved or expanded, please feel free to file an issue on GitHub! If you have any other questions or feedback concerning the Content API for Shopping in general, please let us know on the forum.

Campaign-level positive user lists for remarketing, targeting, and bid modifiers coming to AdWords API


Positive user list criteria for remarketing will be rolling out over the next few months and supported at the campaign level. After this is enabled for your account, you will be able to use Bid Only and Target and Bid targeting settings, along with bid modifiers for these criteria, at the campaign level. While targeting settings for campaigns requires v201609 of the API, adding user list criteria and setting bid modifiers will work with all versions of the AdWords API.

You cannot set user lists at both the ad group and campaign levels at the same time. When switching a campaign from ad group-level user lists to campaign-level lists, you must first remove existing positive user list criteria from all ad groups or there will be a CANNOT_ATTACH_CRITERIA_AT_CAMPAIGN_AND_ADGROUP error upon attaching a user list to the campaign. The process for removing existing user list criteria, adding them at the campaign level, changing targeting settings, and using bid modifiers is similar to that for ad groups and is detailed in the Remarketing guide. Please note that existing code working with campaign criteria may need to be modified to handle the presence of user lists.

If you have any questions about this change, or other questions about the AdWords API, contact us via the forum.


Mobile Ads Garage #9: AdMob Mediation


Episode nine of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

In this episode of The Mobile Ads Garage, we discuss mediation, which is a way for publishers to get multiple networks of advertisers competing to display ads in their apps. We’ll show you how AdMob mediation works and what it can do for your business. Learn the pros and cons of mediation, see the details of implementation, and find out whether it’s right for your app. You'll also get screencasts for Android and iOS showing the integration of a third-party SDK, plus links to samples, written resources, and Gary the Graphics Guy acting like his usual, snarky self.

width="560" height="315" src="" frameborder="0" allowfullscreen>

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.


Access multiple AdWords accounts with one Google account


On September 12th, AdWords announced that you can now use one Google login to access multiple AdWords accounts. With this change, you can associate up to 5 AdWords accounts with a single Google account.

To take advantage of this new feature, the AdWords API has changed the behavior of CustomerService.getCustomers() starting with v201603. In the past, the Google account you used to obtain your OAuth2 credentials could only be associated with one AdWords account, which resulted in getCustomers() only returning one AdWords account. Now that a Google account can be associated with multiple AdWords accounts, getCustomers() can return multiple AdWords accounts. If you only want to retrieve the details of a specific customer using CustomerService, you can set the clientCustomerId in the request header starting with v201607.

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

Support for v201607 reports in AdWords Scripts


We have added support for AdWords API v201607 reports in AdWords scripts. The major changes in this release are: The ConvertedClicks field and its derived fields were removed from all reports. Modify your report requests to retrieve the corresponding fields based on Conversions instead. New columns were added to the CAMPAIGN_PERFORMANCE_REPORT and ADGROUP_PERFORMANCE_REPORT for Desktop and Tablet device bid modifiers. The QualityScore field will now have a value of "--" on rows where HasQualityScore = false. Previously, these rows had a default QualityScore value. EffectiveFinalUrl on the FINAL_URL_REPORT and FinalUrl on the SEARCH_QUERY_PERFORMANCE_REPORT will now have a value of "--" when no data is available. Previously, these fields returned the empty string in this situation. See the AdWords API release notes for more details. v201605 will remain the default version for reports until the week of October 10th, 2016. This gives you enough time to verify your scripts and make sure it works with the latest report version. If you use API versioning in your reports, you need to modify your code to use v201607: var report =, { apiVersion: 'v201607'}); If you don’t use API versioning, no code changes are required. Your reports will continue using v201605 for now, and switch to v201607 when we make v201607 the default version the week of October 10th, 2016. If you 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[...]

Introducing IMA SDK and Google Cast examples


Have you ever asked yourself, Can I use the IMA SDK and Google Cast together to display videos with ads on a cast-enabled device? The answer is, yes you can!

We’ve put together a new section of guides and examples that show you how to add cast support to your IMA SDK implementation. They also explain the logic behind requesting ads on the sender and receiver devices. We’ve included both Androidand iOSexample sender apps, and an example HTML5receiver.

We recommend familiarizing yourself with the Google Cast SDK as well as the IMA SDKs for Android, iOSand HTML5before diving into these examples.

If you have any questions about these examples, feel free to contact us via the support forum.


How and when to use service accounts with the Content API for Shopping


The Content API for Shopping documentation now includes a guide for using OAuth 2.0 service accounts with Content API for Shopping. This guide will be of particular interest to in-house developers, whose applications do not need access to third-party information. In such cases, requiring the application to get user approval and to keep track of refresh tokens may be unnecessary overhead. Instead, service accounts provide a private key that the application can use to authenticate when using the Content API.

For developers that work with third-party information, you should still use the OAuth2 three-legged authentication flow as described in the Authorize Requests guide to request permission from users for access to their information.

If you have questions about which flow is more appropriate for your project, or any other questions or feedback concerning the Content API for Shopping, please let us know on the forum.

AdWords API v201603 sunset reminder


AdWords API v201603 will be sunset on October 31, 2016, after which all v201603 API requests will begin to fail. This version was deprecated on July 28, 2016. If you are still on v201603, we recommend that you skip v201605 and v201607 and migrate directly to v201609. Please be sure to migrate prior to the sunset to ensure your API access is unaffected.

We've prepared various resources to help you with the migration: As always, if you have any questions about this migration, please contact us via the forum.

Google Click ID (GCLID) will now be generated at impression-time


Currently, if you turn on auto-tagging, when a user clicks on your ad, a unique Google Click ID (GCLID) will be generated that you can use to track offline conversions using UploadConversion. If a user clicks on your ad several times, you will get multiple GCLIDs, one for each click. Click Performance Report shows click details by returning one row for each click, which is equivalent to one GCLID.

In Q4 2016, we will change the timing of GCLID generation to impression time (or when your ad is shown) instead. As a result, if a user clicks on a particular ad impression multiple times, those clicks will be associated with only one GCLID. Consequently, landing page visits for the exact same impression will share the same GCLID value. This change opens the door for future improvements to user experience with Google ads.

To report the number of clicks associated with a GCLID, we are adding a new report field, Clicks, to Click Performance Report before this change. If your ads are normally clicked many times per impression, you will see fewer rows returned by Click Performance Report. For click-time GCLIDs, Clicks will always be returned as 1.

What you should do
  • Ensure that your application is aware of multiple clicks to your landing pages with the same GCLID.
  • Do not make any assumption that a GCLID is unique per click.
  • If you use the Click Performance Report, be aware that you may get fewer data rows than before.
As always, if you have any questions, please post on the forum or the Ads Developers Plus Page.

Announcing v201609 of the AdWords API


Today we’re announcing the release of AdWords API v201609. Here are the highlights: Universal app campaigns support. Management of universal app campaigns is now supported by the AdWords API. Check out the updated mobile app campaigns guide for details.Conversion attribution models. The AdWords API now supports modifying and retrieving the attribution model attributes of each of your conversion types via the new attributionModelType and dataDrivenModelStatus fields of ConversionTracker.Improved customer match management. The AdwordsUserListService now allows you to remove all members from a CrmBasedUserList without specifying the hashed email address of each member. Read the updated reference documentation for instructions on how to use this new feature.Call conversion imports. The AdWords API has a new OfflineCallConversionFeedService to allow you to import call conversions. Check out the updated tracking & importing conversions guide to get started.AdWords campaign experiments. In keeping with the recent blog post, the ExperimentService was removed in favor of the new campaign drafts and experiments services introduced in v201603. If you’re using v201603 or v201605 of the AdWords API, please note that they’re now deprecated and will be sunset on October 31, 2016 and February 28, 2017, respectively. We encourage you to skip v201607 and migrate straight to v201609. As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201609 migration guide. The updated client libraries and code examples will be published shortly. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page. - Josh Radcliff, AdWords API Team[...]

Fatal versus non-fatal errors in the IMA SDKs


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:failedWithErrorDataadsManager: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


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.


Google Mobile Ads Unity Plugin v3.0.7


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,asisa changelogfor this release. If you have any questions about Unity integration, you can reach us on our developer forum.


Support for Search Audiences in AdWords Scripts


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.


Support for additional audiences in AdWords Search and Shopping campaigns


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.

New dates for quality score changes in AdWords scripts


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.

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


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 calendaror 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[...]