Guide de Prévision d'Inventaire Google Ad Manager : Prévoir, Simuler et Gérer l'Overbooking

Pourquoi la prévision (Forecasting) est-elle cruciale ?

La gestion d'un serveur publicitaire comme Google Ad Manager implique de vendre des volumes d'impressions futurs. Sans un système de prévision fiable, un éditeur s'expose à deux risques majeurs :

• Le sous-booking (Under-booking) : perdre du chiffre d'affaires potentiel en n'exploitant pas tout l'inventaire disponible par excès de prudence.
• Le surbooking (Over-booking) : s'engager sur des volumes de diffusion que l'inventaire ne pourra pas honorer, provoquant des ruptures de campagne, des pénalités financières et une surcharge opérationnelle de recalibrage.

Comment fonctionne le forecasting avec le LLM ?

OrbiAds intègre le protocole MCP (Model Context Protocol), ce qui permet à notre assistant IA (LLM) de communiquer en temps réel avec le ForecastService de Google Ad Manager. L'IA peut automatiquement interroger et analyser l'état de votre inventaire publicitaire.

En langage naturel, vous pouvez poser des questions telles que :

« Est-ce que j'ai assez d'impressions disponibles pour diffuser 500 000 impressions au format 300x250 sur mon site en décembre ? »
« Simule une baisse de volume si j'ajoute un ciblage géographique sur la France et la Belgique sur ce Line Item. »

Ce que l'IA (LLM) interroge et vous retourne

L'assistant IA appelle en arrière-plan des outils spécialisés du serveur MCP :

• get_inventory_forecast : pour récupérer les impressions estimées disponibles pour un ciblage donné avant la création de toute ressource.
• get_standalone_forecast : pour simuler un forecast complexe sans modifier de campagnes existantes.
• get_delivery_forecast_by_line_item : pour projeter la livraison future d'un Line Item déjà actif.
• get_prospective_delivery_forecast : pour simuler l'impact d'un changement de ciblage hypothétique sur un Line Item existant.

Le LLM analyse ces données brutes et vous retourne :

1. Impressions estimées (Matched / Available / Possible) :
   • Matched : impressions totales correspondant au ciblage.
   • Available : impressions libres et réservables (non réservées par d'autres campagnes prioritaires).
   • Possible : impressions totales cumulées si aucun autre Line Item concurrent n'était diffusé.
2. Analyse de la contrainte (Ciblage pénalisant) : Si vous demandez à l'IA d'analyser une pénurie d'inventaire, elle utilise les données de targetingCriteriaBreakdowns pour isoler précisément le critère (ex: un couple clé-valeur trop restrictif ou une zone géographique trop petite) qui bloque la diffusion.
3. Scénarios alternatifs : L'IA peut analyser des formats équivalents en clics ou en impressions visibles (Active View) à l'aide du champ alternativeUnitTypeForecasts de l'API GAM.

L'importance de passer les bonnes dimensions et priorités

L'API de prévision de Google Ad Manager est extrêmement sensible aux paramètres d'entrée. Une simulation approximative mènera à un échec de livraison. Vous devez veiller à spécifier :

• Les dimensions exactes (ex: 300x250, 728x90) : Un forecast sans dimension ou avec une mauvaise dimension sous-estimera dramatiquement l'inventaire ou provoquera des erreurs, car GAM filtre les opportunités par taille de tag publicitaire.
• La priorité (Priority) et le type de Line Item : La prévision de GAM prend en compte la hiérarchie de diffusion. Une campagne de type Sponsorship (Priorité 4) préemptera les campagnes de type Standard (Priorité 8). L'assistant IA a besoin de connaître le type précis pour simuler correctement les conflits de livraison et l'impact sur le reste du réseau.
• Les limites de fréquence (Frequency Caps) : Les règles de répétition limitent l'inventaire réel exploitable par utilisateur. Les oublier dans le forecast surévalue la capacité de livraison.

Améliorer son flux de travail : Tester plusieurs scénarios

Dans l'interface classique de Google Ad Manager, tester plusieurs scénarios de ciblage est fastidieux : il faut dupliquer manuellement des Line Items, modifier les critères, cliquer sur « Check Inventory », enregistrer les résultats, puis nettoyer les entités de brouillon créées.

Avec OrbiAds et le LLM, le flux est rationalisé :

Que se passe-t-il lors d'un booking en surbooking ?

Une question récurrente des trafickers concerne le comportement du système lorsque l'inventaire est saturé et qu'on tente de valider la réservation d'un Line Item.

1. Comportement par défaut de GAM

Si vous tentez de réserver un Line Item dont l'objectif dépasse les impressions disponibles calculées par le forecast, l'API GAM renvoie un message d'erreur bloquant (ex: INVENTORY_NOT_AVAILABLE). La transaction échoue immédiatement, interrompant le déploiement de la campagne.

2. La gestion intelligente avec OrbiAds (allowOverbook)

Pour éviter ces blocages bloquants lors de campagnes stratégiques à forcer absolument, OrbiAds intègre le paramètre allowOverbook :

• Le paramètre allow_overbook (à false par défaut) se passe directement à l'outil MCP/CLI de création de line items.
• Avec allow_overbook: true, l'autorisation est transmise à GAM lors de la création des line items.
• La prévisualisation dry-run signale explicitement l'état avant toute confirmation : ⚠ Overbooking : Autorisé.
• Au moment de l'appel SOAP de création des Line Items dans GAM, le paramètre "allowOverbook": True est envoyé. GAM accepte alors de forcer la création sans lever d'erreur.
• Enfin, l'événement SSE (Server-Sent Events) de création affiche un indicateur dans vos logs :

  Line Item 1/3 created — lineItemId=87654321 (150 000 imp.) (⚠ overbooked)

Ce flux garantit que le forçage est un choix **délibéré et tracé** du Trafficker dès la phase de configuration, évitant les interruptions inattendues lors de la livraison.

3. Subtilités techniques et limites (Ciblage & Non-persistance)

L'implémentation de l'overbooking dans Google Ad Manager présente plusieurs particularités importantes pour les développeurs :

• Non-persistance du flag : Le paramètre allowOverbook n'est pas persistant sur le Line Item dans GAM. Il s'agit d'une instruction transactionnelle envoyée uniquement lors de la création ou de la mise à jour pour bypasser le blocage de l'API. Si vous relisez l'objet plus tard, ce champ n'existe plus.
• Conflit de ciblage créatif : Si le Line Item de proposition d'origine n'autorise pas la surréservation, l'application d'un ciblage au niveau des créatifs (creative-level targeting) provoquant un surbooking retournera l'erreur stricte CANNOT_OVERBOOK_WITH_CREATIVE_TARGETING.
• Couplage de ciblage complexe : Lors de ciblages croisés complexes (combinaison de critères géographiques et de clés-valeurs dynamiques), GAM peut rejeter le forçage si les formats de taille ou les répartitions de buts (Impression Goals) sont structurellement incohérents. Effectuer une prévalidation via get_inventory_forecast reste indispensable.