Tag Archives: AdMob

Take the 2023 Google Mobile Ads SDK developer survey

Today, we’re excited to announce the launch of our 2023 Google Mobile Ads SDK Developer Survey. As part of our efforts to continue updating the AdMob and Ad Manager products, we’d like to hear from you about where we should focus our efforts. This includes product feedback as well as feedback on our guides, code samples and other resources. Your feedback will help shape our future product and resource roadmap.

Take the survey

This anonymous survey should only take about 15 minutes to complete and will provide our team with your valuable feedback as we plan for the months ahead. Whether you’re an engineer, Ad Ops personnel, or a PM, your feedback on AdMob, Ad Manager, and the Google Mobile Ads SDK is valuable to us. We appreciate you taking the time to help improve our developer experience!

Use Mobile Ads SDK Volume APIs Correctly to Maximize Video Ad Revenue

The volume control APIs provided by the Google Mobile Ads SDK are intended to mirror your app’s own custom volume controls. Utilizing these APIs ensures that the user receives video ads with the expected audio volume.

We’ll talk about some best practices implementing the volume control APIs in your iOS, Android or Unity project.

Why are we mentioning this?

Publishers can lose revenue when using these APIs to lower or mute the volume of the Google Mobile Ads SDK. Two issues we have commonly seen:

  1. Apps are using their own custom volume controls not sending the app’s accurate volume to the Google Mobile Ads SDK, but always sending zero
  2. App are just muting the SDK

Some apps have close to a 100% mute rate which doesn’t sound correct (pun intended). Setting application volume to zero or muting the application reduces video ad eligibility, which as a result may reduce your app’s ad revenue.

Volume control APIs

The Google Mobile Ads SDK offers two volume control APIs: setting the volume and toggling mute. These APIs are applicable to App Open, Banner, Interstitial, Rewarded and Rewarded Interstitial ad formats. For Native ads, use GADVideoOptions.

Setting application volume on each platform

iOS GADMobileAds.sharedInstance().applicationVolume = 1.0
Android MobileAds.setAppVolume(1.0f)
Unity MobileAds.SetApplicationVolume(1.0f)

Use applicationVolume to set your custom volume relative to the device volume. The range can be from 0.0 (silent) to 1.0 (current device volume). For example, if the device volume level was at half level and the user set your app’s custom volume to max level, set the applicationVolume to 1.0 and the user will receive an ad with the volume at half level.

Setting application mute on each platform

iOS GADMobileAds.sharedInstance().applicationMuted = true
Android MobileAds.setAppMuted(true)
Unity MobileAds.SetApplicationMuted(true)

Use applicationMuted if your custom volume controls include a mute button. Only toggle applicationMuted if the user selects your custom mute button. For example, if the user adjusts your custom volume to 0 you do not need to call applicationMuted; just call applicationVolume = 0.0.

Setting mute for native ads on each platform

iOS
let videoOptions = GADVideoOptions()
videoOptions.startMuted = true
adLoader = GADAdLoader(
adUnitID: "AD_UNIT_ID",
rootViewController: self,
adTypes: [ ... ad type constants ... ],
options: [videoOptions])
Android
val videoOptions = VideoOptions.Builder()
.setStartMuted(false)
.build()
val adOptions = NativeAdOptions.Builder()
.setVideoOptions(videoOptions)
.build()
val adLoader = AdLoader.Builder(this, "AD_UNIT_ID")
.forNativeAd( ... )
.withNativeAdOptions(adOptions)
.build()
Unity N/A - Native video ads are not supported in Unity.

Use startMuted if your custom volume controls include a mute button. Only toggle startMuted if the user selects your custom mute button.

Best Practices

To use our APIs as intended:

  1. applicationVolume should be called only when your custom volume control settings are set to reflect the new volume
  2. applicationMuted or startMuted should only be toggled to true if the user has muted your custom volume

As a rule of thumb, if your app does not have custom volume controls then you should not use these APIs.

What should you do?

To verify that your mobile applications are using these APIs correctly, we recommend that you enable test ads and force load a video test ad in your application. If your app has custom volume controls, the ad’s volume should be at the same level as the custom volume. Otherwise, the ad’s volume should match the device volume.

If you have any questions or need additional help, please contact us via the forum.

Announcing iOS Google Mobile Ads SDK Version 10.0.0

We are excited to announce the release of our newest version of the Google Mobile Ads SDK. We recommend upgrading as soon as possible to stay up-to-date with our latest features.

Version 10.0.0 Changes

Google Mobile Ads SDK version 10.0.0 introduces a few major changes:

  • The minimum OS version has been bumped from 11 to 12. Given the high adoption rate of iOS 16, we are continuing the trend of incrementing the minimum support level. Applications can still be built for iOS 11, however, the SDK will not load any ads on iOS 11.
  • Since bitcode is deprecated in Xcode 14, we have disabled bitcode in the SDK. As a result, this has decreased the download size of our SDK by ~35MB. What this means for you is to integrate with SDK version 10.0.0, you also have to disable bitcode (if you haven’t already) in the build settings of your Xcode project.
  • Ad Manager applications require an app ID upon initialization of the SDK. This also means the key GADIsAppManagerApp will no longer bypass this check. App IDs are added to the Info.plist with a key of GADApplicationIdentifier. See Update your Info.plist for more details.
  • Ad Manager applications require GoogleAppMeasurement.xcframework as a dependency. If you install the Google Mobile Ads SDK through CocoaPods or Swift Package Manager, no additional action is required. If you install frameworks manually, see Manual Download for more details.
  • We also have removed deprecated APIs of various properties and classes.

For the full list of changes, check the release notes. Check our migration guide to ensure your mobile apps are ready to upgrade.

SDK Deprecation Reminder

Per the deprecation schedule announced last year, the release of version 10.0.0 means that:

  • iOS Google Mobile Ads SDK versions 8.x.x is officially deprecated, and will sunset in Q2 2024.
  • Versions 7.x.x and below will sunset sometime in Q2 2023, approximately 60 days following the release of Android Google Mobile Ads SDK major version 22.0.0.

As always, if you have any questions or need additional help, contact us via the forum.

SwiftUI Case Study: Presenting from View Controllers

We are happy to announce the release of an iOS sample application that demonstrates how to integrate the Google Mobile Ads SDK into a SwiftUI-based app. This post covers how we implemented full screen ad formats (interstitial, rewarded, rewarded interstitial) in SwiftUI.

The Google Mobile Ads SDK relies heavily on the UIKit Framework, depending on UIView or UIViewController for each ad format. For example, the SDK currently presents full screen ads using the following method:

present(fromRootViewController rootViewController: UIViewController)

In UIKit, ads are typically implemented in a UIViewController, so it is rather trivial to pass in a rootViewController value by simply invoking self. SwiftUI requires us to diverge from this approach, however, because UIViewController cannot be directly referenced in SwiftUI. Since we can’t just pass in self as the root view controller, we needed to achieve a similar result using a SwiftUI-native approach.

Our solution

We created an implementation of the UIViewControllerRepresentable protocol with a UIViewController property. Its one job is to provide access to the UIViewController reference in SwiftUI.

private struct AdViewControllerRepresentable: UIViewControllerRepresentable {
let viewController = UIViewController()

func makeUIViewController(context: Context) -> some UIViewController {
return viewController
}

func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {}
}

AdViewControllerRepresentable needs to be included as part of the view hierarchy even though it holds no significance to the content on screen. This is because canPresent(fromRootViewController:) requires the presenting view controller’s window value to not be nil.

private let adViewControllerRepresentable = AdViewControllerRepresentable()

var body: some View {
Text("hello, friend.")
.font(.largeTitle)
// Add the adViewControllerRepresentable to the background so it
// does not influence the placement of other views in the view hierarchy.
.background {
adViewControllerRepresentable
.frame(width: .zero, height: .zero)
}
}

To present the full screen ads in our sample app, we leveraged action events in SwiftUI.

Button("Watch an ad!") {
coordinator.presentAd(from: adViewControllerRepresentable.viewController)
}

And our AdCoordinator class does the honor of presenting it from our view controller.

private class AdCoordinator: NSObject {
private var ad: GADInterstitialAd?

...

func presentAd(from viewController: UIViewController) {
guard let ad = ad else {
return print("Ad wasn't ready")
}

ad.present(fromRootViewController: viewController)
}
}

And voila!

An alternative option

Instead of creating a UIViewControllerRepresentable, there was always the option to query the rootViewController property from UIWindow.

UIApplication.shared.windows.first?.rootViewController

We decided against this option for the following reasons:

  1. There is the inherent nullability risk to querying an optional array index.
  2. The default value of rootViewController is nil.
  3. If your app utilizes more than one window, the windows array will have multiple elements and therefore, makes querying the “first” window object unreliable.
  4. windows on the UIApplication object is deprecated in iOS 15 and UIWindowScene now holds the reference to this property.

Conclusion

We know there is more than one way to cook an egg when it comes to writing code in SwiftUI. For our use case, we chose the most low-code friendly option. If you have any questions, reach out to our developer forum.

Try it out!

Announcing a deprecation schedule for the Google Mobile Ads SDK

To provide Google Mobile Ads SDK developers for AdMob and Ad Manager more transparency and predictability on the expected lifetime of an SDK version, we are introducing a deprecation schedule for the Google Mobile Ads SDKs for Android and iOS.

Benefits

Introducing a predictable deprecation schedule offers the following benefits for app developers and publishers:

  1. Ability to predict and plan for SDK updates with a year of lead time.
  2. Legacy SDK code that only exists to support old versions can be deleted, thereby decreasing SDK size and lowering the risk of bugs.
  3. Engineering resources are freed up to focus more on support for newer SDKs and innovation of new SDK features.

Glossary

To understand the deprecation schedule, let’s first align the terms used to describe the state of a Google Mobile Ads SDK version:

SDK State Impact
Supported
Deprecated
  • Ads will still serve to this SDK.
  • Support questions specific to this SDK version are no longer answered on the Google Mobile Ads SDK developer forum. Users will be asked to validate the issue in a supported SDK version to receive full support.
Sunset
  • Ads will not serve to this SDK.
  • Ad requests return a no fill with an error indicating that this version is sunset.

Timelines

The deprecation and sunset timelines will revolve around major SDK version releases. We plan to do a major version release annually, in the first quarter of each year. The release of a new major version on both Android and iOS will trigger changes in SDK state for older major versions on both platforms.

Once we release a new major version N for both Android and iOS:

  • All SDK versions with major version N-2 on their respective platforms are considered deprecated immediately. Questions specific to these versions will no longer receive support.
  • All SDKs versions with major version N-3 on their respective platforms will sunset after 2 months.
    • We will publish subsequent blog posts communicating specific sunset dates to activate this two-month sunset period. The first sunset announcement is expected in Q1 2023 with a sunset date in Q2 2023.

With this schedule, a new major version will live in the supported state for about 2 years, and in the deprecated state for an additional year before moving to the sunset state.

The graphic below helps visualize the schedule:

How does the change apply to existing versions?

Effective today, Android v19 and iOS v7 versions are considered deprecated. In accordance with the schedule above, we plan to sunset Android v19 and iOS v7 versions in Q2 2023 following the releases of Android v22 and iOS v9 planned for Q1 2023. We will provide more specific sunset dates following the releases of Android v22 and iOS v9.

The graphic below helps visualize the state of existing Google Mobile Ads SDK versions for Android and iOS with today’s announcement.

Note: Versions 6.x.x and below for both Android and iOS have been sunset since 2018.

Exceptions

The deprecation schedule provides a framework for predictable lifetimes for an SDK version. However, there may be exceptions in the future. This schedule does not preclude us from sunsetting an SDK version at an earlier date, but we are committed to providing proactive communication with ample lead time for any future changes.

Next Steps

  1. Refer to the deprecation developer pages (Android | iOS) for the latest updates to the deprecation schedule. If you are on a deprecated version, see the Android migration guide or iOS migration guide for more information on how to update.
  2. Stay tuned for future updates to this blog, where more specific sunset dates will be communicated once new major Google Mobile Ads SDK versions are released.

If you have any questions about this announcement, please reach out to us on the Google Mobile Ads SDK Developer Forum.

New ways to diversify your games revenue

With more than 3 billion people playing games across platforms, the games industry continues to evolve rapidly. Still, one thing remains unchanged: developers need to grow revenue and profitability from their mobile games for long term success. This week, at the Think with Google Gaming Day in China, we shared new ways to help developers like you earn more revenue and attract high-value players.

Strengthen your monetization strategies

The right metrics can make a huge difference to your game’s success by enhancing transparency and clarity in your ads performance. AdMob’s updated Ads Activity report contains new measurement dimensions to help you do just that. Easily analyze earnings including those from third-party ad sources with dimensions like “hour of delivery,” “app version” or “ad source.” Publishers can also better monitor and understand the impact of privacy changes on revenue with report dimensions indicating publisher and user response to the iOS privacy framework.

Screengrab of Google Ads user interface, featuring the ads activity report dimensions and metrics in table format

The Ads Activity report contains new dimensions to help you understand your ads performance

Along with the Ads Activity report, we announced more features to help you diversify and grow your revenue for the long-term:

  • Google Mobile Ads Software Developer Kit (GMA SDK): Implement the latest GMA SDK version to stay updated on new feature releases such as the same app key that delivers more relevant and personalized ads for your apps on iOS.
  • H5 Games Ads (beta): Grow your earnings by easily showing interstitial and rewarded ads in your HTML5 (H5) games today.
  • New bidding partner: Access demand from Pangle, now available on AdMob in addition to more than 200 demand partners competing in real-time for your inventory.

Drive deeper engagement and revenue performance

To drive sustainable growth for your game, you’ll need more than just a strong monetization strategy. It is also important to have the right tools to effectively attract quality players. Now, with the ability to add an audience signal to your Android App campaigns, we’re making this even easier. You’ll be able to use your existing knowledge on the types of players you believe your campaigns would be most successful with to help guide our models to find similar new players who are more likely to convert. This will be available in beta in the coming months.

Add an audience signal to help you find new players who are more likely to convert

As the industry moves away from individual identifiers like device IDs, measuring your campaign performance accurately — along with acting on your conversion data — is critical. That’s why earlier this year, we introduced on-device conversion measurement. With on-device conversion measurement, user interactions with app ads can be matched to app conversions in a way that prevents user-identifying information from leaving a user's device. This helps you to prioritize privacy standards without compromising performance. Explore our developer guide to learn how you can implement this solution for your iOS App campaigns.

We are also releasing other new features to help you grow engagement and performance:

  • New audience lists: Re-engage high-value players with automatically generated lists of past purchasers based on your apps’ play data. This feature is now generally available through App campaigns for engagement.
  • Creative testing for video: Easily run experiments to understand the impact your video creative has on your App campaign performance. This will be available in beta in the coming months.
  • Target return on ad spend (tROAS) for ad revenue: Acquire players who are more likely to engage with ads shown in-app. In the coming months, all developers can send ad revenue from monetization platforms to Google Analytics to improve tROAS bidding in Google Ads.

Scale your reach to third-party app inventory

Lastly, advertisers now have the opportunity to extend their App campaign reach to more users. Advertisers using Google Ads and Display & Video 360 will have the opportunity to participate in real-time bidding integrations with third-party monetization platforms AppLovin (MAX), DT FairBid and Helium by Chartboost.

Also, developers who use third-party platforms will now have easy access to competitive real-time bids from advertisers using Google Ads and Display & Video 360. The program is currently in closed beta and these buying tools will be available as a bidder for approved publishers on these third-party real-time bidding monetization platforms at this time.

Watch the full Ads keynote to hear more about how these solutions can help you drive revenue and profitability for your games business.

Use the new Google Mobile Ads SDK getVersion() method

We heard your feedback that MobileAds.getVersionString() was confusing as it didn’t match the external version. We addressed it by adding a new method - MobileAds.getVersion(). In doing so, we have deprecated MobileAds.getVersionString().

Distinctions between getVersionString() and getVersion()

getVersionString() [deprecated] getVersion()
Sample return value afma-sdk-a-v214106000.214106000.0 21.0.0
Requires calling initialize() first? Yes No

Calling MobileAds.getVersionString() returns an internal version number. The MobileAds.getVersion() method outputs a simplified, external version number that matches the version in the release notes. For example, 21.0.0.

Also as part of the v21.0.0 release, you can call MobileAds.getVersion() before calling MobileAds.initialize(). Previously, you had to initialize the SDK to query the SDK version number, or else the app would crash.

Querying the SDK version number can be accomplished in your Android apps with the following code snippet:

// Log the Mobile Ads SDK Version.
Log.d("MyApp", MobileAds.getVersion()); // "21.0.0"

// Initialize the SDK.
MobileAds.initialize(this, new OnInitializationCompleteListener() {
@Override
public void onInitializationComplete(InitializationStatus status) {}
});

For the full list of changes in the v21.0.0 release, check the release notes. If you have any questions or need additional help, contact us via the forum.

Celebrate publisher stories on our new website

Publishers create the blogs, news, games, tools and videos we all enjoy. But we don’t always get to see the work that goes into building the content on the internet we know and love today. In 2021, the commercial internet helped generate 17 million jobs for Americans — and we’re celebrating just a few of those who were a part of that success.

After sitting down with these publishers, we’ve learned how they use digital ad revenue to grow their businesses, create free and accessible content, impact their communities and most of all, how their passion for their work fuels them to keep serving their audiences.

Check out their stories on Google for Publishers and hear from small and large publishers — in their own words.