Posted:
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.

Posted:

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.

Posted:
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.

Posted:

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.

Posted:
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.

Posted:
Today we're releasing v3.0 of the DCM/DFA Reporting and Trafficking API. Highlights of this major version release include: 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!

Posted:

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.