(Translated by https://www.hiragana.jp/)
Google Ads Developer Blog: admob_mediation

Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides.

Open Source Mediation Adapters on GitHub

Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides.

Open Source Mediation Adapters on GitHub

In partnership with some of our mediation partners, we've open-sourced many of the most popular adapters used with DFP and AdMob mediation. You can see for yourself at our GitHub repos for iOS and Android:

In addition to adapter source, there's also a project containing example adapter and custom event implementations, plus a test app.

Import Mediation Adapters with CocoaPods and Gradle

In addition to open-sourcing the adapters, we've also made importing compiled adapters into your projects simpler by uploading them to Bintray and making them available via jCenter and CocoaPods. Rather than downloading and manually including libraries, publishers can get the correct adapter simply by updating their Podfile with a line like this:

    pod 'GoogleMobileAdsMediationMoPub'

...or their build.gradle file with a line like this:

    compile 'com.google.ads.mediation:mopub:11.10.1.0'

With many ad networks choosing to distribute their SDKs in the same manner, it's frequently possible to bring a new mediation network into an app with nothing more that a Podfile or build.gradle tweak. For instructions on which gradle artifacts and CocoaPods to use, check the AdMob Mediation Overview (iOS, Android) and look for networks in the "Open source and versioned" section.

Network-specific guides

Each mediated network is a little bit different. They have their own front-end, their own reporting systems, and their own vocabulary including things like "placement," "location," or "zone." Once you start trying to add a second or third network to your mediation waterfall, things can get confusing in a hurry.

To help publishers navigate through these details, we've created network-specific guides for the mediation partners who have joined our open source repositories. Each one includes step-by-step instructions (with screenshots) that guide a publisher all the way from configuring their account in the mediated network's web site to setting up their mediation stack and importing the right adapter.

For more details, there's no better place to go than the guides themselves. You can find them in the AdMob Mediation Overview (iOS, Android).

Questions?

If you've got questions about our open source adapters or the best ways to get up and running with mediation, stop by our support forum.

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.

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.

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.

The Mobile Ads Garage has returned with its second episode. In this video, you'll see screencasts and detailed breakdowns of how to implement banner ads for both iOS and Android. Plus, you'll get links to guides, samples, and other great resources.

The Mobile Ads Garage has returned with its second episode. In this video, you'll see screencasts and detailed breakdowns of how to implement banner ads for both iOS and Android. Plus, you'll get links to guides, samples, and other great resources.


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.

Today, the first episode of the Mobile Ads Garage hits YouTube! The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down a feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

Today, the first episode of the Mobile Ads Garage hits YouTube! The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down a feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

The series will make its home on YouTube's Google Developer Channel, where you'll find the first episode in the Mobile Ads Garage playlist along with a sneak peek of the next four.


In addition to being a new way that people can find out about the SDK and how to use it, the series is a way for publishers to let us know what features they'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.

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.

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.

For Android developers, Context objects can be tricky. To start with, android.content.Context has a zillion subclasses, some of which are really specific (I’m looking at you, NotificationCompatSideChannelService). On top of that, there are a bunch of available calls to retrieve the current Context, all of which seem slightly different. Once you start talking about passing these objects from one part of an app to another, which happens during AdMob mediation, it can get confusing in a hurry. In order to keep things straight, engineers building Android custom events and mediation adapters need to make sure they’re handling Contexts properly.

For Android developers, Context objects can be tricky. To start with, android.content.Context has a zillion subclasses, some of which are really specific (I’m looking at you, NotificationCompatSideChannelService). On top of that, there are a bunch of available calls to retrieve the current Context, all of which seem slightly different. Once you start talking about passing these objects from one part of an app to another, which happens during AdMob mediation, it can get confusing in a hurry. In order to keep things straight, engineers building Android custom events and mediation adapters need to make sure they’re handling Contexts properly.

If you’ve ever built a custom event or mediation adapter for AdMob, you’re probably familiar with these two methods:

requestInterstitialAd(Context context, 
                      CustomEventInterstitialListener listener,
                      String serverParameter,
                      MediationAdRequest mediationAdRequest,
                      Bundle customEventExtras)

requestInterstitialAd(Context context,
                      MediationInterstitialListener listener,
                      Bundle serverParameters,
                      MediationAdRequest mediationAdRequest,
                      Bundle mediationExtras)

They’re from the CustomEventInterstitial and MediationInterstitialAdapter interfaces, respectively, and are used to request interstitial ads from custom events and adapters. Both include a Context parameter that can be used to retrieve information about the execution environment, query permissions, and access user preferences. In most cases, that object ends up being the Activity an app is displaying when its ad request is made (Activity is a subclass of Context), but that’s not guaranteed.

For example, consider an app that switches quickly from one Activity to another, and occasionally shows an interstitial ad during one of the transitions. Requesting a new ad in each onCreate method will likely waste resources, so offloading that work to a separate class that lives outside the Activity lifecycle is a common solution. Because that class isn’t an Activity, though, it can’t use itself as a Context, and instead must request interstitials using the Application object (another Context subclass). If the app uses custom event and adapter classes that were only tested with Activity objects, they might break!

The best practice here is to make sure to test your custom events and adapters with both Activity and Application objects prior to releasing them. A reliable custom event needs to operate the same no matter which is provided, and the same goes for adapters. If, for some reason, the SDK you’re adapting just can’t work with an Application object as the context parameter, you can always trap this using instanceof and log the error:

    @Override
    Public void requestInterstitialAd(Context context,  
                      CustomEventInterstitialListener listener,
                      String serverParameter, 
                      MediationAdRequest mediationAdRequest,
                      Bundle customEventExtras) {
    if (!(context instanceof Activity)) {
        Log.w(“Example”, “Context not an Activity. Returning error!”);
        listener.onAdFailedToLoad(AdRequest.ERROR_CODE_INVALID_REQUEST);
    }

    // ... code to request an ad using the Activity context ...
}

If you have technical questions about activities, contexts, or anything else relating to the Google Mobile Ads SDK, stop by our forum.

If you’re an Android developer who uses ProGuard to post-process builds, you already know the improvements it can make to APK size and speed. Just as handy, though, is its ability to obfuscate your compiled code by stripping out debug information and renaming classes, methods, and fields to generic identifiers. It’s a great way to discourage reverse-engineering of your application. If you’re an AdMob publisher who uses mediation, however, you need to take special care when configuring ProGuard in order to avoid obfuscating some of the code used in the mediation process.

If you’re an Android developer who uses ProGuard to post-process builds, you already know the improvements it can make to APK size and speed. Just as handy, though, is its ability to obfuscate your compiled code by stripping out debug information and renaming classes, methods, and fields to generic identifiers. It’s a great way to discourage reverse-engineering of your application. If you’re an AdMob publisher who uses mediation, however, you need to take special care when configuring ProGuard in order to avoid obfuscating some of the code used in the mediation process.

AdMob mediation needs two classes to maintain their original names in your final APK: AdUrlAdapter and AdMobAdapter. If either of those has been renamed by ProGuard, it can cause the SDK to incorrectly return “no fill” responses for the AdMob demand in your mediated ad units.

The good news is that it’s easy to avoid this problem. Just add the following two keep options to your ProGuard configuration file:

-keep class com.google.ads.mediation.admob.AdMobAdapter {
    *;
}

-keep class com.google.ads.mediation.AdUrlAdapter {
    *;
}

These options instruct ProGuard to avoid renaming the two classes, and to leave the names of their fields and methods unobfuscated as well. With the original names intact, the mediation system will be able to instantiate them dynamically whenever they’re needed, and your otherwise obfuscated application won’t miss out on any AdMob impressions.

The third-party networks your app mediates may also need certain classes exempted from obfuscation. Be sure to check with those networks to find out if they have recommendations for ProGuard configuration.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

tags: android, admob_mediation, mobile_ads_sdk

Smart banners are a handy thing for publishers. You can drop an AdMob smart banner into a layout or storyboard, and it’ll stretch or squeeze itself at runtime until it’s just the right size for the device, then request an ad to match. They’re a great feature with all the extra work hidden under the hood.

Smart banners are a handy thing for publishers. You can drop an AdMob smart banner into a layout or storyboard, and it’ll stretch or squeeze itself at runtime until it’s just the right size for the device, then request an ad to match. They’re a great feature with all the extra work hidden under the hood.

If you’re building an Android mediation adapter or custom event, though, things aren’t quite as simple -- after all, you’re under that hood, too! A common rough spot for developers is retrieving a smart banner’s size. Because the Google Mobile Ads SDK uses constants to internally represent a smart banner’s height and width, the getHeight and getWidth methods of a smart banner’s AdSize will return those constants (they’re negative numbers, so they’re quite hard to miss). That means relying on calls to getHeight and getWidth to determine a smart banner’s true size isn’t a workable strategy.

So how should adapter and custom event developers calculate sizes correctly? By avoiding getHeight and getWidth, and instead asking for pixel counts using getHeightInPixels and getWidthInPixels, two other methods offered by AdSize. You can scale their return values according to the device’s metrics and end up with the same kind of DPI values returned by getWidth and getHeight for other ad sizes. Here’s a code snippet that shows how it’s done:

// Get the raw pixel counts.
int widthInPixels = size.getWidthInPixels(context);
int heightInPixels = size.getHeightInPixels(context);

// These metrics include screen density, which is what we’re after.
DisplayMetrics displayMetrics = Resources.getSystem().getDisplayMetrics();

// These are values you can send to your mediated network’s SDK.
int widthInDpi = Math.round(widthInPixels / displayMetrics.density);
int heightInDpi = Math.round(heightInPixels / displayMetrics.density);

Once you finish the math, you’ll have proper DPI values that can be sent to whichever network you’re mediating. The calls to getHeightInPixels and getWidthInPixels require a valid Context, but you can use the one provided as a parameter to the requestBannerAd methods in MediationBannerAdapter and CustomEventBanner.

Now you know the best way to gauge the size of a smart banner! Use this approach and it’ll help keep your mediation running smoothly.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

Today, we’re excited to announce a new release to both our Android and iOS Google Mobile Ads SDKs. The key new features added in these releases are in-app purchase ads for both platforms and new mediation APIs for Android.

Today, we’re excited to announce a new release to both our Android and iOS Google Mobile Ads SDKs. The key new features added in these releases are in-app purchase ads for both platforms and new mediation APIs for Android.

In-App Purchase Ads

In this release we’ve added SDK-level support (front-end support coming soon!) for running house ads that can initiate an in-app purchase. In-app purchase ads require that you set an in-app purchase listener on your interstitial ad. If an in-app purchase ad is shown, it will present the user with an option to buy one or more items that you have configured:

When the user clicks Buy now, the SDK will invoke your in-app purchase listener with the purchase information necessary to start a transaction for that product. You are responsible for implementing the in-app purchase flow from this point. Full implementation details can be found in our Android and iOS documentation.

Note: Front-end support for this feature is not available yet, but is coming soon.

New Mediation APIs

As part of our Google Play services API revamp, we’ve added new mediation APIs (which we’re calling mediation v2) to make it easier for ad networks to create mediation adapters.

Don’t worry! We’re still supporting mediation adapters written against mediation v1 APIs. This change won’t require any immediate updates to your apps.

If you previously passed extra parameters to third party networks, note that this process has changed for mediation v2. You’ll now pass a bundle to the ad network, keyed by its mediation v2 adapter class. Here is an example of passing extra parameters to AdMob:

Bundle adMobBundle = new Bundle();
adMobBundle.putString("color_bg", "AAAAFF");
AdRequest request = new AdRequest.Builder()
    .addNetworkExtrasBundle(AdMobAdapter.class, adMobBundle)
    .build();

You can also use this snippet to check for the existence of mediation v2 support. If this snippet compiles, then the adapter supports mediation v2. If there is a compilation error saying that the arguments don’t match the arguments for addNetworkExtrasBundle(Class, Bundle), then that adapter class does not support mediation v2.

See the documentation for more information on passing parameters to mediation v2.

Dropped Support for iOS 4.3

The 6.9.2 iOS SDK release has dropped support for iOS 4.3. By dropping iOS 4.3, the SDK can take advantage of automatic reference counting (ARC) weak references to provide a more stable release. The SDK still supports iOS 5.0 and above.

Check out the downloads page to grab the latest iOS release. A new Google Play services revision will soon be available in Android’s SDK Manager.

For a full list of SDK changes, see the release notes. If you have any technical questions about these changes, we’re available on the forum. Finally, stay tuned for an update on front-end support for in-app purchase ads on our Google+ page.

We recently announced the ability to set an eCPM floor when making requests to the AdMob network. This post will show you how to set up this new feature to get the maximum benefit from the AdMob network.

We recently announced the ability to set an eCPM floor when making requests to the AdMob network. This post will show you how to set up this new feature to get the maximum benefit from the AdMob network.

First of all, we highly recommend that you create a new AdMob publisher ID on admob.com for each Mediation Placement you want to configure with AdMob eCPM floor. By creating a unique publisher ID, you’ll get fine grained reporting on how eCPM floor is performing on each of your placements.

Next, select Add Ad Network on your mediation placement, and add the AdMob eCPM Floor Beta network. In the Ad Network Configuration Settings, point this network to your newly created eCPM floor publisher ID.


Note: If you didn’t previously have a mediation placement, you’ll need to create a mediation placement on mediation.admob.com, and use the mediation placement ID in your application in place of your AdMob publisher ID.

Finally, you need to update your allocation to give the AdMob eCPM Floor Beta network an eCPM value. A suitable value for the eCPM floor is a value higher than the highest eCPM you’re getting from other networks.

In the sample below, Ad Network A is getting $0.37 eCPM. By setting AdMob eCPM Floor Beta slightly higher at $0.40, AdMob Mediation will first try to fetch an ad worth $0.40 eCPM from the AdMob Network. If it can’t fill that request, Mediation will try Ad network A, followed by Ad network B. If neither of those networks can fill the request, Mediation will come back to the AdMob network to fetch an ad without the eCPM floor restriction.


This new configuration will increase your ad revenue for requests fulfilled by AdMob eCPM Floor Beta, while still maintaining the same revenue from the rest of your requests where AdMob cannot fill the eCPM Floor request. You can also track your eCPM Floor performance by viewing sites and apps reporting for your newly created eCPM floor publisher ID.

If you have any questions about eCPM Floor or AdMob in general, please direct them to our forum. You can also follow us on our Google+ page to get updates on all Google ads developer products.

Today, we’re giving AdMob developers more control over the value of ad impressions served to their apps. The AdMob eCPM Floor beta allows developers to set a minimum CPM they’d like to receive for each ad. The beta is available to AdMob developers who are using AdMob Mediation.

How does this work? Advertisers bid to show their ads on apps in the AdMob network, and an auction is run for every impression to determine the winner. We predict what the ‘expected CPM’ (eCPM) of that ad impression will be. The developer sets a minimum eCPM and we will only serve ads to their app that meet or exceed that level. For example, if a floor of $1.25 is set, we’ll only show ads with an eCPM of $1.25 or more. When choosing a floor value it’s important for developers to look at their own reporting and determine a value that’s relevant to them.

Here are a few details to know when taking part in the beta:
  • Make sure the eCPMs that are set for other ad networks are accurate.
  • We don’t guarantee the final value of the eCPM, since we don’t know if a user will click on the ad.
Developers who use the beta have the option of setting just one network line item in their mediation stack which uses the eCPM floor. Or, they can have two network line items, one that uses the eCPM floor and one without, so they can continue to fill impressions at their current fill rate. Setting the eCPM floor at a very high value will likely lead to a decrease in the fill rate.


Find setup instructions in the AdMob Help Center here under the article titled ‘Allocate traffic by eCPM’.

Posted by: Vishay Nihalani, Product Manager, Google

Ad networks take into account a variety of signals when targeting ads to your users. Generally speaking, the more information you provide to an ad network, the more accurately that network can target its ads, and the better those ads perform.

Ad networks take into account a variety of signals when targeting ads to your users. Generally speaking, the more information you provide to an ad network, the more accurately that network can target its ads, and the better those ads perform.

Many parameters, such as age, gender, and location, are commonly used by most ad networks. AdMob Mediation supports passing those parameters directly in the AdRequest; these parameters will be passed to the networks you’re mediating:

AdRequest adRequest = new AdRequest();
adRequest.addTestDevice(AdRequest.TEST_EMULATOR);
adRequest.setBirthday(new Date(2000, 1, 1));
adRequest.setGender(AdRequest.Gender.MALE);
adRequest.setLocation(location);

AdMob Mediation also supports passing specialized parameters to specific networks. Any custom parameters used by a specific ad network can be passed to an instance of that network adapter’s NetworkExtras object, which is then set on the AdRequest. Here is how you can customize the background and text colors for AdMob text ads, and set education level and number of children for a hypothetical Example ad network:

AdMobAdapterExtras adMobExtras = new AdMobAdapterExtras();
adMobExtras.addExtra("color_bg", "00FFFF");
adMobExtras.addExtra("color_text", "FF0000");
adRequest.setNetworkExtras(adMobExtras);

ExampleAdapterExtras exampleExtras = new ExampleAdapterExtras();
exampleExtras.setEducation(Education.BACHELORS);
exampleExtras.setNumberOfChildren(2);
adRequest.setNetworkExtras(exampleExtras);

AdMob Mediation will pass an adapter only the NetworkExtras object specific to that network. So in this case, the AdMob adapter will be provided with the AdMobAdapterExtras object, and the Example adapter will be provided with the ExampleAdapterExtras object. You can find the class name for each ad network’s NetworkExtras object in their respective adapter jar file.

Custom Events

You can also use CustomEventExtras to pass special parameters to any custom events that your app implements. Keep in mind that you can call AdRequest.setNetworkExtras() with only one instance of CustomEventExtras for all custom events that you implement. To make sure your custom event doesn’t access parameters meant for other custom events, we recommend you create a HashMap for each custom event, and pass in any necessary key-value pairs related to that custom event in that map.

CustomEventExtras customEventExtras = new CustomEventExtras();
HashMap customExtras1 = new HashMap();
customExtras1.put("key1", "value1");
customExtras1.put("key2", "value2");
customEventExtras.addExtra("customEvent1", customExtras1);
HashMap customExtras2 = new HashMap();
customExtras1.put("key1", "othervalue1");
customExtras1.put("key2", "othervalue2");
customEventExtras.addExtra("customEvent2", customExtras2);

Your custom event implementation just needs to check CustomEventExtras for the HashMap at whatever key that was designated for it - in this case customEvent1. You’ll use these parameters to construct your custom event.

HashMap extras =
    (HashMap) customEventExtras.getExtra("customEvent1");

Load the Ad

Once you’re done setting all targeting options, make sure to call loadAd with that request.

// This snippet assumes you have an AdView object named "adView".
adView.loadAd(adRequest);

If you have any questions or comments about AdMob, mediation, custom events, or targeting, we can field them in the forum. Also follow us on our Google+ page for ads-related updates.