Google Ads Developer Blog

Introducing Ad Placements for the Google Mobile Ads Unity plugin

2020-10-06T11:18:00.000-07:00

We’re excited to announce a new feature for app developers who use Unity: Ad Placements. It is now available in Open Beta.

What are Ad Placements?

Ad Placements provide a cleaner and more intuitive way to place ad units from Google AdMob in your games. Ad Placements allow developers to add ad units with a Unity Editor interface, making the specification of ad units for your game centralized, re-usable, and decoupled from your scripts.

You can then create Ad GameObjects that reference these Ad Placements entirely from the Unity Editor, which means no need for additional scripts!

Developers don’t need to write code to manage the ad unit. Callback functions and ad unit creation are all managed directly in the Unity UI.

Why use Ad Placements?

We’ve developed Ad Placements to help address the feedback that many of you have shared, which is integrating the Google Mobile Ads Unity plugin APIs requires too much scripting. Now with Ad Placements and their associated Ad GameObjects, implementing Google Mobile Ads into your Unity games should be a lot easier and more intuitive. You can add placements, load ads and show them all from easy-to-use Unity Editor integrations. With this new UI-driven approach, we can help you insert ad placements into your game with almost no additional code.

How do I get started?

See the Ad Placement documentation for a download link to the early access build and instructions to help you get started.

As always, please reach out on our developer forum if you have any questions.

- Samuel Stow, Mobile Ads Developer Relations

Reviewing ad issues in mobile apps with the Google Mobile Ads SDK

2020-05-19T16:25:00.000-07:00

In order to help mobile app publishers review ad issues (e.g., out-of-memory caused by graphic intense creatives, violations of Ad Manager policies, or AdMob policies and restrictions) in production apps, we have recently added an ad response ID to the ResponseInfo and GADResponseInfo objects in the Google Mobile Ads Android SDK (v. 19.0.0) and iOS SDK (v. 7.49.0). An ad response ID is a unique string for each ad response from the AdMob or Ad Manager server, regardless of ad formats. If the same ad is returned more than once, the ad response ID will differ each time.

You can look up an ad response ID in the Ad Review Center (AdMob, Ad Manager) to find and block the offending ad. You can also report problematic ads to Google using the ad response ID, especially when it is difficult to capture a mobile ad's click string.

The screenshot above shows an ad response ID in Android Studio logcat.

If you use Firebase, you can refer to the Firebase Crashlytics Android (AdMob, Ad Manager) or iOS (AdMob, Ad Manager) guide for logging the ad response ID. This technique can be useful for debugging production app crashes as you would have both the SDK symbols and the ad response ID data in the same log.

We hope this new feature makes it easier to troubleshoot ad issues.

If you would like to give us feedback on this feature, please post your comments and questions on our Google Mobile Ads SDK Technical Forum.

- Thang Duong, Mobile Ads Developer Relation

Introducing adaptive anchor banners

2019-11-13T16:36:00.000-08:00

In today’s mobile-first world, app publishers who use banner ads must serve them across a greater variety of screen sizes and layouts than ever before. Existing responsive banner ad formats often produce ads that are too small and not optimally tailored to the specifications of each device.

To address this, we’ve created a new banner type called adaptive anchor banners. These banners dynamically adjust creative size to deliver an ad that is ideally sized across all of your user’s devices, without the need to write any custom code.

These banners are designed to replace standard 320x50 and leaderboard banner sizes, as well as smart banners. Here is a comparison of the 3 formats on a standard mobile device:

Standard banner vs. smart banner vs. AdMob’s adaptive anchor banner

Migrating your banner implementation to adaptive

Here are a few simple steps to update your banner implementation to use adaptive banners:

Ensure your UI supports a variable height banner. Depending on what constraints or layout mechanism you are using to position your banner, you may need to remove height constraints such that the layout accepts variable content size.
- For Android this can be done using WRAP_CONTENT.
- For iOS constrain your banner in terms of X and Y positions, you may also give it a width constraint, but ensure any height constraint or content size is placeholder only.
Note that the max height is 15% of the device height or 90px, whichever is smaller.
Use the adaptive banner ad size APIs to get an adaptive ad size. The adaptive ad size APIs are available for different orientations.
Android:
AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(context, width)
AdSize.getPortraitAnchoredAdaptiveBannerAdSize(context, width)
AdSize.getLandscapeAnchoredAdaptiveBannerAdSize(context, width)
iOS:
GADCurrentOrientationAnchoredAdaptiveBannerAdSizeWithWidth(width)
GADPortraitAnchoredAdaptiveBannerAdSizeWithWidth(width)
GADLandscapeAnchoredAdaptiveBannerAdSizeWithWidth(width)
Unity:
AdSize.GetCurrentOrientationAnchoredAdaptiveBannerAdSizeWithWidth(width)
AdSize.GetPortraitAnchoredAdaptiveBannerAdSizeWithWidth(width)
AdSize.GetLandscapeAnchoredAdaptiveBannerAdSizeWithWidth(width)

Which one you use depends on your use case. If you want to preload ads for a given orientation, use the API for that orientation. If you only need a banner for the current orientation of the device, use the current orientation API.
Once you have an ad size, set that on your banner view as usual before loading an ad. The banner will resize to the adaptive ad size as long as you have laid it out without any conflicting constraints.
Update your mediation adapters. If you use mediation, update your mediation adapters to the latest version. All open source mediation adapters that support banners have been updated to support the adaptive banner ad size requests. Note that adapters will still only return ad sizes supported by their corresponding ad network SDK, and those ads will be centered in your adaptive banner view.

Review our developer resources

For further information including detailed implementation guidance, review our developer resources:

Adaptive banner guide (AdMob iOS | AdMob Android | AdMob Unity | Ad Manager iOS | Ad Manager Android)
Adaptive banner sample app (AdMob iOS | AdMob Android | Ad Manager iOS | Ad Manager Android)

As always, please reach out on our developer forum if you have any questions.

- Samuel Stow, Mobile Ads Developer Relations

Share your feedback about AdMob and Ad Manager mobile app integration

2019-09-04T10:48:00.000-07:00

We’re continuously improving our guides, code samples, and other developer resources for the Google Mobile Ads SDK to help you integrate AdMob and Ad Manager into your mobile apps.

To learn more about what's working well and what could be improved, we're announcing our second annual developer feedback survey for the Google Mobile Ads SDK. We'd like to hear from you about where we should focus our efforts.

SHARE YOUR FEEDBACK

Your answers will be completely anonymous. The survey should take about 15 minutes to complete and will close on September 30, 2019.

Your feedback is truly important to us. Here are a few highlights of the changes we made based on feedback from last year’s survey:

Continuous translations of the developer docs in several languages
Continuous build integration of sample applications via Travis CI
Launched a Developer tutorials playlist on the Google AdMob YouTube channel
Launched the App Policy Center to help publishers handle policy violations

Please let us know what you’d like us to focus on next. Thank you in advance for helping us continue to improve the developer experience for everyone.

Eric Leichtenschlag, Mobile Ads Developer Relations

Google Mobile Ads SDK for Android: How to migrate to v18.0.0

2019-06-21T17:28:00.000-07:00

Earlier this week, Google Play services released a major update to many of its libraries to migrate all Android support library dependencies to Jetpack (using androidx.* packages). This includes the play-services-ads library from the Google Mobile Ads SDK, which has been updated to 18.0.0.

While the Google Mobile Ads SDK itself hasn’t changed between version 17.2.1 and 18.0.0, you’ll need to migrate your own app and all of your dependencies to AndroidX in order to pick up play-services-ads 18.0.0 or any future versions. This is particularly important if you use AdMob mediation, as several mediation partners have dependencies on Android support libraries that aren’t compatible with AndroidX.

To make the migration process as smooth as possible for you, Android Studio offers an easy way to convert your project and its dependencies to AndroidX using the Migrate to AndroidX option.

Migrate to AndroidX

Android Studio 3.2 or higher includes a Refactor > Migrate to AndroidX menu option to convert your project to use AndroidX. We’ll demonstrate what happens when converting our BannerExample to AndroidX.

Change the project’s compileSdkVersion to 28. This is a prerequisite for migrating to AndroidX.
Right click the app module, and select Refactor > Migrate to AndroidX. You’ll be given an option to save your project as a zip file before Android Studio converts it.
Select Do Refactor to complete the migration.

What changed?

Here is the project before the migration:

And here is the project afterwards:

First, you’ll notice that the package name for AppCompatActivity has changed to androidx.appcompat.app. The refactor has changed this project’s com.android.support:appcompat-v7:26.1.0 dependency to androidx.appcompat:appcompat:1.0.0 and fixed the associated imports.

Second, this migration added a gradle.properties file with these two lines:

android.useAndroidX=true
android.enableJetifier=true

These properties ensure your project and its dependencies use AndroidX, by rewriting any binaries that are using an Android support library. See Using AndroidX for more details on these flags.

Now that your project is converted to AndroidX, you can safely update your play-services-ads dependency to 18.0.0 in your project-level build.gradle file:

dependencies {
   implementation 'androidx.appcompat:appcompat:1.0.0'
   implementation 'com.google.android.gms:play-services-ads:18.0.0'
}

As always, you can follow the release notes to learn what’s changed in the Google Mobile Ads SDK. We’d also love to hear about how your migration went! If you have any questions about the release or have trouble migrating, please reach out to us on the Google Mobile Ads SDK developer forum.

- Eric Leichtenschlag, Mobile Ads Developer Relations

Announcing v17.0.0 of the Android Google Mobile Ads SDK

2018-10-08T02:37:00.000-07:00

Updated on 10/9/2018 to fix the format of the AdMob application ID. The format of an AdMob app ID is ca-app-pub-################~##########.

Google Mobile Ads SDK v17.0.0 for Android has just been released, and it comes with two important changes that you should be aware of:

A tag is now required in AndroidManifest.xml.
NativeAppInstallAd and NativeContentAd APIs are deprecated in favor of UnifiedNativeAd.

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:

<manifest>
    <application>
        <!-- TODO: Replace with your real AdMob app ID -->
        <meta-data
            android:name="com.google.android.gms.ads.APPLICATION_ID"
            android:value="ca-app-pub-################~##########"/>
    </application>
</manifest>

Failure to add this tag will result in the app crashing at app launch with a message starting with "The Google Mobile Ads SDK was initialized incorrectly."

What if I'm using Google Ad Manager instead of AdMob?

Publishers using Google Ad Manager will need to declare themselves as an Ad Manager app with a different tag to avoid the same crash:

<manifest>
    <application>
        <meta-data
            android:name="com.google.android.gms.ads.AD_MANAGER_APP"
            android:value="true"/>
    </application>
</manifest>

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:

AdLoader adLoader = new AdLoader.Builder(context, "ca-app-pub-3940256099942544/2247696110")
    .forUnifiedNativeAd(new UnifiedNativeAd.OnUnifiedNativeAdLoadedListener() {
        @Override
        public void onUnifiedNativeAdLoaded(UnifiedNativeAd unifiedNativeAd) {
            // Show the ad.
        }
    })
    .build();
adLoader.loadAd(new AdRequest.Builder().build());

Check out the native ads guide to get started with the unified API.

What else changed?

See the release notes for a full list of changes. If you have any questions about the release, please reach out to us on the Google Mobile Ads SDK developer forum.

- Eric Leichtenschlag, Mobile Ads Developer Relations

Announcing the Mediation Test Suite Beta

2018-08-09T15:32:00.000-07:00

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.

Mediation Test Suite allows you to:

View a full list of mediation ad source configurations for your app
Automatically check your project for missing SDKs, adapters, and manifest changes required by partner ad sources
Load a banner, interstitial, rewarded, or native ad for any ad source using a certified Google Mobile Ads SDK implementation
Batch test multiple ad sources for the same ad unit
Test both open source mediation adapters and custom event adapters

Integrating Mediation Test Suite is easy -- once you have the SDK imported, it can be launched with just a single line of code. All you need is your AdMob app ID.

On Android, the launch code looks like this:

import com.google.android.ads.mediationtestsuite.MediationTestSuite;
...
String appId = "YOUR-ADMOB-APP-ID";
MediationTestSuite.launch(MainActivity.this, appId);

On iOS, all that's required is importing the correct header and launching the Test Suite:

#import "GoogleMobileAdsMediationTestSuite.h"
...
NSString* appId = @"YOUR-ADMOB-APP-ID"
[GoogleMobileAdsMediationTestSuite presentWithAppID:appId
                                   onViewController:self delegate:nil];

Unity is just as simple, but please note that you need to use the appropriate app ID for your platform:

using GoogleMobileAdsMediationTestSuite.Api;
...
#if UNITY_ANDROID
string appId = "YOUR-ANDROID-ADMOB-APP-ID";
#elif UNITY_IPHONE
string appId = "YOUR-iOS-ADMOB-APP-ID";
#else
string appId = "";
#endif
MediationTestSuite.Show(appId);

Including Mediation Test Suite in production builds is optional

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.

- Jon Weisbaum, Mobile Ads Developer Relations

Simpler Native Ads Implementation with the Unified Native Ads API

2018-02-06T09:40:00.000-08:00

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.

With this feature, the existing native ad formats in Native Ads Advanced — GADNativeAppInstallAdand GADNativeContentAd— are replaced by a single format, GADUnifiedNativeAd. The corresponding views, GADNativeAppInstallAdViewand GADNativeContentAdView, are replaced by a single corresponding view, GADUnifiedNativeAdView.

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:

@implementation ViewController

- (void)viewDidLoad {
  [super viewDidLoad];

// Note here we request only `kGADAdLoaderAdTypeUnifiedNative` and no
// longer request both `kGADAdLoaderAdTypeAppInstall` and
// `kGADAdLoaderAdTypeContentAd`
  self.adLoader = [[GADAdLoader alloc] initWithAdUnitID:YOUR_AD_UNIT_ID
          rootViewController:self
                     adTypes:@[ kGADAdLoaderAdTypeUnifiedNative ]
                     options:nil];
  self.adLoader.delegate = self;
  [self.adLoader loadRequest:[GADRequest request]];
  }
}

#pragma mark - GADUnifiedNativeAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveUnifiedNativeAd:(GADUnifiedNativeAd *)nativeAd {
 // A unified native ad has loaded, and can be displayed.
}

// Note that the two separate ad type delegate callbacks are no longer needed.
#pragma mark - GADNativeAppInstallAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveNativeAppInstallAd:(GADNativeAppInstallAd *)nativeAppInstallAd {
   // An app install ad has loaded, and can be displayed.
}

#pragma mark - GADNativeContentAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveNativeContentAd:(GADNativeContentAd *)nativeContentAd {
   // A content ad has loaded, and can be displayed.
}

With the Unified Native Ads format, you still need to respect the required and recommended assets for display, and check the availability of certain assets when displaying the Unified Native Ad.

For detailed documentation on how to implement Unified Native Ads, refer to the developer documentation and the updated sample code.

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

Use ad content filtering to help improve your users’ ad experience

2018-01-18T16:52:00.000-08:00

Cross posted from the AdMob blog.

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.

Posted by Alexa Haushalter, Product Manager, AdMob

Simpler testing with new AdMob test ads

2018-01-03T15:38:00.000-08:00

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.

Sample 300x250 Banner ad

For native advanced test ads, the headline asset has the text "Test Ad" prepended.

Sample native content 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.

- Eric Leichtenschlag, Mobile Ads Developer Relations

Loading multiple native ads in the Google Mobile Ads SDK

2017-12-07T10:36:00.000-08:00

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:

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:

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

Kotlin and the Google Mobile Ads SDK

2017-10-27T11:20:00.001-07:00

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.

- Andrew Brogdon, Mobile Ads Developer Relations

Get your ads ready for iPhone X

2017-10-25T07:01:00.000-07:00

Cross-posted from the AdMob blog.

Every interaction a user has with your app matters. That's why we're constantly evolving our advertising recommendations and policies to ensure that no matter where and on what device users are engaging with your apps, they have good experiences.

Example of ad appearing outside of "safe area" on iPhone X

With the launch of the iPhone X, app developers now need to plan for new design considerations as the rounded corners, notch, and home screen indicator on the extended screen can obscure content and lead to poor ad experiences for users when ads are placed in these areas.

That's why we've put together a guide to help you adapt your ad strategy for iPhone X. This includes guidance for how you can shift placement of banner or native ads to designated "safe areas" for this new device.

We've also updated our policiesto indicate that ads must not be placed where objects may interfere with the user's typical interaction with the ad or app, such as under the home screen indicator on the iPhone X.

Please review these policy updates and our suggested implementation guide to ensure you're compliant by November 20th.

If you have any questions, visit the AdMob Help Center or contact your Google account team.

Posted by Pablo Alvarez, Product Manager, AdMob

Register now for the April 2017 Display Ads API Workshops

2017-03-29T09:13:00.000-07:00

We're pleased to announce that we'll be holding a series of Display Ads API Workshops in April 2017. These workshops are a half-day of tech talks, group discussions, networking activities, and one-on-one time with Googlersgeared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.

These workshops offer you the following:

A great way for you to meet with the display ads API team to ask questions in person and give feedback directly to us.
A great opportunity to meet and exchange ideas with fellow developers in the community.
Previews of API and SDK roadmaps and select upcoming features.
For the first time, one-on-one office hours with ads API Googlers. Sign-ups will be available on-site on the day of the workshops.

The workshops will be held in the following cities:

New York - April 20, 2017
Register here
Location: Google New York (Chelsea Market)
San Francisco - April 25, 2017
Register here
Location: Google San Francisco

For more information on the agenda and a preview of our talks, please see our workshop page.

As always, if you have any questions, feel free to drop us a line on the DFP API forums, IMA SDK forums, Mobile Ads SDK forums, or the Ads Developer Google+ page.

- Vincent Tsao, DFP API Team

Google Mobile Ads Unity Plugin v3.3.0

2017-03-20T10:22:00.000-07:00

We recently launched v3.3.0 of the Google Mobile Ads Unity Plugin with support for ad position offsets and Unity 5.6 compatibility. The updated v3.3.0 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Ad positions offsets

Version 3.3.0 of Google Mobile Ads Unity Plugin adds the ability to specify an x and y position for both BannerView and NativeExpressAdView objects. To position ad views outside of the existing AdPosition values, provide x and y offsets instead of an AdPosition when instantiating an ad view, as shown below.

BannerView bannerView = new BannerView(adUnitId, AdSize.SmartBanner, 50, 50);

The code snippet above creates a BannerView offset from the top-left corner of the screen by 50 density independent pixels in the x and y axis. NativeExpressAdView positions can be offset in the same manner, as shown below.

NativeExpressAdView nativeExpressAdView = new NativeExpressAdView(
        adUnitId, new AdSize(320, 150), 50, 50);

Support for Unity 5.6

Although Unity 5.6 is still in beta, the latest version of the Google Mobile Ads Unity plugin includes changes to be fully compatible with the upcoming release.

In addition to the new features outlined above, it is recommended to update to the latest version of the Google Mobile Ads plugin to take advantage of stability and bug fixes. The source code and a sample app for the plugin are available in our GitHub repo,as isthefull changelogfor this release. If you have any questions about Unity integration, you can reach us on our developer forum.

- Ram Parameswaran, Mobile Ads Developer Relations

Native Express Video

2017-03-10T11:13:00.000-08:00

If you've created a Native Express ad unit recently, you may have noticed a new template format alongside App Install and Content: Video App Install. In the past few weeks, AdMob has rolled out support for video assets in Native Ads Express, giving publishers a new way to create more engaging presentations for their users.

How to get started

Enabling video demand for a Native Express ad unit is easy. Just open the ad unit's settings in the AdMob console, and look for the Ad type checkboxes at the top of the editor:

Check the checkbox marked "Video app install," and save the change. In a short while, your ad unit will start serving video creatives alongside the other two formats, with no code changes to your app required. That means you can update your existing apps to display this new format without redeploying to the Play Store or App Store.

An important thing to note is that video creatives are only available for ad units using the Large template size. The video player needs a certain amount of space, and the Large template ensures that it's available.

Customizing the experience

While there's no mobile code required to take advantage of Native Express Video, AdMob has introduced some new features to the API that allow publishers to customize the user experience. In particular, a new video options class (VideoOptions on Android, and GADVideoOptions on iOS) gives publishers a way to influence how the ads behave.

For example, the following code will cause video ads appearing in an Android NativeExpressAdView to begin playing with their audio on:


mAdView = (NativeExpressAdView) findViewById(R.id.adView);
mAdView.setVideoOptions(new VideoOptions.Builder()
    .setStartMuted(false)
    .build());

Staying in the know

App publishers can retrieve information about the video assets in their ads through the use of a video controller object (VideoController on Android, GADVideoController on iOS). The ad view classes for native express have been updated to include video controller properties that apps can grab and query for info like whether a video is present in the ad, and what its aspect ratio is. Even if the ad doesn't contain an video asset (or no ad has been loaded at all), you'll always get a valid reference to the ad view's video controller.

For example, here's a Swift snippet that shows how to check if an ad that just loaded contains a video asset:


func nativeExpressAdViewDidReceiveAd(_ nativeExpressAdView: GADNativeExpressAdView)
{
  if nativeExpressAdView.videoController.hasVideoContent() {
    print("Received an ad with a video asset.")
  } else {
    print("Received an ad without a video asset.")
  }
}

More Info

Native Express is designed to make implementing native ads easy, but if you have questions about how to get up and running or how you can best put it to use in your apps, stop by our support forum. The Mobile Ads Garage recently released an episode covering Native Express Video as well, with feature details and screencasts for iOS and Android:

- Andrew Brogdon, Mobile Ads Developer Relations

Mobile Ads Garage #12: Native Express in a UITableView

2016-12-27T09:28:00.000-08:00

Episode twelve 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.

With their customizable presentations and ability to be precached, Native Express ads fit right in with list-based user interfaces:

In this deep dive episode of the Mobile Ads Garage, you'll learn how to integrate Native Express ads into an iOS app that uses a UITableViewController for its primary UI. Along the way you'll get a detailed set of step and see screencasts of an implementation in Xcode. The episode also covers a handy technique for tapping into the ad lifecycle to load native express ads sequentially, from the top of the list to the bottom.

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.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

- Andrew Brogdon, Mobile Ads Developer Relations

AdMob Native Express ads in a content feed

2016-12-16T09:05:00.000-08:00

Today we're excited to announce iOS and Android sample projects that display AdMob Native Express ads in a feed. These samples address a common use case for monetizing apps with feeds or lists of content. The iOS (Swift and Objective-C) apps display Native Express ads in a UITableView and the Android app shows them in a RecyclerView.

Native Express ads work well in lists of content for two reasons. First, impressions are not counted until the ad is on screen, which enables you to preload the ads ahead of time. Preloading can help with optimizing scroll performance by making sure the ad is ready to be displayed when the user scrolls through the list. Second, you have more control over the styling of the ads, allowing you to create presentations that fit naturally with your content.

You can check out these sample apps by downloading them from our iOS and Android GitHub repos, and you can see them being coded in the Mobile Ads Garage YouTube series. Episode 11 walks you through the implementation for adding native ads into an Android RecyclerView. Episode 12, which will cover the implementation of native ads in an iOS UITableView, is due out next week.

If you have any questions or feedback regarding our SDK, feel free to contact us through our forum.

- Tristan Emrich, Mobile Ads Developer Relations

Mobile Ads Garage #11: Native Express in a RecyclerView

2016-12-02T09:55:00.000-08:00

Episode 11 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 a break with tradition, this video is a deep technical dive on one subject: Native Ads Express in an Android RecyclerView. You'll learn how to modify an existing RecyclerView implementation to include Native Express ads, all the way from updating the adapter to loading the ads. In addition, you'll get a clever trick that makes sure your ads are always sized to match the UI, so they fit right in with your content.

If you haven't used Native Ads Express before, you can see them in action in Episode 7. Andrew and Gary cover all the basics: loading ads, placing them in layouts and storyboards, and using CSS to style the ads to match your app.

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

- Andrew Brogdon, Mobile Ads Developer Relations

Mobile Ads Garage #10: Ad Events

2016-11-03T16:03:00.000-07:00

Episode 10 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.

Knowing what's going on with your ads is a big part of maintaining a great user experience. In the latest episode of the Mobile Ads Garage, you'll see how to tap into the ad lifecycle so your app's informed of loads, clickthroughs, and other key events. You'll also get a detailed breakdown of the steps that occur in the life of an ad, info about which classes and callbacks to use for common tasks like pausing game engines and muting audio, and a real world example of how to put it all together.

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

- Andrew Brogdon, Mobile Ads Developer Relations

Announcing rewarded video custom event support for AdMob mediation

2016-10-13T17:42:00.000-07:00

Following its launchat the 2016 Game Developer’s Conference, AdMob’s mediation support for rewarded video ads has been a hit with publishers and users alike, with rapid adoption on both Android and iOS platforms.

Our growing list of mediation partners includes eight different ad networks. Choosing AdMob for your rewarded video mediation platform gives you access to ad content from all of them, while you develop against a single API from AdMob. Now, with the launch of custom events for rewarded video, you can also request and display rewarded videos from ad networks that are not directly supported by AdMob.

Our implementation guide for rewarded video adapters (Android| iOS) outlines how to implement an adapter that can serve rewarded video ads from a third party ad network. Special attention should be paid to steps specific to custom events that are summarized below:

Adding a custom event to your ad unit

To define a custom event, you must first create it in the AdMob interface at apps.admob.com. You can find instructions for creating a custom event in this help center guide.

Retrieving server parameters

The optional server parameter passed to your custom event is accessed via a special key. Here’s an example showing how to access the value in a rewarded video adapter:

Android

String parameter = serverParameters.getString(
    MediationRewardedVideoAdAdapter.CUSTOM_EVENT_SERVER_PARAMETER_FIELD);

iOS

NSString *parameter = [self.connector.credentials
    objectForKey:GADCustomEventParametersServer];

You can find additional documentation on rewarded video ads in our Get Started guides (Android| iOS), and more information about mediation is available in our mediation guides (Android | iOS). For any other questions about rewarded video mediation, you can reach us through our developer forum.

- Ram Parameswaran, Mobile Ads Developer Relations

Mobile Ads Garage #9: AdMob Mediation

2016-10-10T15:39:00.000-07:00

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.

- Andrew Brogdon, Mobile Ads Developer Relations

Google Mobile Ads Unity Plugin v3.0.7

2016-09-27T16:24:00.000-07:00

We recently launched v3.0.7 of the Google Mobile Ads Unity Plugin. The updated v3.0.7 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Native Ads Express

This release introduces support for Native Ads Express. With Native Ads Express, you can create CSS templates that define how ads are presented in your app (things like image sizes, fonts, colors, and so on). These CSS templates are used to generate ad creatives that complement the native look and feel of your app. You can find more information on integrating Native Ads Express into Unity applications in our developer docs.

Android IL2CPP

The v3.0.7 release resolves compatibility issues with the IL2CPP scripting backend and the Google Mobile Ads Unity Plugin. This allows the use of the the IL2CPP scripting backend, a high-performance alternative to the Mono virtual machine and AOT compiler, in Unity applications with the Google Mobile Ads SDK.

The source code and a sample app for the plugin are available in our GitHub repo,as isa changelogfor this release. If you have any questions about Unity integration, you can reach us on our developer forum.

- Ram Parameswaran, Mobile Ads Developer Relations

Use Google Mobile Ads SDK 7.11.0 to update apps for iOS 10

2016-09-15T17:00:00.000-07:00

With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.

What changed?

With the rollout of iOS 10, the App Store’s privacy policy requires apps to provide a usage description when attempting to access privacy-sensitive data, such as a user’s calendaror Bluetooth. You may have seen the following errors when attempting to upload your app to iTunes Connect:

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."

The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.

Information for MRAID creative designers

To comply with the App Store privacy changes, we removed support for the mraid.createCalendarEvent() and mraid.storePicture() methods. You will now see that the mraid.supports("calendar") and mraid.supports("storePicture") methods always return false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.

If you have any questions regarding these changes, please contact us through our forum.

- Tristan Emrich, Mobile Ads Developer Relations

Mobile Ads Garage #5: Interstitial best practices

2016-06-10T16:05:00.000-07:00

A new episode of The Mobile Ads Garage has hit 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, break down the feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

In the last episode, Andrew and Gary the Graphics Guy showed you how to implement AdMob interstitials on iOS and Android. Now they're back to show you how to put interstitials to work in the best ways possible. When is the best time to display? How early should you request an ad, and how often should your users see one? You'll get answers to these questions and more, along with cupcakes, cats who can play chess, and what appears to be a cloning incident gone awry.

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

- Andrew Brogdon, Mobile Ads Developer Relations