Ces attributs sont le grain fin de votre flux produit Merchant Center : la donnée que Google lit ligne par ligne pour comprendre ce que vous vendez.
Un flux peut être rempli comme un formulaire administratif, juste assez pour faire taire les alertes. Il peut aussi être construit comme un système de pilotage, où chaque attribut a une source claire et une utilité précise.
La différence dépasse le cosmétique. Pour Shopping, la qualité du flux dépend d’abord de la fiabilité de ces valeurs. Un attribut manquant peut limiter la visibilité. Un attribut faux peut déclencher une alerte, une restriction ou un refus. Cette page couvre les champs les plus sensibles, GTIN, catégorie Google, product_type, variantes et attributs descriptifs, pour traiter le catalogue avant que les problèmes n’apparaissent.
Étage 1 : les identifiants, Google sait-il ce que vous vendez ?
GTIN, marque, MPN : ce trio aide Google à rattacher votre ligne de flux au bon produit réel. Avec un GTIN valide, le produit est plus facile à classer, à comparer et à associer aux bonnes fiches.
La règle utile tient en une phrase : si un identifiant existe chez le fabricant, fournissez-le. Si vous ne le connaissez pas, cherchez-le. Si vous l’inventez, vous créez un risque.
Un identifiant incorrect est plus risqué qu’un identifiant absent. Le manque peut limiter la visibilité. Le faux peut associer le produit au mauvais objet et déclencher un problème Merchant Center.
GTIN présent, absent ou inventé : quelle conduite dans chaque cas ?
Trois cas, trois conduites.
- Votre produit a un GTIN (il a un code-barres) : fournissez-le, tel quel, vérifiable au besoin via les outils GS1.
- Votre produit n’a aucun identifiant fabricant (sur-mesure, fait main, pièce unique, vintage, livre d’avant 1970) : utilisez identifier_exists à false, plutôt que de créer un identifiant fictif.
- Votre produit a un identifiant que vous ne connaissez pas encore : retrouvez-le sur l’emballage, chez le fournisseur ou dans la documentation fabricant. Le déclarer absent quand il existe peut limiter l’exposition. L’inventer crée un problème plus sérieux.
Et les variantes ajoutent leur exigence propre : chaque déclinaison de couleur ou de taille est un objet distinct, avec ses identifiants uniques. Recycler le GTIN du parent sur toutes les variantes est une erreur de structure, pas un raccourci.
Sans GTIN, faut-il forcément déclarer identifier_exists à false ?
Non. C’est justement la nuance importante. L’attribut identifier_exists à false ne signifie pas « je n’ai pas trouvé le GTIN ». Il signifie : aucun code produit unique n’est disponible pour ce produit.
Si le produit dispose d’identifiants fabricant, Merchant Center attend une donnée fiable : GTIN exact ou, selon les cas, marque et MPN. Un produit de marque dont vous ne connaissez pas encore le GTIN n’est donc pas un produit sans identifiant.
identifier_exists à false se justifie pour les produits qui n’ont réellement ni GTIN, ni MPN, ni marque fabricant exploitable : sur-mesure, fait main, pièce unique, certains articles anciens. Ce réglage ne sert pas à « faire taire l’alerte ».
Où trouver et comment vérifier le GTIN d’un produit ?
Le GTIN est rarement à inventer. Il est presque toujours à retrouver. Commencez par le code-barres imprimé sur l’emballage ou l’étiquette, puis par la fiche fournisseur ou la documentation fabricant. Les outils GS1 servent ensuite à vérifier la validité et l’attribution du code.
Une fiche vue chez un autre marchand peut aider à enquêter. Mais elle ne suffit pas comme preuve. Un code récupéré sur une place de marché tierce doit être vérifié avant d’entrer dans le flux.
Pour les articles vendus en lot, le bon identifiant dépend du conditionnement réellement vendu. Le GTIN de l’unité seule et celui du pack ne sont pas interchangeables.
GTIN manquant, incorrect ou restreint : trois états, trois corrections
Il n’y a pas deux états d’erreur de GTIN mais trois, et ils n’appellent pas la même correction.
Manquant : le produit peut rester éligible. Mais sa visibilité peut être limitée si un identifiant existe et n’est pas fourni. Incorrect : le code ne correspond pas au bon produit. Restreint : le code tombe dans une plage que Google ne considère pas comme valable pour ce produit.
La correction diffère donc. Un GTIN absent se recherche. Un GTIN incorrect ou restreint se remplace par le bon code. Identifier_exists à false ne s’utilise que si aucun code produit unique n’existe vraiment. La procédure de levée des refus et l’appel relèvent des erreurs et suspensions Merchant Center, pas de cette page.
GTIN, marque, MPN : facultatif ou obligatoire selon votre plateforme ?
Dans Merchant Center, le GTIN n’est pas requis pour tous les produits. Il est fortement recommandé quand le fabricant en a attribué un. Facultatif ne veut donc pas dire sans conséquence : un identifiant manquant peut limiter la visibilité ou certaines fonctionnalités Shopping.
Si votre flux part d’un site WooCommerce, la case GTIN n’existe pas nativement dans la fiche produit. Elle dépend d’un plugin, d’une extension d’export ou d’un champ personnalisé. C’est là qu’un mauvais mappage peut laisser le flux vide sans que l’équipe le voie avant l’alerte Merchant Center.
Le bon contrôle consiste à identifier, pour chaque famille d’articles, quel champ source alimente le GTIN, la marque et le MPN. Les outils GS1 restent la référence de vérification du code, quelle que soit la plateforme d’origine.
Étage 2 : la catégorisation, où Google vous range
Deux attributs cousins, deux fonctions. La catégorie Google (`google_product_category`) utilise la taxonomie officielle de Google. Elle peut être attribuée automatiquement. Mais vous pouvez la renseigner pour corriger ou préciser le classement quand c’est nécessaire.
Visez juste et précis. Une catégorie de premier niveau appliquée à tout un catalogue donne trop peu de contexte, surtout sur les univers où les exigences varient selon la famille de produits.
Le `product_type`, lui, correspond à votre propre arborescence. Google peut l’utiliser pour mieux comprendre ce que vous vendez. Mais son intérêt opérationnel principal reste Google Ads : organiser les enchères, les rapports et les groupes de produits selon votre logique commerciale.
Un `product_type` pauvre (« Produits >. Divers ») ne déclenche pas forcément d’alerte Merchant Center. Mais il appauvrit votre pilotage. On ne segmente finement que ce qu’on a nommé en amont.
Étage 3 : les descriptifs, pour quelles requêtes vous sortez
Couleur, taille, genre, matière, tranche d’âge : ces attributs affinent le matching et alimentent les filtres. Une requête comme « robe lin vert sauge 40 » a besoin de retrouver ces informations dans des champs lisibles, au-delà d’un titre approximatif.
La discipline consiste à compléter gamme par gamme, en commençant par les familles où les requêtes de recherche Shopping sont les plus fréquentes. C’est le prolongement naturel du travail des titres : les mêmes informations. Mais en version structurée.
Quand la donnée existe sans être dans le bon champ, code couleur en texte libre, taille noyée dans le titre, matière absente du flux, on peut souvent la déplacer par les règles de flux et sources supplémentaires.
Combien de temps garder les mêmes données descriptives sur vos fiches produits ?
Aucune règle Merchant Center n’impose une fréquence fixe pour mettre à jour couleur, taille ou matière. Ce sont des informations plus stables que le prix ou la disponibilité.
La discipline utile n’est donc pas la date de rafraîchissement. Mais la cohérence : le même produit doit porter les mêmes informations sur le site, dans le flux et sur la page de destination. Un format indiqué sur la fiche mais absent du flux, ou une URL qui pointe vers une mauvaise variante, fragilise la donnée produit.
C’est un contrôle à refaire chaque fois que le catalogue change de structure (nouvelle catégorie, nouveaux articles, refonte des titres), pas un chantier ponctuel qu’on classe et qu’on oublie.
item_group_id : l’attribut qui relie les variantes
Donner des identifiants propres à chaque variante ne suffit pas : encore faut-il dire à Google qu’elles appartiennent au même produit. C’est le rôle de l’attribut item_group_id (« item group », le groupe d’articles de la variante), une même valeur partagée par toutes les déclinaisons d’un article.
Sans lui, robe-vert-38 et robe-vert-40 peuvent être traitées comme deux produits séparés plutôt que comme deux variantes d’une même famille. Le moteur perd le regroupement, les filtres de taille et de couleur se dégradent, et la lecture du catalogue devient moins claire.
L’identifiant unique par variante répond à « quel objet ? ». Item_group_id répond à « quelle famille ? ». Il faut les deux.
Condition, multipack, bundle : les trois attributs d’état qu’on oublie de renseigner
Il y a un angle mort récurrent sur les catalogues : l’attribut condition, qui indique si le produit est neuf, reconditionné ou d’occasion. Dès que vous vendez du reconditionné ou de l’occasion, la valeur doit être explicite (`new`, `refurbished`, `used`, en anglais dans le flux).
Le lot de trois savons vu plus haut a deux cousins à distinguer : `multipack`, quand le marchand regroupe plusieurs unités identiques, et `is_bundle`, quand plusieurs produits différents sont vendus ensemble à un prix unique.
Sur un lot que vous constituez vous-même, ne pas renseigner le bon attribut laisse Google interpréter le niveau de prix et l’unité vendue. Le résultat peut être incohérent avec la fiche produit.
Ces trois attributs partagent le défaut des identifiants : personne ne les regarde tant qu’aucune alerte ne tombe, et l’alerte tombe souvent après le lancement de la campagne, pas avant.
Produits multicanaux : quand faut-il séparer les identifiants ?
Un même article peut être vendu en ligne et en magasin avec des prix ou disponibilités différents. Tant que le produit réel reste le même, cette variation se gère via les flux adaptés. En revanche, si le cœur de la fiche change, condition, composition, pack, variante réellement différente, il faut éviter de forcer deux réalités sous un seul id produit.
La leçon prolonge la doctrine de cette page : un identifiant ne se bricole pas pour faire tenir deux produits sous une seule ligne. Le cadrage d’ensemble, structure du flux, sources de données, soumission, relève de votre flux produit Merchant Center. Ici, on retient seulement que l’id doit décrire un produit réel, pas une commodité d’export.
Checklist express : les erreurs d’attributs les plus fréquentes sur un flux
Avant de refaire une page entière de doctrine, voici les vérifications concrètes qui règlent la majorité des cas, au niveau de vos produits un par un.
- GTIN au format EAN, UPC ou ISBN mélangés sans logique : un même product_type qui mélange des articles EAN (Europe) et des articles UPC (import hors zone) sans schéma de colonne dédié finit par produire des erreurs de format lors du contrôle du flux. Indiquez la source du GTIN par ligne si votre catalogue est mixte.
- Titre du produit qui ne reprend pas les mêmes mots que le product_type : si votre titre parle de « pack de 3 », votre product_type doit le refléter en descriptif, au-delà de la catégorie.
- Codes couleur ou format codés en interne (« C12 », « T3 ») au lieu du mot lisible : Google ne devine pas qu’un code fournisseur correspond à « bleu marine » ou à « taille unique », indiquez la valeur explicite, pas la référence fabricant brute.
- URL de la fiche produit qui pointe vers une page supprimée ou une autre variante : un lien mort ou mal ciblé fragilise le raccrochage, même quand tous les autres attributs sont propres.
- Attribut renseigné une fois puis oublié : un emballage qui change de contenance, une unité de vente qui passe du lot à la pièce, un article qui change de fournisseur, la vérification doit suivre vos changements produits, pas un calendrier arbitraire.
Ce guide express ne remplace pas la hiérarchie des trois étages. Il en est la version opérationnelle pour l’équipe qui alimente le flux au quotidien.
Pourquoi les attributs conditionnent-ils tout le reste du flux ?
| Étage | Attributs | À qui il parle | Ce qu’il débloque |
|---|---|---|---|
| Identifiants | GTIN, marque, MPN | Au moteur (quel objet réel) | Le raccrochage produit (faux = refus, absent = visibilité limitée) |
| Catégorisation | google_product_category | Au moteur | Contexte d’enchère et exigences applicables |
| Catégorisation | product_type | Au pilotage Ads et au reporting | Le découpage des campagnes et l’analyse par familles produit |
| Descriptifs | couleur, taille, unité, genre, matière, âge | Au matching | Les requêtes sur lesquelles vous sortez |
Tout ce que cette branche construit ensuite repose sur ces attributs : la couche « trouvable » du flux est faite d’eux, et beaucoup des erreurs qui dégradent un compte Merchant Center naissent ici.
L’audit d’attributs n’est pas le chantier le plus visible du dispositif. C’est pourtant celui dont tous les autres héritent, produit par produit, sur des données qui se corrigent rarement en bloc.
- Trois étages : identifiants (GTIN, marque, MPN) pour dire quel objet réel vous vendez, catégorisation (google_product_category pour la taxonomie Google, product_type pour le pilotage Ads), descriptifs pour le matching.
- Un GTIN faux ou deviné est plus risqué qu’un GTIN absent. Quand aucun code produit unique n’existe vraiment, identifier_exists passe à false.
- Chaque variante porte ses identifiants propres : ne recyclez pas le GTIN du parent.
- Le product_type aide surtout à organiser enchères et rapports. Construisez-le comme vous voudrez analyser et piloter vos familles de produits.
Le mappage du flux : où passent vos attributs avant Google
Un attribut mal placé n’est pas toujours une erreur de saisie : c’est souvent une erreur de mappage, entre votre source (CMS, ERP, tableur) et le schéma attendu par Merchant Center. Trois points de contrôle évitent la majorité des désagréments.
- Le champ source existe. Mais son contenu ne correspond pas à l’attribut attendu. Un champ « référence interne » mappé sur GTIN produit des codes qui ne sont pas des GTIN, une erreur de structure, pas d’absence.
- Les valeurs supplémentaires du flux (custom labels, product highlights) restent vides alors qu’elles pourraient porter une partie de vos descriptifs faute de champ dédié. Elles ne remplacent pas les attributs officiels. Mais elles absorbent l’information qui déborde du schéma standard.
- L’url canonique du produit change sans que le flux suive. Une refonte de plateforme qui modifie la structure des url fragilise le lien entre l’annonce et la page de destination, même si tous les autres attributs restent corrects. L’URL de destination doit être contrôlée dans le flux final.
Indiquer une seule fois, au bon endroit, vaut mieux que corriger dix fois après coup. Un flux propre n’est pas forcément complexe : chaque attribut y a une source claire dans votre schéma de données.
Pour qui c’est critique, et la limite
Revendeurs multi-marques : les GTIN sont prioritaires, parce qu’ils rapprochent vos produits des références déjà connues et comparables. Marques propres et artisans : le sujet principal est plutôt l’honnêteté de `identifier_exists`, la qualité descriptive et la cohérence entre site et flux.
La limite est simple : les attributs rendent votre donnée lisible et classable. Ils ne créent ni demande ni compétitivité. Un flux parfaitement rangé ne compense pas un prix, une offre ou une page produit faibles.
À l’échelle du catalogue, la question devient donc : vos identifiants sont-ils vrais, vos catégories précises, vos variantes distinctes, et votre `product_type` permet-il de piloter comme votre marge l’exige ? Ce guide ne remplace pas un audit ligne à ligne. Il en fixe la grille.
Avant de soumettre : le contrôle en cinq points sur un échantillon de produits
Ne validez pas un flux entier sur la seule confiance dans l’export. Prélevez un échantillon de vingt à trente produits représentatifs de vos catégories, puis vérifiez ligne par ligne :
- Le GTIN correspond au bon niveau d’emballage (unité, pack, lot) et pas à un autre article du même fournisseur.
- Le champ identifier_exists n’est à false que pour des produits qui n’ont réellement aucun code produit unique disponible.
- Le product_type reprend le vocabulaire du titre, pas une classification interne illisible pour qui n’est pas dans votre entreprise.
- Les valeurs des attributs descriptifs (couleur, matière, genre) sont écrites en toutes lettres, pas en codes internes.
- Chaque variante indique bien son propre GTIN et le même item_group_id que ses sœurs.
Cet échantillon révèle souvent les défauts structurels avant qu’ils ne remontent en alertes Merchant Center sur l’ensemble du catalogue. Reproduisez-le à chaque changement de fournisseur, de plateforme ou de méthode d’export.
Trois cas pratiques, pour fixer les idées
Un lot de trois savons vendu comme un seul produit. Si le lot possède son propre GTIN fabricant, indiquez le GTIN du pack, pas celui de l’unité. Sinon, traitez le lot selon sa vraie nature : multipack créé par le marchand ou bundle, selon la composition.
Une gamme de meubles avec des dimensions en option. Les dimensions ne sont pas un product_type : ce sont des valeurs descriptives supplémentaires, au même niveau que la couleur ou la matière. Un canapé 2 places et un canapé 3 places restent le même product_type (« Salon >. Canapés »), avec une unité de mesure différente en attribut descriptif, pas deux branches distinctes de votre arborescence.
Un accessoire vendu sans marque déposée. Si aucun GTIN, MPN ni marque fabricant n’est disponible, identifier_exists à false reste l’option honnête. Inventer une valeur pour combler une case ne crée pas de visibilité fiable.
Ces trois cas couvrent beaucoup d’hésitations récurrentes sur les catalogues e-commerce.
Ce que change un audit d’attributs sur un catalogue existant
Reprendre un flux déjà en ligne n’est pas comme le construire à neuf. Les erreurs se sont accumulées produit après produit, souvent silencieusement. Car Merchant Center n’alerte que sur une partie d’entre elles.
La démarche que j’applique tient en quatre passes, dans cet ordre précis.
Passe 1, les identifiants. On isole les produits en visibilité limitée ou refusés. Puis on distingue les identifiants à retrouver, les identifiants incorrects à remplacer, et les produits sans aucun code produit unique disponible.
Passe 2, la catégorisation. On vérifie que le google_product_category est attribué au niveau de précision maximal disponible pour chaque famille de produits, et que le product_type reflète une arborescence pensée pour vos futurs groupes de produits, pas recopiée du menu du site.
Passe 3, les descriptifs. On croise les attributs structurés avec les mots présents dans vos titres et vos requêtes gagnantes côté Google Ads. Là où les deux divergent, il faut comprendre si le titre manque de précision ou si l’attribut n’est pas remonté au bon endroit.
Passe 4, la cohérence multi-source. Site, flux, et le cas échéant point de vente physique doivent porter les mêmes valeurs pour un même produit. Quand deux réalités produit divergent, il vaut mieux les séparer proprement que les faire tenir sous le même identifiant.
Un catalogue de taille moyenne se traite souvent en quelques jours suivant cette méthode. Un catalogue de plusieurs milliers de produits demande d’abord un échantillonnage rigoureux, puis seulement une correction en masse.
Glossaire rapide des attributs cités sur cette page
| Champ | Rôle | Facultatif ou requis |
|---|---|---|
| GTIN | Identifiant produit normalisé (EAN, UPC, ISBN) | Facultatif au sens du schéma, fortement recommandé en pratique |
| identifier_exists | Indique explicitement l’absence légitime d’identifiant | À utiliser quand aucun code produit unique n’est disponible |
| item_group_id | Regroupe les variantes d’un même article | Requis pour toute famille avec variantes |
| google_product_category | Catégorie officielle Google | Facultatif, utile pour corriger ou préciser la catégorisation Google |
| product_type | Votre propre arborescence de pilotage | Facultatif, très utile pour les enchères et les rapports Google Ads |
Ce tableau sert de mémo : il rappelle quel champ correspond à quel usage, sans remplacer le contrôle ligne par ligne.
Ce qui distingue un attribut « attribué » d’un attribut deviné
Un GTIN attribué par le fabricant porte une garantie que rien d’autre ne remplace : il est enregistré, traçable, et rattaché à un seul produit dans le monde entier. Un GTIN attribué en interne, sur un tableur, sans passer par cette chaîne, n’a de GTIN que la forme, c’est un numéro qui ressemble à un GTIN, pas un GTIN.
La même logique vaut pour la marque et le MPN quand ils servent de repli : la marque doit être celle réellement attribuée au produit par son fabricant, pas une mention commerciale que vous ajoutez pour faire genre « premium ». Le MPN, lui, doit être le code que le fabricant attribue à sa référence, pas une numérotation interne inventée pour la circonstance.
Cette exigence de traçabilité est la même qui structure tout le reste de la page : un attribut n’a de valeur que si sa source est vérifiable. Un champ rempli n’est pas forcément un champ juste, et Merchant Center finit souvent par révéler l’écart.
Le cas des flux multi-pays : mêmes produits, attributs différents
Si vous diffusez le même catalogue de produits sur plusieurs flux, un par pays ou par devise, résistez à la tentation de dupliquer une seule ligne de données pour tous. Certains attributs doivent rester identiques (le GTIN, qui identifie l’objet réel, ne change jamais selon le pays de vente), d’autres doivent impérativement varier : le prix, la disponibilité, et parfois le google_product_category lui-même, quand la taxonomie ou les exigences réglementaires diffèrent d’un pays à l’autre.
Le `product_type` peut rester identique d’un pays à l’autre si votre structure de campagnes est la même partout. La cohérence à préserver ici n’est pas géographique, elle est structurelle : chaque marché garde son propre prix et sa propre disponibilité. Mais l’identité du produit reste stable.
Les erreurs les plus fréquentes sur ce type de flux viennent d’un export unique mal segmenté : une devise appliquée au mauvais pays, un GTIN dupliqué sur un produit qui n’existe en réalité que dans un seul marché. Un contrôle croisé, pays par pays, sur l’échantillon de produits déjà recommandé plus haut, couvre aussi ce risque.
Ce que Merchant Center facture et ne facture pas dans votre décision
Renseigner correctement ces attributs coûte surtout du temps. L’inverse coûte plus cher : un produit refusé arrête sa diffusion, un produit en visibilité limitée perd des opportunités, et un `product_type` pauvre prive les campagnes d’un levier de pilotage.
La priorisation tient en une phrase : commencez par les identifiants, poursuivez par la catégorisation, terminez par les descriptifs. Les trois niveaux n’ont pas le même risque ni la même urgence.
Où renseigner ces attributs selon votre plateforme e-commerce
Shopify, PrestaShop, WooCommerce, ou un flux généré manuellement dans un tableur : la logique des attributs ne change pas, seul l’endroit où vous les renseignez varie.
Sur Shopify, le GTIN se trouve dans le champ « code-barres » de chaque variante, la marque dans le champ dédié, et le product_type dans le champ éponyme. Mais son export brut vers Merchant Center passe le plus souvent par une application tierce qui doit être configurée pour respecter votre arborescence, pas la générer automatiquement à votre place.
Sur PrestaShop, les identifiants vivent dans les fiches produit sous l’onglet associations, et le product_type doit être construit manuellement dans le module d’export, faute de quoi il reprend par défaut la catégorie du site, qui n’est pas conçue pour piloter des campagnes.
Sur WooCommerce, comme vu plus haut, aucun champ GTIN natif n’existe : tout passe par une extension, avec le risque de mappage déjà évoqué.
Dans tous les cas, la vérification finale reste la même : ouvrez le flux final tel qu’il part vers Merchant Center, au-delà de l’interface de votre CMS. Contrôlez que chaque attribut porte la valeur attendue, pas une valeur par défaut générée sans validation.
Un dernier repère : attributs et marché cible
Un attribut correctement renseigné n’a de sens que rapporté au marché sur lequel vous vendez. Une catégorie Google mal adaptée au pays, une devise appliquée au mauvais flux ou un champ WooCommerce mappé sur le mauvais standard produit les mêmes symptômes qu’un attribut faux.
Note sur les extensions WooCommerce
Toutes les extensions WooCommerce de flux Google Shopping ne se valent pas : certaines mappent automatiquement un champ existant sur le GTIN sans vérifier qu’il en contient réellement un, produisant l’erreur de structure déjà décrite plus haut. Avant de choisir une extension WooCommerce, vérifiez qu’elle permet un mappage manuel, champ par champ, plutôt qu’une génération automatique opaque.
Récapitulatif en une phrase par étage
Si vous ne devez retenir qu’une ligne par étage : pour les identifiants, un GTIN vrai vaut mieux qu’un GTIN absent, qui vaut lui-même mieux qu’un GTIN inventé. Pour la catégorisation, `google_product_category` précise la taxonomie Google et `product_type` structure le pilotage. Pour les descriptifs, chaque attribut fiable donne plus de contexte au matching.
Pour finir
Ce contenu couvre l’essentiel des attributs qui déterminent le sort de votre flux, du plus critique (le GTIN) au plus fin (les descriptifs de matching). Reprenez la checklist et le contrôle en cinq points la prochaine fois que vous modifiez votre catalogue ou changez de plateforme e-commerce : c’est là que les erreurs de structure s’installent, silencieusement, en attendant l’alerte Merchant Center.
Une dernière distinction utile : catégorie du site et product_type
Beaucoup de catalogues confondent trois arborescences qui devraient rester distinctes : le menu de navigation du site, pensé pour le visiteur qui clique de rayon en rayon. Le google_product_category, pensé pour la taxonomie officielle de Google. Et le product_type, pensé pour votre pilotage d’enchères. Recopier l’une pour remplir les deux autres produit systématiquement un product_type trop large ou une catégorie Google mal ajustée.
Le test simple : si vous deviez enchérir différemment demain sur deux sous-ensembles de produits, votre product_type actuel permet-il déjà de les isoler ? Si la réponse est non, l’arborescence est à revoir avant le prochain export du flux, pas après.
Attributs et rythme de mise à jour du flux
Merchant Center ne traite pas toujours votre flux instantanément. Chaque plateforme fixe son rythme de soumission : plusieurs fois par jour, quotidien ou manuel selon la méthode choisie.
Un attribut corrigé prend donc effet au prochain cycle de traitement. Si vous corrigez un GTIN incorrect sur un article en cours de refus, attendez la prochaine lecture du flux avant de conclure que la correction a échoué.
Cette latence est une raison de plus pour corriger à la source, dans le CMS, l’ERP ou le tableur maître. Une correction manuelle dans Merchant Center peut être écrasée si le flux source repart avec l’ancienne valeur.
Attributs et audit de compte : par où commencer
Si vous héritez d’un compte Google Ads e-commerce sans connaître l’historique du flux, les attributs sont le premier chapitre de l’audit, avant même de toucher aux enchères ou aux groupes de produits. Un product_type mal construit ou des GTIN douteux faussent tout diagnostic de performance fait plus haut dans la chaîne : on ne sait pas si une campagne sous-performe à cause du ciblage ou à cause d’un catalogue mal segmenté à la source.
L’ordre de vérification : d’abord les identifiants (produits refusés ou en visibilité limitée dans Merchant Center), puis la structure du product_type (cohérente avec les groupes de produits actuels de vos campagnes), enfin les descriptifs (couverture des attributs sur les catégories qui génèrent le plus de volume). Ce triage évite de corriger des symptômes de performance qui ne sont, en réalité, que la conséquence d’attributs mal renseignés en amont.
Le dernier mot
Attribut par attribut, produit par produit, ce guide ramène au même arbitrage : la donnée doit être vraie avant d’être complète.
En résumé pour les pressés
Trois vérités résument cette page : un GTIN inventé est pire qu’un GTIN absent, un `product_type` pauvre appauvrit le pilotage, et un attribut n’a de valeur que si sa source est vérifiable. Une fois ces trois points réglés, les erreurs restantes deviennent plus faciles à isoler.
