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