Google Ad Manager : guide éditeur complet

Comment diffuser les publicités des autres sur votre propre site, et pourquoi c’est un monde complètement différent de Google Ads.

1. Les trois noms que tout le monde confond

Google a trois produits aux noms presque identiques, et les mélanger envoie des projets entiers dans le mur :

Produit	Qui l’utilise	Ce qu’il fait
Google Ads	Annonceurs (buy side)	Vous achetez de l’espace publicitaire pour promouvoir votre propre activité sur Google Search, YouTube et les sites partenaires.
Compte Google Ads Manager (MCC)	Agences et freelances (buy side)	Un identifiant parapluie au-dessus de Google Ads. Il ne lance aucune campagne : il permet à une agence de gérer de nombreux comptes clients depuis un seul tableau de bord (jusqu’à 85 000 comptes liés, voir l’aide Google Ads).
Google Ad Manager (GAM)	Éditeurs (sell side)	Vous vendez de l’espace publicitaire. C’est un ad server : il décide en temps réel quelle création d’annonceur s’affiche dans chaque emplacement de votre site.

Cet article parle du troisième : Google Ad Manager, la plateforme quand les publicités de votre site ne sont pas les vôtres. Vous possédez le rayonnage, les annonceurs le louent. Le changement de réflexe est le suivant : dans Google Ads, on pense campagnes, mots-clés et enchères pour gagner l’audience des autres. Dans GAM, on pense inventaire, commandes et priorités pour arbitrer entre des annonceurs qui se disputent votre audience.

2. Ce qu’est vraiment Google Ad Manager

Imaginez un panneau d’affichage numérique dans une gare, où quelqu’un décide, à la seconde où vous le regardez, quelle affiche montrer. GAM est cet ad server : à chaque chargement d’une page avec un emplacement vide, la page demande « que dois-je afficher ? », et GAM répond avec la création gagnante, ou une réponse vide (no-fill). Deux moitiés font le système : GAM côté serveur (inventaire, campagnes, logique de décision) et GPT (Google Publisher Tag, gpt.js) côté site, qui décrit chaque emplacement, appelle GAM et injecte la création dans le bon <div>. Sans GPT déployé, une page génère zéro requête : des audits trouvent régulièrement des sites à 0 impression pendant un trimestre parce que le tag n’a jamais été publié en production.

3. Les briques de base (modèle d’inventaire)

Un network (votre compte, identifié par un network code) contient des ad units, les emplacements vendables, avec un chemin du type /NETWORK_CODE/UNIT_NAME : ce chemin est la clé, la page et le serveur doivent le prononcer à l’identique. Des orders (un par deal d’annonceur) contiennent des line items qui disent où, quoi, quand et avec quelle priorité diffuser, et portent des créations. Les key-values sont des étiquettes que la page ajoute à sa requête pour cibler ou exclure finement.

4. La vie d’une requête publicitaire

C’est l’aller-retour que vous devez savoir rejouer de tête pour déboguer :

La page charge gpt.js, puis defineSlot('/NETWORK/UNIT', [[728,90]], 'div-id') avec ses options (SRA, consentement, lazy load).
display('div-id') ou refresh() déclenche l’appel HTTP vers securepubads.g.doubleclick.net/gampad/ads.
GAM associe les line items éligibles et choisit un gagnant : création injectée, ou no-fill et <div> replié.

La règle d’or : GAM et GPT doivent prononcer exactement le même chemin d’ad unit. Si la page demande une adresse que GAM ne connaît pas (faute de frappe, mauvais chemin), GAM ne trouve personne et renvoie vide. La pub échoue non parce que la campagne est mal configurée, mais parce que la question était mal posée. À l’inverse, une réponse vide avec un chemin parfaitement correct signale un blocage du matching côté serveur (order expiré, taille incompatible, ciblage, site non vérifié…).

5. Comment GAM décide : types de line items et priorités

C’est là que GAM diffère le plus de Google Ads. Dans Google Ads, une enchère décide de tout. Dans GAM, vous fixez des priorités qui ordonnent vos line items, et l’allocation dynamique laisse l’enchère gagner une impression quand elle paie plus que le « coût d’opportunité » d’une ligne garantie, sans que cette ligne sous-livre. Un 100 % Sponsorship bloque totalement l’enchère.

Type de line item	Priorité (par défaut)	Usage typique
Sponsorship	4	« L’annonceur X possède 100 % de l’emplacement sur la période » : parts de voix, roadblocks, habillages de homepage
Standard	6 / 8 / 10	Campagnes garanties classiques : N impressions entre deux dates, rythme géré par GAM
Price Priority	12	Non garanti : concourt au CPM contre la demande résiduelle et l’enchère
AdSense / Ad Exchange	12 (concourt par allocation dynamique)	L’enchère programmatique se dispute ce que la vente directe ne prend pas

Plus le nombre est bas, plus la priorité est haute : une ligne Sponsorship (4) passe avant une ligne Standard (8), et l’enchère ne prend une impression à une ligne garantie que si elle paie plus que son coût d’opportunité (sources : types de line items et priorités, allocation dynamique). C’est tout l’intérêt de GAM : permettre à une équipe commerciale de promettre « votre bannière sera en homepage tout le mois de mars » et de le garantir contre l’enchère ouverte.

6. Tarification : floors et Unified Pricing Rules

Les priorités décident qui diffuse, la tarification décide si l’impression vaut d’être diffusée. Un price floor est le CPM minimum accepté. Trop bas, vous vendez votre meilleur inventaire au prix du résiduel ; trop haut, l’impression reste invendue et un no-fill rapporte exactement zéro. Depuis que l’exchange de Google est passé à une enchère unifiée au premier prix, les floors sont devenus votre principal levier de prix.

Les Unified Pricing Rules (UPR) sont l’endroit où vivent les floors : des règles centrales appliquées à la demande non garantie (Ad Exchange, Open Bidding, backfill AdSense, line items résiduels, pas House ; Unified pricing rules). Chaque règle peut être ciblée par ad unit ou placement, format et taille, appareil, géographie, acheteur ou deal. L’erreur à éviter est un floor unique pour tout le site : votre rubrique la plus lue et votre page 404 ne valent pas la même chose. Gardez au moins un segment en floor manuel comme groupe témoin face à l’optimisation automatique, et revoyez vos floors à date fixe : la demande est saisonnière, pas vos réglages.

7. Configuration, de bout en bout

Network (Admin → Global settings) : notez le network code, réglez fuseau horaire et devise, invitez les utilisateurs avec les bons rôles.
Ad units : un par modèle d’emplacement, nommage hiérarchique clair (NEWS_HOME_TOP_BANNER), tailles IAB standard (300×250, 728×90, 970×250, 320×50, 300×600). Les tailles maison exotiques attirent peu ou pas de demande programmatique.
Sites (Inventory → Sites) : déclarez et vérifiez chaque domaine. Un site non vérifié affiche « Needs attention » (statut des sites).
ads.txt : publiez https://yourdomain.com/ads.txt avec vos vendeurs autorisés (Google : « not mandatory, but is highly recommended », guide ads.txt). Un ads.txt sans votre ID vendeur Google dit aux acheteurs que Google n’est pas autorisé.
Tags : gpt.js dans le <head>, defineSlot et un <div> par emplacement, un display() par emplacement, déployés sur les vrais templates de production (en dur ou via GTM : un tag non publié, c’est zéro requête pour toujours). Ajoutez enableSingleRequest() (SRA, nécessaire aux roadblocks), collapseEmptyDivs(), le lazy loading des emplacements sous la ligne de flottaison et des key-values via setTargeting().
Consentement : installez une CMP certifiée Google qui implémente IAB TCF v2.3 (exigences TCF de Google). Sans chaîne TCF, les requêtes passent en mode limité (npa=1, ltd=1), ce qui baisse les CPM et peut restreindre la diffusion en EEE. Configurez aussi Privacy & messaging → European regulations (rien n’y est configuré sur un network neuf), et faites porter la CMP par vos pages de test.
Trafficking : un order par deal, un line item (type, priorité, dates, objectif, ciblage), une création par taille réservée. Deux tueurs silencieux : la date de fin (un order expiré arrête tout instantanément) et les exclusions de key-values (inoffensives tant que la page n’envoie pas la clé, une bombe le jour où elle l’envoie).
Programmatique, le moment venu : backfill AdSense (une case par ad unit), Ad Exchange (accès sur approbation), header bidding (Prebid.js) ou Open Bidding. Fixez de vrais tarifs sur les line items directs : des deals saisis à 0 € donnent des rapports sans visibilité sur le revenu.

8. Direct contre programmatique, Open Bidding contre header bidding

En vente directe, votre équipe négocie un prix fixe pour de l’inventaire premium, avec garantie de diffusion et formats libres. En programmatique, une enchère automatisée fixe le prix par impression, sans garantie, avec des tailles IAB standard en pratique. Les éditeurs matures font les deux : le direct prend les emplacements premium, le programmatique monétise le reste.

	Header bidding (Prebid)	Open Bidding
Où tourne l’enchère	Dans le navigateur (ou votre wrapper serveur), avant l’appel GAM	Côté serveur, dans la stack de Google
Qui l’exploite	Vous	Google
Latence de page	Un délai mesurable à plafonner par un timeout	Minimale : un seul appel
Transparence	Vous voyez chaque réponse d’enchère	Vous voyez le résultat, pas la mécanique
Coût	Votre temps d’ingénierie	Une commission sur les transactions

Ne mettez jamais le même exchange dans les deux chemins : il enchérirait contre lui-même et vous paieriez la latence deux fois. La bonne question n’est pas « lequel paie plus ce mois-ci » mais « combien de temps d’ingénierie puis-je consacrer durablement à l’infrastructure publicitaire ? ».

9. Débogage : la boîte à outils qui marche

Google Publisher Console : ajoutez ?google_console=1 à l’URL (ou googletag.openConsole() ; voir Publisher Console). Elle affiche chaque emplacement, son chemin et son statut fill/no-fill, mais ne s’active que si la page charge déjà gpt.js : sur une page non taguée, l’absence de console est déjà un diagnostic.
L’onglet Network : trouvez la requête gampad/ads, lisez iu= (le chemin demandé) et les tailles. Un 200 OK au corps vide avec un iu correct désigne le matching côté serveur, pas le tag. npa=1 et ltd=1 signalent l’absence de consentement TCF valide.
Delivery Tools → Inspect webpage ads et Simulate request : le verdict officiel de Google sur pourquoi votre ligne ne sert pas ou a perdu (voir Delivery Tools).

Causes réelles de « les pubs ne s’affichent pas », à peu près par ordre de fréquence :

GPT jamais déployé en production : pas de gpt.js ni de gampad/ads dans Network. Méfiez-vous des bannières <img> statiques du CMS qui ressemblent à de la diffusion mais génèrent 0 impression GAM.
Order ou line item expiré : tout marchait hier, réponses vides aujourd’hui sur tous les domaines à la fois.
Site non vérifié, ou ads.txt avec un mauvais ID éditeur.
Chaîne de consentement cassée : pas de CMP/TCF, mode limité ltd=1, CPM écrasés.
Exclusion de key-value dormante qui s’active, ou page de test différente de la production.

10. Requête ≠ impression ≠ impression viewable

Trois chiffres utilisés indifféremment en réunion. Une ad request signifie que le navigateur a demandé une pub, pas qu’elle est revenue (pas de demande, floor trop haut ou ciblage non rempli finissent en no-fill). Une impression signifie qu’une création a commencé à s’afficher, pas que quelqu’un l’a vue : elle peut être 2 000 pixels sous la ligne de flottaison dans un onglet en arrière-plan. Une impression viewable a atteint le seuil MRC, pas forcément le regard de l’utilisateur. Le standard MRC exige au moins 50 % des pixels à l’écran pendant une seconde continue pour le display standard, deux secondes pour la vidéo, et 30 % des pixels pour les très grands formats (MRC).

« On fait 4 M d’impressions » n’a aucun sens tant que personne ne dit lequel des trois chiffres c’est. Et le lazy loading déplace les chiffres en sens opposés : bien réglé, il baisse les impressions brutes, monte la viewability et le revenu ; trop agressif, la pub arrive après le scroll et vous perdez sur les deux tableaux.

11. Pourquoi vos chiffres et ceux de l’annonceur ne collent jamais

Quand un annonceur dit avoir compté 12 % d’impressions de moins que vous n’avez facturé, personne ne ment : deux systèmes de mesure comptent à des points différents de la chaîne, avec leurs propres filtres anti-fraude, leurs fuseaux horaires, leurs pertes de latence et d’abandon, et chaque redirection ou wrapper peut perdre le beacon. L’aide de Google indique que des écarts jusqu’à 20 % sont courants avec un ad server tiers (discrepancies) ; beaucoup de contrats tolèrent 10 %. Au-delà, cherchez une cause précise : tag dupliqué, lazy loading qui demande des pubs jamais atteintes, chaîne de redirections qui casse le compteur, consentement qui bloque le pixel de l’acheteur mais pas votre ad server. La seule solution durable est contractuelle : nommez une source de vérité pour la facturation avant la campagne, et écrivez l’écart toléré.

12. KPI, reporting et GAM 360

Les annonceurs optimisent le coût d’acquisition (CPC, CPA, ROAS), les éditeurs optimisent le yield : ad server impressions, eCPM, fill rate, viewability, delivery/pacing des lignes garanties et répartition programmatique/direct. Côté reporting, le Query Tool répond à « combien » (rapports agrégés planifiables, accessibles par API). Data Transfer répond à « pourquoi » : des fichiers bruts au niveau événement vers un stockage cloud (option payante, voir Data Transfer), qui permettent de réconcilier avec GA4, d’expliquer un écart événement par événement et de reconstruire un funnel dans BigQuery. Les données agrégées vous laissent observer un problème, seules les données événementielles vous laissent l’expliquer.

L’offre gratuite de GAM en fait bien plus qu’on ne l’imagine (inventaire, vente directe, cascade complète de priorités, programmatique de base) et suffit à un éditeur de taille moyenne. Les limites de GAM 360 portent sur le volume (un plafond mensuel d’impressions que Google révise : vérifiez le chiffre actuel), les fonctionnalités avancées et les données. Le vrai déclencheur n’est presque jamais le trafic : c’est le jour où vous ne pouvez plus expliquer vos propres chiffres. Tant que vous vendez du volume, la version gratuite suffit ; le jour où vous vendez de la performance, il faut pouvoir la prouver.

13. En résumé

Google Ads dépense de l’argent pour placer vos pubs chez les autres. Google Ad Manager en gagne en orchestrant les pubs des autres chez vous : un cerveau côté serveur et une bouche sur la page (GPT) qui doivent prononcer les mêmes chemins d’ad unit. Son super-pouvoir est le système de priorités ; sa fragilité, les pannes silencieuses (tag non publié, order expiré, domaine non vérifié, consentement manquant) qui donnent toutes un emplacement vide.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : Google Ad Manager: The Complete Publisher’s Guide (and How It Differs from Google Ads).

Google Ad Manager : le guide complet de l’éditeur (et ses différences avec Google Ads)