Attributs du flux Shopping : GTIN, product_type et données fiables

Chaque offre de votre flux produit Merchant Center porte une identité, une catégorie, des caractéristiques et une destination. Ces valeurs ne sont pas de simples cases à remplir. Un champ requis manquant peut entraîner un refus. Un identifiant officiellement attribué mais omis peut limiter la diffusion ; une valeur fausse peut provoquer un avertissement, une visibilité limitée ou un refus selon le problème.

L’absence n’est pourtant pas une faute lorsqu’aucun identifiant n’existe. La règle dépend du produit, de son état, de sa catégorie, du pays ciblé et de la méthode marketing. Il faut donc partir de l’article réellement vendu, puis lire l’onglet « Attention requise », au lieu d’appliquer une recette uniforme à tout le flux Shopping.

Le contrôle tient en six blocs : identifiants, catégories, données descriptives, variantes et lots, correspondance des champs, puis audit. C’est assez pour corriger ce qui bloque sans ajouter des termes ou des attributs qui n’ont rien à faire là.

1. Identifiants : reconnaître l’article vendu

Trois identifiants se croisent souvent, mais ils ne répondent pas à la même question. L’identifiant d’offre [id] est votre clé dans Merchant Center. Le GTIN [gtin] identifie un article commercial dans le système GS1. La référence fabricant [mpn] vient du fabricant. La marque [brand] complète cette identité.

Merchant Center utilise un seul attribut [gtin] pour les formats GTIN-8, GTIN-12 (UPC), GTIN-13 (EAN ou JAN), GTIN-14 et ISBN-13. L’EAN n’est pas réservé à l’Europe, pas plus que l’UPC ne constitue une identité différente du produit. Et les premiers chiffres d’un EAN-13 n’indiquent ni le pays de fabrication ni l’origine du produit : ils renvoient à l’organisation GS1 qui a attribué le préfixe.

Quand un identifiant a été attribué

S’il existe, fournissez-le. Google recommande fortement le GTIN attribué par le fabricant et l’exige pour certaines catégories ou destinations. Son absence peut limiter la visibilité et, dans certains cas, empêcher la diffusion. La marque et la référence fabricant obéissent à leurs propres règles. Les fournir peut aider Google à comprendre l’article et à enrichir les annonces Shopping ou les fiches gratuites ; cela ne garantit ni classement, ni comparaison, ni performance.

Un article d’occasion ou ancien peut conserver le GTIN attribué lors de sa fabrication. Son état se décrit avec [condition] ; il ne fait pas disparaître son identité. De même, chaque variante reçoit son propre [id] et le GTIN ou le MPN qui lui a été attribué. Le numéro doit correspondre à la couleur, à la taille et au conditionnement vendus, pas au produit parent ni à l’unité contenue dans un pack différent.

Ne cherchez un numéro que s’il est censé exister. Commencez par l’emballage, l’étiquette, le fournisseur ou le fabricant. Une fiche trouvée chez un autre vendeur donne une piste, jamais une preuve. Dans le flux, contrôlez les chiffres, la longueur et la variante. Google ignore les espaces et les tirets dans ce champ, mais je préfère conserver une valeur numérique propre pour éviter les transformations silencieuses entre outils.

Deux vérifications GS1 répondent à deux questions différentes. Le calcul du chiffre de contrôle vérifie la composition numérique. Verified by GS1 interroge la licence, identifie l’organisation à laquelle le numéro est attribué et renvoie les données produit disponibles, parfois limitées au titulaire du préfixe. Un chiffre de contrôle juste ne prouve donc pas que le numéro appartient au bon produit.

Les diagnostics ne se limitent pas à « manquant » et « incorrect ». Vous pouvez rencontrer un code non valide, une longueur erronée, un format non accepté, une plage à circulation restreinte ou une plage réservée aux coupons. Ces plages ont une fonction GS1 ; elles ne signifient pas que Google a reconnu un autre produit. La correction reste concrète : vérifier l’article, la variante, le paquet vendu, la longueur, le chiffre de contrôle et l’attribution. Si aucun numéro n’a été attribué, laissez [gtin] vide.

Quand [identifier_exists] peut être faux

[identifier_exists] à no ou false signifie que le produit ne possède pas les identifiants uniques applicables : aucun GTIN, aucune marque et aucune référence fabricant attribués. Les valeurs booléennes acceptées dans une source textuelle ou XML sont en anglais : yes, true, no ou false. Ne pas connaître un GTIN existant n’est pas un motif valable.

Le fait main, la marque privée ou la vente exclusive ne rendent pas automatiquement ce champ faux. Si vous fabriquez le produit, le nom de votre marque et la référence stable que vous lui attribuez peuvent devenir [brand] et [mpn]. Une pièce réellement sans identifiants reste un cas différent. Les exceptions propres à certaines catégories doivent être vérifiées dans la spécification en vigueur.

2. Catégories : séparer taxonomie Google et taxonomie marchande

[google_product_category] et [product_type] sont deux taxonomies, pas deux versions du même champ.

Google attribue automatiquement une catégorie issue de sa propre classification. La documentation prévoit une substitution manuelle dans des cas définis : lorsque des exigences d’attribut dépendent de la catégorie, lorsque la catégorie sert au ciblage des campagnes Shopping dans Google Ads, ou pour les boissons alcoolisées. Choisissez alors une seule catégorie, celle qui décrit la fonction principale du produit. Descendre plus bas dans l’arbre n’est utile que si le niveau est réellement plus exact.

Cette catégorie peut déterminer des exigences de données. En France, elle peut aussi servir à subdiviser les groupes de produits des campagnes Shopping. Elle ne fixe pas directement une enchère hors de la structure de campagne que vous avez créée.

Le type de produit [product_type] est facultatif et suit votre propre classement. Vous pouvez fournir jusqu’à cinq valeurs ; seule la première est utilisée pour organiser les enchères et les rapports des campagnes Shopping. Dans un chemin, séparez les niveaux avec un chevron > entouré d’espaces. Une valeur pauvre ne provoque pas à elle seule un refus, mais elle peut rendre les subdivisions et les rapports moins utiles.

Le menu du site peut alimenter [product_type] s’il reflète déjà votre logique commerciale. Il n’existe aucune obligation de créer une arborescence artificiellement différente. Le test est opérationnel : les familles que vous devez lire ou piloter séparément existent-elles dans une valeur stable ? Pour une segmentation économique, les libellés personnalisés fondés sur la marge peuvent être plus adaptés qu’un nouveau niveau de catégorie.

Une modification dans le flux ne réécrit pas les groupes de produits déjà subdivisés dans Google Ads. Il faut contrôler ces groupes et les mettre à jour manuellement lorsque leurs valeurs ont changé. Le type de produit est donc un levier parmi la catégorie Google, la marque, l’état, l’identifiant d’article et les libellés personnalisés. Pas le seul.

3. Données descriptives : fournir du contexte vérifiable

Couleur [color], taille [size], sexe [gender], tranche d’âge [age_group] et matière [material] peuvent aider les systèmes Google à comprendre l’article et à le rapprocher de recherches pertinentes. Leur caractère requis dépend du produit, de la catégorie, du pays et de la destination. Leur présence ne garantit ni une requête, ni un filtre, ni une position.

Les champs contrôlés doivent conserver les valeurs prévues par Google. [gender], [age_group] et [condition] utilisent notamment des valeurs anglaises documentées. La couleur et la matière décrivent, elles, le produit dans la langue de la source. Un titre précis n’a pas besoin de recopier mot pour mot [product_type], et ce dernier n’est pas un emplacement pour le nombre d’unités d’un lot.

Le titre [title], la description [description] et l’image principale [image_link] sont aussi des attributs clés : ils présentent l’offre dans les annonces Shopping et les fiches gratuites. Le titre identifie le produit ; la description développe ses caractéristiques sans promesse invérifiable. L’image doit montrer l’article vendu, sans élément promotionnel ajouté. Des images supplémentaires [additional_image_link] peuvent compléter les angles utiles. Leur qualité aide l’utilisateur à évaluer l’offre, mais ne compense ni un identifiant faux ni une page incohérente et ne garantit pas la performance dans les résultats de recherche.

Le point fort du produit [product_highlight] présente des bénéfices lisibles. Les informations détaillées [product_detail] accueillent des caractéristiques techniques vérifiables qui ne disposent pas déjà d’un attribut dédié. Aucun des deux ne remplace la couleur, la taille, la matière ou les identifiants officiels.

Le lien [link] est l’URL de destination, pas une déclaration d’URL canonique. Il doit être accessible et conduire au produit exact. Pour une variante, la bonne option doit être présélectionnée dans une URL distincte ou paramétrée. Le prix et la disponibilité affichés doivent correspondre à l’offre. Une page inaccessible, ou une page qui ouvre systématiquement la mauvaise variante, peut entraîner un refus.

La priorité ne se décide pas au nombre de cases vides. Je regarde d’abord les diagnostics, puis la couverture par catégorie, le volume et la valeur des articles, enfin les termes de recherche réellement observés. Le travail sur les titres des produits Shopping peut révéler une information utile, mais elle doit rejoindre le champ prévu au lieu d’être répétée partout.

Conservez aussi une provenance interne : table produit, PIM, ERP, champ du CMS ou règle d’enrichissement. Cette provenance n’est pas un attribut Merchant Center. C’est ce qui permet de savoir quel flux corriger. Les données d’identité restent stables tant que l’article commercial ne change pas ; prix et disponibilité peuvent varier légalement selon le canal ou le magasin, à condition que chaque offre et sa page restent cohérentes.

4. Variantes, lots et canaux : garder les identités cohérentes

Une variante est une offre, puis un membre de famille

Chaque variante possède son propre [id], ses attributs distinctifs et ses identifiants fabricant lorsqu’ils ont été attribués. Les variantes d’une même famille partagent un [item_group_id]. Pour les fiches gratuites, cet identifiant de groupe est requis pour les variantes ; il l’est aussi pour les annonces Shopping ciblant notamment la France.

La valeur du groupe doit être unique, stable et jamais recyclée. Son absence peut empêcher le regroupement attendu, sans permettre de promettre un affichage ou un filtre précis. Google documente désormais deux attributs complémentaires pour enrichir ce regroupement : [item_group_title] et [variant_option]. Si vous les fournissez, le titre de groupe reste identique et les noms d’options, par exemple couleur et taille, utilisent le même ensemble dans toutes les variantes. Chaque URL ouvre la variante correspondante.

Ne confondez pas les trois niveaux : [id] identifie l’offre, [gtin] l’article commercial, [item_group_id] la famille de variantes. Un canapé deux places et un canapé trois places peuvent être des variantes si l’expérience d’achat et les options les présentent ainsi ; ce n’est pas une règle automatique. Leurs dimensions réelles peuvent être décrites dans [product_detail]. Il n’existe pas de champ générique à inventer pour imposer cette relation.

État, multipack et lot décrivent des choses différentes

• [condition] décrit l’état : new, refurbished ou used.
• [multipack] indique combien de produits identiques le marchand a regroupés pour former une offre.
• [is_bundle] signale un lot créé par le marchand qui associe un produit principal à des articles différents.

Un multipack emballé par le fabricant possède ses propres identifiants de pack ; n’utilisez pas [multipack] pour recopier le nombre d’unités indiqué sur cet emballage. Pour un regroupement créé par le marchand, indiquez le nombre de produits regroupés et les identifiants des produits individuels. Pour un lot créé par le marchand, les identifiants sont ceux du produit principal. Un lot défini par le fabricant utilise les identifiants du lot.

Le titre, la page et le prix doivent décrire ce qui est réellement acheté. Omettre un attribut requis peut faire comprendre une mauvaise composition ou provoquer un refus. Contrôlez donc l’onglet « Attention requise » avant d’activer la diffusion, pas seulement après avoir vu baisser les ventes.

Un même article dans plusieurs pays ou canaux

Le même article commercial conserve son GTIN lorsqu’il est vendu dans un autre pays. Il conserve aussi le même [id] Merchant Center lorsqu’il cible plusieurs pays ou plusieurs langues. En revanche, une composition différente, un emballage réglementaire distinct ou une version linguistique qui crée un autre article commercial peut justifier un nouveau GTIN selon les règles GS1. Le pays, à lui seul, ne suffit pas.

Un même flux peut cibler plusieurs pays si la langue, les données produit, la livraison et la disponibilité conviennent. Google peut convertir automatiquement une devise dans les configurations prévues. Réutiliser le même GTIN d’un pays à l’autre est donc normal ; cibler un pays où l’offre n’est pas achetable ne l’est pas. La taxonomie Google ne change pas parce que le pays change : modifiez la catégorie seulement si le produit ou l’un des cas de substitution documentés le justifie.

Un mauvais ciblage pays, une incohérence de prix, une catégorie inexacte et une mauvaise correspondance de champ ne produisent pas le même diagnostic. Vérifiez-les séparément au lieu de ranger toutes ces erreurs sous une seule étiquette « flux ».

Pour l’en ligne et le magasin, utilisez le même [id] pour associer le même produit et gardez ses attributs d’identité cohérents. Le système multicanal de Google unifie désormais les informations principales. Les prix et disponibilités peuvent venir des sources propres à chaque canal. Si vous avez besoin d’attributs principaux différents, Google recommande des produits distincts avec des [id] distincts.

Une composition, une version réglementaire ou un conditionnement qui crée un autre article commercial reçoit un nouvel [id] et, lorsqu’il est attribué, son propre GTIN. Une simple correction de titre, de catégorie ou d’identifiant erroné ne justifie pas de remplacer l’[id] stable de l’offre.

5. Correspondance des champs : contrôler ce qui sort vraiment

Un champ correct dans le CMS ne prouve rien tant que sa valeur n’arrive pas dans le flux final. La correspondance doit être explicite : champ d’origine, transformation éventuelle, attribut Google, portée produit ou variante. Les règles d’attributs et sources supplémentaires servent à corriger ou enrichir cette chaîne, pas à fabriquer une identité absente.

Google for WooCommerce documente la migration vers ce champ natif pour les installations de son extension en version 2.9.0 ou ultérieure. Une ancienne boutique peut donc avoir des numéros dans un champ personnalisé et un champ natif vide, ou l’inverse. Faites la migration après sauvegarde, puis comparez une variante dans WooCommerce, le flux envoyé et la fiche reçue.

Sur Shopify, ne vous arrêtez pas au nom du champ visible dans l’administration. Ouvrez un produit synchronisé et contrôlez le GTIN de chaque variante, la marque, la catégorie et les attributs propres à la famille. Sur PrestaShop, les références sont documentées ; la construction de [product_type] dépend du module choisi. Toute affirmation du type « la plateforme reprend toujours la catégorie du site » est trop large.

La source qui fait autorité doit être désignée dans votre organisation : PIM, ERP, boutique ou fichier maître. Cette décision est interne. Merchant Center peut agréger plusieurs méthodes, mais vous devez pouvoir remonter de chaque valeur reçue à son propriétaire. Sinon, une correction manuelle tient jusqu’au prochain conflit.

6. Contrôle : corriger par risque et vérifier après traitement

Une méthode d’audit qui ne confond pas échantillon et couverture

1. Ouvrez « Attention requise » et séparez les refus, les limites de visibilité, les avertissements et les simples possibilités d’amélioration.
2. Inventoriez les sources et leurs correspondances. Repérez les changements récents de CMS, d’extension, d’API ou de règle.
3. Constituez un échantillon stratifié par catégorie, marque, état, présence de variantes, source et valeur commerciale. Vingt à trente offres peuvent suffire pour un premier passage ; ce n’est ni une norme ni un substitut au contrôle complet.
4. Pour chaque offre, comparez la fiche source, la ligne du flux envoyée, la valeur reçue et la page de destination.
5. Mesurez ensuite la couverture sur tout le flux. Un échantillon révèle un défaut de système ; il ne prouve pas que les autres lignes sont justes.

Dans cet échantillon, je vérifie au minimum :

• un [id] unique et stable pour chaque offre, y compris chaque variante ;
• le GTIN, la marque et le MPN réellement attribués, y compris sur les marques privées, le fait main et l’occasion ;
• [identifier_exists] à false uniquement dans le cas précis où les identifiants applicables n’existent pas ;
• la catégorie Google exacte pour la fonction principale, pas simplement la branche la plus profonde ;
• un [product_type] utile aux subdivisions prévues, sans exiger qu’il répète le titre ;
• les valeurs contrôlées, les caractéristiques techniques et les options de variantes ;
• la destination présélectionnée, le prix, la disponibilité et la composition vendue ;
• les diagnostics de l’ensemble du catalogue après traitement.

L’ordre de correction s’adapte au risque. Commencez par ce qui refuse une offre ou limite sa diffusion, puis par les articles à forte valeur et les familles touchées par une modification récente. Traitez ensuite les champs qui rendent la segmentation inutilisable. Sur un catalogue sans refus, l’ordre peut donc être différent. Il n’y a pas de doctrine sérieuse qui impose le même triage partout.

Trois cas évitent les faux raccourcis. Une marque privée peut avoir une marque et un MPN sans GTIN. Un article d’occasion peut garder le GTIN du produit neuf tout en passant [condition] à used. Un multipack créé par le marchand reprend les identifiants de l’article individuel et ajoute le nombre regroupé. Le bon résultat vient de l’article vendu, pas d’une valeur par défaut.

Après une correction

Le délai dépend de la source, de son programme de récupération, de l’API, du canal ou de l’exploration. La valeur corrigée doit d’abord être traitée, puis le diagnostic et, s’il y a lieu, l’examen doivent évoluer. Les informations peuvent ensuite demander 24 à 48 heures pour se synchroniser dans les groupes de produits Google Ads. Ce délai documenté n’est pas une promesse de résolution.

Google recommande de modifier la méthode d’importation d’origine. L’éditeur de produits Merchant Center peut être utilisé, mais sa correction remplace celle apportée par une autre méthode. Si vous supprimez une offre dans Merchant Center alors qu’elle reste dans la source, elle sera rajoutée lors de la synchronisation suivante. Corrigez donc la source qui fait autorité et gardez le même [id] pour préserver l’historique.

Après un changement de [product_type], de catégorie ou de libellé, ouvrez les groupes de produits. Les subdivisions existantes ne se mettent pas à jour toutes seules. Après un changement de GTIN, vérifiez le produit reçu, l’onglet « Attention requise » et la procédure d’examen proposée. Les diagnostics repèrent de nombreux défauts de format et d’éligibilité ; ils ne peuvent pas garantir à eux seuls que chaque valeur décrit le bon article.

Ne pas attribuer toute sous-performance au flux

Un type de produit pauvre peut gêner la lecture et la subdivision. Un identifiant requis manquant peut toucher l’éligibilité ou la compréhension. Cela ne transforme pas chaque baisse de chiffre d’affaires en problème d’attributs. L’offre, le prix, la marge, les enchères, la demande, la page de destination, la concurrence ou la mesure peuvent aussi expliquer le résultat.

Je traite donc les données produit comme une hypothèse à confirmer : diagnostics, couverture des champs, groupes réellement utilisés et économie des articles. Corriger un catalogue fiable est utile. Lui faire porter le diagnostic complet du compte ne l’est pas.

Sources Google officielles vérifiées le 21 juillet 2026 : spécification des données produit, GTIN, codes produit uniques, existence d’un identifiant, catégorie Google, type de produit, groupes de variantes, titre de groupe, options de variantes, multipacks, lots, informations détaillées, points forts du produit, identifiants d’offre, groupes de produits, éditeur de produits, gestion des sources, produits multicanaux et ciblage de plusieurs pays.

Sources GS1 officielles vérifiées le 21 juillet 2026 : définition du GTIN, calcul du chiffre de contrôle, Verified by GS1, portée du préfixe GS1 et usage d’un GTIN dans plusieurs pays.

Sources plateformes officielles vérifiées le 21 juillet 2026 : WooCommerce sur le champ natif de la version 9.2 et la migration Google for WooCommerce ; Shopify sur les exigences du canal Google & YouTube ; PrestaShop sur l’emplacement des références produit.

Questions fréquentes

Vincent Duquesne

Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.

Google Partner Premier 2026