In July, there was a change in how the Content API for Shopping responds when inserting products that contain validation errors due to work related to advanced feed management.

What changed?
Here are the changes in behavior when inserting product information that contains validation errors and would result in an invalid product:

	Before	After
Inserting new product	Error (inserted)	Success (inserted)
Updating invalid product	Error (inserted)	Success (inserted)
Updating valid product	Error (not inserted)	Error (not inserted)

That is, before the Content API would return an error whenever the new product information contained validation errors. Now, an error is returned only if the product information cannot be updated because it would invalidate the currently valid product.

Note: With this change, the Content API now returns an error response to product insertion only when the returned error response contains the not_inserted error. Since this error is now redundant, we plan to remove it in the future.

Why has this behavior changed?
With the new advanced feed management features, the products inserted via the Content API may be augmented with information from associated supplemental feeds. This means that a product that would normally be invalid from just the information provided by the Content API may become valid when the information is combined with supplemental feeds to produce the final version of a product.

For example, suppose you submit product information via the Content API that lacks needed GTIN information. You then submit the GTIN information for your products separately via a supplemental feed that is connected to the Content API feed in Merchant Center. The products inserted by the Content API are not valid products due to the lack of GTIN information, but once the GTIN information from the supplemental feed is added, the resulting products are valid.

What do I need to do?
If you depend on error responses from Products.insert to detect validation issues, then you should instead also check your Content API feed for validation issues by using either Productstatuses or Accountstatuses. This will catch products that were inserted with invalid information and have not been made valid after insertion via supplemental feeds.

Note: If you are using Productstatuses.list to check all the products in a given account, you'll need to set the includeInvalidInsertedItems parameter to return products with validation errors.

If you have any questions or feedback about this change or any other questions about the Content API for Shopping, please let us know on the forum.
 - Stevie Strickland, Content API for Shopping Team

MacOS High Sierra includes a new version of Safari, Safari 11. This new version by default will remove support for auto-playing videos unless they are muted. If your desktop site currently autoplays unmuted video with the IMA SDK, your users will see the first frame of the ad, but the ad will not play. To resolve this, you can either change your implementation to click-to-play, or attempt to autoplay and revert to click-to-play if that fails. We've also added a new error that will fire if the SDK is asked to autoplay an ad but is prevented from doing so by the browser. Continue reading for more info on these solutions.

Click-to-play

The simple, advanced, and playlist IMA SDK samples use this click-to-play functionality. In short, you add a play button to your UI, and render that play button on page load. Your code should then delay calls to adDisplayContainer.initialize(), adsManager.init() and adsManager.start() until the user clicks that play button.

Attempt to autoplay

We've added a new sample to our GitHub repo, Attempt to Autoplay. This sample will autoplay ads if allowed, and if not, will follow the above click-to-play workflow. The sample starts by attempting to autoplay the content video. If autoplay succeeds, it pauses the content to play a pre-roll. This happens in an instant, so the users will not see any content actually play before the ads. If this autoplay attempt fails, the sample renders a play button and waits for the user to click that button to initialize the ad display container and play ads.

New error for failed autoplay

We've added AdError.ErrorCode.AUTOPLAY_DISALLOWED which the SDK will fire if it is asked to autoplay an ad but is prevented from doing so by the browser. You should not see this error if you've properly implemented one of the solutions above. This error is wrapped in a VIDEO_PLAY_ERROR; you can look for it as follows:

onAdError(adErrorEvent) {
  if (adErrorEvent.getError().getInnerError().getErrorCode() ==
      google.ima.AdError.ErrorCode.AUTOPLAY_DISALLOWED) {
    // The browser prevented the SDK from autoplaying an ad.
  }
}

If you have any questions, feel free to reach out to us on our support forum.

 - Shawn Busolits, IMA SDK Team

We are making the following changes to AdWords OAuth Scopes during the week of January 8, 2018.

Invalid OAuth scopes will no longer be supported
One mistake that developers make when obtaining an OAuth2 access or refresh token for AdWords API is to use the service URL prefix (e.g. https://adwords.google.com/api/adwords/cm/v201708, https://adwords.google.com/api/adwords/reportdownload/v201708) as OAuth2 scope. When we switched to OAuth2, this was a common source of confusion for AdWords API users, so we allowed developers to use these scopes. Since most users are now using the new scope, we are sunsetting these old scopes. Any refresh tokens authorized with the old scopes will stop working with an invalid_scope error. If this error occurs, you will have to re-authorize your users with the proper AdWords scope (https://www.googleapis.com/auth/adwords) to continue making API calls.

Change to permitted OAuth 2.0 scopes when creating Location Extension feeds
When creating a Feed for Location Extensions, make sure you set the OAuthInfo object’s httpRequestUrl field to the AdWords API scope (https://www.googleapis.com/auth/adwords). In the past, we also supported using the Google My Business scope (https://www.googleapis.com/auth/plus.business.manage) for this field; we are sunsetting support for this scope. Similarly, the httpAuthorizationHeader field must have an access token that is authorized for the AdWords API scope.

While we don’t expect most users to be affected by these changes, make sure you review your code and make necessary changes if needed. As always, if you have any questions, let us know on the AdWords API forum.
Anash P. Oommen, AdWords API Team

On March 15, 2018, we are stopping development and support for Google Media Framework (GMF) for Android in favor of the new ExoPlayer IMA extension. GMF's technology and approach are based on an older version of ExoPlayer.

The new v2 version of ExoPlayer and the ExoPlayer IMA Extension make basic integration simple enough that a layer between ExoPlayer and the IMA SDK is no longer necessary. The new approach is cleaner, requires less code, and uses the most up-to-date version of ExoPlayer.

Support for GMF for Android will end on March 15, 2018, after which we will no longer respond to issues or make any further releases of GMF for Android. The repository will also be shut down at this time. If you want to access the code, you can clone the repository before the March 15, 2018 shutdown date.

Note: We are NOT deprecating GMF for iOS.

If you have any questions, feel free to contact us via the IMA SDK developer forum.

 - Yury Pavlotsky, IMA SDK Team

You can now access RTB Breakout metrics programmatically with new RTB troubleshooting resources added to the DoubleClick Ad Exchange Buyer REST API. These include the following:

• filterSets
• filterSets.bidMetrics
• filterSets.bidResponseErrors
• filterSets.bidResponsesWithoutBids
• filterSets.filteredBidRequests
• filterSets.filteredBids
• filterSets.filteredBids.creatives
• filterSets.filteredBids.details
• filterSets.impressionMetrics
• filterSets.losingBids
• filterSets.nonBillableWinningBids

RTB troubleshooting resources are placed hierarchically under both bidders and bidders.accounts. For more information about these resources and how they differ when used at the bidder or account level see the RTB troubleshooting guide.

If you have any feedback or questions about the RTB troubleshooting resources, feel free to reach out to us via the DoubleClick Ad Exchange Buyer API support forum.

 - Mark Saniscalchi, Ad Exchange Team

In the Google Mobile Ads SDK Android version 11.2.0 and iOS version 7.21.0, we added multiple native ads, a new feature for AdMob Native Ads Advanced. This feature lets you load up to five unique native ads with a single request. If you're showing native ads in a scrolling feed, this will allow you to get a batch of ads different from one another. It also means fewer network calls, which improves latency.

If you're displaying multiple native ads in a feed and loading ads one by one, converting to the new API should be fairly straightforward.

First, make a decision about how many ads you wish to fetch in one request. This is a function of how frequently you display ads in your feed. If you request five ads, AdMob will return the top five ads, ordered by eCPM value. If only three ads are available for the ad unit, only three ads will be returned.

iOS Implementation

Before initializing your ad loader, you need to create an instance of GADMultipleAdsAdLoaderOptions and set the numberOfAds property. Then include this object in the array of options when calling GADAdLoader's initializer:

override func viewDidLoad() {
    super.viewDidLoad()

    let multipleAdsOptions = GADMultipleAdsAdLoaderOptions()
    multipleAdsOptions.numberOfAds = 5

    adLoader = GADAdLoader(adUnitID: YOUR_AD_UNIT_ID, rootViewController: self,
        adTypes: [GADAdLoaderAdType.nativeContent,
                  GADAdLoaderAdType.nativeAppInstall],
        options: [multipleAdsOptions])
    adLoader.delegate = self
    adLoader.load(GADRequest())
  }

When requesting multiple native ads, you will still get individual callbacks when each ad is loaded. For example, for an app install ad you will have a callback to -adLoader:didReceiveNativeAppInstallAd:, and for a content ad -adLoader:didReceiveNativeContentAd:. This way you don't need to change the way the ads are received and shown.

To determine when ads have finished loading, there are two new APIs available:

1. On the GADAdLoader object, a new property, loading, has been added. It returns true if a request is in progress, and false otherwise. You can check this property after each ad has loaded to find out if loading ads has completed.
2. On the GADAdLoaderDelegate, the adLoaderDidFinishLoading: method has been added. It's invoked when all ads for a request have been returned.

Android Implementation

The Android implementation is similar to iOS. There's a new method on AdLoader, loadAds() which accepts the number of ads to load. There's also a new isLoading() method that indicates whether a request is currently in progress.

For a detailed walkthrough of the implementations, see the AdMob Native Ads Advanced implementation guides (iOS | Android). If you have any questions about this feature in the Google Mobile Ads SDK, please drop us a line at the developer forum.

 - Samuel Stow, Mobile Ads Developer Relations

We have added support for AdWords API v201708 and v201710 reports in AdWords scripts.

The major changes in v201708 are:

• New fields in various report types.
• The TABLE_EXTENSION enum value for ClickType was renamed to PRICE_EXTENSION.
• See the full AdWords API release notes for more details.

The major changes in v201710 are:

• The Automated field was added to the AD_PERFORMANCE_REPORT.
• The EnhancedCpvEnabled field was removed from all reports.
• See the full AdWords API release notes for more details.

In addition to these changes, v201705 is now the default version for reports. You can use one of the newly supported versions instead by specifying the apiVersion in your report request:

var report = AdWordsApp.report(query, {
    apiVersion: 'v201710'
});

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

- Mike Cloonan, AdWords API Team.

Today we're releasing v3.0 of the DCM/DFA Reporting and Trafficking API. Highlights of this major version release include:

• Advertiser landing pages
• Creative polite load and placement video orientation options
• Support for global site tags

Although we strive to maintain backwards compatibility between releases, a number of enhancements in this release necessitated breaking changes to existing API workflows. Details of these and all other changes are covered in our release notes.

Deprecation and sunset reminder
In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.8, which will sunset on August 31st, 2018. After this date, any requests made against v2.8 will begin returning errors.

As a final reminder, API version 2.7 will be sunset on December 7th, 2017. To avoid an interruption in service, all users are required to migrate to a newer version before the sunset date.

Learn More
As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the release notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

Give it a try and let us know if you have any questions!
- Jonathon Imperiosi, DCM API Team

Today we're pleased to announce several additions and improvements to the DFP API with the release of v201711. This release includes a new service, CdnConfigurationService, which manages the configuration of DAI (Dynamic Ad Insertion) content ingestion and delivery networks.

Please note that Ad Exchange historical reports will be run in the Pacific timezone in v201711. This will allow you to report on Bid and Deals metrics. If you need to continue running Ad Exchange historical reports in your network timezone, please stay on v201708. Future versions will support both options.

Additionally, the release adds the ability to generate in-site preview URLs for native styles, and you can now determine if an AdUnit supports fluid sizes by looking at the new isFluid attribute.

For a full list of API changes in v201711, see the release notes.

With each new release comes a deprecation. If you're using v201611 or earlier, it's time to look into upgrading. Also remember that v201702 will be sunset at the end of February 2018.

As always, if you have any questions, feel free to drop us a line on the DFP API forum.

 - Gabe Rives-Corbett, DFP API Team

If you use AdWords API reports to retrieve performance statistics for AdWords Express campaigns, please read on as these changes will affect you.

What's changing?
In preparation for upcoming improvements, an ongoing migration process is modifying campaigns managed by AdWords Express.

Currently, when you enable an AdWords Express promotion, it creates up to two AdWords campaigns:

• A Search Network campaign with:
  • AdvertisingChannelType = SEARCH (appears as Search)
  • AdvertisingChannelSubType = SEARCH_EXPRESS (appears as Search Express)
• A Display Network campaign with:
  • AdvertisingChannelType = DISPLAY (appears as Display)
  • AdvertisingChannelSubType = DISPLAY_EXPRESS (appears as Display Express)

As part of the migration, the two campaigns above will be paused and replaced by a single AdWords campaign with:

• AdvertisingChannelType = EXPRESS (appears as Express)
• AdvertisingChannelSubType = UNKNOWN (appears as an empty string)

After the campaigns for a promotion are migrated, performance statistics for the AdWords Express promotion will be available in reports as follows:

• Performance statistics for dates prior to the migration will be attributed to the original campaigns with SEARCH / SEARCH_EXPRESS and DISPLAY / DISPLAY_EXPRESS.
• Performance statistics for dates after the migration will be attributed to the new campaign with EXPRESS / UNKNOWN. The new campaign will only appear in the CAMPAIGN_PERFORMANCE_REPORT.

For example, assume an AdWords Express promotion manages the following two AdWords campaigns today:

Campaign ID	Campaign Status	Advertising Channel Type	Advertising Channel Sub Type
1000	ENABLED	SEARCH	SEARCH_EXPRESS
2000	ENABLED	DISPLAY	DISPLAY_EXPRESS

After the migration, the account will contain the following campaigns for the AdWords Express promotion:

Campaign ID	Campaign Status	Advertising Channel Type	Advertising Channel Sub Type	Performance statistics
1000	PAUSED	SEARCH	SEARCH_EXPRESS	Before the migration
2000	PAUSED	DISPLAY	DISPLAY_EXPRESS	Before the migration
3000	ENABLED	EXPRESS	UNKNOWN	After the migration

What should you do?
Ensure that your application properly handles all three combinations of AdvertisingChannelType and AdvertisingChannelSubType. For example:

• If your application inspects AdvertisingChannelType or AdvertisingChannelSubType to handle AdWords Express campaigns, please adjust the logic to handle the new combination of EXPRESS / UNKNOWN.
• If you use predicates on AdvertisingChannelType or AdvertisingChannelSubType to include or exclude AdWords Express campaigns, make sure that your predicate takes the new combination into account.

Reminder: The AdWords API only supports retrieving AdWords Express entities. You cannot modify AdWords Express entities in your account using the AdWords API.

If you have any questions about this change, please contact us via the forum.
- Josh Radcliff, AdWords API Team

DCM/DFA Reporting and Trafficking API v2.7 will be sunset on December 7th, 2017. From this date onwards, all requests made against v2.7 of this API will fail. If you're still actively working with this version, we strongly encourage you to begin migrating to the most current release to avoid an interruption in service.

For most, migrating will be as easy as adopting the latest version of your preferred client library. However, all users are advised to review the release notes to learn about important version differences you may need to be aware of.

If you have questions about this or anything else DCM API related, feel free to reach out to us on our support forum.
- Jonathon Imperiosi, DCM API Team

Starting mid-November, we’ll be updating AdWords API impression share reporting data more frequently. As a result, you'll be able to get the previous day's data by 12 PM (your local time). Previously, you might have had to wait up to 48 hours for the previous day’s data. This change affects the following reporting fields:

• SearchBudgetLostImpressionShare
• SearchExactMatchImpressionShare
• SearchImpressionShare
• SearchRankLostImpressionShare

With this change, you may see data fluctuate for report definitions that contain any of the above fields along with one of the following date ranges:

• YESTERDAY, TODAY, LAST_7_DAYS, THIS_MONTH, ALL_TIME, LAST_14_DAYS, LAST_30_DAYS, THIS_WEEK_SUN_TODAY, THIS_WEEK_MON_TODAY
• CUSTOM_DATE that includes the current date or the day before the day when you make a report request

This change allows for more real-time monitoring of search impression share. If you prefer to see more stable values, make sure the date range in your request doesn’t include the current date or yesterday if it’s not yet 12 PM in your time zone.

As always, if you have any questions, please post on the forum.
 - Thanet Praneenararat, AdWords API Team

One of the biggest cheers from the crowd at I/O '17 came in response to Stephanie Saad Cuthbertson's announcement that Kotlin would be an officially supported language for Android development starting with Android Studio 3.0. If you're an AdMob or Doubleclick publisher who's been eager to make the leap to a new language, we've got another announcement you might like: now that the new version of Android Studio has launched, we've released bunch of new mobile ads resources to support the Kotlin community.

If you haven't seen Kotlin yet, it's a statically typed language developed by JetBrains that compiles down to the same JVM bytecode that Java does, but includes a number of new features that can make Android development faster and easier. Things like dedicated data classes with less boilerplate, the Elvis operator, lambdas, SAM conversion, explicit nullability for references, and lots of other modern language features come built-in. For more information, see Introduction to Kotlin (also from I/O '17) in which Andrey Breslav and Hadi Hariri code up examples of the language's best features:

When you're done, you can see those same features in action in our new developer resources, which are now available to the AdMob and Doubleclick publisher community.

Samples

The Mobile Ads DevRel team maintains a GitHub repository of Android samples covering our API, and we've pushed Kotlin versions for each ad format. If you been wondering how Kotlin's Android extensions work with AdMob's banner ad layouts, for example, we've got a new sample app that'll show you. If you're curious how native ads work with all the new nullability stuff, we've got you covered with Kotlin samples for those formats as well.

In addition, we've included a new version of our API Demo app, which features a navigation drawer full of individual API demos for things like banner sizes, category exclusions, and more, all in Kotlin.

Implementation Guides

We've also updated our publisher guides with Kotlin snippets wherever code is shown. Similar to the mobile ads guides for iOS (which show either Swift or Objective-C syntax with a click of a tab), the Android guides now let developers easily switch back and forth between Java and Kotlin implementations.

Questions?

If you take a look at the Kotlin guides and samples and find you've got questions about the best way to implement something in Android's first ever new language, stop by our support forum. Our staff there will be happy to help.

 - Andrew Brogdon, Mobile Ads Developer Relations

The Ad Exchange Seller REST API is being deprecated as of October 26, 2017. No new API clients will be supported after this date. Existing API clients will need to migrate to the DoubleClick for Publishers API before July 26, 2018. After this date, all requests to the Ad Exchange Seller REST API will return errors.

What action is required

Current Ad Exchange Seller REST API users will need to migrate to the DoubleClick for Publishers API before July 26, 2018. This migration guide provides a mapping of each Ad Exchange reporting metric to its equivalent in the DFP API.

For more details about reporting in the DFP API, see the reporting guide.

For general assistance with the DFP API or your migration, reach out on our developer forum.

Why this is happening

As a part of our effort to provide a unified tool to manage your ad business and monetize your inventory, the DoubleClick for Publishers API now supports all of the features of the Ad Exchange Seller REST API. The DFP API is more robust and has more frequent updates.

What isn't changing
Users will not need to create new accounts. All Ad Exchange Seller users already have a DoubleClick for Publishers account.

No data is changing. The only change is how you programmatically access that data.

 - Chris Seeley, DFP API Team

Cross-posted from the AdMob blog.

Every interaction a user has with your app matters. That's why we're constantly evolving our advertising recommendations and policies to ensure that no matter where and on what device users are engaging with your apps, they have good experiences.

Example of ad appearing outside of "safe area" on iPhone X

With the launch of the iPhone X, app developers now need to plan for new design considerations as the rounded corners, notch, and home screen indicator on the extended screen can obscure content and lead to poor ad experiences for users when ads are placed in these areas.

That's why we've put together a guide to help you adapt your ad strategy for iPhone X. This includes guidance for how you can shift placement of banner or native ads to designated "safe areas" for this new device.

We've also updated our policies to indicate that ads must not be placed where objects may interfere with the user's typical interaction with the ad or app, such as under the home screen indicator on the iPhone X.

Please review these policy updates and our suggested implementation guide to ensure you're compliant by November 20th.

If you have any questions, visit the AdMob Help Center or contact your Google account team.

Posted by Pablo Alvarez, Product Manager, AdMob

The KeywordOptimizer open-source app demonstrates the exciting possibilities of using the Targeting Idea Service in the AdWords API to identify new keyword suggestions. The app shows how, in combination with estimated traffic volume, to generate new keyword targeting ideas for AdWords using an evolutionary approach. We think that there is a lot more that the tool could do to demonstrate these and other features so we’re asking for your ideas to help shape the future development of the app.

If you’re interested in using KeywordOptimizer or are already using it, we would like to hear your ideas on how we can improve the app. Please submit your suggestions via the GitHub issues page.
 - Damien Allison, AdWords API Team

Today we’re announcing the release of AdWords API v201710. Here are some of the highlights for key AdWords features:

• Account-level placement exclusions. The new CustomerNegativeCriterionService allows you to exclude specific criteria across all campaigns in an account. The guide contains step-by-step instructions for using this service.
• Promotion extensions. You can now create promotion extensions for different languages. Check out the updated Extension Settings guide for examples and instructions.
• Shared sets for manager accounts. The AdWords API now supports the creation of shared negative keyword sets for manager accounts. Previously, creation of SharedSets via the AdWords API was only supported for client accounts.
• Ad rotation settings. You can now manage the new ad rotation settings announced in August via the AdWords API. The updated code examples for adding AdGroups demonstrate how to set the new rotation options.
• Customer match by phone number. You can now include phone numbers when uploading Members of a CrmBasedUserList. The updated remarketing guide contains requirements and details.
• Batch job support for shared sets. BatchJobService now supports CampaignSharedSetOperations, SharedCriterionOperations, and SharedSetOperations for managing shared sets. Check out the updated Batch Processing guide for details.

If you’re using v201702 of the AdWords API, please note that it will be sunset on February 14, 2018. We encourage you to skip v201705 and v201708 and migrate straight to v201710. Please note that v201705 is deprecated. As mentioned in the recent blog post on the sunset and release schedule, both v201705 and v201708 will be sunset on March 28, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201710 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff on behalf of the AdWords API Team

In 2016 and 2017 we supported at least three versions of the AdWords API at any given time and four versions for a brief period after each new release. This led to older versions of the API supporting outdated functionality and lacking new features.

To improve your AdWords API experience, we will be updating our release schedule. Starting in March 2018 we will only support two releases concurrently at all times, and three releases for a brief period of four weeks, allowing developers to skip a version. To get us back on schedule, we will concurrently sunset v201705 and v201708 in March 2018. This brings the average lifespan of every API version released in 2018 down to nine months.

Additionally, we will be moving back to a schedule that releases three versions per year. The 2018 releases are scheduled for February, June and September.

As usual, make sure to check our deprecation schedule for more details on sunsets. If you have any questions about the new schedule, please reach out to us on the AdWords API forum or the Ads Developers Plus Page.
Herlen Zoljargal, AdWords API Team

On Thursday, November 30th, 2017, in accordance with the deprecation schedule, v201611 of the DFP API will be sunset. At that time, any requests made to this version will return errors.

If you’re still using this version, now’s the time to upgrade to the latest release and take advantage of new features like support for creating ImageOverlayCreatives, new Ad Exchange reporting dimensions and columns, and the change history table. In order to upgrade, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code.

Significant changes include:

• Reporting dimensions and columns are now at parity with Ad Exchange.
• Editing AdUnit assignments to Placements now happens in the Placement service.
• AdUnit.inheritedAdSenseSettings has been replaced with AdUnit.adSenseSettings and AdUnit.adSenseSettingsSource.
• The AdUnit fields mobilePlatform, partnerId, isSharedByDistributor, and crossSellingDistributor have been removed.
• Placement fields adSenseTargetingLocale, isAdsenseTargetingEnabled, targetingDescription, targetingSiteName, and targetingAdLocation have been removed to align with the UI.
• Company.Type enumerations AFFILIATE_DISTRIBUTION_PARTNER and CONTENT_PARTNER have been removed.
• CrossSellingDistributor has been removed.
• Old partner metrics have been replaced by new PARTNER_MANAGEMENT fields.

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.

 - Gabe Rives-Corbett, DFP API Team

We're happy to announce that with this week's release of version 7.24.1, the Google Mobile Ads SDK is officially iOS 11 ready. You can get the latest version via CocoaPods or via manual download.

Check the release notes for a full list of updates. One prominent issue that this SDK release resolves is the banner ad views rendering out of bounds in some situations on iOS 11.

Stay tuned for another SDK update ahead of the iPhone X release. Speaking of which...

iPhone X

At this year's launch event, Apple announced a new iPhone, the iPhone X. With this new device comes a new form factor and some additional design considerations for developers, as the rounded corners, notch, and soft home button on the extended screen can obscure content.

With this in mind, we want to highlight some best practices for Google Mobile Ads publishers to ensure that ad placement conforms to Apple's new design guidelines for the iPhone X and iOS 11.

Banner and native ads should be placed inside the safe area, a concept new to iOS 11. This ensures that ad content is not obscured. Additionally, the safe area respects UI elements such as navigation bars, the status bar, and tab bars on all iOS 11 devices.

When using autolayout, ensure any constraints are relative to safe area layout guides. If you're using manual layout, check that banners and native ads fit within the safeAreaInsets.

For interstitials and rewarded video ads, we're working to ensure all controls and important content are also placed within the safe area. Keep an eye out for another Google Mobile Ads SDK release ahead of the iPhone X release date.

If you have any questions about iOS 11 support in the Google Mobile Ads SDK, please drop us a line at the developer forum.

 - Samuel Stow, Mobile Ads Developer Relations

Users of ExoPlayer, an extensible, open-source media player for Android, can now easily integrate with the IMA SDK using the new ExoPlayer IMA extension. The IMA extension, released alongside ExoPlayer 2.5, wraps the IMA SDK for Android and provides seamless ad playback.

The extension ensures that ads are integrated into ExoPlayer's video timeline, and UI components are ad-aware. It also reduces buffering by eliminating the need to swap out and rebuffer the video player's source when transitioning between ads and content.

You can find more details on the extension in ExoPlayer's blog post on Medium, and find the extension on GitHub. If you have any questions or issues, please file them on ExoPlayer's issue tracker.

 - Yury Pavlotsky, IMA SDK Team

Starting today, the Datafeeds service will allow you to use the Content API for Shopping to set up data feeds that target multiple countries and/or languages, which a recent update added to the Merchant Center. The update to the Datafeeds service will also allow you more control over the destinations for products in data feeds managed via the Content API.

What's changing?
To handle feeds that target multiple countries and/or languages, a new targets field is being added. This field contains a list of targets, and each target contains the following fields:

• country - the target country
• language - the content language for this target
• includedDestinations - a list of destinations to include for this target
• excludedDestinations - a list of destinations to exclude for this target

Note: The above links to the reference documentation for the new fields will go live on the same day that the feature is introduced.

The following now-redundant fields are being deprecated:

• targetCountry
• contentLanguage
• intendedDestinations

Currently, code that uses these deprecated fields will continue to work as before for managing feeds with a single target. Any changes made via these deprecated fields will also appear as a single target in the new targets field, and vice versa if the targets field contains a single target. These deprecated fields will not be returned when retrieving feeds with multiple targets. Since these deprecated fields may be removed in the future, we recommend migrating your code to use the new targets field now.

To support feeds that have multiple targets, the Datafeedstatuses.get method now takes two additional parameters:

• country - the target country
• language - the content language

These new parameters must be supplied for feeds that have multiple targets, since the status of a feed may differ depending on the target. These parameters can be omitted when retrieving the status of a feed with a single target.

Similarly, when retrieving all feed statuses using the Datafeedstatuses.list method, you will receive multiple entries for a feed with multiple targets, where each entry corresponds to a particular target.

What do I need to do?
To manage feeds that use any of the following features, you must update your code to use the new targets field:

• Feeds that target multiple countries and/or languages
• Feeds that exclude destinations that are included by default

In addition, you must supply the new country and language parameters when retrieving the status of a feed that has multiple targets.

Otherwise, your existing code will continue to work as before. However, since we may remove the old fields in the future, we recommend you update your code for managing data feeds to use the new targets field.

Note: To use the new targets field and the new country and language parameters if you are using one of the Content API client libraries, update to a version published on or after Sep 21, 2017.

If you have any questions or feedback about the changes to data feed management or other questions about the Content API for Shopping, please let us know on the forum.
 - Stevie Strickland, Content API for Shopping Team

What’s changing?
On August 14th, we announced that AdWords users should start migrating their mobile app install campaigns to Universal App campaigns (UACs). Starting on October 16, 2017, all requests to create new mobile app install campaigns will fail, and all requests to add ads and ad groups to these existing campaigns will fail with an ADD_OP_NOT_PERMITTED error. Edits to these existing campaigns will still be allowed. Starting on November 14, 2017, these mobile app install campaigns will be deleted and will stop serving. Reporting stats for these campaigns will still be available. Mobile app engagement campaigns will not be affected.

Why is this happening?
If you want to learn more about these changes, check out our Propel your mobile app growth with Universal App campaigns announcement.

What should I do?
To avoid errors when managing your mobile app campaigns, here’s what you need to do by October 16th:

• Modify your code to enable the creation of Universal App campaigns. Check out our guide on creating Universal App campaigns, which includes code samples in all client library languages.
• Disable the creation of mobile app install campaigns and adding ad groups or ads in these campaigns. Edits will still be allowed.

To keep your ads serving beyond November 14th:

• Search for all campaigns in your accounts that have campaign status ENABLED or PAUSED with advertisingChannelSubType DISPLAY_MOBILE_APP or SEARCH_MOBILE_APP. After November 14th, these campaigns will have a status of REMOVED because they will be deleted automatically by the AdWords system.
• Create a new Universal App campaign to replace each campaign you find.
• Once that Universal App campaign is online and serving, remove the mobile app install campaign.

Where can I learn more?
Here are a few resources to get you started:

• Mobile app campaigns guide
• Universal App campaigns
• Client Libraries: Code examples are available in Java, PHP, Python, Ruby, Perl, C#, and VB.NET.

If you have questions while you’re upgrading, please reach out to us on the AdWords API forum.
Nadine Sundquist, AdWords API Team

What's changing?

Currently, the Accounts.delete method deletes sub-accounts whether or not they contain products. On Sep 28, 2017, we will change the default behavior of Accounts.delete to only delete empty sub-accounts. We are introducing this change to help avoid accidental deletion of sub-accounts that are still serving products.

To override this behavior, we have introduced a force parameter, which currently defaults to true. On Sep 28, 2017, the default value will change to false. After this change, you must set this parameter to true to delete non-empty sub-accounts. Attempts to delete non-empty sub-accounts with force = false will result in a 403 Forbidden error. The error will also explain how to delete the non-empty account.

What do I need to do?

Right now, we suggest you familiarize yourself with the new force parameter. If you regularly delete non-empty accounts, you should adjust your code to set force to true to avoid errors when the default behavior changes. If you want to inspect the error that you will receive after the default behavior changes, you can manually set the force parameter to false and attempt to delete a non-empty account. (Of course, we suggest you create a new sub-account and add some products to it to try out this new behavior, instead of calling it on an existing live account.)

Once this change is live on Sep 28, 2017:

• To delete an empty sub-account, you do not need to make any changes.
• To delete a sub-account that contains products, you must set the new force flag to true when calling Accounts.delete.

Note: If you are using one of the Content API client libraries, you will need to update to a version published after Aug 28, 2017 to take advantage of this new parameter.

If you have any questions or feedback about the changes to account deletion or other questions about the Content API for Shopping, please let us know on the forum.

 - Stevie Strickland, Content API for Shopping Team

AdWords API v201609 will be sunset on October 2, 2017. After this date, all v201609 API requests will begin to fail. This AdWords API version was deprecated on May 31st, 2017. If you are still using v201609, we recommend that you skip v201702 and v201705 and migrate directly to v201708. Please migrate prior to October 2, 2017 to ensure your API access is unaffected.

We've prepared various resources to help you with the migration:

• v201708 migration guide
• v201705 migration guide
• v201702 migration guide
• Release notes

As always, if you have any questions about this migration, please contact us via the forum.
- Mike Cloonan, AdWords API Team

Since the early days of the AdWords API, we've continually evolved the platform to help you more efficiently and creatively manage large or complex AdWords accounts and campaigns.

To learn more about what's working well and what could be improved, we're running our first AdWords API feedback survey. Your answers will be completely anonymous, so we hope you'll take the opportunity to let us know about any changes you'd like to see to help make managing campaigns even easier.

SHARE YOUR FEEDBACK
The survey will close on August 30, 2017, and should take about 15 minutes to complete. Thanks in advance for sharing your thoughts to help us improve the AdWords API Developer experience for everyone.
- Anash P. Oommen, AdWords API Team

Today we’re pleased to announce several additions and improvements to the DFP API with the release of v201708.

CreativeService: The API now supports the skippableAdType attribute on VideoCreatives and the mezzanineFile asset on VideoRedirectCreatives.

CreativeWrapperService: The HTML header and footer fields have been renamed to htmlHeader and htmlFooter, and they are now strings instead of CreativeWrapperHtmlSnippets.

ProposalService: Proposals are now automatically synced with marketplace. Therefore, the proposal action SyncProposalsWithMarketplace has been removed (sending this action with performProposalAction is now a no-op in previous API versions).

PublisherQueryLanguageService: In v201702 the Change_History table was introduced. Now, new entities for Sales Management have been added to the EntityType column. The new entities are BASE_RATE, PREMIUM_RATE, PRODUCT, PRODUCT_PACKAGE, PRODUCT_PACKAGE_ITEM, PRODUCT_TEMPLATE, PROPOSAL, PROPOSAL_LINK, PROPOSAL_LINE_ITEM, PACKAGE, RATE_CARD, and WORKFLOW.

ReportService: DateRangeType now supports a new LAST_3_MONTHS option. Also, several deprecated reporting metrics have been removed. They can be replaced with their corresponding partner management metrics, so you will need to update any code using those fields. For more information, check out the support entry for partner management reporting metrics.

For a full list of API changes in v201708, see the release notes.

With each new release comes a new deprecation. If you're using v201611 or earlier, it's time to look into upgrading. Also, remember that v201608 will be sunset at the end of August 2017.

As always, if you have any questions, feel free to reach out to us on the DFP API forums or the Ads Developer Google+ page.
 - Donovan McMurray, DFP API Team

Today we’re announcing the release of AdWords API v201708. Here are some of the highlights for key AdWords features:

• Externally attributed conversion import. Support for importing partial conversion credits has been added to ConversionTrackerService and OfflineConversionFeedService. Our updated conversion tracking guide contains step-by-step instructions to help you get started.
• Maximize conversions bid strategy. The new MAXIMIZE_CONVERSIONS bidding strategy allows you to opt in to and control settings for the Maximize conversions automated bidding strategy. Check out the updated bidding guide for more details.
• Remarketing lists. The new CombinedRuleUserList allows you to create audiences based on users who visited a combination of pages on your site.
• Responsive ads for Display. Additional attributes were added to ResponsiveDisplayAd for call to action text and ad images. Check out the updated guide for details.

If you’re using v201609 of the AdWords API, please note that it will be sunset on October 2, 2017. We encourage you to skip v201702 and v201705 and migrate straight to v201708. Please note that v201702 is deprecated and will be sunset on February 14, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201708 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff on behalf of the AdWords API Team

Starting today, calls to the Accountstatuses service return not only product-level issues, but also account-level issues. This means all account-level issues present in the Diagnostics tab of the Merchant Center can now be retrieved using the Content API. Account-level issues are located in a new accountLevelIssues field, so existing code should be unaffected by this change. For more details, see the accountStatus resource representation in the reference documentation.

Note: Some account-level issues, like unclaimed websites, were already returned as product-level issues. Currently, these issues still show up at the product level as well as at the account level, but this may change in the future.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.
 - Stevie Strickland, Content API for Shopping Team