At the 2016 Games Developer’s Conference, we announced a new addition to the AdMob mediation platform: rewarded video ads. This new avenue for monetization offers users the option to engage with ads in exchange for in-app rewards. Our growing list of mediation partners includes:

  • Unity Ads
  • Chartboost
  • Vungle
  • AdColony
  • AppLovin
  • Fyber
  • Upsight

Choosing AdMob for your rewarded video mediation platform gives you access to ad content from all of these networks, and allows you to develop against a single API from AdMob.

Rewarded video ads are requested and displayed using the the new RewardedVideoAd and GADRewardBasedVideoAd classes. Here’s an example showing how to request a rewarded video ad on Android:

RewardedVideoAd mRewardedVideoAd = MobileAds.getRewardedVideoAdInstance(this);
mRewardedVideoAd.loadAd(AD_UNIT_ID, new AdRequest.Builder().build());

And here’s the iOS equivalent:

GADURewardBasedVideoAd *rewardedVideo = [GADRewardBasedVideoAd sharedInstance];
rewardedVideo.delegate = self;
[rewardedVideo loadRequest:request withAdUnitID:adUnitID];

You can find additional documentation on rewarded video ads in our publishers get started guides (Android | iOS). Mediation documentation not specific to rewarded video ads can be found in the mediation get started guides (Android | iOS).

If you have any questions about rewarded video mediation, you can reach us on our forum. You can also find us on Google+, where we have updates on all of our Google Ads developer products.


There are only a few things I care about more than the DFP API. One is ice cream. The other is the DFP Sales Manager API (yes I'm cheating, but they're both unique enough that I consider them separately). The DFP Sales Manager API is incredibly powerful in terms of flexibility and functionality, but as a great man once said:

"With great power comes great responsibility"
        - Ben Parker

To properly use the Sales Manager API, you have to fully understand its services & objects and how they all fit together.

I'm extremely pleased to announce that we now have a full set of Sales Manager-specific guides that walk you through each component of the sales flow, from generating the inventory / products you wish to sell, creating proposals and proposal line items, approving these items through a workflow, and reconciling that data to amend any data discrepancies.

So grab a plate of cookies, pour yourself a glass of milk, and lose yourself in the riveting seven-part series we've put together:

As usual, feel free to reach out to us with any questions, concerns, or if you're dying to see what happens in the next chapter of sales manager.

Today we’re announcing the release of AdWords API v201603. This is the second release that follows the new release schedule announced in January 2016. Here are the highlights: If you’re using v201509 of the AdWords API, please note that it’s now deprecated and will be sunset on June 21st, 2016. We encourage you to skip v201601 and migrate straight to v201603.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201603 migration guide. The updated client libraries and code examples will be published shortly. With this release, we’ve also updated the Required Minimum Functionality document to include some of the newly added features.

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

AdSense Management API v1.2 and v1.3 have been marked as deprecated and will be sunset on August 17th 2016, after which all requests will begin to fail. Please migrate to v1.4 as soon as possible to ensure your API access is unaffected; be sure to check the release notes and migration guide for help while changing versions.

If you have any questions about this migration, please contact us via the forum.

AdWords API v201506 will be sunset on April 11, 2016, after which all v201506 API requests will begin to fail. This version was deprecated on October 5, 2015. If you are still on v201506, we recommend that you migrate directly to v201601 and skip v201509. Please be sure to migrate prior to 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 or the Ads Developers Plus Page.


We recently announced SDK-less mediation - a new way for DFP and AdMob publishers to use mediation to access additional ad networks without having to integrate and maintain multiple third-party SDKs and adapters. Today, we would like to go into more detail on how you can integrate SDK-less in your project.

With SDK-less mediation, everything is done through a single SDK, the Google Mobile Ads SDK. It is now possible to add additional ad networks server-side without having to update your apps. Also, SDK-less supports all existing mediation features including ad network optimization, live eCPM, and country-specific CPM values, so you won’t lose any of the features that you get with standard mediation.

An SDK-less network looks and feels like any other third-party mediation network in AdMob. It includes an ‘SDK-less’ suffix (see screenshot below) and has its own settings.

Supporting SDK-less Mediation

To support SDK-less ad networks, Android apps require v7.8 or higher of the Google Mobile Ads SDK for both AdMob and DFP. However, devices that have an up-to-date Google Play services already support SDK-less.

For iOS apps, v7.2.1 or higher of the Google Mobile Ads SDK is required for AdMob and v7.6.0 or higher is required for DFP. If a publisher’s app is not updated to the minimum SDK version required to support SDK-less networks, then the mediated request excludes all SDK-less networks.

In many cases, even after you migrate to the latest version of the Google Mobile Ads SDK, there may be apps that still reference older SDKs. To accommodate this, AdMob allows publishers to place both SDK adapters and SDK-less sources in a single mediation chain. Apps that don’t meet the minimum SDK requirements will ignore the SDK-less mediation sources automatically.

Ad Networks Supporting SDK-less Mediation

There are currently four ad networks that support SDK-less mediation for both banner ads and interstitial ads. The AdMob developer site for Android and iOS provides a table that lists all the AdMob mediation networks including the type of mediation and ad formats that they support. Please keep an eye on this table as there will be more ad networks supporting SDK-less in the near future.

If you have any questions regarding SDK-less mediation, feel free to contact us through our forum.

We’ve just released v2beta1 of the DoubleClick Ad Exchange Buyer REST API. Unlike previous releases, this is an early access open beta that only allows three new resources—Clients, Invitations, and Users. In order to access this version, new users will need to go to the API Manager in the Google Developers Console and enable “Ad Exchange Buyer API II”; current users will have this enabled automatically. For access to existing resources such as Accounts or Creatives, you should continue using v1.4.

The new resources available in this release allow you to add and manage clients programmatically rather than through the Ad Exchange UI. A Client represents an advertiser, agency, or brand that can view, negotiate, and/or approve deals in areas of the Ad Exchange UI related to the Marketplace. You can send Invitations on behalf of a Client to add Users—the individuals accessing the UI as the Client.

To get even more familiar with these new resources, check out the Client Access Overview. There are some subtle differences when using the client libraries with this version, so we recommend that you look at our samples for guidance on initializing clients and making API calls. At this time, the Java, PHP, and Python samples have been updated for compatibility with this version and the others are planned for the near future. If you have any questions or feedback related to these changes, feel free to reach out to us at the DoubleClick Ad Exchange Buyer API forums or the Ad Developers Google+ Page.


We are pleased to announce that the IMA SDK for HTML5 now supports VPAID Flash creatives. When Flash is available on the running platform, the SDK is able to play these creatives in addition to existing formats. This feature allows video publishers added flexibility in their adoption of the SDK as they can continue to accept advertiser VPAID Flash creatives using the HTML5 SDK.

As an example, take a look at a sample ad running in our Video Suite Inspector tool.

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

In AdWords, finding the right keywords to trigger your ads is one of the main drivers of success — yet a major challenge at the same time. You can use our Keyword Planner to browse for new keyword ideas, or utilize the AdWords API services for keyword suggestion and traffic estimation to find and evaluate keywords at scale.

But wait, now there’s more! We’ve just released KeywordOptimizer, a sample app showcasing how to combine these services to find the perfect set of keywords. Starting from an initial set of seed keywords (obtained using a sample URL, business category etc.), the iterative process repeatedly discards low-quality keywords and “reproduces” high-quality ones. With each step, the average quality across all keywords increases, just like evolution!

KeywordOptimizer is designed to provide guidance on how to use the TargetingIdeaService and TrafficEstimatorService. Simply run it from the command-line to get a CSV file with keywords and estimation with minimal effort. Advanced users can easily extend the tool with custom implementations. For example, you can change the calculation for the keyword quality score to combine clicks with impressions, or your own metrics in a way that works best for you.

Get started with Keyword Optimizer’s GitHub repository. Feel free to ask questions or give feedback via the project’s issue tracker, the AdWords API Forum, or our Google+ page.