Google Mobile Ads — qu’est-ce que c’est, SDK publicitaire et monétisation

Qu’est-ce que Google Mobile Ads ?

Google Mobile Ads — est la plateforme publicitaire de Google pour les applications mobiles, fournissant un SDK pour l’affichage de publicités et des outils d’analyse des revenus. La plateforme comprend deux systèmes principaux : AdMob (pour les développeurs indépendants) et Google Ad Manager (pour les grands éditeurs avec des campagnes publicitaires directes). Les deux systèmes utilisent le même SDK Google Mobile Ads, ce qui simplifie la migration entre les plateformes.

Le fonctionnement de Google Mobile Ads repose sur les enchères en temps réel (RTB — Real-Time Bidding). Lorsqu’une application demande l’affichage d’une publicité, le SDK envoie une requête aux serveurs Google, où des algorithmes analysent le profil de l’utilisateur, le contexte de l’application et les campagnes publicitaires disponibles. Le gagnant de l’enchère est déterminé en 100 à 300 millisecondes — plus l’enchère de l’annonceur est élevée, plus le revenu du développeur est important. Selon Google (2025), l’eCPM moyen pour les applications Android est de $5 à 15.

eCPM (effective Cost Per Mille) — l’indicateur clé de monétisation, montrant le revenu pour 1000 impressions. L’eCPM dépend de la région de l’utilisateur (plus élevé aux États-Unis et en Europe, plus faible en Asie), du format publicitaire (la vidéo récompensée donne un eCPM de $10 à 30, les bannières $0.50 à 2) et de la période de l’année (en décembre, l’eCPM est 30 à 50% plus élevé). Le SDK Google Mobile Ads optimise automatiquement les impressions pour un eCPM maximal via les enchères.

Formats publicitaires : bannières, interstitiels, récompensées et natives

Bannières publicitaires — blocs rectangulaires de taille fixe (320x50 — standard, 320x100 — grand, 300x250 — moyenne). Les bannières sont placées en bas ou en haut de l’écran et prennent un minimum de place. Inconvénients : faible eCPM ($0.50-2) et accoutumance des utilisateurs — le taux de clics (CTR) des bannières est de 0.05 à 0.5%. Les bannières sont automatiquement actualisées toutes les 30 à 60 secondes, mais Google recommande de ne pas les actualiser plus souvent que toutes les 60 secondes pour préserver l’expérience utilisateur.

Interstitiel (publicité interstitielle) — publicité en plein écran, affichée lors des pauses naturelles de l’application (entre les niveaux de jeu, lors du changement d’écran). L’interstitiel donne un eCPM de $3 à 15, mais nécessite un placement prudent — des affichages fréquents irritent les utilisateurs. Google limite la fréquence : pas plus d’un interstitiel par minute. Selon Google, avec un placement approprié, l’interstitiel ne réduit pas la rétention des utilisateurs de plus de 5%.

Récompensée (publicité avec récompense) — vidéo pour laquelle l’utilisateur reçoit un bonus (vies supplémentaires, pièces, accès premium). Le format le plus coûteux avec un eCPM de $10 à 30 et un fort engagement utilisateur — 80% des utilisateurs acceptent de regarder une vidéo récompensée. Important : la récompense doit être significative pour l’utilisateur, sinon il ne regardera pas la publicité. Rewarded interstitial — format hybride (récompense sans visionnage obligatoire), disponible depuis le SDK 21.0.0.

// Charger et afficher RewardedAd
class RewardedAdManager {

    private var rewardedAd: RewardedAd? = null

    fun loadAd(context: Context) {
        RewardedAd.load(
            context,
            "ca-app-pub-3940256099942544/5224354917",
            AdRequest.Builder().build(),
            object : RewardedAdLoadCallback() {
                override fun onAdLoaded(ad: RewardedAd) {
                    rewardedAd = ad
                }
                override fun onAdFailedToLoad(
                    error: LoadAdError
                ) {
                    Log.d("AdMob", error.message)
                }
            }
        )
    }
}

App Open Ads : publicité au lancement de l’application

Annonces natives — publicités visuellement adaptées au design de l’application : le développeur contrôle l’emplacement du titre, de la description, de l’image et du bouton d’appel à l’action. Les annonces natives offrent le CTR le plus élevé (0.5-2%) parmi tous les formats et s’intègrent le mieux dans l’UX de l’application. Le SDK Google Mobile Ads fournit des modèles d’annonces natives (NativeTemplate) ou un contrôle complet via NativeAdOptions. Le format ad_source_type indique de quel réseau provient le créatif natif.

AdMob ou Ad Manager : que choisir

AdMob — la plateforme publicitaire de Google pour les applications mobiles, conçue pour les développeurs indépendants et les petits studios. AdMob propose le remplissage automatique des emplacements publicitaires via les enchères, une configuration simple via l’interface web et une médiation intégrée avec plus de 30 réseaux publicitaires. Seuil de retrait : 100 $. AdMob convient à 90% des développeurs, y compris les studios moyens avec des revenus allant jusqu’à 100 000 $ par mois.

Google Ad Manager — plateforme avancée pour les grands éditeurs avec leurs propres campagnes publicitaires (direct deals), garanties programmatiques et priorisation des sources. Ad Manager prend en charge plusieurs serveurs publicitaires, les enchères concurrentielles (App Bidding) et des analyses détaillées pour chaque annonceur. La connexion d’Ad Manager nécessite un trafic mensuel d’au moins 5 millions d’impressions. Selon Google, Ad Manager augmente les revenus des grands éditeurs de 15 à 30% par rapport à AdMob.

Pour migrer d’AdMob vers Ad Manager, il suffit de changer l’ID de l’unité publicitaire dans le code de l’application — le SDK reste le même (Google Mobile Ads SDK). Google recommande de commencer avec AdMob et d’envisager de passer à Ad Manager lorsque les revenus mensuels atteignent 10 000 $ ou plus. App Bidding — la technologie clé d’Ad Manager, permettant à tous les réseaux publicitaires de concourir dans une seule enchère, ce qui augmente l’eCPM de 10 à 40%.

Médiation : connexion de plusieurs réseaux publicitaires

Médiation (Ad Mediation) — technologie de Google Mobile Ads qui permet de connecter plusieurs réseaux publicitaires à une seule unité publicitaire. Lorsque le SDK demande une publicité, il interroge séquentiellement les réseaux : d’abord Google Ads, puis les réseaux partenaires (Facebook Audience Network, Unity Ads, AppLovin, IronSource, Mintegral et autres), en sélectionnant le réseau avec l’enchère la plus élevée pour cet utilisateur.

Le SDK Google Mobile Ads prend en charge la médiation de plus de 30 réseaux publicitaires via des adaptateurs, qui sont chargés comme des dépendances Gradle séparées. Chaque adaptateur implémente une interface Google unifiée, permettant au SDK de fonctionner de manière uniforme avec n’importe quel réseau. Selon Google, la médiation augmente les revenus publicitaires totaux de 15 à 50% par rapport à l’utilisation d’AdMob seul. App Bidding — version plus avancée de la médiation, où tous les réseaux participent à une seule enchère simultanément, et non séquentiellement.

// Configuration de la médiation (build.gradle)
dependencies {
    implementation "com.google.android.gms:play-services-ads:23.3.0"
    // Adaptateurs pour la médiation
    implementation "com.google.ads:mediation-facebook:6.17.0.0"
    implementation "com.google.ads:mediation-unity:4.10.0.0"
    implementation "com.google.ads:mediation-applovin:12.3.0.0"
}

// Initialiser le SDK Mobile Ads
MobileAds.initialize(this) {
    Log.d("AdMob",
        "Initialized: $it")
}

App Bidding : enchère parallèle

Point important : la médiation augmente la latence d’affichage des publicités, car le SDK interroge plusieurs réseaux séquentiellement. Pour les bannières, ce n’est pas critique (délai acceptable jusqu’à 2 secondes), mais pour les interstitiels et les récompensées, un délai de plus d’une seconde réduit la probabilité d’affichage (l’utilisateur peut quitter l’écran). Google recommande d’utiliser App Bidding au lieu de la médiation séquentielle pour minimiser les latences. App Bidding traite toutes les enchères en parallèle en 100 à 200 ms.

Configuration de Google Mobile Ads dans un projet Android

La configuration de Google Mobile Ads dans une application Android commence par l’ajout de la dépendance play-services-ads dans build.gradle et l’initialisation du SDK dans la classe Application. Le SDK Google Mobile Ads nécessite Android 5.0 (API 21) et Google Play Services version 21.0.0 ou supérieure. Il est recommandé d’initialiser le SDK le plus tôt possible — dans Application.onCreate() — afin que la publicité se charge en parallèle du démarrage de l’application.

Après l’initialisation du SDK, le développeur crée une unité publicitaire dans l’interface web AdMob ou Ad Manager et intègre AdView dans la disposition de l’application (pour les bannières) ou charge InterstitialAd/RewardedAd par programmation. Important : utilisez un ID d’unité publicitaire de test pendant le développement et un ID de production après la publication. Le SDK Google Mobile Ads détecte automatiquement le mode test selon l’appareil ajouté aux appareils de test dans la console AdMob.

// Initialiser le SDK dans la classe Application
class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        MobileAds.initialize(this)

        // Activer le mode de consentement GDPR
        val params = RequestConfiguration.Builder()
            .setTagForUnderAgeOfConsent(false)
            .build()
        MobileAds.setRequestConfiguration(params)
    }
}

// Bannière inline en XML
// <com.google.android.gms.ads.AdView
//     android:id="@+id/adView"
//     android:layout_width="match_parent"
//     android:layout_height="wrap_content"
//     app:adUnitId="ca-app-pub-3940256099942544/6300978111"
//     app:adSize="BANNER" />

Après la configuration du SDK et des unités publicitaires, le développeur doit ajouter une politique de confidentialité dans l’application — c’est une condition obligatoire de Google pour la publication sur le Play Store. L’intégration du SDK UMP (User Messaging Platform) est également nécessaire pour recueillir le consentement au traitement des données des utilisateurs de l’EEE et du Royaume-Uni. Sans le SDK UMP, Google peut limiter l’affichage des publicités personnalisées, ce qui réduira l’eCPM de 40 à 60%.

Confidentialité des utilisateurs et GDPR

Google Mobile Ads exige le respect des règles de confidentialité pour les utilisateurs de l’Espace économique européen (EEE), du Royaume-Uni, des États-Unis (CCPA/CPRA) et d’autres régions ayant des lois sur les données. L’outil principal est le SDK User Messaging Platform (UMP), qui affiche à l’utilisateur une boîte de dialogue de consentement pour la collecte et le traitement des données à des fins de personnalisation des publicités.

Sans le consentement de l’utilisateur à la personnalisation, le SDK Google Mobile Ads n’affichera que des publicités non personnalisées, ce qui réduit l’eCPM de 40 à 60%. TCF v2.0 (Transparency & Consent Framework) — la norme d’IAB Europe pour la transmission des signaux de consentement entre les systèmes publicitaires. Google Ad Manager prend en charge TCF v2.0 automatiquement. Pour AdMob, une intégration via le SDK UMP avec le paramètre FORMS_PUBLISHER_ID est nécessaire.

// Demande de consentement utilisateur SDK UMP
val consentInfo = UserMessagingPlatform.getConsentInformation(this)

consentInfo.requestConsentInfoUpdate(
    context,
    ConsentRequestParameters.Builder()
        .setTagForUnderAgeOfConsent(false)
        .build()
) { error ->
    if (error != null) return@requestConsentInfoUpdate

    if (consentInfo.isConsentFormAvailable()) {
        UserMessagingPlatform.loadAndShowConsentFormIfRequired(
            activity,
            activity.getOnConsentFormSuccess(),
            activity.getOnConsentFormFailure()
        )
    }
}

TCF v2.0 et conformité GDPR

Exigences supplémentaires : pour les utilisateurs de Californie (CCPA), Google exige la prise en charge de l’option « Do Not Sell My Personal Information ». Pour les enfants (COPPA) — activation de tagForChildDirectedTreatment. Google Play Store exige que toutes les applications avec publicité aient une politique de confidentialité et un lien vers celle-ci dans la Google Play Console. La violation de ces exigences entraîne le blocage de l’affichage des publicités ou le retrait de l’application du Play Store.

Exemple de code : affichage d’une vidéo récompensée en Kotlin

Exemple complet d’intégration de publicité récompensée avec gestion de la récompense utilisateur. L’application charge une vidéo récompensée au démarrage, l’affiche lors du clic sur le bouton « Obtenir un bonus » et attribue des pièces à l’utilisateur après un visionnage complet. Le code utilise des coroutines pour le chargement asynchrone et vérifie que la publicité n’est pas affichée si l’utilisateur a déjà reçu une récompense (protection contre la double récompense).

class RewardViewModel : ViewModel() {

    private var rewardedAd: RewardedAd? = null
    private val _rewardEarned = MutableLiveData<Boolean>(false)
    val rewardEarned: LiveData<Boolean> = _rewardEarned

    fun loadRewardedAd(context: Context) {
        RewardedAd.load(context, AD_UNIT_ID,
            AdRequest.Builder().build(),
            object : RewardedAdLoadCallback() {
                override fun onAdLoaded(ad: RewardedAd) {
                    rewardedAd = ad
                }
            }
        )
    }

    fun showAd(activity: Activity) {
        rewardedAd?.show(activity, {
            // L’utilisateur a reçu la récompense
            _rewardEarned.postValue(true)
            addCoins(100)
            loadRewardedAd(activity) // Preload next
        })
    }
}

Bonnes pratiques pour les publicités récompensées : préchargez la publicité suivante immédiatement après la fermeture de la publicité actuelle (l’utilisateur n’attend pas le chargement). Affichez les vidéos récompensées uniquement dans un contexte où la récompense est évidente (par exemple, le bouton « Regarder une publicité pour 100 pièces »). Google interdit d’afficher des publicités récompensées sans demande explicite de l’utilisateur (l’autoplay est interdit). Vérifiez le rappel onUserEarnedReward — ce n’est qu’après celui-ci que vous devez attribuer la récompense.

Conseils d’optimisation des revenus publicitaires

L’optimisation des revenus de Google Mobile Ads commence par le bon choix des formats publicitaires. La combinaison de bannières (pour un revenu de fond constant) et de vidéos récompensées (pour une interaction active) donne le revenu total maximal. Utilisez les interstitiels uniquement dans les pauses naturelles — pas plus de 3 à 4 fois par session. Google Analytics pour Firebase permet de suivre quels écrans génèrent le plus de revenus et où les utilisateurs ferment le plus souvent les publicités.

Le deuxième facteur important est la médiation. Connectez 3 à 5 réseaux publicitaires via la médiation AdMob. Selon Google, les applications avec médiation gagnent 30% de plus. App Bidding (disponible pour Ad Manager et partiellement pour AdMob) offre un gain supplémentaire de 10 à 40% grâce aux enchères simultanées. Tests A/B du placement des publicités : testez différentes positions de bannières (haut/bas, gauche/droite) et la fréquence des interstitiels sur différents segments d’utilisateurs.

Le troisième facteur est le ciblage géographique. L’eCPM aux États-Unis, au Canada et en Australie est 3 à 5 fois plus élevé qu’en Inde ou en Indonésie. Si votre application est populaire dans des régions à faible eCPM, Google recommande d’utiliser la médiation en cascade avec des réseaux de ces régions (par exemple, InMobi pour l’Inde). Configurez une limite de fréquence : pas plus d’un interstitiel toutes les 2 minutes et pas plus de 5 vidéos récompensées par heure — cela réduit la lassitude publicitaire des utilisateurs.