Tag Archives: AdMob

We know app developers of all sizes need valuable and easy-to-use solutions to earn more from their apps. That’s why we’ve invested in providing tools that not only empower you to build sustainable revenue streams, but also make your job easier.

Here are a few vital ways we help developers grow their businesses, along with a look at what’s new.

Google’s advanced monetization technology

Earlier this year we introduced Open Bidding in beta, a new monetization model where all participating ad buyers compete simultaneously in one unified auction. Developers using Open Bidding are already seeing more ad revenue and less latency for their users.

Today, we are excited to announce that the Open Bidding program now features eight advertising partners for mobile ad buying. In addition to OpenX, Index Exchange, Smaato, Tapjoy and AdColony, now Facebook Audience Network, AppLovin, and Rubicon Project are joining the ongoing beta. With these new partners, we're offering diverse sources of app advertising to compete for ad inventory in real time, driving even more revenue for app developers.

"AdColony is excited to join forces with Google to move the app monetization ecosystem forward with Open Bidding. AdMob’s scale of advertiser demand and ease of integration provides a tremendous opportunity for app developers to drive more revenue and operational efficiency.”

- David Pokress, EVP Publishing & Account Management at AdColony

We’re continuing to add new features to Open Bidding based on feedback from our beta participants, including support for all ad formats like interstitial, rewarded, banner, which are all available today, and native, which will be added soon.

In addition to asking for more formats and advertising demand, developers participating in our beta have also asked us for transparency into who is bidding on and buying their ad inventory. We’re pleased to announce that we'll be adding a new auction report that allows developers to understand how their different advertising partners are performing. Open Bidding Auction Reports will be available to beta participants early next year.

While we’re paving the way for the next era of monetization technology, we also know that waterfall mediation* isn’t going away anytime soon. That’s why we’ve built Open Bidding to work seamlessly with waterfall mediation to maximize the value of every impression and simplify operations. Beta participants have noted the compatibility as a meaningful value-add.

Get set up quickly with developer-first tools

Regardless of whether developers use waterfall mediation, Open Bidding, or both, we’re committed to delivering the best experience on our platform. We know onboarding processes can be painful and create extra work—but we’ve got a few new tools to help with that.

AdMob’s new Mediation Test Suite beta makes it easier to test if your app is set up correctly to display ads, so you don’t miss out on revenue. Now, if you hit a snag with the SDK integration, you can test each individual network and instantly identify the source of the issue (e.g. SDK, adapter, credentials, etc.)—no more blindly troubleshooting issues and searching for the source. Once everything checks out, you’ll see an ad in the testing environment to confirm that the pipes are ready.

Another new beta feature is the ability to “warm up” your SDK adapters to reduce timeouts on the first ad request. Soon, you'll be able to initialize all SDK adapters in a single call to AdMob, ensuring all adapters are ready to go when the first ad is requested.

Our goal is to make setup easier. And if you do get stuck, we have the resources and global support to help you move fast.

In addition to building better tools, we’re partnering with players across the ecosystem and moving to a more efficient model that enables developers to earn more from their apps. Stay tuned for more exciting announcements over the next few months.

*Waterfall mediation uses historical revenue data to prioritize networks and call them one at a time.

Required AndroidManifest.xml changes

Starting in version 17.0.0, if you are an AdMob publisher you are now required to add your AdMob app ID in your AndroidManifest.xml file. Once you find your AdMob app ID in the AdMob UI, add it to your manifest adding the following tag:

See the getting started guide (AdMob | Ad Manager) for additional details on how to make this change.

NativeAppInstallAd and NativeContentAd APIs are deprecated

This release also officially deprecates the NativeAppInstallAd and NativeContentAd APIs in favor of the previously released UnifiedNativeAd API. The UnifiedNativeAd APIs offer a consolidated way to render any type of native ad, reducing the number of lines of code needed to integrate native ads by up to 50%.

The following example shows how to load both app install and content ads using the new unified API:

Today we're announcing the release of Mediation Test Suite Beta. Mediation Test Suite is a lightweight SDK that enables Google AdMob publishers to easily test mediation ad network integrations without having to make changes in the AdMob UI, saving you and your developers time. It is available on Android, iOS, and Unity.

You are not required to keep the Mediation Test Suite library in the production release of your app; however, you may choose to leave it in and hide it behind a debug gesture. Doing so enables you to launch Mediation Test Suite within your production build.

You can find more information about how to use Mediation Test Suite in the developer guide (Android | iOS | Unity). Remember that Mediation Test Suite is a beta product, so if you have any questions or feedback, please contact us on the developer forum.

To support publishers in meeting their duties under the Google EU User Consent Policy, Google offers a Consent SDK. The Consent SDK is an open-source library that provides utility functions for collecting consent from your users. The full source code is available on GitHub.

With the latest release of the Consent SDK (v1.0.5 for Android or v1.0.2 for iOS), the Google-rendered consent form is now compatible with any number of ad technology partners, including the full list of commonly used partners. Apps that update to the latest version of the Consent SDK can start taking advantage of this additional flexibility immediately.

You can find additional documentation for the Consent SDK on the Google Mobile Ads Android and iOS developer docs. If you have any questions about implementing the Consent SDKs, you can reach us on our forum.

Today we're pleased to announce the release of the Unified Native Ads API, an easier way to implement AdMob Native Ads Advanced. This feature is now available in Google Mobile Ads for iOS, as of version 7.28.0. The Android version will be made available in an upcoming release.

Using the Unified Native Ads API, you no longer need to create UIs for ad content and app install ad formats separately. Instead you will create one UI for unified native ads, saving you time from developing and maintaining two separate UIs and associated code for the two previous ad formats, while still getting the same ad demand.

Here's a short code example showing how your implementation might change when migrating from the separate formats to the new unified format:

Optimizing the ad experience on your app for a varied audience can be difficult. Showing users ads that are a better fit can improve their overall ad experience and help maximize your app’s revenue.

AdMob has launched a new feature that allows you to specify the content rating for Google ads served in your app. With the new max_ad_content_rating signal, you can now choose the content rating of Google demand that you want to deliver on a per-request basis.

Four content rating choices offer you the granularity you need to provide users at each level with a better user experience. The four new content rating choices are:

G: Content suitable for general audiences

PG: Content suitable for most audiences with parental guidance

T: Content suitable for teen and older audiences

MA: Content suitable only for mature audiences

You can start sending the new max_ad_content_rating signal in the Google Mobile Ads SDK by following these Android and iOS guides. To learn more about the new signal and the content rating choices, visit the AdMob help center or contact your Google account team.

Optimizing the ad experience on your app for a varied audience can be difficult. Showing users ads that are a better fit can improve their overall ad experience and help maximize your app’s revenue.

AdMob has launched a new feature that allows you to specify the content rating for Google ads served in your app. With the new max_ad_content_rating signal, you can now choose the content rating of Google demand that you want to deliver on a per-request basis.

Four content rating choices offer you the granularity you need to provide users at each level with a better user experience.

The four new content rating choices are:

G: Content suitable for general audiences

PG: Content suitable for most audiences with parental guidance

T: Content suitable for teen and older audiences

MA: Content suitable only for mature audiences

You can start sending the new max_ad_content_rating signal in the AdMob SDK by following these Android and iOS guides.

To learn more about the new signal and the content rating choices, visit the AdMob help center or contact your Google account team.

Today we're announcing a behavior change when requesting test ads using the Google Mobile Ads SDK. It enables you to test your own ad units while also ensuring that you are in test mode.

When using the Google Mobile Ads SDK during development, we recommend that you configure your device to request test ads. Always testing with test ads is important so you avoid having your account flagged for invalid activity.

Previously, enabling test ads resulted in the same sample ad like this one being shown in your app:

While this worked well as a basic check, it didn't allow for testing what real ads would look like in a production environment. For example, you couldn't test your mediation configurations or the different types of banner and interstitial formats that AdMob offers. The update we're rolling out addresses these problems.

New Test Ad Behavior

Starting today, apps built against Google Mobile Ads SDK 11.6.0 or higher on Android or 7.26.0 or higher on iOS can take advantage of the new behavior of test ads, which serves production-looking ads without charging advertisers. With this change, you can safely test the clickthrough behavior of your ads without your account getting flagged for invalid activity.

Banner, interstitial, and rewarded test ads now show a "Test Ad" label in the top-middle of the ad to give you a visual indicator that the ad returned is actually a test ad.

Test ads with Mediation

When using mediation, ads shown from third-party ad networks won't display the test ad label. Only Google ads show the test ad label. You are responsible for ensuring that your testing of third-party ad networks is compliant with their stated policies. See each mediation network's respective mediation guidefor more information on how to enable test ads on those networks.

See the testing guide (Android | iOS) for more information on how to enable test ads in the Google Mobile Ads SDK. If you have any questions, contact us on the developer forum.

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 GADMultipleAdsAdLoaderOptionsand set the numberOfAdsproperty. Then include this object in the array of options when calling GADAdLoader's initializer:

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

On the GADAdLoaderobject, 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.

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.

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.