Tag Archives: ad_manager

Reduce ANRs when implementing mobile ads

We heard your feedback via Play Console crash reports regarding Application Not Responding (ANRs) errors related to the Google Mobile Ads SDK. After analyzing these reports, we updated our SDK implementation best practices to reduce ANR rates. The recommended best practices are as follows:

  1. Initialize the Mobile Ads SDK on a background thread
  2. Enable optimization flag for ad loading

1. Initialize the Mobile Ads SDK on a background thread

Our previous best practice was to specify the OPTIMIZE_INITIALIZATION manifest flag. However, some work on the calling thread is still required to prepare MobileAds to handle other method calls synchronously.

We now recommend calling MobileAds.initialize() on a background thread, enabling the work required on the calling thread to happen in the background.

import com.google.android.gms.ads.MobileAds
import kotlinx.coroutines.CoroutineScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.launch

class MainActivity : AppCompatActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    CoroutineScope(Dispatchers.IO).launch {
      // Initialize the Google Mobile Ads SDK on a background thread.
      MobileAds.initialize(this@MainActivity) {}
      runOnUiThread {
        // Load an ad on the main thread.
        loadAd()
      }
    }
  }
}

Note: When calling MobileAds.initialize() on a background thread, the OPTIMIZE_INITIALIZATION manifest flag is no longer required.

2. Enable optimization flag for ad loading

By enabling the OPTIMIZE_AD_LOADING manifest flag, you can offload most ad loading tasks to a background thread. We recommend enabling this flag in your app's AndroidManifest.xml file to reduce the occurrence of ad loading causing ANRs.

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

We’ve updated all of our Android example apps to implement these best practices. For more details on initialization and optimization flags, see Get started and Optimize initialization and ad loading. Contact us if you have any questions or need additional help.

Announcing Android Google Mobile Ads SDK Version 23.0.0

Version 23.0.0 of the Android Google Mobile Ads SDK is now available. We recommend upgrading as soon as possible to get our latest features and performance improvements.

The minimum Android API level is 21

Starting in version 23.0.0, the Google Mobile Ads SDK requires all apps to be on a minimum Android API level 21 to run. To adjust the API level, change the value of minSdk in your app-level build.gradle file to 21 or higher.

Ad Manager builder methods can now be chained

In version 23.0.0, AdManagerAdRequest.Builder methods inherited from its parent can be chained together to build an AdManagerAdRequest using a single call:

var newRequest = AdManagerAdRequest.Builder()
  .addCustomTargeting("age", "25") // AdManagerAdRequest.Builder method.
  .setContentUrl("https://www.example.com") // Method inherited from parent.
  .build() // Builds an AdManagerAdRequest.

A side effect of this change is AdManagerAdRequest.Builder no longer inherits from AdRequest.Builder.

SDK deprecation and sunset timelines activated

With this Android major version 23 launch and the iOS major version 11 launch last month, we are announcing new deprecation and sunset dates for older major releases. Specifically:

  • Android Google Mobile Ads SDK versions 21.x.x are officially deprecated, and will sunset in Q2 2025.
  • Android versions 20.x.x and iOS versions 8.x.x will sunset on June 30, 2024.
    • While there are currently no plans to disable ad serving on Android versions 20.x.x and iOS versions 8.x.x, we strongly recommend updating to a supported SDK version to avoid being impacted in the future.

For the full list of changes in v23.0.0, check the release notes. Check our migration guide to ensure your mobile apps are ready to upgrade. As always, if you have any questions or need additional help, contact us via the developer forum.

Announcing iOS Google Mobile Ads SDK Version 11.0.0

Today, we are announcing that version 11.0.0 of the Google Mobile Ads SDK is now available. We recommend upgrading as soon as possible to get our latest features and performance improvements.

Simplified SwiftUI development

Version 11.0.0 no longer requires publishers to declare a view controller to present full-screen ads. As a result, SwiftUI Publishers can now present full-screen ads without the need for UIKit or UIViewControllerRepresentable workarounds. See our SwiftUI guide for more information.

struct ContentView: View {
  private let adCoordinator = AdCoordinator()

  var body: some View {
    ...

    Button("Watch an ad") {
      adCoordinator.showAd()
    }
  }
}

private class InterstitialAdCoordinator: NSObject, GADFullScreenContentDelegate {
  private var interstitial: GADInterstitialAd?

  ...

  func showAd() {
    guard let interstitial = interstitial else {
      return print("Ad wasn't ready")
    }

    // The SDK uses the app's main window to look up view controllers
    // automatically when one is not provided.
    interstitial.present(fromRootViewController: nil)
  }
}

Continue collecting user metrics in AdMob

The Google Mobile Ads SDK dependency on GoogleAppMeasurement has been removed. This dependency that powered the user metrics toggle in AdMob will be discontinued in early 2024. To continue collecting user metrics in AdMob, link your AdMob app to Firebase and integrate the Google Analytics for Firebase SDK into your app.

Changes to minimum OS and Xcode requirements

  • The minimum OS version to load ads has been bumped from 12 to 13. Applications can still be built for iOS 12, but the SDK will only load ads on iOS 13 and higher.
  • The minimum supported Xcode version has been bumped to 15.1.

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, the release of version 11.0.0 means that:

  • iOS Google Mobile Ads SDK versions 9.x.x are officially deprecated, and will sunset in Q2 2025.
  • Versions 8.x.x and below will sunset in Q2 2024, approximately 60 days following the release of Android Google Mobile Ads SDK major version 23.0.0.
    • While there are currently no plans to disable ad serving on version 8.x.x, we strongly recommend updating to a supported SDK version to avoid being impacted in the future.

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

Optimally configure the Attribution Reporting API for ad measurement

Background

Ad-tech providers have historically used third-party cookies for conversion measurement, and for attributing conversions to ad interactions. Conversion measurement is critical for evaluating the performance of ad campaigns and automated bidding strategies. Now, with technology changes and privacy regulations on the rise, traditional ad-measurement systems must change in order to remain effective while protecting user privacy.

Chrome’s Attribution Reporting API (ARA), part of the Privacy Sandbox initiative, offers a new path to conversion measurement after Chrome’s planned third-party cookie deprecation in the second half of 2024, subject to addressing any remaining competition concerns of the UK’s Competition and Markets Authority (CMA). Google’s ads teams have made significant investments in learning to use the ARA more effectively, to help advertisers achieve more accurate measurement.

In a previous post, we provided a high-level overview of the approach Google’s ads teams are taking to effectively blend the ARA event-level and aggregate summary reports to maximize accuracy. A key point is that your configuration determines what data you query, and how you query it. It’s crucial for ad-tech providers to effectively configure the ARA for their use cases. Google’s ads teams have found that configuring specific ARA settings can lead to notable accuracy improvements. We encourage other ad-tech providers to integrate with the ARA to retrieve the conversion data they need, and process the ARA's output to help maintain accurate measurement in a post-third-party-cookie world.

The ARA is flexible to support various use cases. Google’s ads teams use this flexibility to configure unique ARA settings for each advertiser. This way, ARA-based measurement adapts to each advertiser’s specific needs. For example, we’ve noticed that when advertisers differ in conversion volume, it’s better to have advertiser-specific configurations related to the granularity of aggregation keys and the maximum observable conversions per ad interaction.

Google’s ads teams’ approach

Here's how Google's ads teams use the ARA to ensure the raw data we receive is as useful as possible for downstream blending. We configure ARA settings as explicit mathematical optimizations by defining objective functions to represent data quality, then choosing settings to optimize those functions. Ad-tech providers can choose their own approach. Google’s ads teams plan to continue sharing insights we learn from our own optimizations with the ad-tech community.

Please see our detailed technical explainer for more information about our approach to ARA configuration.

We’ve Made Updates to the User Messaging Platform SDK APIs

In case you missed it, we announced new consent management platform requirements for serving ads in the EEA and UK. Beginning January 16, 2024, Google will require all publishers to use a Google-certified consent management platform (CMP) when serving ads to users in the European Economic Area or the UK.

In addition to growing our list of certified CMPs, we explored how to improve the User Messaging Platform (UMP) SDK developer experience for those who choose to use Google’s consent management solution. We are excited to share several updates in the latest iOS and Android versions that we think will streamline your integration.

Loading and presenting a consent form

The latest UMP SDK release introduces a new API, loadAndPresentIfRequired(), that consolidates the existing individual load and present consent form methods into a single method. The new API loads a consent form and if consent is required, automatically presents the consent form. This method is intended to be used at the beginning of a new app session.

Here is a code example of how to use the new API on iOS:

class ViewController: UIViewController {

  private var isMobileAdsStartCalled = false

  override func viewDidLoad() {
    super.viewDidLoad()

    UMPConsentInformation.sharedInstance.requestConsentInfoUpdate(with: parameters) {
      [weak self] requestConsentError in
      guard let self else { return }

      // Call the helper method once consent information has been updated.
      UMPConsentForm.loadAndPresentIfRequired(from: self) {
        [weak self] loadAndPresentError in
        guard let self else { return }

        if UMPConsentInformation.sharedInstance.canRequestAds {
          self.startGoogleMobileAdsSDK()
        }
      }
    }

    // canRequestAds will be true if consent was gathered in the previous session.
    if UMPConsentInformation.sharedInstance.canRequestAds {
      startGoogleMobileAdsSDK()
    }
  }

  private func startGoogleMobileAdsSDK() {
    DispatchQueue.main.async {
      guard !self.isMobileAdsStartCalled else { return }

      self.isMobileAdsStartCalled = true

      // Initialize the Google Mobile Ads SDK.
      GADMobileAds.sharedInstance().start()
      // Request an ad.
      GADInterstitialAd.load(...)
    }
  }
}

Checking when to request ads

We added a new boolean property canRequestAds to use as a check before initializing the Google Mobile Ads SDK and requesting ads. canRequestAds returns true when the consent status is either OBTAINED or NOT_REQUIRED; as a result you don’t need to implement any enum checking yourself.

You should use the canRequestAds API in two places (as seen in the code snippet above):

  1. Once consent has been gathered in the current session.
  2. Immediately after you have called requestConsentInfoUpdate. It is possible consent has been gathered in the previous session in which case it is not necessary to wait for the callback to finish.

Checking privacy options requirement status

GDPR requires that publishers allow users to withdraw their consent choices at any time. It should be as easy to withdraw consent as it is to gather consent. To simplify this process, we have added two new APIs:

  1. privacyOptionsRequirementStatus to determine whether you should include a UI element that can re-present the consent form, such as a button in your application’s settings page.
  2. presentPrivacyOptionsForm() to show the form so the user can update their consent status at any time.

Here is a code example of how to use the new APIs on iOS:

// Show a privacy options button if required.
private var isPrivacySettingsButtonEnabled: Bool {
  return UMPConsentInformation.shared.privacyOptionsRequirementStatus == .required
}

// Present the privacy options form when a user interacts with your app.
@IBAction func privacySettingsTapped(_ sender: UIBarButtonItem) {
  UMPConsentForm.presentPrivacyOptionsForm(from: self) {
    [weak self] formError in
    guard let self, let formError else { return }

    // Handle the error.
  }
}

Developer resources

We updated our AdMob banner samples applications for iOS and Android to showcase integrating the UMP SDK. Keep an eye out as we add UMP SDK support to the rest of our samples soon.

Also take a look at our iOS and Android developer documentation for instructions on how to implement the UMP SDK.

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

Effectively use the Attribution Reporting API for ad measurement

Overview

Historically, ad-tech providers have used third-party cookies (3PC) as a mechanism for conversion measurement, and for attributing conversions to ad interactions. Conversion measurement provides critical ad performance data to advertisers, and helps optimize auction-based bidding strategies.

Currently, the online advertising ecosystem is pivoting towards improved ways to protect user privacy. Chrome’s Attribution Reporting API (ARA), a part of the larger Privacy Sandbox initiative, offers an alternative for measurement after the third-party cookie deprecation in 2024. Ad-tech providers, including Google’s ads platforms, should consider adopting the ARA to maintain high-quality conversion measurement and support the pivot toward user privacy protection.

Google Ads has made significant investments to use the ARA more effectively and to help advertisers achieve more accurate measurement. We encourage other ad-tech providers to integrate with the ARA, configure the integration to retrieve the data they need, and process the ARA's output to help maintain accurate measurement after the planned third-party cookie deprecation in 2024.

Goals of the ARA

The ARA has two goals:

  • Protect users’ cross-site and cross-app identities from ad-tech providers, advertisers, publishers and other entities by using differential privacy techniques, such as aggregation, or adding an element of noise to the data.
  • Provide useful measurement information to ad-tech providers, advertisers, and publishers.

The ARA represents a change to both the format and granularity of conversion data available to ad-tech providers. As a result, ad-tech providers must change their current measurement protocols in order to start leveraging the ARA.

A glimpse into our approach

Ad-tech providers who participate in the Privacy Sandbox initiative receive data from the ARA in two forms: event-level reports and aggregate summary reports. This way, two independent views of the same underlying data are available. We encourage ad-tech providers to configure the reporting settings in the API to optimize for better measurement accuracy without 3PC, as well as improve how these two types of reports can be post-processed and used together.

There are many possible ways to utilize the ARA reports. The methodology that works for an ad-tech provider will ultimately depend on its conversion data and measurement requirements. Google Ads has found that leveraging both report types can help the industry benefit from the strengths of each report.

Google Ads leverages both event types to produce a more complete, ad event-level log. We are committed to sharing our process and engaging with the ecosystem to help our partners and the broader industry transition into a future without third-party cookies.

For more details on how we’re implementing the Attribution Reporting API, please refer to our detailed technical guide.

Prepare to test Privacy Sandbox APIs with Google’s ads platforms

Last week, Chrome announced the upcoming general availability of Privacy Sandbox APIs for the ads ecosystem. We welcome this opportunity to test these APIs in Google’s ads platforms, and we invite ad technology partners to get involved and be ready for Chrome’s third-party cookie deprecation in 2024.

We’ve seen encouraging results from our recent interest-based advertising experiments, and we plan to integrate Topics, Protected Audience and Attribution Reporting APIs into our ads products. We’ll use Privacy Sandbox APIs alongside other privacy-preserving innovations to help deliver relevant ads and accurate measurement insights without the need to track people across the web.

We encourage advertisers and publishers to continue to adopt the full range of Google’s privacy-first ads solutions, and encourage their ad technology platform partners to adopt and test Privacy Sandbox APIs.

Through the rest of 2023, we will work with our ad technology partners to test the Privacy Sandbox APIs alongside first-party data and AI-powered solutions, and prepare for Q1 2024 when Chrome plans to deprecate third-party cookies for one percent of its users. The Q1 2024 tests will help us to evaluate the effectiveness of these solutions, and share our findings with Chrome, the UK’s Competition and Markets Authority, and the industry.

We encourage technology partners to review the below guidance to prepare for testing with Google’s Ads solutions:
  • If you’re a Google Authorized Buyer or participant in Open Bidding, see integration guidance for Topics and Protected Audience.
  • If you’re a publisher platform working with Google Ads or Google Marketing Platform (Display & Video 360 or Campaign Manager 360), see integration guidance for Topics, Protected Audience and Multiple seller testing.
  • If you’re a measurement provider working with Google Marketing Platform (Display & Video 360 or Campaign Manager 360), see integration guidance for the Protected Audience API.
  • If you’re a publisher or ad tech provider working with Google Marketing Platform (Display & Video 360, Campaign Manager 360 or Search Ads 360), see integration guidance for the Attribution Reporting API.
We’re excited to continue building privacy-first innovations that help partners drive performance, earn revenue and get accurate measurement insights without third-party cookies.

Announcing new testing features for ad inspector

We’re excited to announce the launch of new testing features on ad inspector across all platforms for our AdMob and Ad Manager publishers.

Previously, ad inspector tested all ads in context - in other words, you had to fire up your app, navigate to the appropriate screen in the UI, and have your ad load as it would for any other user. While this provides for the most accurate testing scenario, it also puts more work on you as the publisher and tester of your app. You don’t want ads buried in more obscure screens in your app to lose out on the testing attention and care they need!

With our latest update, you can now use test ads to load requests for any ad unit - no matter where it's located in your app. Rather than needing to navigate through your app to test each ad unit, you can execute your tests directly from ad inspector.

How do I use ad inspector’s new testing features?

Beginning with version v10.0.0 on iOS and v21.4.0 on Android of the Google Mobile Ads SDK, ad inspector supports running tests directly from the ad unit detail screen via a “Request test ad” button:

All of your requests made from your app’s UI or within ad inspector will appear in the SDK request log; your requests made from within ad inspector will be differentiated by being labeled with “Requested from ad inspector”. For these special requests you’ll be able to tap the “View” button one time to view the actual ad, see which network filled the slot, and more.

Alongside single ad source testing, these new testing features will allow you to rigorously test each individual ad network integration in your app.

To learn more about how to test your ads with ad inspector, check out our developer guides here:

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

Android Google Mobile Ads SDK Version 22.0.0 activates SDK sunset timelines

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 22.0.0 Changes

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

  • MobileAds.getVersionString() is removed in version 22.0.0 in favor of MobileAds.getVersion(). The new method returns the expected external version number (for example, 22.0.0), helping you more clearly identify your SDK version. For more information about this change, see the Use the new Google Mobile Ads SDK getVersion() method blog post.
  • In version 21, the Google Mobile Ads SDK provided you the NativeCustomFormatAd.getVideoMediaView() method to get the media asset for an Ad Manager native custom ad format. In version 22, NativeCustomFormatAd provides direct access to getMediaContent() enabling you to define your MediaView in layout files along with the rest of your other views, and simply populate that view with its content once the ad loads.

See release notes for the full changelog. See our migration guide to help you migrate your apps.

SDK deprecation/sunset activated

Per the deprecated schedule announced last year, the release of iOS version 10.0.0 in February and this Android version 22.0.0 release activate the sunset period of earlier Android/iOS releases. Specifically:

  • Android Google Mobile Ads SDK version 20.x.x is officially deprecated, meaning that you will be asked to update to at least version 21.0.0 to receive full support from the Google Mobile Ads SDK developer forum.
  • Android versions 19.x.x and below, as well as iOS versions 7.x.x will sunset on June 30th, 2023, meaning that ad serving could be disrupted. See details below.

Updated definition of sunset

We remain committed to regularly disabling old SDK versions balanced with minimizing disruption to ad serving. Aligned with this goal, we are making some changes to the previously announced sunset definition for 2023:

  1. We previously communicated that the sunset notice period would be 2 months. For this 2023 sunset, the sunset date is June 30th, approximately 3 months notice.
  2. We will leverage the “Outdated” feature on the Google Play SDK Index, requiring you to move off a sunset SDK version for future releases of your Android apps. See Understanding issues with your app’s third-party SDK for more information.
  3. Starting June 30th, you may notice some disruptions in your ad serving. While we do not plan to stop ad serving for iOS version 7.x.x and Android versions 19.x.x and earlier at this time, we will regularly review usage of all sunset versions going forward to consider disabling ad serving. The oldest versions with lower usage and higher maintenance costs will be targeted first. Therefore, ad traffic from sunset SDKs versions will be at risk of receiving automatic no fill due to stopped ad serving going forward.

To avoid disruptions in ad serving, we highly recommend upgrading to a supported version as soon as possible so your users have a chance to update before June 30th, 2023.

Check if your apps are affected

To help you prepare for these changes, there are several ways you can check if your apps are affected:

  • Use the Ads Activity report and enable the “GMA SDK” dimension to see iOS app traffic running on iOS 7.x.x or earlier. Currently, only the Google Mobile Ads SDK for iOS is supported.
  • In Android Studio, check your build.gradle file for build warnings, which are thrown when compiling with Android SDK version 19.x.x or earlier.
  • Check your console logs for warning logs when making ad requests.

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

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!