La structure du catalogue est l’architecture de données qui détermine comment les produits sont organisés pour la navigation, le merchandising, les menus, les pages d’atterrissage et la découverte par les clients. Un produit peut exister correctement dans l’administration tout en restant difficile à trouver si sa relation avec une catégorie, son appartenance à une collection, son chemin de menu, sa position de tri ou le contexte de sa page d’atterrissage n’est pas correctement représenté.
Dans une boutique e-commerce, l’organisation du catalogue ne se limite pas toujours à un simple arbre de catégories. Une plateforme peut utiliser des catégories imbriquées avec des relations parent-enfant. Une autre peut s’appuyer sur des collections manuelles ou automatisées, des tags produit, des champs de taxonomie, des liens de menu, des types de produit, des pages d’atterrissage créées avec un page builder ou des règles de merchandising pilotées par la recherche. Deux boutiques peuvent sembler similaires aux clients tout en reposant sur des modèles de données très différents.
Une analyse technique de la structure du catalogue doit donc distinguer plusieurs couches : l’objet de regroupement sous-jacent, la relation entre les produits et les groupes, le chemin de navigation emprunté par les clients, le contenu associé aux pages de catégorie ou de collection, les règles qui déterminent l’inclusion des produits et la logique d’affichage qui décide de ce qui apparaît en premier.
Ce que représente la structure du catalogue dans une boutique e-commerce
La structure du catalogue définit la manière dont les produits sont organisés en parcours de navigation utiles. Elle aide les clients à passer d’une intention large à des produits précis, par exemple Women > Shoes > Running Shoes, Electronics > Laptops > Gaming Laptops ou Replacement Parts > Refrigerator Parts > Water Filters.
Cette structure remplit généralement d’autres fonctions que la navigation. Elle peut influencer les pages d’atterrissage de catégorie, les fils d’Ariane, les liens internes, les pages d’entrée SEO, les produits mis en avant, les règles de merchandising, la découverte produit, la catégorisation marketplace, le reporting et la manière dont les équipes entretiennent le catalogue.
Une structure de catalogue peut comprendre plusieurs objets de données et couches de présentation :
| Composant du catalogue | Ce qu’il représente | Fonctionnement concerné |
|---|---|---|
| Catégorie ou collection | Regroupement de produits utilisé pour la navigation ou le merchandising | Pages de catégorie, listes de produits, filtres et découverte |
| Hiérarchie parent-enfant | Relation entre les groupes larges et plus précis | Profondeur des menus, fils d’Ariane, parcours de navigation et structure des URL |
| Affectation de produit | Lien entre un produit et une catégorie ou collection | Visibilité du produit dans les pages de navigation |
| Élément de menu | Lien de navigation de la boutique vers une catégorie, collection, page ou URL externe | Manière dont les clients accèdent aux pages du catalogue |
| Chemin de fil d’Ariane | Parcours de navigation ou trace hiérarchique affiché | Orientation, maillage interne et compréhension du parcours |
| Contenu de catégorie | Texte, images, bannières, métadonnées, blocs ou contenu de page d’atterrissage | SEO, merchandising et explication de la page de catégorie |
| Règles de tri et d’affichage | Ordre manuel, tri par défaut, mise en avant ou classement algorithmique | Produits que les clients voient en premier |
| Règle d’inclusion dynamique | Conditions qui ajoutent automatiquement des produits à un groupe | Collections automatisées, catégories intelligentes, groupes saisonniers et maintenance courante |
Ces couches peuvent être étroitement reliées sur une plateforme et entièrement séparées sur une autre. Cette différence explique en grande partie pourquoi la migration du catalogue ne peut pas être évaluée uniquement en comptant les catégories.
Structure de données et relations courantes
Une catégorie, une collection ou un groupe de catalogue possède généralement son propre enregistrement. Celui-ci peut contenir un ID interne, un nom, un slug, une référence au parent, un chemin, un statut, un ordre de tri, une description, une image, des champs SEO, des paramètres d’affichage, des règles d’affectation de produit et des indicateurs de visibilité dans la boutique.
Une structure courante de groupe de catalogue peut comprendre :
| Champ de données | Fonction habituelle | Pourquoi il compte |
|---|---|---|
| ID interne | Identifiant système stable | Maintient les affectations et références reliées |
| Nom | Libellé du groupe pour l’administration ou le client | Contrôle l’affichage, les menus et la reconnaissance par les équipes |
| Slug ou handle | Identifiant adapté aux URL | Influence les URL des pages et les références des menus ou liens |
| ID parent | Définit la catégorie parente ou le groupe de niveau supérieur | Crée la hiérarchie et la profondeur de navigation |
| Chemin ou niveau | Enregistre la position complète dans la hiérarchie | Alimente les fils d’Ariane, le tri et les menus imbriqués |
| Statut ou visibilité | Active, désactive, masque ou publie le groupe | Détermine si les clients peuvent accéder à la page |
| Position de tri | Contrôle l’ordre des groupes ou des produits | Influence la navigation et la priorité de merchandising |
| Description et contenu | Fournit l’explication de catégorie ou le contenu de la page d’atterrissage | Soutient le SEO, l’intention d’achat et le contexte client |
| Image ou bannière | Représentation visuelle du groupe | Influence les grilles de catégories et les pages d’atterrissage |
| Titre et description SEO | Métadonnées destinées aux moteurs de recherche | Soutiennent la présentation dans les résultats organiques |
| Relation d’affectation produit | Relie les produits au groupe | Détermine ce qui apparaît dans les listes de produits |
| Règle d’inclusion | Sélectionne automatiquement les produits selon des conditions | Alimente les collections intelligentes ou catégories dynamiques |
| Référence de menu | Relie le groupe à la navigation | Détermine si les clients peuvent atteindre naturellement la page |
L’affectation de produit est souvent stockée séparément de l’enregistrement du groupe. Une relation plusieurs-à-plusieurs peut permettre à un même produit d’appartenir à plusieurs catégories ou collections. Un modèle strict à catégorie unique peut exiger une catégorie principale. Un modèle fondé sur des règles peut ne pas enregistrer chaque affectation directement : il peut inclure les produits selon le type de produit, un tag, un fournisseur, une marque, une valeur d’attribut, le prix, l’état du stock ou la date de publication.
La différence entre affectation enregistrée et affectation calculée est importante. Une catégorie statique contient des liens explicites vers les produits. Une collection dynamique est reconstruite à partir de règles. Une catégorie pilotée par la recherche peut dépendre d’un index. Une page d’atterrissage gérée par une extension peut afficher les produits via un bloc, widget, module ou appel API plutôt que par une appartenance native à une catégorie.
Arbres de catégories, collections et modèles taxonomiques
Les plateformes diffèrent fortement dans leur manière de modéliser l’organisation du catalogue.
Certaines utilisent principalement des arbres de catégories. Des catégories parentes contiennent des catégories enfants, qui peuvent elles-mêmes contenir des sous-catégories plus profondes, et les produits sont affectés à un ou plusieurs nœuds. Ce modèle est courant dans les boutiques aux catalogues volumineux, les pièces détachées, les assortiments B2B, les produits techniques ou les navigations profondes par département. Il fournit une hiérarchie forte, mais exige une gestion précise de la profondeur, des noms, des relations parent-enfant et des affectations de produits.
D’autres plateformes privilégient les collections. Une collection peut ressembler à une page de catégorie côté boutique, mais sa logique sous-jacente peut être manuelle, automatisée, fondée sur des tags, sur un type de produit ou sur des règles. Elle offre une grande souplesse de merchandising sans imposer un arbre strict. En contrepartie, menus, fils d’Ariane et signification parent-enfant peuvent nécessiter une configuration séparée.
Les modèles taxonomiques ajoutent une autre couche. Une taxonomie est un système de classification contrôlé qui définit les familles de produits et les attributs attendus. Elle peut être native à la plateforme, importée d’une marketplace, administrée dans un PIM ou maintenue pour les flux et canaux publicitaires. Taxonomie et navigation de boutique ne sont pas toujours équivalentes. Un produit peut être classé d’une manière pour les clients et d’une autre pour Google Shopping, les flux marketplace, les achats ou le reporting.
Un même groupe métier peut donc prendre plusieurs formes :
| Concept métier | Représentation possible sur la plateforme |
|---|---|
| Chaussures de course | Catégorie enfant, collection, collection intelligente, type de produit, groupe de tags, nœud taxonomique ou page d’atterrissage |
| Articles en déstockage | Collection manuelle, collection automatisée, groupe fondé sur une règle de prix, page par tags ou campagne de merchandising |
| Filtres de remplacement | Chemin de catégorie profond, taxonomie de compatibilité, résultat de recherche à facettes ou famille produit pilotée par un PIM |
| Nouveautés | Collection automatisée selon la date de publication, un tag, la date de sortie ou une règle de merchandising |
| Page de marque | Catégorie, collection, page fournisseur, page d’atterrissage, résultat de recherche ou page générée par une application |
Une migration peut préserver le libellé tout en changeant le modèle. Cela peut être acceptable si la représentation cible conserve le même comportement de navigation. Le risque apparaît lorsqu’un arbre de catégories est aplati en collections, qu’une collection intelligente devient un groupe statique ou qu’une page d’atterrissage de catégorie devient une simple liste de produits.
Navigation, menus et fils d’Ariane constituent des couches distinctes
Un groupe de catalogue peut exister sans apparaître dans le menu de la boutique. Un menu peut pointer vers une page qui n’est pas une catégorie native. Un fil d’Ariane peut être généré à partir de la hiérarchie, du chemin de menu, du chemin d’URL, de l’affectation du produit, de la logique du thème ou d’une application.
Cette séparation est importante parce que les clients perçoivent la structure du catalogue à travers la navigation, et non à travers les enregistrements de la base de données. Une catégorie peut être correctement migrée comme enregistrement, mais les clients peuvent perdre le chemin qui les guidait auparavant vers elle.
Les menus possèdent souvent leur propre structure de données. Un élément de menu peut contenir un libellé, une cible, un élément parent, une position, un paramètre de visibilité, un périmètre de marché ou de langue, une icône, une image, un badge, une mise en page de méga-menu et des références à des blocs personnalisés. Les méga-menus peuvent intégrer des liens de catégories, des produits mis en avant, des images, des blocs promotionnels ou des sous-menus élaborés manuellement.
Les fils d’Ariane peuvent eux aussi fonctionner différemment selon les plateformes. Certaines les dérivent de l’arbre de catégories. D’autres utilisent le chemin de menu, la collection principale du produit, le chemin d’URL ou des règles de thème. Un produit affecté à plusieurs catégories peut nécessiter un chemin principal pour l’affichage du fil d’Ariane. Sans chemin principal, le fil peut devenir incohérent ou trompeur.
Pour la planification du catalogue, la distinction technique essentielle est la suivante :
| Couche | Question technique |
|---|---|
| Groupe du catalogue | La catégorie, collection ou le nœud taxonomique existe-t-il ? |
| Relation produit | Les produits sont-ils reliés au bon groupe ? |
| Navigation | Les clients peuvent-ils atteindre le groupe par le chemin de menu attendu ? |
| Fil d’Ariane | La boutique affiche-t-elle le chemin et le contexte attendus ? |
| Page d’atterrissage | La page du groupe conserve-t-elle son contenu, son merchandising et son fonctionnement d’affichage ? |
Un résultat de catalogue fiable suppose que ces cinq couches fonctionnent ensemble.
Affectation des produits et présence dans plusieurs groupes
L’affectation des produits détermine où ils apparaissent. Dans un catalogue simple, un produit peut appartenir à une seule catégorie. Dans la plupart des boutiques matures, les produits apparaissent dans plusieurs contextes : marque, département, groupe promotionnel, collection saisonnière, groupe de compatibilité, chemin de pièce de remplacement, guide cadeau, contexte de bundle ou page de campagne.
La présence dans plusieurs groupes dépend de la plateforme. Certaines autorisent un nombre illimité d’affectations de catégories. D’autres utilisent des collections, tags, types de produit, champs fournisseur, canaux de vente ou champs personnalisés. Certaines prennent en charge une catégorie principale pour les chemins canoniques et les fils d’Ariane. D’autres traitent toutes les appartenances à des groupes de façon équivalente.
Cela influence plusieurs comportements :
| Comportement d’affectation | Effet possible |
|---|---|
| Le produit appartient à plusieurs catégories | Il peut apparaître dans plusieurs parcours de navigation, mais le chemin canonique et les fils d’Ariane peuvent nécessiter des règles |
| Le produit possède une seule catégorie principale | Hiérarchie plus forte, mais moins de contextes de navigation si les affectations secondaires sont absentes |
| Le produit est affecté par tag ou par règle | Maintenance plus simple, mais résultats dépendants de la qualité des tags et de la précision des règles |
| Le produit apparaît via la recherche ou la logique d’une application | Affichage flexible, mais comportement difficile à préserver avec les seules données natives de catégorie |
| Le produit est masqué sur un canal mais visible sur un autre | Boutique, marketplace, B2B et catalogues régionaux peuvent diverger |
Un produit à forte valeur peut être migré correctement comme fiche produit tout en échouant commercialement s’il disparaît d’un parcours de catégorie important. La validation fondée sur le nombre de produits ne détecte pas ce problème si les échantillons d’affectation n’incluent pas les catégories critiques pour le chiffre d’affaires et les produits présents dans plusieurs groupes.
Groupes statiques, groupes dynamiques et collections intelligentes
Les groupes de catalogue peuvent être statiques ou dynamiques. Un groupe statique enregistre explicitement les affectations de produits. Un groupe dynamique inclut les produits lorsqu’ils répondent à certaines conditions.
Le regroupement dynamique peut dépendre :
- des tags produit ;
- du type de produit ;
- du fournisseur ou de la marque ;
- du prix ou du statut promotionnel ;
- de la disponibilité du stock ;
- de la date de publication ou de sortie ;
- des valeurs d’attribut ;
- des valeurs de variante ;
- du groupe client ou du marché ;
- des metafields ou champs personnalisés produit ;
- de règles gérées par une application ;
- de conditions de l’index de recherche.
Les collections intelligentes et catégories automatisées peuvent réduire la maintenance manuelle, mais elles introduisent une dépendance technique. Le groupe n’est pas seulement un nom de catégorie : il correspond à un ensemble de règles plus un modèle de données produit qui doit continuer à satisfaire ces règles.
Une collection dynamique comme Summer Dresses Under $100 peut dépendre du type de produit, d’un tag de saison, du genre, de la catégorie, du prix, de l’état du stock et du statut de publication. Si l’un de ces champs change de modèle sur la plateforme cible, la collection peut devenir incomplète ou trop large. Une catégorie qui se mettait automatiquement à jour peut devenir statique après migration si la plateforme cible ne peut pas représenter la même logique de conditions.
Les groupes dynamiques nécessitent un contrôle plus poussé que les groupes statiques, car le risque est différé. La collection peut sembler correcte au lancement mais ne plus inclure les futurs produits si la règle n’est pas recréée ou entretenue.
Pages d’atterrissage de catégorie et structures de contenu
Les pages de catégorie contiennent souvent plus qu’une liste de produits. Une page d’atterrissage peut inclure un texte d’introduction, du contenu SEO, des bannières, des vidéos intégrées, des guides d’achat, des blocs FAQ, des liens internes, des sous-catégories mises en avant, des carrousels de produits, des tuiles promotionnelles ou des sections de page builder.
Selon la plateforme, ce contenu peut être stocké à différents endroits :
| Type de contenu | Emplacement possible |
|---|---|
| Description de catégorie | Champ natif de catégorie, description de collection, bloc CMS, metafield, champ personnalisé |
| Image de bannière | Image de catégorie, section de thème, bloc de page builder, médiathèque, données d’application |
| Métadonnées SEO | Champs SEO natifs, champs de plugin/module, champs CMS, paramètres du thème |
| Produits mis en avant | Tri manuel de catégorie, module de merchandising, bloc produit, règle d’application |
| Contenu de guide d’achat | Page CMS, bloc de contenu de catégorie, article de blog, modèle de page builder |
| Liens internes | HTML de description, blocs de menu, sections de thème, données de module personnalisé |
Une page d’atterrissage peut donc ressembler à une catégorie tout en dépendant techniquement de données CMS, de paramètres de thème, de champs personnalisés ou d’extensions. Si ces composants ne sont pas identifiés, la catégorie peut être migrée comme une simple page de listing et perdre le contenu qui faisait sa valeur.
C’est ici que la Section 6 doit rester distincte des sujets SEO de la Section 2. Cette analyse technique ne porte pas sur la stratégie de redirection. Elle traite du stockage structurel et des dépendances derrière le contenu des pages de catégorie. La planification des URL et des redirections appartient à un autre sujet ; l’architecture des données de page de catégorie appartient à celui-ci.
Tri, merchandising et règles d’affichage
Les pages de catégorie et de collection dépendent souvent de règles d’affichage. L’ordre des produits peut être alphabétique, du plus récent au plus ancien, fondé sur le prix ou les meilleures ventes, organisé manuellement, ajusté selon la disponibilité, calculé d’après un score de recherche, piloté par la marge ou contrôlé par une application.
Les données de merchandising peuvent comprendre :
- une position manuelle des produits dans une catégorie ;
- des indicateurs de produit mis en avant ;
- des produits épinglés ;
- des produits promus ;
- des produits exclus ;
- des règles de tri propres à la catégorie ;
- une visibilité propre à certains groupes clients ;
- une visibilité propre au marché ou au canal ;
- un classement tenant compte du stock ;
- un classement piloté par une application ;
- des règles de promotion ou de déclassement dans un moteur de recherche.
Ces détails sont faciles à perdre parce qu’ils ne ressemblent pas toujours à de la structure de catalogue. Une catégorie peut contenir les bons produits tout en les présentant dans le mauvais ordre. Pour les catégories à fort trafic, l’ordre influence le chiffre d’affaires, les stratégies de déstockage, la saisonnalité et la découverte produit.
Lorsque les plateformes source et cible utilisent des modèles de merchandising différents, la préservation peut nécessiter de transposer une liste de positions manuelles, recréer des règles de collection, reconstruire les boosts de recherche ou accepter un nouveau modèle de tri. La bonne décision dépend du degré auquel la boutique s’appuie sur une présentation produit organisée manuellement.
Comportements de catalogue propres aux plateformes
Les différentes familles de plateformes créent des difficultés de catalogue différentes.
Les plateformes SaaS séparent souvent collections, menus de navigation, tags produit et sections de thème. Cela peut simplifier l’administration, mais aussi créer un écart entre l’objet de données et le chemin visible côté boutique. Une collection peut exister sans être placée dans un menu. Un tag peut piloter une collection automatisée. Un thème ou une application peut contrôler la manière dont une page de collection affiche les filtres, bannières et blocs de produits.
Les plateformes Open-Source exposent souvent des arbres de catégories plus profonds, des ensembles d’attributs, des modules et des relations au niveau de la base de données. Elles peuvent prendre en charge des hiérarchies complexes et des comportements personnalisés, mais les boutiques peuvent dépendre d’extensions, de tables personnalisées, de systèmes de réécriture d’URL ou de surcharges de thème qui ne font pas partie des enregistrements de catégorie standard.
Les plateformes d’entreprise et B2B peuvent proposer des catalogues par groupe client, liste de prix, compte d’entreprise, canal de vente, zone géographique, contrat ou processus d’approbation. Un produit peut exister globalement tout en n’apparaissant que dans certains catalogues propres à des clients. La structure de catégories peut alors dépendre des autorisations, de la hiérarchie des comptes, des rôles acheteurs ou de la tarification contractuelle.
Les boutiques connectées à des marketplaces ou pilotées par un PIM peuvent maintenir une structure de navigation pour la boutique et une autre structure de classification pour les canaux externes. Le PIM peut détenir la taxonomie, les attributs, les familles de produits et les affectations de catégories, tandis que la boutique ne fait que consommer les résultats publiés. Dans ce modèle, la planification de la migration doit identifier la véritable source de référence du catalogue.
Ce qui peut changer lorsque le modèle de catalogue est recréé
La structure du catalogue peut changer de manière peu visible dans le simple nombre d’enregistrements.
| Changement structurel | Effet possible |
|---|---|
| Un arbre profond devient un ensemble de collections plates | Les clients perdent la hiérarchie, les fils d’Ariane et les parcours d’affinage |
| Des catégories statiques deviennent des collections dynamiques | La maintenance future s’améliore, mais la précision des règles devient critique |
| Des collections dynamiques deviennent des groupes statiques | Le lancement peut sembler correct, mais l’inclusion future des produits devient manuelle |
| Le contenu de catégorie devient une simple description | La mise en page, les liens internes et les blocs promotionnels peuvent être dégradés |
| La structure de menu est reconstruite séparément | Les catégories existent, mais certains chemins de navigation attendus peuvent manquer |
| Les affectations produit sont recalculées à partir de tags | L’appartenance aux groupes dépend de la cohérence des tags et de la conception des règles |
| L’ordre de tri manuel disparaît | La catégorie contient les bons produits mais leur présentation commerciale est moins efficace |
| La catégorie principale n’est pas préservée | Fils d’Ariane, chemins canoniques et reporting peuvent devenir incohérents |
Tous les changements ne sont pas nécessairement mauvais. Une migration peut être l’occasion de simplifier un arbre de catégories désordonné, de remplacer des catégories en double par des collections plus propres ou de passer d’un regroupement manuel à un regroupement fondé sur des règles. L’important est de reconnaître qu’il s’agit de décisions d’architecture, et non d’effets secondaires involontaires.
Ce que les marchands doivent examiner
L’analyse du catalogue devrait commencer par des parcours de navigation représentatifs, et non par la liste complète des catégories.
Un examen pratique devrait inclure :
- les parcours de catégorie générant le plus de chiffre d’affaires ;
- les pages de catégorie ou de collection organiques à fort trafic ;
- les chemins de hiérarchie profonde avec plusieurs niveaux parent-enfant ;
- les produits affectés à plusieurs catégories ou collections ;
- les collections intelligentes ou catégories automatisées ;
- les pages de catégorie avec contenu de page d’atterrissage ;
- les pages avec ordre produit manuel, mises en avant ou règles de merchandising ;
- les structures de menu, méga-menus et comportement des fils d’Ariane ;
- les catalogues propres à certains groupes clients, usages B2B, marchés ou canaux ;
- les structures de catalogue contrôlées par un PIM, ERP, fournisseur de recherche, application, module ou code personnalisé.
Pour chaque échantillon, le marchand doit comparer la structure de données et le comportement côté boutique. Le groupe existe-t-il ? Les bons produits lui sont-ils affectés ? Est-il accessible depuis la navigation ? Les fils d’Ariane sont-ils cohérents ? La page conserve-t-elle son contenu et son rôle de merchandising ? Le groupe continue-t-il à se mettre à jour automatiquement s’il reposait sur des règles ? La plateforme cible représente-t-elle la même hiérarchie, ou celle-ci est-elle devenue un autre modèle ?
L’examen doit aussi identifier la propriété des données. Si la hiérarchie du catalogue est maintenue dans un PIM, un ERP, un flux marketplace ou un module d’administration personnalisé, la plateforme de boutique n’est peut-être pas la véritable source du modèle de catalogue. Préserver uniquement la boutique peut alors ne pas préserver le fonctionnement opérationnel.
Quand les données nécessitent une analyse plus approfondie
La structure du catalogue demande une analyse plus poussée lorsque le parcours de navigation dépend de davantage que les enregistrements de catégorie standard.
Une analyse approfondie est généralement nécessaire lorsque :
- la plateforme source et la plateforme cible utilisent des modèles différents de catégorie, collection ou taxonomie ;
- la boutique possède des hiérarchies profondes, des produits présents dans plusieurs catégories ou une logique importante de catégorie principale ;
- les pages de catégorie comprennent du contenu riche, des blocs CMS, des bannières, des mises en page de page builder ou des structures de liens internes ;
- des collections intelligentes, groupes automatisés, règles de recherche, tags, attributs ou logiques d’application contrôlent l’inclusion des produits ;
- l’ordre manuel, la mise en avant, les produits épinglés ou les règles de merchandising influencent le chiffre d’affaires ;
- les menus, méga-menus, fils d’Ariane ou la logique du thème sont séparés des enregistrements de catégorie ;
- les catalogues par groupe client, B2B, marché, canal ou contrat modifient la visibilité ;
- un PIM, ERP, une marketplace ou un système de recherche détient une partie du modèle de classification du catalogue.
Lorsque le modèle de catalogue ne peut pas être représenté par un transfert direct de Category ou de collection, le projet doit définir une représentation cible pour la hiérarchie, la navigation, les champs personnalisés, les menus, le contenu de page d’atterrissage et la propriété des systèmes externes. Toute conception de migration personnalisée doit rester liée à ce résultat spécifique du catalogue.
Conclusion
La structure du catalogue est l’architecture de données derrière la navigation produit. Elle relie catégories, collections, taxonomies, affectations produit, menus, fils d’Ariane, pages d’atterrissage, règles de tri et comportements de merchandising pour créer le parcours visible qui mène de l’intention du client à la découverte d’un produit.
Une transition de plateforme fiable ne préserve pas seulement les noms des catégories. Elle conserve les relations et comportements qui rendent le catalogue utilisable : hiérarchie, accessibilité, logique d’affectation, regroupement dynamique, contexte de contenu et ordre de merchandising. La préparation la plus solide consiste à examiner le catalogue comme un ensemble de parcours de navigation et de dépendances structurelles avant de supposer que les seuls enregistrements de catégorie représentent toute l’expérience du catalogue.
Questions fréquentes
Les catégories et les collections sont-elles la même chose ?
Non. Elles peuvent se ressembler côté boutique, mais utiliser des modèles de données différents. Les catégories impliquent souvent une hiérarchie. Les collections peuvent être manuelles, fondées sur des règles, basées sur des tags ou dépendantes du thème. La bonne structure cible dépend du comportement que la boutique doit conserver.
Pourquoi une catégorie peut-elle exister tout en étant absente de la navigation ?
Les enregistrements de catégorie et les menus sont souvent séparés. Une catégorie ou collection peut exister dans l’administration sans être reliée au menu de la boutique, au méga-menu, au fil d’Ariane ou à la structure de page d’atterrissage utilisée par les clients.
Quelle est la différence entre les groupes de catalogue statiques et dynamiques ?
Un groupe statique enregistre explicitement les affectations de produits. Un groupe dynamique inclut les produits qui correspondent à des règles comme un tag, un type de produit, un fournisseur, un prix, la disponibilité, une valeur d’attribut ou une date de publication. Préserver un groupe dynamique exige de préserver ses règles, pas seulement son nom.
Pourquoi l’affectation produit est-elle importante si tous les produits ont été migrés ?
Les clients ne parcourent pas directement des enregistrements de produits. Ils naviguent dans des catégories, collections, résultats de recherche et menus. Un produit migré peut perdre sa visibilité commerciale s’il disparaît d’un parcours de navigation important.
Quand la hiérarchie du catalogue nécessite-t-elle un traitement personnalisé ?
Un traitement personnalisé peut être nécessaire lorsque la hiérarchie dépend de données d’extension, de menus personnalisés, de règles dynamiques, de contenu de page builder, d’un PIM ou ERP externe, de catalogues propres à certains clients ou d’un modèle de catalogue source qui ne correspond pas directement au modèle de la plateforme cible.