Utiliser Codex pour transformer le forecast Google Ad Manager en décisions de campagne

Formuler le forecast comme une décision

Un rapport forecast n’est utile que s’il répond à une décision de campagne : peut-on vendre ce package, faut-il élargir le ciblage, ou manque-t-il de l’inventaire ?

Dans le reporting Google Ad Manager, les vues Future Sell-Through et inventory aident à estimer capacité et pression. Codex peut préparer la requête MCP, comparer des scénarios et expliquer le compromis sans modifier les objets de trafficking actifs.

• Énoncer la question commerciale avant de choisir les champs.
• Utiliser des dimensions stables comme date, ad unit, device category, country et inventory size quand disponible.
• Séparer le résultat forecast des actions de booking tant qu’un humain n’a pas confirmé le scénario.

Donner à Codex une checklist de champs

Codex ne doit pas deviner les champs reporting de mémoire. Demandez-lui d’inspecter d’abord la référence dimensions et metrics, puis de construire la requête MCP à partir de noms valides.

Prompt solide : "Vérifie les dimensions disponibles pour Future Sell-Through, puis construis une vue forecast par ad unit, date et device category. Retourne capacité disponible, pression sell-through et principales contraintes."

• Utiliser get_report_dimensions pour éviter les noms de dimensions invalides.
• Utiliser get_report_metrics avant d’ajouter des metrics de capacité ou sell-through.
• Demander à Codex d’afficher la liste finale des champs avant de lancer un rapport coûteux.

Comparer des scénarios plutôt qu’un rapport statique

Le forecast devient opérationnel quand Codex compare deux ou trois scénarios : ciblage large, ciblage country restreint et package ad unit premium, par exemple.

Le résultat doit être un tableau avec capacité, niveau de risque et recommandation. Si le signal est faible ou si les dimensions sont trop larges, Codex doit le dire plutôt que surinterpréter une donnée bruitée.

• Comparer les scénarios sur la même plage de dates.
• Garder les dimensions constantes pour que les écarts viennent du scénario, pas de la forme de requête.
• Archiver le report ID et le prompt pour reproduire le forecast avant booking.