Ces deux outils servent à corriger certaines données de votre flux produit Merchant Center, sans modifier immédiatement le site.
« On corrigera ça à la prochaine mise à jour du site » : la phrase paraît raisonnable, mais elle laisse parfois le flux en attente trop longtemps. Entre votre constat, des titres pauvres, une couleur manquante, une colonne mal nommée, un prix à reprendre, et le déploiement CMS qui le réglerait, il peut y avoir un ticket, un sprint, un prestataire et plusieurs semaines. Pendant ce temps, le catalogue diffuse tel quel, et les campagnes Shopping paient l’écart.
Merchant Center propose deux outils pour traiter une partie de ces cas. Ils transforment les données du catalogue en aval, sans toucher une ligne du site ni son code, avant que Google ne les diffuse dans vos annonces Shopping. Encore faut-il savoir lequel fait quoi, et où s’arrête la correction côté flux.
Comment activer les règles d’attributs dans Merchant Center ?
Détail d’interface qui a coûté des heures à beaucoup : selon la configuration Merchant Center, ces fonctions peuvent ne pas être visibles par défaut. Vérifiez le module complémentaire « Gestion avancée des sources de données » et vos droits d’accès avant de chercher un onglet qui n’apparaît pas.
Au passage, le vocabulaire a changé dans Merchant Center Next : on parle plutôt de règles d’attributs là où beaucoup de process internes disent encore « règles de flux » ou feed rules. Le mécanisme reste le même : transformer une donnée reçue avant sa diffusion.
Règle d’attributs et source supplémentaire : deux métiers distincts
Ces deux outils interviennent à des stades différents et ne sont pas interchangeables.
La règle d’attributs : transformer ce qui existe
Ce mécanisme reprend une donnée déjà envoyée par le fichier amont et la remet au bon format. Mapper une colonne mal nommée vers le champ officiel, réaffecter une catégorie mal classée, corriger le code pays quand il traîne encore un ancien format. Recomposer les titres selon une structure marque + type + caractéristiques, à partir des champs existants : c’est l’outil d’industrialisation des modèles de titres par gamme.
Il peut remplacer des valeurs (« Fuchsia » vers « Rose » pour coller aux libellés standard), extraire une information d’un champ pour en peupler un autre, poser une valeur par défaut quand le champ est vide ou recalculer un prix affiché après une mauvaise conversion de devise. La transformation est conditionnelle, s’exécute à chaque récupération tant qu’elle reste active et réapplique la correction aux articles concernés.
La source supplémentaire : ajouter ce qui manque
La source supplémentaire complète le fichier principal. C’est souvent un simple Google Sheet, relié par l’identifiant de chaque référence. Certains comptes peuvent aussi utiliser une correspondance personnalisée sur un autre champ. Cette table vient enrichir ou écraser les fiches déjà présentes : labels personnalisés absents du CMS (la segmentation par marge en est l’usage fréquent), donnée absente de l’export, correction ponctuelle sur cinquante références ou disponibilité que votre CMS ne remonte pas assez vite.
Elle ne crée pas un catalogue complet et ne supprime pas les articles déjà importés. Elle peut en revanche alimenter des champs d’exclusion ou de destination quand le cas s’y prête.
Combien d’étiquettes personnalisées pouvez-vous utiliser ?
Puisque le label personnalisé est un usage fréquent, autant connaître le format avant de bâtir votre segmentation dessus. Vous disposez de cinq emplacements par référence, custom_label_0 à custom_label_4. Chaque emplacement accepte une valeur par article, avec une limite de 1 000 valeurs uniques par champ dans le compte.
La limite opérationnelle arrive souvent plus tôt : une segmentation trop fine devient vite illisible en rapports comme en pilotage d’enchères, même si l’interface n’affiche pas forcément d’erreur.
Où ça mord en pratique : une segmentation par marge trop fine, une étiquette générée automatiquement à partir d’un identifiant ou d’une référence quasi unique par article. Le compte dilue le signal et une partie de vos mécanismes d’optimisation perd en lisibilité sur un sous-ensemble du catalogue. La correction : redescendre à des valeurs regroupées par tranche ou par catégorie plutôt que par référence individuelle, puis republier le fichier.
Comment choisir : règle, source supplémentaire ou correction CMS ?
Troisième cas : la donnée est structurellement erronée dans le CMS, mauvais prix, mauvaises références, descriptions fausses, images qui ne correspondent plus à l’article. Ni transformation aval ni apport complémentaire : corrigez le CMS, car une erreur bien formatée reste une erreur et la page continue d’afficher ce que Google croisera tôt ou tard.
Le premier outil transforme, le second ajoute, le CMS répare. Confondre les trois fabrique un flux propre en apparence dans Merchant Center, mais contradictoire avec la réalité.
La mécanique des règles d’attributs
Chaque transformation combine un opérateur et des conditions : voici ce que l’ordre d’exécution change.
Les opérateurs disponibles et leur usage
Ce n’est pas un champ libre : vous choisissez un opérateur précis, et chacun fait un seul métier sur les données du catalogue. Les gens cherchent « règles de flux exemples » parce que personne ne nomme le catalogue complet. Voici les principaux, qualifiés par usage, pas par capture d’écran.
- Définir sur : pose une valeur, statique ou composée par concaténation de colonnes existantes. C’est l’opérateur de la recomposition de titre marque + type + caractéristique.
- Rechercher et remplacer : substitue un texte par un autre, avec options mot entier, casse, et expression régulière pour les cas tordus. L’outil du nettoyage de libellés (« Fuchsia » → « Rose »).
- Ajouter un préfixe / Ajouter un suffixe : colle une chaîne au début ou à la fin de la valeur, sans toucher au reste.
- Extraire : récupère un fragment selon un critère (regex possible) pour peupler un autre champ, typiquement sortir une information ou une valeur de caractéristique noyée dans la description.
- Séparer et sélectionner : découpe une liste délimitée (un
product_typedu type « Maison > Cuisine > Casseroles ») et choisit une position, la dernière par exemple. Utile aussi pour reconstruire une catégorie Google propre à partir d’un intitulé maison. - Calculer : opère sur des valeurs numériques, prix ou poids, convertir une unité, appliquer un coefficient, ou ajuster un prix soldé mal remonté par le CMS.
- Optimiser l’URL : édite ou retire des paramètres du lien produit, utile quand vos codes de tracking parasitent la page de destination.
- Ajouter un champ répété : alimente les valeurs multiples, par exemple images additionnelles, destinations incluses ou exclues, pays exclus Shopping quand le champ le permet.
- Effacer : vide complètement un champ, pour purger un « n/a » ou un texte provisoire parasite sur une série d’articles.
- Sélectionner le plus récent : arbitre entre deux entrées pour le prix ou la disponibilité, détail dans la section suivante.
Le bon opérateur est souvent le plus simple qui fait le travail sur une donnée du catalogue. Un titre à recomposer se traite avec Définir sur et une concaténation, pas trois opérations empilées. Pour les conventions de titres par gamme, l’angle complet est sur optimiser les titres Shopping. Un champ absent de l’export relève d’un apport supplémentaire ou de la doctrine GTIN / product_type quand ils manquent. Un GTIN mal formé se corrige avec la valeur fabricant, ou il est retiré si la référence n’a réellement aucun GTIN attribué.
Chaque opérateur se restreint par des conditions : un champ comparé à une valeur (égal à, contient, est différent de, commence par), avec des combinaisons en ET / OU. C’est ce qui rend l’action ciblée plutôt que globale : recomposer le titre uniquement quand product_type contient « chaussures », ne corriger que les références sans GTIN, ne mettre à jour les images que pour un lot précis ou ne cibler qu’un pays donné quand le catalogue dessert plusieurs marchés. Sans condition, l’action frappe toutes les références ; c’est rarement ce que vous voulez.
Quand utiliser « Sélectionner le plus récent » entre deux flux ?
Cas précis, souvent découvert trop tard : le fichier principal et une table complémentaire alimentent tous deux le prix ou la disponibilité, mais ils ne sont pas synchronisés à la même heure. Le stock bouge dans votre CMS, le prix dans un export tarifaire tiers, et Merchant Center doit choisir la valeur correcte au moment de la lecture.
C’est le métier de Sélectionner le plus récent : arbitrer entre plusieurs entrées sur un même champ quand leur fraîcheur diffère. Son terrain naturel, ce sont les données qui bougent en continu et se contredisent, prix et disponibilité en tête. Pour un titre, une image ou une catégorie, une transformation classique reste souvent plus lisible qu’un arbitrage par fraîcheur.
En pratique, vous configurez l’opérateur en désignant les colonnes à comparer, par exemple le prix du fichier principal contre celui de la table complémentaire, ou la disponibilité de l’un contre celle de l’autre. L’objectif est d’éviter qu’un prix ou un stock ancien écrase une valeur plus fraîche.
Cas utile : un export issu du CMS remonte le stock une fois par jour, tandis qu’un connecteur de caisse ou un PIM actualise la disponibilité toutes les heures dans une table complémentaire. Sans cet arbitrage, vous devez choisir manuellement quelle entrée fait autorité ou accepter un ordre de priorité qui ne colle pas à la réalité des deux flux.
L’ordre d’exécution : la cascade
En cascade, la première opération s’applique, puis la deuxième travaille sur la donnée déjà transformée, et ainsi de suite. L’ordre n’est pas cosmétique : il change le résultat final affiché sur vos annonces Shopping.
Concrètement, remplacer un texte puis en extraire un fragment ne donne pas la même sortie que l’inverse : la seconde opération lit ce que la première a laissé. Et Effacer est terminal : une fois le champ vidé, aucune étape suivante n’a de matière à transformer. C’est la cause classique du « j’ai écrit la configuration, elle ne fait rien » : elle est correcte, mais court-circuitée en amont.
Conséquence directe : l’ordre de la cascade fait partie de l’inventaire, au même titre que le contenu des transformations et les informations modifiées. Une opération isolée se lit ; une cascade non documentée se devine, et au mauvais moment.
Un exemple concret, du symptôme à la règle publiée
Rien ne vaut un cas réel pour fixer la mécanique. Une boutique multimarque exporte son catalogue avec un product_type du type « Chaussures > Running > Homme », mais la catégorie Google utilisée pour la diffusion reste trop générique. Résultat visible dans le compte : des produits mal regroupés, des campagnes Shopping qui manquent de segmentation, et un taux de clics qui stagne sur ces familles de produits mal cataloguées.
Le diagnostic, en suivant l’arbre plus haut : la donnée de départ existe (product_type est bien rempli), mais elle doit être mappée vers un champ exploitable par Google. C’est un cas de transformation, pas d’apport complémentaire.
La configuration se construit en trois temps : une condition cible les lignes où product_type contient « Running », l’opérateur Définir sur pose la valeur numérique de catégorie Google correspondante, puis une seconde condition traite les autres familles (Homme, Femme, Enfant). Chaque opération reste isolée, testable et documentée avant publication.
Après republication, les articles remontent avec une catégorisation plus cohérente, les groupes Shopping deviennent plus lisibles et le diagnostic Merchant Center plus simple à interpréter. Le CMS, lui, n’a pas bougé d’une ligne.
La dette de transformation : tenir l’inventaire
Le revers de la souplesse. Un catalogue passé par six transformations et trois apports complémentaires devient un palimpseste : la donnée affichée sur les fiches ne ressemble plus à celle exportée par le CMS. Au prochain incident, un champ change sans raison apparente, un titre résiste à toute modification ou une catégorie ne correspond plus à rien ; il devient difficile de savoir quelle couche agit.
La discipline est simple : tenez un inventaire des transformations, avec le mécanisme, le champ concerné, la raison, la date et la plage d’articles. Une revue régulière détermine ensuite quelles rustines doivent enfin être réparées dans le CMS plutôt que corrigées en aval à chaque récupération.
Ces outils sont faits pour aller vite, pas pour héberger définitivement la dette du CMS.
- Si ces outils n’apparaissent pas, vérifiez le module « Gestion avancée des sources de données » et vos droits.
- Le premier transforme l’existant ; le second complète ce qui manque ; le CMS corrige les erreurs structurelles.
- Un apport complémentaire enrichit les articles déjà importés ; il ne constitue pas un catalogue autonome.
- Chaque transformation doit être documentée : mécanisme, champ, raison et date.
Quels attributs corrige-t-on le plus souvent avec une règle ?
Sur le terrain, cinq champs concentrent une grande part des tickets qui traînent. Les connaître évite de rechercher le bon mécanisme à chaque incident.
item_id(l’identifiant) : rarement corrigé lui-même, mais c’est la clé qui relie le fichier principal et la table complémentaire. Une incohérence ici, et l’enrichissement ne colle à aucun article.condition(l’état) : neuf, reconditionné ou occasion, mais la valeur doit sortir en anglais (new,refurbished,used) quel que soit votre marché. Un CMS qui exporte encore « occasion » en toutes lettres se corrige avec Rechercher et remplacer.google_product_category(la catégorie Google) : le point de friction classique entre une arborescence maison et la nomenclature officielle. Une correspondance texte-vers-catégorie évite de reclasser le catalogue à la main.price: au-delà de la simple conversion d’unité vue plus haut, vous pouvez corriger un format ou une devise, mais le prix transmis doit rester aligné avec la page et le paiement, taxes comprises quand le pays cible l’exige.- Les étiquettes personnalisées servent ensuite à construire vos groupes d’annonces Shopping ou vos réglages d’enchères. Quand le CMS ne produit pas cette segmentation, l’un des deux outils la construit sans dépendre d’un export dédié.
Dans chaque cas, le réflexe reste le même : vérifier si la donnée existe mais est mal formée, si elle est absente ou si elle est erronée dans le CMS.
Pour qui ces outils sont décisifs, et leur limite
Équipes marketing sans accès à la technique, prestataires qui pilotent des campagnes sans droits CMS, boutiques aux exports rigides : ces outils donnent de l’autonomie sur les données du catalogue et les groupes d’annonces. La nuance à garder : ils transforment la donnée transmise, pas la réalité de la page.
Google contrôle surtout la cohérence avec la page : prix, disponibilité et informations commerciales doivent correspondre, sinon l’article peut être refusé. Vous transformez la forme, pas le fond.
Commencez par trier les sujets : transformation, apport complémentaire ou correction CMS. Ce tri évite de traiter dans Merchant Center un problème qui doit remonter au site. Si vos titres attendent un sprint depuis trois mois, remettez le sujet à plat pour votre catalogue Merchant Center et la rentabilité de vos campagnes Shopping.
