Comment unifier les données du produit fournisseur sans perdre l'identité du produit

Pourquoi les catalogues des fournisseurs deviennent difficiles à faire confiance

Deux fournisseurs peuvent décrire le même type de produit de manière complètement différente. L'un envoie un rouleau de fond, l'autre envoie un rouleau de fond, et un troisième met le modèle de machine dans une note en texte libre. Les mesures peuvent arriver en millimètres, centimètres ou pouces. Les noms de marque acquièrent des changements de ponctuation, les couleurs utilisent des noms locaux, et les champs importants sont enfouis dans les titres parce que le tableur n'a nulle part où les mettre.

Le problème devient plus grave lorsque ces fichiers sont importés à plusieurs reprises. Un titre modifié peut créer un deuxième produit. Un fournisseur UGS peut être confondu avec celui du marchand. Une colonne vide peut effacer une valeur approuvée. Stock et prix peuvent mettre à jour correctement pendant que la description, la variante ou la relation de compatibilité est attachée au mauvais article.

L'intelligence du produit commence par séparer l'identité, les attributs, les relations et les valeurs commerciales. Ces catégories peuvent alors suivre différentes règles de propriété et de révision au lieu d'être traitées comme une ligne indifférenciée.

Commencer par l'identité du produit, et non la formulation du produit

Un titre est destiné aux gens et peut changer légitimement. C'est une mauvaise clé primaire. Conservez des identifiants stables pour l'enregistrement source, l'enregistrement marchand et chaque plateforme de destination. Ceux-ci peuvent inclure un numéro d'article fournisseur, ID de produit interne, SKU, GTIN, Shopify product ID, Shopify variante ID, NetSuite item ID ou Sage référence stock-item.

Ne présumez pas que tous les identifiants signifient la même chose. Un GTIN identifie un article commercial selon ses règles d'émission; un UGS interne est contrôlé par l'entreprise; un identifiant de produit Shopify identifie le conteneur de produit; et chaque variante purchasable a sa propre identité de plateforme. Conservez le type d'identificateur, la valeur et le système d'émission plutôt que de mettre chaque code dans un champ marqué -numéro de partie

La spécification de Google Merchant Center nécessite un ID de produit unique, conseille de le garder inchangé pendant les mises à jour et dit que le même produit devrait conserver le même ID dans tous les pays ou les langues. Ce principe est précieux au-delà d'un flux : une identité stable permet aux descriptions, aux prix et aux attributs de changer sans rompre la connexion avec l'élément sous-jacent.

• Identité de la source: quel document du fournisseur a produit la valeur
• Identité commerciale: produit canonique du marchand et UGS
• Identité commerciale: un GTIN ou un autre identifiant reconnu, le cas échéant
• Identité de la plateforme: le produit de destination et les identifiants de variante
• Identité de la relation : le lien examiné entre un produit, un modèle, une catégorie ou une application

Créer un modèle d'attribut gouverné

Avant de fusionner des fichiers, définissez les champs dont l'entreprise a réellement besoin. Donnez à chaque attribut un nom clair, un type de données, une unité, des valeurs autorisées, une règle de propriété et une règle de validation. Un diamètre doit être numérique avec une unité explicite. Une marque doit faire référence à une entité de marque canonique. Une propriété yes-or-no ne devrait pas accepter six orthographes de yes

Gardez le modèle pratique. Commencez par les attributs qui affectent l'achat, l'ajustement, la découverte, la conformité, le stock ou l'exécution. Les notes de fournisseur seulement peuvent rester comme preuve de source sans devenir des champs orientés vers le client. L'objectif n'est pas de créer le plus grand schéma; c'est de rendre les faits importants assez cohérents à utiliser.

Shopify modèles un produit comme un conteneur avec des options et des variantes, où une variante représente une combinaison spécifique purchasable et porte des valeurs telles que le prix, l'inventaire et le code-barres. La feuille de calcul plate d'un fournisseur doit donc être cartographiée délibérément dans les champs de niveau produit et de niveau variante plutôt que dans la colonne copiée pour la colonne.

1. Énumérer les décisions que les clients et le personnel doivent prendre en charge.
2. Définir les champs canoniques, les unités et les valeurs contrôlées pour ces décisions.
3. Carter chaque colonne de fournisseur dans un champ canonique ou un champ de preuve seulement.
4. Préservez la valeur originale à côté de la valeur normalisée.
5. Valider les champs requis et l'unicité de l'identificateur avant la fusion.
6. Envoyer les conflits non résolus à examiner au lieu de choisir silencieusement.

Normaliser les valeurs sans détruire la source

La normalisation rend les valeurs équivalentes comparables. Il peut normaliser l'espace blanc, le boîtier, la ponctuation, les unités, les formats de date et le vocabulaire connu. L'acier inoxydable, l'acier inoxydable et le code matériel approuvé d'un fournisseur peuvent correspondre à une valeur canonique, à condition que la cartographie soit documentée et réellement équivalente.

Ne jamais écraser la source brute. Conservez la valeur originale, la valeur normalisée, la règle de transformation, la source, le temps d'importation et l'état de confiance ou de révision. Cela rend les erreurs réversibles et donne à un examinateur suffisamment de contexte pour décider si une cartographie proposée est sûre.

La conversion des unités a besoin de la même discipline. Conserver la mesure et l'unité fournies, enregistrer la valeur convertie et appliquer la précision appropriée. L'arrondissement d'une dimension technique pour l'affichage ne doit pas modifier la valeur exacte utilisée pour l'installation, la fabrication ou l'achat.

Résoudre les doublons avec les preuves, et non la similitude des titres

Les doublons potentiels devraient être notés à partir de signaux multiples : identificateurs stables, numéros de pièce du fabricant, marque, dimensions, structure de variante, relations avec les fournisseurs et autres attributs approuvés. Un titre partagé ou une description similaire peut identifier les candidats, mais ne doit pas autoriser une fusion.

Définir ce que signifie une fusion. Parfois, deux lignes de fournisseurs représentent le même élément commercial de différentes sources et peuvent être reliées à un seul enregistrement canonique. Parfois, il s'agit d'alternatives équivalentes qui doivent rester des produits distincts. Parfois une rangée représente un produit parent tandis qu'une autre représente une variante purchasable. Il s'agit de relations différentes et ne devraient pas s'effondrer en une seule hypothèse.

Lorsque la preuve est en conflit, gardez les deux affirmations avec leurs sources et marquez le champ à examiner. Un examinateur devrait voir exactement quels sont les dossiers en désaccord, les valeurs en jeu, la date de la preuve et les destinations en aval touchées par une décision.

Garder les faits, les relations et les données commerciales séparées

Les faits sur le produit décrivent l'article: matériau, dimensions, marque et attributs techniques. Les relations le relient à des catégories, modèles, applications, accessoires ou alternatives. Les données commerciales couvrent le prix, la disponibilité, la taxe, le coût du fournisseur et l'exécution. Chaque groupe peut avoir une source de vérité différente et mettre à jour la fréquence.

Par exemple, un ERP peut être propriétaire d'un stock et d'un prix alors qu'un fabricant agréé possède des dimensions. Un workflow d'information produit peut posséder des titres et des catégories normalisés. Shopify peut rester la destination principale. La séparation de ces responsabilités empêche un fichier descriptif de fournisseur d'écraser l'inventaire en direct ou un flux d'inventaire d'enlever le contenu approuvé du produit.

Le vocabulaire produit de Schema.org reflète cette distinction en fournissant des propriétés pour les identifiants de produit, marque, catégorie, matériel, modèle et offres. Un modèle structuré ne prouve pas qu'une revendication est correcte, mais il aide les systèmes à transporter différents types d'information produit sans réduire tout à la prose.

Un exemple concret: combiner trois catalogues de sous-couches

Imaginez qu'un marchand reçoive trois fichiers de pièces de sous-couche de pelle. La première utilise les numéros du fabricant, la seconde utilise les UGS du fournisseur et la troisième décrit les applications de la machine dans une colonne de notes. Tous les trois contiennent des rouleaux, des ralentisseurs et des pignons, mais leurs noms de catégorie et dimensions diffèrent.

Le workflow importe chaque fichier dans une zone de mise en scène et attribue une identité source à chaque ligne. Il cartographie les synonymes de catégorie en catégories canoniques révisées, convertit les mesures en une unité commune tout en préservant les originaux, et sépare les modèles de machine des titres de produit. L'identificateur exact correspond automatiquement aux enregistrements; les correspondances probables deviennent des candidats à l'examen.

Un rouleau avec le même numéro de fabricant et les mêmes dimensions dans deux sources peut être lié à un produit canonique tout en conservant les deux offres du fournisseur. Un rouleau similaire visuellement avec une mesure d'alésage différente reste séparé. Une demande de modèle revendiquée n'ayant pas d'identificateur à l'appui ou de relation examinée est stockée comme preuve non vérifiée et n'est pas publiée comme allégation d'ajustement.

L'enregistrement approuvé peut ensuite envoyer du contenu en vitrine à Shopify tout en conservant les identifiants de produit et de variante Shopify, les valeurs opérationnelles de NetSuite ou Sage 200, et la piste de preuves derrière chaque attribut enrichi. Les mises à jour ultérieures du fournisseur correspondent à l'enregistrement source correct plutôt que de s'appuyer sur le titre qui se trouve être présent.

Publier les changements par une file d'attente d'examen contrôlée

Le groupe a proposé des changements par risque. Le formatage et les cartes de vocabulaire approuvées peuvent présenter un faible risque. Les changements d'identité, les enregistrements fusionnés, les demandes de compatibilité, les dimensions, le prix et la disponibilité méritent des vérifications plus rigoureuses. Un lot doit indiquer le nombre d'enregistrements qui changeront, les champs touchés et les destinations qui recevront la mise à jour.

L'examinateur a besoin de la valeur actuelle, de la valeur proposée, des preuves de la source et de la raison du changement. L'approbation devrait s'appliquer à un document et à une destination définis, et non pas accorder un chèque en blanc pour les importations futures. Les enregistrements rejetés ou échoués restent visibles avec une raison claire de sorte que la même erreur n'est pas répétée sur le fichier suivant.

Lorsqu'un système externe est la source de vérité, Shopify documente un flux de travail de synchronisation complet pour les données ERP ou PIM et les mutations ciblées lorsque Shopify possède l'enregistrement. Le choix de la bonne direction est important parce qu'un remplacement complet et une mise à jour sur le terrain ont des conséquences très différentes.

Mesurer si le dossier produit est devenu plus utile

Compter les résultats de qualité des données plutôt que le nombre de valeurs générées. Parmi les mesures utiles, mentionnons les dossiers dont l'identité est stable, l'achèvement des attributions requises, la résolution de duplications de candidats, les conflits en attente d'examen, les relations avec les preuves et les mises à jour de destination confirmées.

Ensuite, connectez l'amélioration des données aux voyages réels. Un client peut-il filtrer l'attribut ? La recherche peut-elle distinguer les variantes? Le personnel peut-il concilier une mise à jour du fournisseur? La page d'accueil correspond-elle au flux du produit? Google avertit que des informations inexactes, manquantes ou contradictoires sur les produits peuvent entraîner des désapprobations, une admissibilité limitée ou des affichages incorrects, ce qui fait du diagnostic d'alimentation un signal de qualité utile plutôt qu'un problème de marketing distinct.

M.I.A.I Product Intelligence est construit pour ce travail: normalisation des attributs, relations entre entités, enrichissement étayé par des preuves et examen de la qualité des données. L'objectif est une connaissance cohérente du produit qui peut soutenir le commerce, la recherche et l'automatisation sans déconnecter la réponse de sa source.

Une liste de contrôle pratique de la qualité des données sur les produits

• Chaque disque a une identité commerciale stable et ses identités de source.
• Les champs de niveau produit et de niveau variante sont cartographiés délibérément.
• Les valeurs originales restent disponibles à côté des valeurs normalisées.
• Les unités, le vocabulaire contrôlé et les règles de transformation sont explicites.
• Les candidats en double ont besoin de preuves au-delà de titres semblables.
• Les revendications conflictuelles demeurent visibles jusqu'à leur examen.
• Chaque champ a un propriétaire et une mise à jour autorisée.
• Destination écrit conserver les identifiants Shopify, NetSuite ou Sage.
• Les faits publiés, les flux et les pages d'atterrissage sont d'accord.
• Chaque importation produit un dossier de vérification vérifiable.