Comment Google Ads lit le site, relie les pages aux requêtes, génère les créations et prépare l'enchère.
Nous avons analysé le code de l’application Google Ads et le fonctionnement de son interface web. Nous avons ensuite comparé nos observations à la documentation publique de Google et aux pièces du procès antitrust.
L’étude éclaire la façon dont Google Ads utilise l’IA : 88 types de scores pour évaluer les annonces, des requêtes liées aux pages via NavBoost et QBST, et des contenus de site préparés pour les modèles de langage. Elle aide à comprendre ce qui se passe entre votre landing page et l’annonce diffusée.
Une campagne Search relie une requête, un mot-clé, une annonce et une landing page. L’analyse du code de Google Ads révèle les nombreuses étapes qui permettent de les associer.
Google Ads récupère les pages et en extrait les titres, les textes, les images et les données structurées. Il prépare ces informations pour l’IA, les rapproche de celles de l’entreprise et des requêtes, puis s’en sert pour créer, vérifier et sélectionner des assets.
La landing page joue depuis longtemps un rôle dans les Dynamic Search Ads, le ciblage sans mots-clés et l’expérience après le clic. Cette étude détaille les fonctions prévues dans le code : stocker le contenu des pages, le préparer pour l’IA, créer des annonces avec AI Max et vérifier que leurs promesses sont justifiées par le site. Elle montre aussi des assistants capables de préparer des modifications de campagne.
Le calendrier explique le moment de cette étude. AI Max for Search est sorti de bêta le 15 avril 2026 et AI Brief a été annoncé le 30 avril. Depuis le 1er septembre, les campagnes qui utilisaient le broad match au niveau campagne ou la text customization héritée basculent d'office vers AI Max ; la fin des Dynamic Search Ads, d'abord prévue à la même date, est repoussée à février 2027. Ce que décrit ce texte devient le régime par défaut des campagnes Search.
Cette étude croise l’analyse de deux versions de l’application Android et de l’interface web avec la documentation Google, des brevets, des publications de recherche et les pièces du procès antitrust. Les noms techniques cités sont présents dans l’application ou l’interface web. Les liens entre les fonctions sont reconstitués à partir de ces observations et des sources publiques. Le code ne permet pas de connaître tous les réglages appliqués par Google ni les fonctions activées sur chaque compte. Les détails techniques sont accessibles dans les blocs « Voir les détails techniques » et dans l’annexe.
Google Ads récupère le contenu des pages et le prépare pour l’IA.
Le système relie site, Merchant Center, Business Profile, YouTube et profils sociaux.
Les pages, les requêtes et le brief servent à créer, évaluer et sélectionner les textes.
Les textes sont évalués sur leur pertinence, leur qualité et le respect des promesses du site.
Créer les annonces, les associer aux requêtes, calculer l’enchère et aider au pilotage.
Dans AI Overviews, elle doit correspondre à la requête et au contenu de la réponse générée.
Crawler les pages, récupérer leur contenu et le préparer pour les annonces.
Pour choisir une annonce, Google Ads a besoin de comprendre l’offre présentée sur la page. Le code de l’application prévoit plusieurs étapes : récupérer la page, vérifier qu’elle est accessible, enregistrer son contenu dans une base utilisée par Ads, puis le préparer pour l’IA.
Les textes, les vecteurs et les estimations, comme la probabilité de clic, sont produits sur les serveurs de Google. Les vecteurs représentent un contenu sous forme de nombres pour comparer son sens à celui d’autres contenus. L’application permet de voir les informations envoyées à Google, les résultats attendus et les vérifications prévues. Elle ne révèle pas le fonctionnement complet des modèles d’IA.
Plusieurs fonctions du code sont consacrées au crawl, à la mise à jour du contenu des pages et à la vérification des URL.
Google Ads peut récupérer le contenu d’une page, vérifier qu’il est utilisable et le mettre à jour. Le code prévoit aussi une base de contenus de landing pages, nommée LANDING_PAGE_REPOSITORY, et indique si une page est disponible pour créer des assets.
Le message ASSET_GENERATION_STATUS_URL_NOT_INDEXED signale qu’une page est absente de la base utilisée par Ads. Il ne renseigne pas sur sa présence dans les résultats naturels de Google. Une page peut donc être enregistrée dans l’un de ces systèmes sans l’être dans l’autre, même si les deux peuvent partager des données.
Google utilise des crawlers spécifiques pour vérifier la qualité des pages publicitaires. Ces bots ignorent la règle générique User-agent: * de robots.txt. Il faut les autoriser ou les bloquer explicitement sous les noms AdsBot-Google et AdsBot-Google-Mobile. Une page techniquement accessible à Googlebot peut donc échouer dans la chaîne Ads, et inversement.
Le code prévoit de récupérer séparément plusieurs parties de la page.
Google Ads distingue le titre, la description, les sections, les passages importants, les extraits de texte, les données structurées et les images. Chaque partie peut servir à une tâche différente.
Le titre et le nom de l’entreprise peuvent aider à identifier l’offre. Les phrases de la page et les assets existants peuvent servir à écrire une annonce. Des versions courtes des pages facilitent leur comparaison pour choisir une URL. Enfin, le système peut chercher le passage qui justifie une promesse de l’annonce : cette vérification s’appelle le grounding.
Les données structurées décrivent notamment l’entreprise, les produits, les catégories et leurs caractéristiques dans un format lisible par les systèmes. Le texte visible apporte les explications et les preuves. Les deux doivent rester cohérents : les données structurées ne remplacent pas le contenu de la page.
Le code prévoit plusieurs façons de préparer le contenu : combiner le nom de l’entreprise, le title, les balises meta, les listes de descriptions et les phrases de la page, puis raccourcir le texte. Google Ads dispose ainsi de plusieurs versions du contenu, à partir du même HTML.
Ces versions servent à retrouver une information, comparer des pages, donner des instructions à l’IA et vérifier les textes produits. Certaines utilisent le Markdown, un format de texte simple qui conserve les titres et les listes. L’objectif reste concret : comprendre l’offre, choisir la bonne page et écrire une annonce qui respecte son contenu.
Le code nomme les principales opérations de préparation et de vérification dans TransformationName_Enum.
Le système rassemble les informations de la page et d’autres sources, puis prépare les consignes données à l’IA. Il vérifie ensuite le texte produit et garde la trace des informations utilisées. La liste des opérations permet de reconstituer ce fonctionnement, sans établir à elle seule l’ordre exact de chaque étape.
Rassembler les informations sur l’entreprise et les rapprocher des recherches des internautes.
Les noms présents dans le code indiquent une fiche sur l’entreprise, distincte de ses pages web. Elle peut réunir son identité, son activité, sa description, les caractéristiques de sa marque et plusieurs sources de contenu.
L’IA s’appuie sur ce profil et sur sa connaissance des produits et de la marque pour évaluer ce que l’annonceur cherche à promouvoir.
Pour les équipes marketing, ces sources doivent raconter la même chose. Des catégories différentes, des descriptions contradictoires ou des offres incohérentes compliquent la création d’annonces et leur association aux bonnes requêtes.
Pour créer un asset, le système peut puiser dans plusieurs pages du site et dans d’autres sources. La liste AdAssistantAssetExtractionSourcePB_Enum distingue notamment les pages selon leur rôle.
La page d’accueil, les pages « À propos », « Contact » et « Pourquoi nous » sont nommées séparément dans le code : HOME_PAGE, ABOUT_PAGE, CONTACT_PAGE et WHY_PAGE. Elles peuvent donc fournir des informations pour créer les annonces, au même titre que la page produit qui reçoit le clic.
Le code suit séparément la disponibilité de chaque source pour les suggestions d’assets : landing page, assets récents, anciennes campagnes, banque d’images, réseaux sociaux, Merchant Center ou Business Profile. AssetAutomationSuggestionsStatus prévoit 17 indicateurs de suivi, dont smartGenaiAssetSuggestionStatus, derrière ce que l’interface présente comme une seule fonctionnalité.
Une page « À propos » peu précise, une page « Pourquoi nous » absente ou un profil social qui contredit le site donnent à Google moins d’informations utiles pour écrire vos annonces.
Le nom LP_GROUNDED indique que la requête ou le mot-clé est comparé au contenu de la landing page. Les réglages QuerySpec permettent de choisir la source des requêtes, leur nombre, la période analysée et un maximum par groupe d’annonces. Seule une partie de l’historique est donc retenue pour préparer les textes.
Les références aux requêtes similaires, aux synonymes, aux DSA et au broad match concernent la recherche de nouvelles requêtes pertinentes. SQM_ORGANIC_TRAFFIC désigne une variante utilisant des informations issues du trafic naturel. Le rapprochement des données payantes et organiques peut servir au reporting et aux suggestions ; il ne démontre pas qu’un score SEO entre dans le calcul d’Ad Rank.
QueryMatchSourcePB_Enum
Ce qui relie l’annonce à la requête
QueryMatchTypePB_Enum
Le type de correspondance utilisé
Le code distingue les correspondances liées au contexte de recherche, les variantes proches et celles associées à Performance Max. Les rapports conservent aussi l’origine de la correspondance : AI Max sans mots-clés ou AI Max en broad match. Un rapport dédié relie chaque terme de recherche à la landing page et au titre d’annonce diffusés.
BROAD_SESSION correspond à l'utilisation du contexte de session. NEAR_EXACT et NEAR_PHRASE décrivent les close variants. UBERVERSAL est associé à Performance Max. Le rapport des termes de recherche conserve lui aussi la provenance du match, avec les valeurs AI_MAX_KEYWORDLESS et AI_MAX_BROAD_MATCH du segment search_term_match_source, et la vue ai_max_search_term_ad_combination_view relie chaque terme à la landing page et au headline servis.
Les règles publiques de priorité donnent l'avantage à une campagne Search lorsqu'une requête est identique à un mot-clé éligible. Les Search Themes ont une priorité comparable aux mots-clés phrase et broad. Les systèmes keywordless d'AI Max, DSA et Performance Max couvrent les demandes restantes.
La documentation publique propose de mesurer si un Search Theme apporte du trafic que Performance Max n’aurait pas trouvé seul. SEARCH_SHADOW désigne vraisemblablement cette base de comparaison. Une hausse des conversions dans le rapport ne suffit donc pas : il faut vérifier si le thème apporte de nouvelles recherches ou récupère celles déjà couvertes.
Le code prévoit plusieurs versions des fonctions de coécriture Coauthor. Cinq fonctions apparaissent chacune sous trois formes : sans précision supplémentaire, avec NavBoost désactivé (NAVBOOST_DISABLED) et avec un filtrage des requêtes rares (K_ANON_NAVBOOST). Le tableau conserve leurs identifiants techniques.
| Fonction | Sans précision supplémentaire | NAVBOOST_DISABLED | K_ANON_NAVBOOST |
|---|---|---|---|
| keyword aware | 19 | 113 | 120 |
| query prefix EN | 41 | 109 | 116 |
| query prefix I18N | 42 | 110 | 117 |
| query prefix headline EN | 50 | 111 | 118 |
| query prefix headline I18N | 51 | 112 | 119 |
Ces noms apparaissent parmi les fonctions qui préparent les landing pages, les requêtes et les titres d’annonces. Ils indiquent que des requêtes liées à une page peuvent aider à rédiger les textes.
Le procès antitrust décrit NavBoost comme un système qui relie requêtes et documents à partir de données de clic mémorisées. Un brevet Google prioritaire en 2004 décrit le mouvement inverse : à partir d'un document, récupérer les requêtes ayant mené à des clics, puis les utiliser comme mots-clés ou matière créative. La variante K_ANON_NAVBOOST indique un filtrage destiné à conserver des comportements agrégés tout en écartant les requêtes trop rares.
QBST signifie Query Based Salient Terms. Il repère les mots et expressions importants dans les pages pertinentes pour une requête, avec aussi des données de clic. Les noms QBST_TEXT_ASSET_SUGGESTION et QBST_ADVERTISER_TEXT_ASSET, présents dans WorkflowAssetGenerationKeywordSourcePB_Enum, le désignent comme une source de termes pour créer des assets.
Ces éléments indiquent que les requêtes, le contenu des pages et les données de clic peuvent aider à créer les annonces. Ils ne montrent pas que les classements naturels et publicitaires sont fusionnés.
Le code permet de reconstituer les étapes entre la lecture de la page, la création des textes et leur sélection.
Les noms regroupés sous les identifiants 226 à 255 de SignalName_Enum évoquent la page, les rapports, la création de textes, leur évaluation, leur sélection et le brief. Le parcours ci-dessous en propose une lecture.
Les identifiants ADSAPI_SUPPORT_AI_BRIEF_FOR_TARGETING et ADSAPI_SUPPORT_PMAX_AI_BRIEF_FOR_TARGETING relient explicitement le brief au ciblage.
AI Max for Search est annoncé en bêta le 6 mai 2025 et sort de bêta le 15 avril 2026. Il regroupe trois fonctions.
Broad match et technologie keywordless fondée sur les mots-clés, les créations et les URL.
Headlines et descriptions produits à partir des textes existants, de la landing page et des signaux de requête.
Sélection d'une page adaptée à l'intention, puis ajustement des assets à son contenu.
La bascule est engagée. Depuis le 1er septembre 2026, les campagnes qui utilisaient les assets créés automatiquement (ACA) sont basculées d'office vers AI Max avec search term matching et text customization activés. Celles qui utilisaient le broad match au niveau campagne reçoivent uniquement le search term matching. Les campagnes DSA suivront à partir de février 2027, avec les trois fonctions et leurs contrôles d'URL conservés.
L’application prévoit des réglages AI Max au niveau de la campagne et du groupe d’annonces, ainsi que des inclusions et exclusions d’URL. Le rapport ai_max_search_term_ad_combination_view permet de relier un terme de recherche à la landing page et au titre d’annonce diffusés.
Une page difficile à trouver dans le site, mal reliée aux autres pages ou peu claire sur son offre est plus difficile à sélectionner. Une page de catégorie, de service ou de zone desservie bien structurée peut répondre plus précisément à une recherche qu’une page générique.
AI Brief, annoncé le 30 avril 2026, organise les consignes de l’annonceur en trois catégories : les messages (Messaging Guidelines), les requêtes à viser (Matching Guidelines) et les audiences (Audience Guidelines). Des noms présents dans le code font référence à ces mêmes usages.
Le brief donne des règles pour choisir les requêtes, rédiger les textes et sélectionner les annonces. Il complète les mots-clés, les exclusions, les objectifs d’enchère et les consignes de marque.
Les informations fournies à l’IA, les consignes et les contrôles comptent autant que le modèle choisi.
Le code permet de combiner le titre et la description de la page, les mots-clés, les assets existants, les informations sur l’entreprise et les requêtes. Il prévoit aussi des consignes de rédaction, des exemples et un format de réponse. Cet ensemble constitue une « recette » de création d’annonces.
LlmAssetGenerationConfig combine le titre et la description de page, les mots-clés, les assets existants, les informations business, le texte saillant et les requêtes. Chaque source possède ses minimums, maximums, séparateurs, préfixes et suffixes. LlmPromptSpec expose les instructions, les developer instructions, le contexte, l'entrée d'inférence, des exemples n-shot et les options de formatage.
Le code prévoit plusieurs systèmes pour faire fonctionner les modèles, avec des versions et des réglages différents. Ce choix peut répondre à des besoins de langue, de rapidité, de disponibilité ou de coût. Sax renvoie à Saxml, un logiciel publié par Google. Beyond, Evergreen, Servo, Steelmill et Uniserve restent des noms internes dont le rôle précis n’est pas documenté publiquement.
La liste AssetSelectionVersionPB_Enum contient 295 versions de méthodes de création et de sélection d’assets. Parmi elles, 157 portent une date, de mai 2020 à mai 2026. Elles montrent une évolution progressive des techniques prévues dans le code. Leur présence ne permet pas de savoir lesquelles sont actives sur un compte aujourd’hui.
Les premières méthodes assemblent des textes extraits du site, des modèles de rédaction par catégorie, des assets sélectionnés et des contenus issus des Dynamic Search Ads. Elles ne reposent pas sur une rédaction libre par l’IA.
Des modèles capables de résumer et de comprendre les textes apparaissent. GROUNDED_GENERATIONS est nommé dès janvier 2022 : le code prévoit déjà de vérifier les textes produits à partir de leurs sources.
L’année compte le plus de versions. On y trouve des modèles adaptés à des tâches ou à des langues, des modèles plus petits entraînés à partir d’autres modèles, et des méthodes d’apprentissage guidées par l’évaluation des résultats. Cinq versions du contrôle QUAC apparaissent, ainsi qu’une méthode utilisant uniquement la base de landing pages.
Les méthodes prévues peuvent tenir compte de plusieurs échanges avec l’IA et de plusieurs groupes d’annonces. Certaines servent à modifier des assets existants ; une autre utilise uniquement le titre de la page.
Le code prévoit de suggérer des mots-clés avec un modèle de langage et nomme un premier assistant. Il associe aussi explicitement GenAI V3 à Final URL expansion.
Les dernières versions datées prévoient un assistant pour vérifier le respect des règles publicitaires et une méthode pour retravailler les textes avec GenAI V4.
Le code contient deux listes pour évaluer les assets : 88 types de scores dans AssetScore_ScoreType et 60 indicateurs de qualité dans AssetQualitySignalType_Enum. Elles partagent 59 noms, mais restent deux listes distinctes. Une grande partie des contrôles vérifie que le texte de l’annonce respecte le contenu de la page et que ses affirmations sont justifiées.
Le binaire déclare deux inventaires distincts pour noter un asset. AssetScore_ScoreType compte 88 valeurs, AssetQualitySignalType_Enum en compte 60, et 59 noms sont strictement identiques d'un registre à l'autre. Les mêmes noms existent des deux côtés : une fois comme signal de qualité attaché à l'asset, une fois comme score exploitable pour filtrer et classer. L'intersection est nominale : hors UNKNOWN, les 58 paires homonymes portent des identifiants numériques différents, ce qui exclut qu'un registre soit une inclusion wire de l'autre. Ce noyau commun est donc presque entièrement consacré à la fidélité et au grounding, avec 38 signaux de la seule famille FAITHFULNESS côté qualité.
Certains scores portent sur la pertinence, les clics attendus ou les conseils donnés pour améliorer les titres. D’autres cherchent à retrouver les phrases de la page qui ont servi à créer le texte. Ces contrôles répondent donc à plusieurs questions : l’annonce est-elle pertinente, attractive et conforme à son contenu source ?
Les 29 valeurs propres à AssetScore_ScoreType disent ce que le second registre ne couvre pas : la pertinence et la performance attendue (KEYWORD_RELEVANCE, PCTR, SELECTABILITY, EXTRACTION, ROUGE_FILTER), les onze classifieurs MAQS hérités de la génération pré-LLM, et les quatre diagnostics ASSET_STRENGTH_HEADLINE_*. Une seule valeur n'existe que du côté qualité, INFERRED_SOURCE_SENTENCES, qui compte les phrases sources reconstituées derrière un asset.
On peut regrouper ces contrôles en sept catégories. Ils aident à choisir les textes, à écarter ceux qui posent problème et à donner des indications à l’annonceur. Tous ne sont pas appliqués à chaque asset.
L’annonce répond-elle à la recherche ?
Signaux tirés de la page de destination
L’annonce décrit-elle correctement l’offre ?
Quels passages justifient les affirmations ?
Qualité de la phrase elle-même
Un texte peut être écarté même s’il attire des clics.
Évaluation de chaque titre, famille ASSET_STRENGTH
Les contrôles dépendent de la source du texte, du modèle utilisé, de la langue, du type d’asset et des fonctions activées sur le compte. Les 88 types de scores ne sont donc pas tous calculés pour chaque proposition d’annonce.
AssetScore transporte un type, une valeur, la langue, une catégorie et un éventuel code d'erreur. Les filtres limitent un scorer selon la source, le modèle, la langue, le type d'asset, la recette et le pourcentage de ramp-up. Google ne calcule donc pas 88 scores sur chaque candidat : le jury réellement convoqué dépend de la recette servie à ce compte, dans cette langue, ce jour-là.
Le code suggère une sélection en plusieurs étapes : des règles simples écartent certains textes, puis des contrôles plus complexes évaluent ceux qui restent. L’ordre exact reste une interprétation de l’étude.
88 types de scores sont prévus ; les contrôles appliqués varient selon les cas.
Les réglages permettent de vérifier différemment un titre, une description, un produit ou un mot-clé. Le système peut comparer un texte entier ou des mots précis avec la page. Il peut aussi mesurer la part du texte justifiée par une source et repérer des négations qui changent le sens.
GenerativeModelGroundingOptions contient des seuils distincts pour headline, description, produit, long headline et mot-clé. LandingPageGroundingTechnique_Enum distingue SIMPLE_FULL_GROUNDING et WORD_LEVEL_GROUNDING. D'autres contrats mesurent le ratio de tokens attribués, le nombre de phrases sources, les filler tokens, les stopwords, les sources invisibles et les négations problématiques.
Le code prévoit de conserver les passages précis qui justifient une partie du texte d’annonce, avec leur langue et des limites de longueur et de nombre. Cette vérification est le grounding présenté plus haut.
SignalAttributionConfig conserve le signal source, la longueur minimale d'un fragment, le nombre maximal de fragments, leur distance et la langue. Le système rattache ainsi un morceau d'asset à des passages précis de la page.
Reprendre les mots du site ne suffit pas à respecter leur sens. Par exemple, transformer « livraison offerte dès 50 € » en « livraison offerte » fait disparaître une condition. Un brevet Google déposé initialement en 2023 décrit une vérification de chaque partie de phrase, le remplacement de celles qui échouent, puis un contrôle de la pertinence et des informations manquantes.
La liste AssetQualitySignalType_Enum prévoit 38 indicateurs liés au respect du contenu source. Les variantes changent surtout les informations fournies pour vérifier le texte : titre seul, description, nom de l’entreprise, extraits ou contenu complet de la page.
| Variante | Informations utilisées pour vérifier le texte |
|---|---|
FAITHFULNESS_V5 | Les informations habituellement fournies à cette méthode. |
…_WITH_TITLE_TAG | Le title de la page, seul. |
…_WITH_TITLE_DL_METATAG | Title, listes de descriptions et meta description. |
…_WITH_BUSINESS_NAME_TITLE_DL_METATAG | Les mêmes, plus le nom de l'entreprise. |
…_NO_LP_SENTENCES | Les mêmes, mais privés des phrases extraites de la page. |
…_WITH_SNIPPETS | Des extraits sélectionnés plutôt que la page entière. |
…_CONTEXT_ONLY_WITH_SNIPPETS_RAW_TEXT | Les extraits et leur contexte, avec le texte complet. |
…_NO_CONTEXT_WITH_SNIPPETS | Les snippets sans aucun contexte autour. |
…_WITH_FILLER_VOCAB_V2 | Des mots de remplissage ajoutés pour tester si le contrôle reste fiable. |
Ces variantes permettent de poser des questions concrètes : le title suffit-il à vérifier une promesse ? La meta description aide-t-elle à retrouver la bonne source ? Le nom de l’entreprise évite-t-il de confondre deux marques ? Le texte complet apporte-t-il une information utile ou complique-t-il la vérification ?
D’autres contrôles cherchent les phrases sources probables, vérifient l’exactitude et l’utilité du texte, ou repèrent des contradictions et des changements de sens ou de ton.
Le même registre contient des juges spécialisés au-delà de la fidélité : INFERRED_SOURCE_SENTENCES pour la source inférée, SENTIMENT_INVERSION_CLASSIFIER_V1 pour le sentiment retourné, ACCURACY_CLASSIFIER_V1 pour l'exactitude, HELPFULNESS_CLASSIFIER_V1 pour l'utilité, AUTO_AIS_V7_CONTRADICTION et AUTO_AIS_V7_NEUTRAL pour la contradiction et la neutralité.
Le title, la meta description, les listes de descriptions et le nom de l’entreprise peuvent servir à vérifier les promesses d’une annonce. Ils doivent décrire clairement la même offre, avec les mêmes conditions. Dans l’exemple de la livraison offerte, le montant minimum doit rester visible dans le contenu utilisé pour écrire l’annonce.
Le code nomme aussi un jeu de tests interne pour évaluer ces vérifications, avec des réponses de référence. Certains réglages permettent de ne renvoyer que les affirmations dont la source n’a pas pu être confirmée.
Un benchmark interne est nommé dans le binaire pour évaluer cette chaîne : IDENTIFIER_ADSORACLE_BENCHMARK_EXAM_GROUNDING_TRUTHS, un jeu de vérités terrain dédié au grounding. ExactGroundingConfig l'accompagne, avec le signal servant de vérité terrain, le type d'attribution à la source, le nombre maximal de valeurs en sortie et une option selectedUngroundedOnly qui ne remonte que ce qui n'a pas pu être vérifié.
L’évaluation prévoit le texte à contrôler, sa source, un résultat choisi parmi les réponses autorisées et une justification.
ExtractAssetRatingCsvConfig attend le texte évalué, son attribution, un label autorisé et une justification.
Un modèle peut donc créer un texte, l’évaluer ou vérifier d’où viennent ses affirmations. Google a aussi publié des méthodes de modération publicitaire qui regroupent les contenus similaires, retirent les doublons et font examiner une sélection par l’IA.
Le code suit le nombre de titres différents, les combinaisons possibles, la variété des arguments et les répétitions. Google décrit une logique comparable pour les RSA : assembler des assets adaptés au contexte, retirer les doublons, évaluer les combinaisons et envoyer les meilleures à l’enchère.
Le système peut aussi utiliser les résultats des annonces déjà diffusées. La liste SignalName_Enum prévoit plusieurs informations sur leurs impressions et leurs clics.
Les textes qui ont obtenu des clics peuvent fournir des informations ou des exemples pour créer les suivants. Certains noms de méthodes citent aussi des objectifs de probabilité de clic (pCTR), d’expérience sur la landing page (pLQ) ou les deux (PCTR_PLQ). Ces estimations peuvent donc guider la création des textes, en plus de leur rôle dans l’enchère.
Pour le SEA, les assets actuels peuvent donc influencer les prochaines suggestions. Des textes peu variés donnent peu d’exemples différents à l’IA. Et un titre qui attire des clics avec une promesse mal tenue peut être intéressant pour le CTR tout en créant une mauvaise expérience après le clic.
Ad Strength évalue la quantité, la pertinence, la diversité et les combinaisons possibles des assets. Google le présente comme une aide à l’amélioration des annonces : il n’entre pas dans le calcul d’Ad Rank ou du Quality Score et n’influence pas directement la possibilité de diffuser. Le statut « Incomplet » empêche toutefois un groupe d’assets Performance Max de diffuser. L’application utilise les recommandations pour indiquer quels assets ajouter afin de viser la note « Excellent ». Ce diagnostic complète l’analyse des performances et du trafic réellement supplémentaire.
Créer, associer aux requêtes, enchérir et mesurer : des fonctions à distinguer.
Avant l’enchère, Google Ads a déjà sélectionné des pages utilisables, des informations pour écrire les textes, des requêtes pertinentes et des combinaisons d’assets. Il a aussi pu choisir des produits, des images ou des vidéos. Ad Rank intervient après ces choix.
| Opération | Ce qui est classé ou sélectionné | Références dans le code |
|---|---|---|
| Recherche de pages | Les pages du site utilisables par Ads. | UrlValidationService · LANDING_PAGE_REPOSITORY · VisurlService |
| Choix des passages utiles | Titres, sections et extraits importants. | SALIENT_STUFF_PROCESSOR · SNIPPET_SEGMENT_PROCESSOR |
| Recherche de requêtes | Les recherches qui expriment les besoins à couvrir. | RAW_TOPK_HISTORICAL_QUERIES · …_LP_GROUNDED · VASCO · SEQUOIA |
| Identification de l’entreprise et de ses offres | Entreprise, marque, produits, établissements. | canonical_business_database_id · business_classification |
| Sélection des textes d’annonce | Titres et descriptions retenus après les contrôles. | AssetScore_ScoreType · FAITHFULNESS · KEYWORD_RELEVANCE |
| Choix des combinaisons d’assets | La combinaison d'assets envoyée en diffusion. | SEMANTIC_GROUPING · LLM_CLUSTERING · MTP_LLM_CLUSTERING |
| Choix des produits et des visuels | Produits, images et vidéos sources. | productFidelityScore · VIDEO_SOURCING_RANKING · indexed_image |
| Enchère | Les annonces éligibles à un emplacement. | pCTR · pCQ · pLQ · Ad Rank |
Les 88 types de scores d’assets servent à évaluer les textes pendant leur préparation. Ils ne constituent pas un second Ad Rank. Le site, le catalogue produit, les données structurées et les consignes de marque jouent donc un rôle en amont : ils fournissent les informations parmi lesquelles le système choisit.
Lire le site et les autres sources sur l’entreprise, préparer les informations pour l’IA, créer les textes, vérifier les promesses et choisir les assets et la landing page.
Déterminer les annonces qui peuvent répondre à une recherche : mots-clés exacts, expression, broad match, variantes proches, DSA, AI Max ou Performance Max. Appliquer les règles de priorité.
Utiliser le bid manuel ou Smart Bidding, les estimations de clic et de qualité, ainsi que les seuils d’Ad Rank pour déterminer la diffusion, la position et le prix.
Utiliser Quality Score, Ad Strength, Optimization Score, les rapports, les recommandations et les simulateurs pour analyser les résultats et piloter les campagnes.
La landing page intervient à plusieurs moments : son contenu aide à créer l’annonce, sa qualité attendue compte dans l’enchère, puis des diagnostics aident l’annonceur à l’améliorer. Elle ne détermine donc pas à elle seule le classement ou le prix du clic.
Avant l'enchère
Smart Bidding estime les chances de conversion et leur valeur, en tenant compte du budget ou de la cible ROAS. Il détermine le bid envoyé à l’enchère.
Pendant l'enchère
Google utilise notamment les estimations de clic et de qualité pour déterminer si l’annonce peut être diffusée, son classement, sa position et son prix.
Selon un document Google remis à la CMA, l’autorité britannique de la concurrence, quelques centaines d’annonces jugées pertinentes arrivent dans Ad Mixer. Ce système leur attribue un score nommé Ad Score ou LTV Score. Les pièces du procès relient ce score au nom public Ad Rank.
D’autres pièces du procès expliquent que Google tient compte de la qualité attendue de l’annonce (pCQ) et de la page (pLQ). Le calcul combine le revenu attendu du clic et les effets négatifs d’une mauvaise expérience. Il intègre aussi le risque que les utilisateurs cliquent moins sur les publicités à l’avenir, appelé ads blindness.
Le document UPX0010 relie explicitement LTV Score et Ad Rank. Le prix du clic dépend aussi de mécanismes de tarification distincts de la qualité de l’annonce. Le dossier cite le squashing, le format pricing et rGSP, dont les détails figurent ci-dessous. L’opinion du juge Mehta indique que Google les a utilisés pour augmenter le prix des annonces textuelles.
UPX0010 établit lui-même le lien entre LTV Score et Ad Rank : « the higher the LTV Score (i.e., the higher the Ad Rank) ». Le prix payé, lui, ne découle pas mécaniquement de la qualité. Le dossier documente des leviers de pricing réglés pour le revenu, pas dérivés de la qualité de l'annonce : le squashing, qui relève artificiellement le pCTR du concurrent classé juste derrière et augmente ainsi son score LTV, le format pricing et rGSP, une enchère au second prix randomisée. L'opinion Mehta retient que Google s'en est servi pour relever le prix des annonces textuelles. La qualité de la page pèse dans le classement ; le CPC final dépend aussi de réglages visant le revenu.
Estime la probabilité de clic selon la requête, l’annonce, la position et le contexte. Google précise que ses modèles pCTR n’utilisent pas d’informations issues de la landing page.
Estime la qualité de l’annonce, indépendamment de la landing page.
Estime avant le clic la qualité de l’expérience sur la landing page, à partir des comportements après le clic et d’informations sur les sessions.
Prend en compte le risque qu’une mauvaise expérience publicitaire réduise les clics futurs.
Des brevets déposés dès 2005 distinguent déjà la probabilité de clic de la qualité de la page de destination. Le code cite aussi des méthodes de création de textes orientées vers pCTR, pLQ ou les deux. Pour le SEA, l’enjeu est clair : un titre peut attirer des clics tout en créant une attente que la page ne satisfait pas.
Les seuils d’Ad Rank déterminent si une annonce peut occuper un emplacement. Ils varient selon sa qualité, le contexte, la position et le sujet de la recherche. Même sans concurrent direct, ils peuvent imposer un prix minimum. D’autres réglages de tarification peuvent également faire varier le CPC.
Les seuils d'Ad Rank déterminent l'éligibilité à un emplacement et varient selon la qualité, le contexte, la position et le sujet. Même sans concurrent direct, ils peuvent fixer un prix minimal. Le dossier judiciaire décrit aussi le squashing, l'ancien format pricing et rGSP, codename Polyjuice. Ces mécanismes modifient la référence de prix ou l'importance relative de certains termes.
La qualité de la page compte dans l’enchère. Le CPC dépend aussi du bid, de la concurrence, des seuils, de la position et des réglages de tarification.
| Indicateur | Niveau | Rôle |
|---|---|---|
| Quality Score 1 à 10 | mot-clé | Diagnostic des composantes de qualité. |
| Ad Strength | annonce ou asset group | Conseils sur le nombre d’assets, leur variété et les arguments couverts. |
| pCTR, pCQ, pLQ | enchère | Estimations de clic et de qualité utilisées lors de l’enchère. |
| Optimization Score | compte ou campagne | Priorisation des recommandations. |
Une pièce du procès distingue pCTR, pCQ et pLQ, utilisés lors de l’enchère, du Quality Score de 1 à 10, qui sert au diagnostic. Les scores affichés ou présents dans le code n’ont donc pas tous le même rôle.
Pour chaque recommandation, le code prévoit un effet sur l’Optimization Score si elle est appliquée et un autre si elle est refusée. Ces effets peuvent être suivis au niveau du compte et de la campagne. La note dépend donc aussi de la manière dont vous traitez les recommandations.
L'Optimization Score n'est pas seulement une note affichée. Les messages internes SuggestionScore et SuggestionScopeScore portent, pour chaque recommandation, un applyUplift et un dismissUplift distincts, un viewedScore et des portées campagne et compte. Le client soustrait ces deux uplifts au score agrégé de la page quand une suggestion est retirée. Le score se comporte comme un registre de mutations, pas comme une somme.
Le code décrit une hausse temporaire du budget, avec un retour possible au budget initial. Il précise les informations nécessaires pour suivre cet ajustement.
Les noms de champs de deux messages internes décrivent un mécanisme d'ajustement temporaire et réversible du budget, avec un cycle de vie complet. Ce ne sont pas des noms d'enums isolés : ce sont des champs résolus à l'intérieur de messages, ce qui constitue une trace plus forte.
Quatre statuts techniques permettent de suivre l’application de la hausse, le retour au budget initial et la fin de l’ajustement. Parmi eux, le statut « apply » apparaît dans la version la plus récente du message.
Le réglage targetRoasRelaxationPercentMillis prévoit un assouplissement temporaire de la cible ROAS en complément de la hausse du budget.
targetRoasRelaxationPercentMillis indique que la hausse de budget s'accompagne d'un assouplissement temporaire de la cible de rentabilité, exprimé en pourcentage-millièmes.
Le réglage budgetBoostSeasonalityEventId associe la hausse à un événement saisonnier. Il suggère un lien avec un calendrier, sans préciser à lui seul comment la hausse est déclenchée.
AdaptiveBudgetsSettings prévoit aussi des limites pour les ajustements automatiques : un pourcentage autorisé, un minimum et un maximum. Des réglages propres à une campagne et une option d’exclusion sont prévus. Le système peut ainsi encadrer l’ampleur des variations de budget.
AdaptiveBudgetsSettings décrit un second mécanisme, adjacent : des bornes d'ajustement automatique en pourcentage, un plafond et un plancher, avec une possibilité de surcharge au niveau campagne et une option d'exclusion. Autrement dit, un compte peut définir l'amplitude dans laquelle le système s'autorise à bouger seul.
En période de forte saisonnalité, une variation de dépense ou de ROAS peut aussi venir d’un ajustement temporaire du budget. Avant d’attribuer l’écart à la concurrence ou à une optimisation, vérifiez si une hausse a été appliquée puis annulée sur la période et quelles limites étaient autorisées.
Dans une réponse générée, l'annonce doit être cohérente avec ce que l'IA vient d'expliquer.
Google indique que, pour les annonces servies dans AI Overviews, deux contextes sont pris en compte : la requête de l'utilisateur et le contenu de l'AI Overview. L'annonce Search ou Shopping doit gagner l'enchère, répondre à la requête et rester pertinente par rapport aux informations de la réponse générée.
Le code contient des fonctions qui pourraient servir à rapprocher les annonces du contenu d’une conversation.
Dans une recherche classique, Google rapproche la requête, l’annonce et la landing page. Avec une réponse générée par l’IA, le contenu de cette réponse compte aussi. Plusieurs brevets de 2023 décrivent des annonces adaptées aux conversations : repérer les termes importants dans les échanges, préciser le besoin au fil des messages et adapter le texte publicitaire. Ces brevets décrivent des possibilités, pas la preuve de leur déploiement.
AI Max for Shopping exploite les données du flux Merchant Center, le contenu du site et la génération de titres pour répondre à des requêtes plus conversationnelles. Final URL expansion peut parcourir le site pour identifier des catégories, nouveautés, pages éditoriales commerciales et autres destinations pertinentes.
Le code prévoit des informations produit (gmc_product_info), des suggestions d’assets Merchant Center, des informations sur les titres et descriptions, ainsi que plusieurs versions de landing pages. Le productFidelityScore évalue si un asset généré décrit correctement le produit.
Les pièces du procès indiquent que les annonces textuelles et les Product Listing Ads utilisent des systèmes d’enchère distincts. Partager des sources de contenu ou des modèles ne signifie donc pas passer par une enchère unique.
Le nom GENERIC_MUTATE indique qu’un assistant peut préparer ou appliquer des modifications dans le compte, avec les contrôles prévus par le produit. Un autre ensemble, Ads Guide, réunit l’historique des échanges, les informations du site, la personnalisation et la création de campagnes. Il prévoit aussi des fonctions spécialisées et des modèles capables de raisonner en plusieurs étapes.
Les produits annoncés par Google suivent la même direction : Ads Advisor, Analytics Advisor et Ask Advisor. Google précise qu'une approbation est demandée avant l'application d'une action.
Pour piloter ces assistants, les consignes et les sources doivent être cohérentes. Une règle de marque est difficile à appliquer si le site, le flux produit, Business Profile et les assets donnent des informations contradictoires. L’assistant s’appuie sur les données auxquelles il a accès.
Huit chantiers pour les équipes SEO, SEA et AI search.
Dans le HTML de la page, chaque information importante doit être facile à repérer : produit ou service, public visé, bénéfices, preuves, prix, disponibilité et conditions. Organisez le contenu en sections claires, avec des phrases compréhensibles même lorsqu’elles sont lues séparément.
Affichez clairement les prix, remises, délais, garanties, certifications et restrictions. Chaque promesse de l’annonce doit pouvoir être retrouvée dans la page, avec ses conditions. Par exemple, conservez « dès 50 € d’achat » à côté de « livraison offerte ».
L’IA peut combiner le title, le H1, les sections, les balises meta et les données structurées. Ces éléments doivent décrire la même offre, la même marque et les mêmes conditions. L’objectif est la cohérence des informations, sans répéter mécaniquement les mêmes mots partout.
Rendez les pages de catégorie, de service, de zone desservie, les comparatifs et les sélections saisonnières faciles à trouver depuis la navigation. Le visiteur doit retrouver rapidement l’offre promise dans l’annonce et comprendre comment acheter ou prendre contact.
Variez les arguments : produit, bénéfice, usage, public, preuve, prix, disponibilité, marque et appel à l’action. Des titres complémentaires donnent plus de possibilités de combinaison que plusieurs reformulations du même bénéfice.
L’historique des requêtes, le broad match, les Search Themes et les rapports AI Max montrent les besoins exprimés par les internautes. Utilisez-les pour repérer les informations manquantes, ajouter des sections utiles et créer des landing pages adaptées. Vérifiez aussi que le site justifie les promesses associées à ces recherches.
Le ciblage sans mots-clés ne supprime pas les règles de priorité. Sur les requêtes importantes pour la marque, les produits ou la rentabilité, un mot-clé identique à la recherche et éligible à la diffusion reste utile pour orienter le choix de la campagne. Cela ne garantit pas à lui seul la diffusion.
Une règle globale dans robots.txt ne suffit pas à contrôler AdsBot. Il faut vérifier AdsBot-Google, AdsBot-Google-Mobile, les réponses HTTP, les redirections et le rendu du contenu principal. Site, Merchant Center, Business Profile, YouTube, profils sociaux et assets existants doivent rester cohérents sur le nom de marque, les catégories, les produits, les visuels, les zones desservies, les prix et les conditions promotionnelles.
Un brief utile précise les messages obligatoires, les promesses interdites, les requêtes à viser ou à éviter, les audiences prioritaires et les pages autorisées. Indiquez aussi les termes sensibles, les catégories exclues et les preuves disponibles sur le site. Suivez ensuite les performances, les requêtes, la cohérence entre l’annonce et la page, et les conversions réellement supplémentaires.
Neuf points à vérifier dans Google Ads, vos rapports et les journaux de votre serveur.
| Point de contrôle | Où le lire | Ce que ça révèle |
|---|---|---|
| Accès d'AdsBot | Logs serveur filtrés sur AdsBot-Google et AdsBot-Google-Mobile, robots.txt, codes de réponse. | Les pages auxquelles AdsBot n’arrive pas à accéder, même si Googlebot y parvient. |
| Origine de la correspondance | Rapport des termes de recherche, colonne de type de correspondance, libellés AI_MAX_KEYWORDLESS et AI_MAX_BROAD_MATCH. | La part du trafic captée hors de vos mots-clés, et sur quelles intentions. |
| Terme de recherche, page et titre d’annonce | ai_max_search_term_ad_combination_view |
La destination et le texte que Google associe à chaque intention. |
| URL retenues par l'expansion | Rapport des URL de destination, liste des exclusions, page feeds. | Les pages sans objectif commercial qui reçoivent du trafic payant. |
| Assets générés automatiquement | Onglet des assets, filtre sur la source de création, assets refusés ou en attente. | Les promesses que la page ne justifie pas, et celles que Google a écartées. |
| Variété des assets | Ad Strength et le détail de ses recommandations, rapport de performance des assets. | Les titres qui se répètent et les arguments manquants. |
| Composantes du Quality Score | Colonnes CTR attendu, pertinence de l'annonce et expérience sur la page, au niveau du mot-clé. | L'écart entre un texte attractif et une destination qui tient la promesse. |
| Cohérence entre vos sources | Diagnostics Merchant Center, fiche Business Profile, suggestions d'assets proposées par Google. | Quelle source Google retient quand le site, le flux et la fiche se contredisent. |
| Trafic supplémentaire des Search Themes | Colonne d'incrémentalité des Search Themes dans Performance Max. | Si un thème capte une demande nouvelle ou en réattribue une déjà couverte. |
Ces observations ne suffisent pas à prouver l’effet d’une modification. La saisonnalité, la concurrence, le budget et l’apprentissage des enchères peuvent aussi faire évoluer les résultats. Pour mesurer un effet, comparez des situations aussi proches que possible, ne changez qu’un facteur à la fois et laissez suffisamment de temps au test.
Nous avons analysé les versions 3.34 et 3.37 de l’application pour relever les fonctions prévues, les informations échangées et les réglages disponibles. La comparaison porte sur la même architecture, afin de distinguer les changements de version des différences liées à la façon dont l’application est construite. Ce travail a été complété par l’observation de l’interface web ads.google.com : plusieurs captures du trafic échangé lors de sessions réelles ont permis de recouper le vocabulaire et les schémas du site avec ceux relevés dans l’application.
Un outil développé pour l’étude a permis de lire la structure du programme, au-delà d’une simple recherche de mots. Des contrôles ont vérifié que l’analyse couvrait bien les données attendues : 3 018 groupes lus sur 3 018, puis 220 champs identiques sur 225 lors d’une comparaison avec l’interface web. L’inventaire de la version 3.37 comprend 1 638 listes de valeurs techniques et 39 409 entrées. La méthode détaillée reste consultable ci-dessous.
Le binaire n'a pas été lu par simple extraction de chaînes. Un désérialiseur du snapshot Dart a été écrit pour l'occasion et contrôlé par les oracles internes du format : 3 018 clusters lus sur 3 018, aucune référence hors de son type, fin de flux atteinte exactement. Les initialiseurs BuilderInfo, qui déclarent les champs protobuf, ont été désassemblés puis recoupés avec les descripteurs de l'interface web : 220 champs identiques sur 225. Les comptes d'inventaire ont été refaits par identité de classe et de bibliothèque, ce qui sépare les homonymes que le premier dump agrégeait : 1 638 types d'enums et 39 409 constantes en version 3.37.
Cette lecture est comparée aux pièces du procès US v. Google, à la documentation des produits, aux publications Google Research et aux brevets cités plus bas. Ces sources aident à interpréter les fonctions repérées dans le code.
L’application ne révèle pas les réglages internes des modèles, les seuils de décision ni les fonctions réellement activées sur chaque compte. Certains liens restent des hypothèses, notamment le rôle de SEARCH_SHADOW et l’ordre des contrôles ou des étapes AI Max. Beyond, Evergreen, Servo, Steelmill, Uniserve et Sequoia restent des noms internes sans documentation publique.
Les inventaires bruts de la version 3.37 sont publiés sur une page séparée : 173 services gRPC regroupés par famille, les 25 enums cités dans l'étude avec leurs 1 507 valeurs, et les 2 143 bibliothèques protobuf. Ils font plusieurs fois la taille de ce texte et ne se lisent pas de la même façon.