Le guide complet des flux de variantes produits

La plupart des problèmes de flux ne ressemblent pas à des problèmes de flux. Ils ressemblent à un refus Google Merchant Center que vous n'arrivez pas à expliquer, à une campagne Advantage+ qui dépense tout son budget sur un seul t-shirt noir, ou à une annonce Shopping qui envoie un client à la recherche d'une chaussure en 42 vers une page où il ne reste que du 38.

Derrière presque tous ces cas se cache la même chose : les variantes.

Une variante est toute version d'un produit qui se distingue par un aspect visible et achetable — taille, couleur, matière, capacité, finition. Elles sont banales dans le commerce et étonnamment complexes dans les flux, car chaque canal les modélise différemment et parce que les erreurs échouent en silence. Rien ne casse. Vos annonces sous-performent simplement sans bruit, et le diagnostic se trouve quatre couches plus bas, dans un fichier de données que personne n'ouvre.

Ce guide couvre l'ensemble du sujet : ce qui compte réellement comme une variante, comment fonctionne item_group_id et où il est mal utilisé, chaque attribut définissant une variante avec ses limites réelles, des exemples de flux fonctionnels en XML, CSV et JSON, la façon dont Google, Meta, TikTok, Pinterest, Amazon et les marketplaces régionales attendent chacun que les variantes soient structurées, et un tableau de diagnostic des erreurs les plus fréquentes.

Il est long parce que le sujet l'est. Utilisez la table des matières pour naviguer.

1. Ce qu'est réellement une variante

Une variante est une version achetable d'un produit qui se distingue de ses déclinaisons sœurs par au moins un attribut entre lequel le client choisit, tout en restant le même produit.

Cette dernière précision est essentielle. Un t-shirt bleu en M et un t-shirt noir en L sont le même produit. Un t-shirt bleu et un sweat à capuche bleu ne le sont pas, même s'ils sont de la même marque et dans le même tissu.

Le modèle standard sur la plupart des canaux est le modèle parent/enfant :

• Le parent est le produit conceptuel — « Merino Crew Neck Sweater ». Il n'est généralement pas achetable en tant que tel.
• Les enfants sont les variantes — chacune avec son propre SKU, son propre niveau de stock, parfois son propre prix et sa propre image.

Dans un flux produits, cela s'exprime presque toujours à plat : chaque variante est une ligne ou un <item> distinct, et une clé de regroupement commune les relie. Il n'y a pas d'imbrication. Un pull décliné en 4 couleurs et 5 tailles représente 20 lignes, portant toutes le même ID de groupe.

Ce qui n'est pas une variante

C'est ici que les flux déraillent avant même qu'une seule ligne de XML soit écrite.

Regrouper l'un de ces cas sous un item_group_id commun produit un groupe dont les membres ne sont pas interchangeables, ce qui perturbe le sélecteur de variantes sur la page de destination et, sur certains canaux, déclenche un refus pour non-concordance.

2. La décision qui conditionne tout

Avant d'écrire la moindre logique de flux, répondez à une question pour chaque type de produit que vous vendez :

Lorsqu'un client choisit une autre option, arrive-t-il sur une page différente, ou sur la même page dans un autre état ?

C'est le test pratique, et il correspond directement à la façon dont vous devez structurer le flux.

Cas A — une URL distincte par variante. Chaque couleur a sa propre page produit (/merino-sweater-navy, /merino-sweater-charcoal). Envoyez chaque variante sur sa propre ligne avec son propre lien. C'est la configuration la plus propre, celle qui offre la meilleure pertinence publicitaire et celle que les canaux préfèrent.

Cas B — une seule URL, variante sélectionnée sur la page. Tout se trouve sur /merino-sweater et le client choisit la couleur et la taille avec un sélecteur. Vous pouvez quand même envoyer chaque variante, mais vous devez ajouter un paramètre de lien profond pour que l'annonce arrive sur le bon état présélectionné :

https://example.com/merino-sweater?colour=navy&size=m

Sans ce paramètre, un acheteur qui a cliqué sur une annonce pour un pull bleu marine en M arrive sur l'état par défaut, qui affiche du gris anthracite en S. Cette non-concordance est l'un des plus grands tueurs silencieux de conversions dans la publicité des variantes, et sur Google elle peut aussi déclencher un refus « Mismatched value (page crawl) », car le robot voit une page dont la couleur visible ne correspond pas à la valeur color transmise.

Cas C — des variantes qui ne valent pas la peine d'être séparées. Certaines déclinaisons n'influencent pas assez la décision d'achat pour justifier des annonces distinctes — la longueur du câble d'un chargeur, par exemple. Vous pouvez alors envoyer délibérément une seule variante représentative. La section 7 explique quand c'est le bon choix.

Attributs définissant la variante ou attributs descriptifs

Chaque attribut de votre flux appartient à l'une de deux catégories, et les confondre est une cause fréquente de groupes mal formés.

Les attributs définissant la variante doivent différer entre les membres du groupe. Ce sont les éléments que le client choisit : color, size, material, pattern, ainsi que des dimensions propres au produit comme la capacité ou la finition.

Les attributs constants au sein du groupe doivent être identiques pour chaque membre : brand, gender, age_group, item_group_title, google_product_category. Si deux lignes partagent un item_group_id mais portent des valeurs gender différentes, soit vous avez mal regroupé les produits, soit vous les avez mal étiquetés.

Les attributs propres à chaque ligne mais ne définissant pas la variante varient d'une ligne à l'autre sans définir la déclinaison : id, price, availability, gtin, image_link, link. Deux variantes peuvent légitimement avoir des prix différents — une taille 3XL coûte souvent plus cher — sans que ce soit le prix qui les distingue.

3. item_group_id : la base

item_group_id est la clé commune qui indique à un canal que « ces lignes sont le même produit ». Tout le reste de la gestion des variantes dépend de sa justesse.

La spécification

Comme Google traite la valeur sans tenir compte de la casse alors que Meta et TikTok en tiennent compte, standardisez partout en minuscules (ou en majuscules). Un catalogue où SWTR-001 et swtr-001 apparaissent tous les deux sera correctement regroupé sur Google et scindé en deux produits sur Meta.

Choisir la valeur

Le meilleur item_group_id est le SKU parent dont vous disposez déjà dans votre ERP ou votre PIM. Il existe, il est stable et il est unique.

Bon :

SWTR-MERINO-CREW
12345
parent-8891

Mauvais, et pourquoi :

Ce dernier point mérite d'être souligné. item_group_id doit rester stable dans le temps. Les canaux accumulent un historique de performances pour le groupe. Si votre export régénère les ID, vous réinitialisez cet historique à chaque synchronisation, et aucune optimisation des enchères ne pourra compenser.

Les trois règles

1. Tous les membres d'un groupe partagent le même item_group_id.
2. Chaque membre a un id unique. Un id en double où que ce soit dans le flux entraîne la suppression silencieuse de la ligne suivante.
3. Chaque membre diffère par au moins un attribut définissant la variante. Deux lignes ayant le même ID de groupe et la même couleur et la même taille sont des doublons, pas des variantes.

Une convention qui respecte les trois règles :

item_group_id: SWTR-MERINO-CREW
id:            SWTR-MERINO-CREW-NAV-M
id:            SWTR-MERINO-CREW-NAV-L
id:            SWTR-MERINO-CREW-CHR-M

Lisible, facile à déboguer, dérivée de données que vous possédez déjà.

item_group_title

Un attribut Google plus récent, facultatif mais recommandé dès que vous soumettez item_group_id. Il contient le nom du produit parent — 150 caractères maximum — et doit être identique pour toutes les variantes du groupe.

xml

<g:item_group_id>SWTR-MERINO-CREW</g:item_group_id>
<g:item_group_title>Merino Crew Neck Sweater</g:item_group_title>
<title>Merino Crew Neck Sweater — Navy, Medium</title>

Notez le principe : title est propre à la variante, item_group_title ne l'est pas. Envoyer la même chaîne dans les deux gaspille le signal.

variant_option

Également récent côté Google : un moyen structuré de déclarer quelles propriétés définissent la déclinaison, au lieu de laisser le canal les déduire. Il accepte jusqu'à 30 paires nom/valeur (chaque sous-attribut jusqu'à 250 caractères, 5 000 caractères au total).

xml

<g:variant_option>
  <g:name>Colour</g:name>
  <g:value>Navy</g:value>
</g:variant_option>
<g:variant_option>
  <g:name>Size</g:name>
  <g:value>M</g:value>
</g:variant_option>

C'est particulièrement utile pour les produits dont les axes de déclinaison ne sont pas couverts par les attributs mode standard — capacité de stockage, gamme de processeur, puissance, nombre de places. Plutôt que de forcer « 256GB » dans size, vous le déclarez correctement.

4. Les attributs définissant les variantes, en détail

color

L'attribut le plus encadré de la spécification, et celui qui est le plus souvent refusé.

Non accepté :

• Des nombres — Colour 42, RAL 5013
• Des codes hexadécimaux — #001F5B
• Des lettres seules — N pour navy
• Des renvois à une image — see photo
• Des valeurs alphanumériques ou des mots accolés — Navy1, NavyBlue (écrire Navy Blue)

Gérer les noms de couleurs marketing. Les marques de mode appellent rarement une couleur « navy ». Elles l'appellent « Midnight Regatta ». Le canal a besoin d'une couleur qu'un acheteur rechercherait ; votre marque a besoin de son propre nom sur la page.

Le compromis praticable :

color:       Navy
description: ...available in Midnight Regatta (navy)...

Faites correspondre les noms marketing à des noms standard dans le flux, et gardez le nom de la marque visible sur la page de destination et dans la description. Ne mettez pas le nom marketing dans color en espérant que ça passe : cela dégrade la correspondance avec les requêtes qualifiées par une couleur, qui comptent parmi les recherches à plus forte intention dans la mode.

Produits multicolores :

color: Navy/White/Grey

La couleur principale en premier. Google lit la première valeur comme la couleur dominante.

size

La règle qui compte : soyez suffisamment précis pour lever toute ambiguïté, et cohérent dans tout le catalogue. M convient si tous les produits utilisent M. Un flux qui mélange M, Medium, med et M/L pour la même notion fragmente vos groupes de variantes et rend impossible toute segmentation par taille.

Pour les produits où une seule dimension ne suffit pas, incluez les dimensions distinctives dans la valeur :

size: 32/34          (waist/inseam)
size: 15.5/34        (neck/sleeve)
size: 9.5 Wide       (shoe width)
size: 200x140cm      (rugs, bedding)

size_type et size_system

Facultatifs, réservés à la mode et sous-utilisés : tous deux améliorent nettement la correspondance pour les acheteurs qui recherchent avec ces qualificatifs.

size_type — jusqu'à 2 valeurs parmi : regular, petite, maternity, big, tall, plus.

size_system — une valeur parmi : US, UK, EU, DE, FR, JP, CN, IT, BR, MEX, AU. S'il est omis, le canal suppose le système du pays cible, ce qui est à l'origine d'une défaillance précise et coûteuse : un e-commerçant turc qui vend en Allemagne avec des tailles EU mais sans size_system déclaré peut voir ses tailles interprétées selon la mauvaise échelle.

xml

<g:size>10</g:size>
<g:size_system>UK</g:size_system>
<g:size_type>regular</g:size_type>

material

200 caractères maximum sur Google. La matière principale en premier, puis jusqu'à deux matières secondaires séparées par /.

material: Cotton
material: Leather/Suede
material: Merino Wool/Nylon/Elastane

Obligatoire uniquement si elle distingue vos variantes — un sac vendu en cuir et en toile. Sinon facultatif, mais utile à transmettre : la matière est un qualificatif de recherche courant.

pattern

100 caractères maximum. Texte libre décrivant l'imprimé ou le graphisme : Striped, Polka Dot, Paisley, Floral, Herringbone. Même règle : obligatoire si c'est ce qui varie.

age_group et gender

Tous deux sont constants au sein du groupe. Chaque variante d'un groupe doit porter la même valeur.

age_group : newborn, infant, toddler, kids, adult — une valeur par produit.

gender : male, female, unisex.

Si un vêtement est réellement proposé en coupe homme et en coupe femme, il s'agit de deux groupes d'articles distincts, et non d'un seul groupe au genre mixte. Les coupes diffèrent, les tailles diffèrent, et l'acheteur choisit entre des produits plutôt qu'entre des options.

Tableau de référence

5. Exemples de flux réels

XML (Google RSS 2.0)

Deux variantes d'un groupe de six. Observez ce qui change et ce qui ne change pas.

xml

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Example Store — Product Feed</title>
    <link>https://example.com</link>

    <item>
      <g:id>SWTR-MERINO-CREW-NAV-M</g:id>
      <g:item_group_id>SWTR-MERINO-CREW</g:item_group_id>
      <g:item_group_title>Merino Crew Neck Sweater</g:item_group_title>
      <title>Merino Crew Neck Sweater — Navy, Medium</title>
      <description>Fine-gauge 100% merino wool crew neck. Ribbed cuffs and hem, regular fit. Machine washable on wool cycle.</description>
      <link>https://example.com/merino-crew-sweater?colour=navy&amp;size=m</link>
      <g:image_link>https://cdn.example.com/swtr-merino-navy-1.jpg</g:image_link>
      <g:additional_image_link>https://cdn.example.com/swtr-merino-navy-2.jpg</g:additional_image_link>
      <g:availability>in_stock</g:availability>
      <g:price>89.00 EUR</g:price>
      <g:brand>Example</g:brand>
      <g:gtin>5012345678900</g:gtin>
      <g:mpn>SW-MC-NAV-M</g:mpn>
      <g:condition>new</g:condition>
      <g:google_product_category>1604</g:google_product_category>
      <g:color>Navy</g:color>
      <g:size>M</g:size>
      <g:size_system>EU</g:size_system>
      <g:size_type>regular</g:size_type>
      <g:material>Merino Wool</g:material>
      <g:gender>male</g:gender>
      <g:age_group>adult</g:age_group>
      <g:custom_label_0>core</g:custom_label_0>
      <g:custom_label_1>full-size-run</g:custom_label_1>
    </item>

    <item>
      <g:id>SWTR-MERINO-CREW-CHR-L</g:id>
      <g:item_group_id>SWTR-MERINO-CREW</g:item_group_id>
      <g:item_group_title>Merino Crew Neck Sweater</g:item_group_title>
      <title>Merino Crew Neck Sweater — Charcoal, Large</title>
      <description>Fine-gauge 100% merino wool crew neck. Ribbed cuffs and hem, regular fit. Machine washable on wool cycle.</description>
      <link>https://example.com/merino-crew-sweater?colour=charcoal&amp;size=l</link>
      <g:image_link>https://cdn.example.com/swtr-merino-charcoal-1.jpg</g:image_link>
      <g:availability>out_of_stock</g:availability>
      <g:price>89.00 EUR</g:price>
      <g:brand>Example</g:brand>
      <g:gtin>5012345678931</g:gtin>
      <g:mpn>SW-MC-CHR-L</g:mpn>
      <g:condition>new</g:condition>
      <g:google_product_category>1604</g:google_product_category>
      <g:color>Charcoal</g:color>
      <g:size>L</g:size>
      <g:size_system>EU</g:size_system>
      <g:size_type>regular</g:size_type>
      <g:material>Merino Wool</g:material>
      <g:gender>male</g:gender>
      <g:age_group>adult</g:age_group>
      <g:custom_label_0>core</g:custom_label_0>
      <g:custom_label_1>broken-size</g:custom_label_1>
    </item>

  </channel>
</rss>

Quatre points à souligner :

1. item_group_id et item_group_title sont identiques ; id et title ne le sont pas.
2. link comporte des paramètres de lien profond pour que l'annonce arrive sur le bon état présélectionné. Le & est échappé en &amp; — obligatoire en XML, et source fréquente d'échecs d'analyse.
3. image_link est propre à la variante. Les lignes navy pointent vers la photo navy. Envoyer une seule image principale pour toutes les couleurs est la deuxième erreur de variantes la plus fréquente, après l'absence d'ID de groupe.
4. La ligne en rupture de stock est étiquetée via custom_label_1, pour pouvoir être exclue ou voir son enchère baisser sans être retirée du flux.

CSV / TSV

Les mêmes données, mises à plat. Une ligne d'en-tête et deux variantes :

csv

id,item_group_id,item_group_title,title,description,link,image_link,availability,price,brand,gtin,condition,google_product_category,color,size,size_system,material,gender,age_group,custom_label_0
SWTR-MERINO-CREW-NAV-M,SWTR-MERINO-CREW,Merino Crew Neck Sweater,"Merino Crew Neck Sweater — Navy, Medium","Fine-gauge 100% merino wool crew neck.",https://example.com/merino-crew-sweater?colour=navy&size=m,https://cdn.example.com/swtr-merino-navy-1.jpg,in_stock,89.00 EUR,Example,5012345678900,new,1604,Navy,M,EU,Merino Wool,male,adult,core
SWTR-MERINO-CREW-CHR-L,SWTR-MERINO-CREW,Merino Crew Neck Sweater,"Merino Crew Neck Sweater — Charcoal, Large","Fine-gauge 100% merino wool crew neck.",https://example.com/merino-crew-sweater?colour=charcoal&size=l,https://cdn.example.com/swtr-merino-charcoal-1.jpg,out_of_stock,89.00 EUR,Example,5012345678931,new,1604,Charcoal,L,EU,Merino Wool,male,adult,core

C'est en CSV que surviennent la plupart des problèmes concrets, car les virgules dans les titres et les descriptions doivent être placées entre guillemets, et les guillemets à l'intérieur de champs entre guillemets doivent être échappés. Si vos titres contiennent des virgules — et c'est presque toujours le cas des titres produits avec couleur et taille —, utilisez plutôt le TSV. Les tabulations n'apparaissent quasiment jamais dans les données produits, et toute une catégorie de bugs d'analyse disparaît.

JSON

Pour une intégration via API :

json

{
  "products": [
    {
      "id": "SWTR-MERINO-CREW-NAV-M",
      "item_group_id": "SWTR-MERINO-CREW",
      "item_group_title": "Merino Crew Neck Sweater",
      "title": "Merino Crew Neck Sweater — Navy, Medium",
      "link": "https://example.com/merino-crew-sweater?colour=navy&size=m",
      "image_link": "https://cdn.example.com/swtr-merino-navy-1.jpg",
      "availability": "in_stock",
      "price": { "value": "89.00", "currency": "EUR" },
      "brand": "Example",
      "gtin": "5012345678900",
      "condition": "new",
      "google_product_category": "1604",
      "variant_attributes": {
        "color": "Navy",
        "size": "M",
        "size_system": "EU",
        "material": "Merino Wool"
      },
      "gender": "male",
      "age_group": "adult"
    }
  ]
}

Une grille de tailles complète

Six variantes — deux couleurs × trois tailles —, avec le schéma d'ID apparent :

En Charcoal, il ne reste qu'une taille sur trois. La section 9 explique comment réagir.

6. Canal par canal

Le concept est universel. Sa mise en œuvre ne l'est pas. Voici comment chaque grande destination attend les variantes, et en quoi chacune diffère.

Google Shopping / Merchant Center

Le plus prescriptif, et l'implémentation de référence dont s'inspirent la plupart des autres canaux.

• item_group_id est obligatoire pour les fiches gratuites, ainsi que pour les annonces Shopping au Brésil, en France, en Allemagne, au Japon, au Royaume-Uni et aux États-Unis, dès que des variantes sont soumises.
• Les attributs définissant les variantes doivent être renseignés : color et size sont obligatoires pour la mode sur ces marchés.
• gender et age_group sont obligatoires pour la mode et doivent être cohérents au sein du groupe.
• La page de destination doit correspondre visiblement aux valeurs de variante transmises, faute de quoi vous risquez un refus Mismatched value (page crawl).
• Chaque variante est en concurrence de manière indépendante dans l'enchère. Google choisit quel membre d'un groupe afficher pour une requête donnée : un groupe incomplet signifie donc un vivier de candidats plus faible.
• image_link doit mesurer au moins 500×500 pixels pour la mode — un minimum appliqué à partir du 31 janvier 2027, qu'il vaut mieux auditer dès maintenant plutôt que dans l'urgence.

Remarque pratique : Merchant Center produit ses rapports au niveau de la variante (id), et non du groupe. Pour évaluer correctement un produit, vous devez agréger vous-même par item_group_id, ce qui est bien plus simple si l'ID de groupe est propre et stable.

Meta (Facebook et Instagram)

Meta utilise le même nom de champ, avec des contraintes différentes et un modèle d'affichage sensiblement différent.

• item_group_id accepte jusqu'à 100 caractères et est sensible à la casse.
• color et size acceptent jusqu'à 200 caractères.
• Les valeurs de disponibilité utilisent des espaces, et non des tirets bas : in stock, et non in_stock. Cette seule différence casse plus de flux Meta que toute autre, surtout lorsqu'un flux Google est réutilisé tel quel.
• Dans Shops et sur les surfaces de détail produit, un ensemble correctement regroupé s'affiche comme un seul produit avec un sélecteur de variantes, plutôt que comme plusieurs fiches quasi identiques.
• Les annonces catalogue Advantage+ utilisent le groupe pour éviter de montrer à un utilisateur six versions du même pull dans un seul carrousel : un catalogue non regroupé produit des annonces visiblement répétitives et des impressions gaspillées.
• Les rapports au niveau des variantes dans Commerce Manager dépendent d'un regroupement correct.

Remarque pratique : ne branchez pas Meta sur votre flux Google sans le modifier. Au minimum, transformez availability et vérifiez les limites de caractères. La plupart des plateformes de flux — Feedance compris — traitent cela comme une transformation au niveau du canal, de sorte que les données sources restent intactes.

TikTok

• item_group_id accepte jusqu'à 150 caractères.
• sku_id est l'identifiant unique par variante : chaque ligne de variante doit avoir une valeur distincte.
• color et size acceptent jusqu'à 200 caractères.
• title accepte jusqu'à 255 caractères, description jusqu'à 10 000 ; google_product_category est attendu.
• TikTok est le canal le plus exigeant en matière d'images propres à chaque variante. Les cartes produits affichent un sélecteur de variantes, et les variantes qui partagent une seule image générique performent nettement moins bien. Si vous devez faire l'impasse sur un point de votre chaîne de production d'images, ne le faites pas ici.

Pinterest

• Suit de près le modèle de Google ; item_group_id regroupe les variantes.
• Pinterest présente les variantes au sein d'une seule Product Pin avec des options sélectionnables.
• La qualité des images et les formats verticaux comptent de façon disproportionnée : Pinterest est une surface de découverte visuelle, et les images de variantes qui ne se distinguent pas ne sont tout simplement pas enregistrées.

Amazon

Amazon n'utilise pas item_group_id, et supposer le contraire fait perdre beaucoup de temps.

Amazon utilise un modèle de relation parent/enfant explicite :

• Un ASIN parent est créé sous forme de fiche non achetable.
• Chaque ASIN enfant référence le parent via les champs parent_sku / parent_child.
• Un thème de variation doit être déclaré — SizeColor, Size, Color, SizeName-ColorName, etc., selon la catégorie.
• Le thème doit être valide pour cette catégorie précise ; un même nom de thème n'est pas disponible partout.

Si vous exportez vers Google et Amazon à partir d'une même source, traitez cela comme une véritable transformation, et non comme un simple renommage de champ. Votre couche de flux doit construire la fiche parent, attribuer le thème et y rattacher les enfants.

Marketplaces régionales et comparateurs de prix

Les canaux turcs et, plus largement, ceux de la région MENA ont chacun leurs propres conventions, et ce sont souvent elles qui font la différence entre un catalogue qui fonctionne et un catalogue cassé sur ces marchés.

• Trendyol utilise son propre modèle parent/enfant avec un jeu d'attributs obligatoire propre à chaque catégorie. La couleur et la taille sont des champs structurés distincts, et les listes d'attributs obligatoires varient selon la catégorie.
• Akakçe et Cimri sont des comparateurs de prix. Ils attendent généralement une ligne par SKU achetable, et les lignes en double quasi identiques ont tendance à être filtrées : envoyer une grille de tailles complète sans données différenciées peut donc réduire la visibilité au lieu de l'augmenter.
• Hepsiburada et N11 définissent chacun leurs propres clés de regroupement des variantes et leurs attributs obligatoires.

C'est le domaine où les outils de flux génériques et mondiaux montrent le plus souvent leurs limites, et où un attribut mal mappé fait disparaître discrètement toute une catégorie d'une marketplace.

Comparatif

7. Séparer ou regrouper ?

Envoyer chaque variante est la recommandation par défaut, mais elle n'est pas toujours juste. La vraie question est de savoir si la déclinaison change ce que veut l'acheteur.

Envoyez chaque variante lorsque…

• La déclinaison est la décision d'achat. Mode, chaussures, tout ce pour quoi la mauvaise taille signifie une vente perdue.
• Le stock diffère sensiblement d'une variante à l'autre. Promouvoir un produit dont la seule option restante est une taille 3XL gaspille du budget.
• Le prix diffère selon la variante. Afficher 89 € alors que l'option sélectionnée coûte 119 € produit une non-concordance de prix et un client mécontent.
• La demande de recherche est qualifiée par variante. Les internautes recherchent « navy merino sweater medium ». Vous ne pouvez pas vous positionner sur cette requête sans la transmettre.

Regroupez sur une variante représentative lorsque…

• Le catalogue est très volumineux et majoritairement homogène. Un distributeur de quincaillerie comptant 200 000 SKU, dont 60 % ne sont que des variations de longueur sans importance, gagne peu à tout détailler et le paie en traitement du flux et en complexité de campagnes.
• Le canal pénalise les quasi-doublons. Plusieurs comparateurs filtrent les lignes répétitives ; une grille de tailles complète peut réduire la visibilité.
• La déclinaison n'affecte ni le prix, ni l'image, ni la disponibilité. Si les douze variantes sont identiques sur tous les plans commercialement pertinents, douze lignes créent du bruit plutôt que du signal.

Lorsque vous regroupez, choisissez délibérément la variante représentative : la variante en stock la plus vendue, et non la première ligne par ordre alphabétique. C'est précisément là que les données de performance justifient leur place dans le flux : les données GA4 ou des plateformes peuvent sélectionner automatiquement la variante représentative au lieu de laisser faire l'ordre de tri.

Une voie intermédiaire

Séparez sur l'axe qui guide la décision ; regroupez sur celui qui ne la guide pas.

Pour les chaussures, cela signifie généralement une ligne par couleur, tailles regroupées : la couleur est l'axe de découverte, la taille est la vérification d'ajustement qui se fait sur la page. Pour un produit dont la capacité détermine le prix, séparez sur la capacité et regroupez sur la couleur.

8. Les 12 erreurs de variantes les plus courantes

Les erreurs 1, 2, 4 et 11 représentent la grande majorité de ce que nous observons lors d'audits réels. Aucune n'est difficile à corriger ; toutes sont invisibles tant que personne ne les cherche.

9. Tailles cassées et santé des stocks

Une grille de tailles cassée (broken size) désigne un produit dont le groupe est techniquement en ligne mais pratiquement invendable : un pull disponible uniquement en XS et en 3XL, une chaussure dont il ne reste que deux tailles sur neuf.

C'est plus important qu'il n'y paraît. Lorsqu'un acheteur clique sur une annonce et découvre que sa taille n'est pas disponible, vous avez payé un clic qui ne pouvait pas convertir, et vous avez entamé au passage le capital sympathie de votre marque. À grande échelle, les produits aux tailles cassées peuvent absorber une part significative du budget tout en ne contribuant presque pas au chiffre d'affaires.

Le détecter

Calculez, pour chaque item_group_id :

size_availability_ratio = in_stock_variants / total_variants

Puis agissez selon des seuils. Un point de départ praticable :

Pondérez ce ratio par la demande, et pas seulement par le nombre. Perdre le XXS et le XXL compte bien moins que perdre le M et le L, qui représentent généralement l'essentiel du volume. Un ratio qui traite toutes les tailles de la même façon réagira trop faiblement à la perte de vos tailles principales.

Agir

L'implémentation la plus propre consiste à étiqueter la situation dans le flux plutôt qu'à retirer le produit :

xml

<g:custom_label_1>broken-size</g:custom_label_1>

Étiqueter plutôt que supprimer préserve l'historique du produit dans le canal et permet de le réactiver instantanément lorsque le stock revient. Retirer puis réajouter réinitialise l'apprentissage.

Deux améliorations supplémentaires méritent d'être mises en place :

• Alimenter le merchandising. Une liste récurrente de tailles cassées est un signal d'achat, et pas seulement un problème publicitaire.
• Revérifier à chaque synchronisation. Le stock évolue ; l'étiquette doit suivre. Une liste statique de tailles cassées est pire que pas de liste du tout, car elle bloque des produits qui ont depuis été réapprovisionnés.

10. Utiliser les variantes pour segmenter les campagnes

Une fois les variantes correctement structurées, les données deviennent une couche de segmentation — sans doute l'usage le plus rentable d'un flux de variantes propre.

Google propose cinq champs custom_label (0–4). Ils acceptent des valeurs libres et n'existent que pour votre propre logique de campagne. Les données de variantes constituent une entrée idéale.

Un schéma praticable

Une fois ces labels en place, la logique de campagne devient simple :

• Augmentez les enchères sur bestseller + full-size-run + high-margin
• Excluez broken-size de la prospection
• Donnez à clearance sa propre campagne avec un tROAS agressif
• Isolez ss26 au lancement de la saison

Performance Max et Advantage+

Tous deux sont largement automatisés, ce qui rend la segmentation au niveau du flux plus importante, et non moins. Vous ne contrôlez plus les enchères au niveau des mots-clés : le flux devient votre principal levier pour orienter les dépenses.

Dans Performance Max, les custom labels pilotent la structure des groupes d'assets et groupes de fiches. Scinder un groupe d'assets fourre-tout en groupes fondés sur la marge ou sur la santé du stock est l'un des rares leviers structurels qui subsistent, et il dépend entièrement de labels alimentés par des données réelles.

Dans les annonces catalogue Advantage+, un regroupement correct évite que le carrousel se remplisse de six coloris du même pull, et des ensembles de produits définis à partir des attributs de variantes vous permettent de séparer l'inventaire de prospection de celui de retargeting.

Enrichir les labels avec les données de performance

Les labels statiques se dégradent. Un bestseller attribué la saison dernière est une information erronée cette saison.

L'implémentation la plus solide recalcule les labels à partir des données de performance en direct — chiffre d'affaires GA4, taux de conversion, nombre de vues — à chaque synchronisation du flux. Un produit qui ne se vend plus sort automatiquement de bestseller ; un produit qui commence à se vendre y entre. C'est un élément central de ce que signifie concrètement l'enrichissement des flux, et c'est la différence entre des labels qui orientent le budget et des labels qui ne font que décrire le trimestre précédent.

11. Mesurer les performances des variantes

C'est au niveau des variantes que la plupart des rapports s'effondrent sans bruit.

Le problème de l'agrégation. Merchant Center et Ads produisent leurs rapports au niveau de l'id. Un pull décliné en 20 variantes apparaît sur 20 lignes, chacune avec une fraction du volume, aucune n'étant significative isolément. Toute conclusion tirée d'une seule ligne de variante relève probablement du bruit.

Analysez toujours à deux niveaux :

1. Niveau du groupe (item_group_id) : ce produit fonctionne-t-il ? Agrégez les dépenses, les conversions et le chiffre d'affaires de tous les membres.
2. Niveau de la variante (id) : quelles options fonctionnent ? Quelles couleurs se vendent, quelles tailles s'épuisent en premier, quelles combinaisons ne bougent jamais.

C'est au second niveau que se trouvent les enseignements intéressants. Il répond aux questions qui intéressent le merchandising : le navy se vend-il trois fois plus que le charcoal ? Les variantes en L convertissent-elles mieux parce qu'elles sont toujours en stock ? Une couleur tire-t-elle la moyenne du groupe vers le bas ?

Indicateurs à suivre par groupe :

Une remarque sur l'attribution. Un acheteur voit souvent une annonce pour une variante et en achète une autre : il clique sur le navy et achète le charcoal. Un ROAS par variante pris au pied de la lettre attribuera donc mal les ventes. Jugez les produits au niveau du groupe ; utilisez les données de variantes pour comprendre les comportements, et non pour prendre des décisions d'enchères sur de petits échantillons.

12. Checklist avant lancement

Passez-la en revue avant de mettre en ligne un flux de variantes, et après toute modification structurelle.

Structure

•  Chaque variante a un id unique
•  Tous les membres d'un groupe partagent un item_group_id identique
•  item_group_id est dérivé d'un champ source stable et ne change pas d'un export à l'autre
•  item_group_id utilise une casse cohérente dans tout le flux
•  Chaque membre diffère par au moins un attribut définissant la variante
•  item_group_title est présent et identique dans tout le groupe

Attributs

•  color utilise des noms de couleurs simples — pas de codes hexadécimaux, de nombres ni de lettres seules
•  Les couleurs multiples sont séparées par /, la principale en premier
•  Les valeurs size sont normalisées dans tout le catalogue
•  size_system est déclaré lorsque vous vendez dans plusieurs zones de tailles
•  gender et age_group sont identiques au sein de chaque groupe
•  material et pattern sont renseignés lorsqu'ils définissent la déclinaison

Liens et images

•  Le link de chaque variante renvoie vers le bon état présélectionné
•  & est échappé en &amp; dans le XML
•  image_link est propre à la variante, et non une image principale partagée
•  Les images respectent les dimensions minimales de chaque canal

Transformations par canal

•  Syntaxe d'availability adaptée à chaque canal (in_stock ou in stock)
•  Limites de caractères respectées pour chaque canal
•  Les exports Amazon construisent les fiches parents et déclarent un thème de variation valide
•  Jeux d'attributs des marketplaces régionales mappés par catégorie

Opérations

•  La fréquence de mise à jour correspond à la vitesse réelle de rotation du stock
•  La détection des tailles cassées s'exécute à chaque synchronisation
•  Le contrôle des id en double s'exécute avant l'export
•  Le flux est validé comme XML/CSV bien formé avant publication
•  Des alertes sont configurées en cas de chute soudaine du nombre de produits

13. FAQ

Dois-je soumettre absolument toutes les variantes ? Pas toujours, mais généralement oui pour la mode et les chaussures, où la taille et la couleur constituent la décision d'achat. Pour les catalogues très volumineux et homogènes, ou pour les canaux qui filtrent les quasi-doublons, soumettre une seule variante représentative bien choisie par groupe peut donner de meilleurs résultats. Choisissez-la selon les ventes et le stock, et non par ordre alphabétique.

Que se passe-t-il si j'omets item_group_id ? Chaque variante est traitée comme un produit sans lien avec les autres. Vous perdez le sélecteur de variantes sur la surface de destination, les annonces deviennent répétitives, les rapports au niveau des variantes ne fonctionnent plus et, sur Google, vous risquez de ne pas respecter une exigence : item_group_id est obligatoire pour les fiches gratuites et pour les annonces Shopping sur plusieurs grands marchés lorsque des variantes sont soumises.

Les variantes peuvent-elles avoir des prix différents ? Oui. Le prix n'est pas un attribut définissant la variante, mais il peut légitimement différer d'une variante à l'autre : les grandes tailles coûtent souvent plus cher. Le prix transmis doit correspondre à celui qu'affiche la page de destination pour cette variante précise.

Les variantes en rupture de stock doivent-elles rester dans le flux ? En général, oui. Conservez-les avec availability: out_of_stock plutôt que de les supprimer. Les retirer puis les réajouter réinitialise l'historique de l'article dans le canal. Excluez-les plutôt des campagnes actives à l'aide d'une règle ou d'un custom label.

Un produit peut-il appartenir à deux groupes ? Non. item_group_id n'accepte qu'une seule valeur par article. Si un produit appartient réellement à deux groupes conceptuels, vous avez un problème de taxonomie merchandising à résoudre en amont.

Ai-je besoin de valeurs item_group_id distinctes pour chaque canal ? Non, et vous ne devriez pas en avoir. Utilisez le même regroupement logique partout. Ce qui diffère d'un canal à l'autre, c'est la transformation appliquée : limites de caractères, casse, syntaxe. Gardez une source de vérité unique et adaptez-la à l'export.

Comment gérer les produits réellement en taille unique ? Transmettez size avec la valeur one_size, OS ou OSFA. Ne le laissez pas vide pour la mode sur les marchés où la taille est obligatoire.

Versions homme et femme d'un même modèle : un groupe ou deux ? Deux. gender doit être identique au sein d'un groupe. Des coupes et des tailles différentes en font des produits différents du point de vue de l'acheteur.

Qu'est-ce qui casse le plus souvent en pratique ? Dans nos audits : des images principales partagées entre les variantes de couleur, des valeurs item_group_id régénérées à chaque export et une syntaxe d'availability reprise telle quelle d'un flux Google vers Meta. Ces trois problèmes sont invisibles dans l'interface et ne se manifestent que par une sous-performance inexpliquée.

Ce qu'il faut en retenir

Les flux de variantes récompensent la précision comme peu d'autres domaines du marketing digital. Il n'y a aucune part de jugement créatif dans item_group_id : il est stable et partagé, ou il ne l'est pas. Les valeurs de couleur respectent la spécification, ou elles sont refusées. Les images correspondent à la variante, ou le clic est gaspillé.

C'est la bonne nouvelle : c'est un problème soluble, avec une réponse précise. Le travail consiste à maintenir cette rigueur, car les catalogues changent chaque jour, les stocks bougent d'heure en heure et chaque canal ajuste sa spécification selon son propre calendrier.

Les entreprises qui y parviennent traitent le flux de variantes comme une infrastructure et non comme un simple fichier. Elles dérivent les ID de groupe de données sources stables, normalisent les attributs une seule fois à la source, appliquent les transformations propres à chaque canal à l'export, recalculent la santé des stocks à chaque synchronisation et déclenchent des alertes dès qu'un élément évolue de manière inattendue.

C'est précisément pour cette couche qu'a été conçu Feedance : des règles de flux pour normaliser les attributs à la source, une détection Broken Size recalculée à chaque synchronisation, un enrichissement GA4 pour garder les labels de performance à jour, et des exports par canal qui appliquent la bonne transformation pour chacune des plus de 200 destinations, sans toucher à vos données sources.

Si vous voulez savoir où en est votre propre structure de variantes avant de modifier quoi que ce soit, notre outil gratuit d'audit de flux évalue gratuitement un flux existant sur sa complétude, la qualité de ses données et sa santé technique, y compris le regroupement des variantes.