Guide Google Merchant Center pour CMO et dirigeants

Ce que Merchant Center pilote réellement

Merchant Center n’est pas un “outil Shopping”, c’est la couche data de votre distribution e‑commerce sur Google

La documentation officielle le dit sans détour : votre donnée produit sert à faire correspondre vos produits aux requêtes, et une information produit incorrecte, inexacte ou manquante peut créer des Issues qui empêchent vos annonces de s’afficher. 

Sur le terrain, ça se traduit par une loi qui ne pardonne pas : si votre système de données est moyen, vous ne “ferez pas mieux” avec une meilleure structure de campagne. Vous aurez juste un algorithme plus agressif qui amplifie des signaux incomplets.

Surfaces gratuites et surfaces payantes partagent la même fondation de données

Les “free listings” peuvent afficher vos produits sans coût sur plusieurs surfaces (Search, Maps, YouTube, onglet Shopping, Images, Lens… et même Gemini selon la configuration/éligibilité) : c’est explicitement listé dans le Help Center. 

Ce point est stratégique pour un CMO : vous n’êtes pas en train d’optimiser “Shopping Ads”. Vous optimisez un système de visibilité produit multi‑surfaces qui dépend de la qualité de votre feed, de votre site et de votre conformité. 

Google a d’ailleurs publié un playbook indiquant qu’après l’introduction des free listings, l’usage “free + ads” a entraîné en moyenne +50% de clics et un doublement des impressions sur l’onglet Shopping (donnée interne Google, juillet 2020). 
C’est un chiffre intéressant, mais il faut le lire comme un indicateur : là où votre donnée produit est solide, Google élargit vos opportunités de diffusion. 

Changements récents qui changent la stratégie

Merchant Center Next est devenu le standard, et l’interface n’est plus un détail

Google a annoncé le déploiement complet de Merchant Center Next, remplaçant l’expérience “classic”, avec notamment de nouveaux rapports d’insights et des outils d’imagerie générative. 

Implication “guide” (et audit) : vous devez expliquer les mécanismes (sources de données, diagnostics, politiques, automatisations, règles…) plutôt que de dépendre d’un chemin de menu, parce que l’UI évolue. 

Merchant API remplace Content API et fixe une échéance de migration en 2026

Google a officialisé Merchant API comme une API “simplifiée”, désormais disponible, et précise qu’elle remplace Content API for Shopping comme interface principale d’accès programmatique. 
Point critique (et hautement actionnable pour un dirigeant) : Google annonce la fin de Content API for Shopping au 18 août 2026. 

Si votre stack (ou votre app e‑commerce) dépend encore de Content API, votre enjeu n’est pas l’optimisation. Votre enjeu est l’éviction technologique : vous risquez une rupture opérationnelle (data sources, mises à jour, quotas, statuts). 

Product Studio et l’outillage “créa” dans Merchant Center Next sont une tendance structurelle

Google a étendu Product Studio (suite d’outils IA pour images produit) à 15 nouveaux pays en décembre 2024 (liste de pays dans l’annonce Help Center). 
Ce n’est pas “un gadget créa” : c’est un signal que Google veut industrialiser la qualité des assets produit directement depuis Merchant Center Next. 

Architecture des données produit et flux

Les sources de données sont votre système d’exploitation, pas un choix de format

Google décrit plusieurs méthodes pour “ajouter vos produits” : fichier, Google Sheets, upload manuel, synchronisation via plateforme e‑commerce, ingestion automatique depuis votre boutique, ou API. 
En audit “CMO‑level”, la question n’est jamais “XML ou CSV”. C’est : quel système garantit la vérité prix/stock/livraison à l’instant où Google crawl ? 

Formats et limites techniques officielles

Google accepte des fichiers .txt, .xml ou .tsv, jusqu’à 4 GB, et précise qu’un format non supporté (ex. .html) empêche le traitement du feed. 
Pour un fichier hébergé, Google précise aussi des règles de lien (http/https/sftp). 

Expiration des produits et discipline de refresh

Google indique que tous les produits expirent 30 jours après le dernier refresh (hors produits ajoutés directement dans Merchant Center). 
Cette règle impose une gouvernance : planification, monitoring, et gestion des erreurs de fetch. Sans ça, on confond souvent “baisse de performance” et “produits expirés / non actifs”. 

Hiérarchie multi‑sources, priorités et pièges de gouvernance

Google explique qu’une “data source” est créée quand vous ajoutez des données produit, et qu’on peut utiliser une ou plusieurs sources avec des méthodes d’upload différentes. 
Point subtil mais décisif : si un produit est uploadé plusieurs fois via des sources différentes, Google indique que le produit est considéré comme faisant partie de la data source la plus récemment mise à jour. 

Conséquence directe pour un CMO : l’enjeu n’est pas seulement “avoir un feed”. L’enjeu est d’éviter les effets de bord (écrasements de champs, overrides involontaires, incohérences entre pays/langues, et conflits entre intégration plateforme et correctifs). 

Attribute rules pour transformer et corriger sans casser l’amont

Google présente les “attribute rules” comme un moyen de transformer les données pour respecter la spécification, résoudre des erreurs et aider Google à interpréter la donnée. 
Google documente aussi la possibilité de créer des “custom attributes” pour manipuler votre donnée avant de l’assigner à un attribut officiel. 

Supplemental sources pour enrichir/overrider à l’échelle

Google définit les “supplemental data sources” comme des sources additionnelles pour améliorer ou overrider la source principale. 
Côté API, Google explique que les “supplemental feeds” permettent des mises à jour partielles de champs (sans affecter le reste), et note un point technique important : les partial updates via supplemental feeds ne reset pas l’expiration produit ; il faut un insert complet pour reset. 

Qualité de données : attributs qui font gagner ou perdre la diffusion

Le minimum “utile” est plus haut que le minimum “accepté”

Le playbook free listings de Google indique un “minimum product data” typique pour l’éligibilité (ID, title, price, description, availability, link, image_link) et liste aussi des attributs additionnels (condition, brand, gtin, mpn, couleur, taille, etc.). 
La spécification Merchant Center insiste de son côté sur le fait que la donnée produit conditionne le matching aux requêtes et la performance des ads et free listings. 

Un guide “suprême” doit donc clarifier une distinction que beaucoup d’agences évitent :

• conforme ≠ compétitif
• validé ≠ prédictible
• pilotable ≠ rentable 

Identifiants produit, GTIN et cohérence marque : la confiance machine

Le playbook Google souligne que l’identification correcte des produits (GTIN/MPN/brand selon pertinence) aide à l’approbation et à la qualité des listings. 
Et Google documente explicitement un cas de “conflit GTIN/brand” : performance limitée si le GTIN fourni n’est pas associé à la marque fournie, et renvoie à l’outil GEPIR de  pour vérifier la propriété des GTIN sur certains marchés. 

Pour un CMO, la conséquence pratique est brutale : si vos GTIN sont faux (ou si votre mapping brand est incohérent), vous ne “perdez pas un point”. Vous fragilisez la capacité de Google à réconcilier vos produits dans son graphe d’entités produit, ce qui impacte la diffusion et la compétitivité (inférence cohérente avec les mécanismes décrits par Google sur les identifiants et les diagnostics). 

Images, qualité visuelle et règles chiffrées

Google détaille des exigences précises autour des images :

• image non‑apparel ≥ 100×100 px ; apparel ≥ 250×250 px ;
• pas d’image > 64 MP ; pas de fichier > 16 MB ;
• éviter les images “placeholder” et les overlays promotionnels (logos, CTA, watermarks), avec possibilité d’activer des “image improvements”. 

Ce niveau de détail est crucial dans un guide Merchant Center orienté leads, parce que les annonceurs sous-estiment l’impact “real world” : une image non conforme = disapproval = coupure d’inventaire = perte de chiffre. 

Spécification en mouvement : update 2025 et nouveaux attributs shipping

Google publie une “product data specification update” annuelle. En 2025, Google annonce notamment :

• la fin du support d’un usage de price pour down payments dans l’installment pricing (au profit de downpayment) ;
• des changements sur les attributs energy efficiency en UE ;
• et surtout de nouveaux attributs shipping “offer‑level”, incluant carrier_shipping, shipping_handling_business_days et shipping_transit_business_days (pour de meilleures estimations de délais de livraison). 

Un guide 2026 qui ignore ces évolutions est mécaniquement obsolète — et un CMO le verra immédiatement. 

Politiques, conformité et risques opérationnels

Misrepresentation n’est pas une “erreur Merchant Center”, c’est un signal de risque business

Google a publié une clarification (octobre 2025) indiquant que la politique “Misrepresentation” inclut davantage d’exemples et de guidance, avec mention explicite de cas autour de la non‑livraison et des processus de retour/remboursement inopérants, ainsi que des informations sur l’appel. 

Google rappelle aussi que des comptes Merchant Center sont revus régulièrement ; les offres peuvent être disapproved si elles ne sont pas conformes, et des violations continues ou “egregious” peuvent conduire à une suspension. 
En clair : la conformité n’est pas un dossier juridique séparé du marketing. C’est un prérequis d’accès à l’inventaire. 

Warnings, suspensions et délais de review

Google explique le fonctionnement des warnings : vous recevez un email avec détails et timeframe, et la période de warning peut s’accompagner d’une visibilité limitée. 
Google précise aussi que dans certains cas “egregious”, il peut ne pas y avoir de warning et la suspension est immédiate. 
Enfin, Google indique que des demandes de review peuvent prendre jusqu’à 7 jours. 

Prix, disponibilité, shipping : les mismatches sont une mécanique d’enforcement, pas un bug

Google documente le mécanisme de “preemptive item disapproval (PID)” :

• les warnings de mismatch prix/disponibilité entre feed et landing pages entraînent un PID plutôt qu’une suspension ;
• le PID est considéré comme de l’enforcement account‑level, et une review est requise ;
• surtout, Google précise que seuls les mismatches prix/disponibilité peuvent entraîner un PID, alors que d’autres violations data quality peuvent mener à une suspension si non résolues sur la période de warning (mention explicite de 28 jours). 

Ce que doit marteler un guide “tranché” : si vous avez des mismatches, vous n’avez pas “un problème Merchant Center”. Vous avez un problème de synchronisation de vérité entre votre pricing/stock system et ce que Google peut crawler. 

Shipping costs inaccurate : la règle d’override qui piège les équipes

Google précise que si l’attribut shipping est fourni au niveau produit, il override les réglages shipping au niveau compte. 
Google recommande aussi, si on ne peut pas fournir les coûts exacts, de légèrement surestimer ce qui est déclaré dans Merchant Center (pour éviter l’écart au checkout). 

CSS en Europe : contrainte structurelle à intégrer dès le début

Google indique que dans l’Espace Économique Européen, au Royaume‑Uni et en Suisse, un compte Merchant Center doit être associé à un Comparison Shopping Service (CSS). 
Google liste les pays concernés (dont la France) sur la page “About advertising with Comparison Shopping Services”. 

Un guide “suprême” doit traduire le sous‑texte : en UE, Shopping sur la SERP general search results est, dans cette architecture, un jeu d’intermédiaires CSS. L’erreur typique est de traiter ça comme une formalité “setup” au lieu d’un paramètre de gouvernance (qui détient la relation, qui peut diffuser, qui a accès). 

Mesure, attribution et audit Merchant Center orienté profit

Lier Merchant Center et Google Ads est une condition de fonctionnement pour Shopping et un levier de gouvernance

Google documente les étapes de liaison Merchant Center ↔ Google Ads, et précise des points structurants :

• l’activation peut passer par “Business Manager” ou un lien “Merchant Center only” ;
• un Merchant Center peut être lié à jusqu’à 500 comptes Google Ads ;
• la dissociation peut interrompre des campagnes dépendantes des données produit. 

Côté documentation développeur, Google indique aussi que la liaison Ads ↔ Merchant Center est requise avant de créer une campagne Shopping. 
Et Google Ads rappelle que pour que Shopping et Performance Max “run effectively”, il faut ajouter des produits au feed Merchant Center lié (destination shopping ads). 

Pour un dirigeant, la traduction est simple : la liaison est un couplage opérationnel. Dans un audit sérieux, on contrôle qui initie, qui approuve, qui peut casser le lien, et comment on évite la dépendance à un seul compte utilisateur. 

“Key events” et conversions : Merchant Center a harmonisé sa sémantique, mais pas la réalité des écarts

Google a renommé, côté Merchant Center (free listings), le “conversion tracking” en “key events”, et explicite la raison : des événements marqués conversions dans Analytics étaient mesurés différemment des conversions Google Ads, créant des divergences ; Google veut aligner la terminologie et clarifier que le terme “conversion” est désormais “ads context” (optimisation bidding). 

C’est un point capital pour un guide “CMO‑level” : si votre organisation lit Merchant Center, Analytics et Ads comme un seul système, vous vous trompez. Il faut une grille de lecture qui distingue organique produit, paid, et modèles de mesure selon plateforme. 

Audit Merchant Center premium : la méthode qui évite les faux gains

Un guide destiné à générer des leads qualifiés doit être utile au point qu’il “met mal à l’aise” les audits basiques. Le Help Center fournit une base claire pour structurer un audit robuste :

• La page “Issues in Merchant Center” décrit un flux de résolution (Needs attention, request review) et introduit une fonctionnalité “Priority fixes” qui filtre les problèmes à impact moyen/haut (donc une logique de priorisation officielle). 
• Le guide officiel sur les suspensions insiste sur l’examen des politiques, la cohérence des informations business, des policies et des contacts, avant re‑review. 
• La documentation sur les automatisations permet d’activer/désactiver des mises à jour automatiques (prix, disponibilité, condition, améliorations d’images) depuis l’onglet Automations. 
• La documentation sur la vérification d’URL explique des méthodes de vérification incluant , email, HTML tag/file,  ou Google Analytics, et précise que, dans la plupart des cas, une seule vérification suffit. 

Sur cette base officielle, un audit “Convertix‑style” (process ultra‑structuré, tracking avancé, obsession scalabilité) se construit généralement autour de trois blocs — que vous pouvez présenter dans le guide comme une méthode reproductible :

Éligibilité et conformité

Inclure systématiquement : CSS (UE/UK/CH), vérification/claim, politiques retours/livraison, cohérence checkout, et mécanismes d’enforcement (warnings, PID, suspensions). 

Data quality et “machine trust”

Inclure : identifiants (GTIN/brand/MPN), cohérence catégories et taxonomie, qualité images, règles sur capitalisation/spam, et mécanismes d’amélioration (image improvements). 

Architecture et scalabilité

Inclure : choix de data sources, cadence de refresh (expiration 30 jours), gestion multi‑sources (source la plus récente), attribute rules, supplemental sources, et plan de migration Merchant API si dépendance Content API. 

Positionnement premium et “ROAS réel” : comment l’ancrer sans promesse marketing

Le nivellement par le bas du marché vient souvent d’une confusion : “Merchant Center est validé donc la perf dépend des enchères”. C’est faux dans la moitié des cas, parce que Merchant Center peut vous retirer l’inventaire (Issues, disapprovals, suspensions), ou le dégrader (limited performance) via des signaux de data quality. 

C’est ici que le discours “premium” de  devient rationnel : un service plus cher est défendable quand il réduit un risque business mesurable (rupture de diffusion, suspension, PID, perte de vérité prix/stock) et améliore la qualité du signal long terme (structure data, gouvernance, process, migration API). 

Enfin, si vous voulez un chiffre “business” qui frappe et qui reste crédible, vous pouvez appuyer le besoin d’exigence data sur un repère macro :  cite une estimation du coût moyen de mauvaise qualité des données à au moins 12,9 M$ par an (moyenne) dans une recherche évoquée par Gartner. 
C’est volontairement macro, mais utile pour cadrer la discussion : Merchant Center n’est qu’un cas particulier où la data quality devient immédiatement visible (via disapprovals et enforcement). 

Exemples de preuves sociales “safe” issues de Google

Google présente Merchant Center comme un outil gratuit pour gérer et promouvoir ses produits “across Google Search, Maps, YouTube and more”, et affiche des témoignages/case studies avec des uplifts (ex. +280% ROI depuis 2019 pour  ; +58% de revenus pour ). 
À utiliser dans un guide non pas comme “promesse”, mais comme preuve que Google positionne Merchant Center comme un levier de croissance quand la donnée produit est industrialisée. 

Sources clés mobilisées

La documentation officielle de  sur Merchant Center Next, Merchant API et product data spec. 
Le Help Center sur free listings (surfaces), policies, issues, warnings, suspensions, misrepresentation et PID. 
Les ressources officielles sur data sources, création de fichiers, limites, refresh et expiration. 
Les ressources officielles sur CSS (UE/UK/CH). 
Les guides Google Search Central sur Product structured data et merchant listings. 
Le playbook Google sur free listings et l’impact moyen “free + ads” (données internes Google, juillet 2020).