Cómo unificar los datos del producto del proveedor sin perder la identidad del producto

Por qué los catálogos de proveedores se vuelven difíciles de confiar

Dos proveedores pueden describir el mismo tipo de producto de maneras completamente diferentes. Uno envía “rollo de fondo”, otro envía “rollo más bajo”, y un tercero pone el modelo de máquina en una nota de texto libre. Las mediciones pueden llegar a milímetros, centímetros o pulgadas. Los nombres de marca adquieren cambios de puntuación, los colores usan nombres locales, y los campos importantes están enterrados en títulos porque la hoja de cálculo no tiene otro lugar para ponerlos.

El problema se vuelve más grave cuando esos archivos se importan repetidamente. Un título cambiado puede crear un segundo producto. Un proveedor SKU puede ser confundido con el SKU del comerciante. Una columna en blanco puede borrar un valor aprobado. El stock y el precio pueden actualizar correctamente mientras que la descripción, la variante o la relación de compatibilidad se adjunta al artículo incorrecto.

La inteligencia del producto comienza separando la identidad, los atributos, las relaciones y los valores comerciales. Esas categorías pueden entonces seguir diferentes reglas de propiedad y revisión en lugar de ser tratadas como una fila no diferenciada.

Inicio con identidad de producto, no redacción de producto

Un título está destinado a la gente y puede cambiar legítimamente. Es una pobre clave primaria. Mantenga identificadores estables para el registro de origen, el registro mercante y cada plataforma de destino. Estos pueden incluir un número de producto del proveedor, ID de producto interno, SKU, GTIN, ID de producto Shopify, ID de variante, ID de artículo NetSuite o referencia de stock del Sage.

No asuma que todos los identificadores significan lo mismo. Un GTIN identifica un artículo comercial según sus reglas de emisión; un SKU interno es controlado por el negocio; un ID de producto Shopify identifica el contenedor de productos; y cada variante de compra tiene su propia identidad de plataforma. Almacene el tipo de identificador, valor y sistema emisor en lugar de poner cada código en un campo etiquetado “número de parte”

La especificación de Google Merchant Center requiere un ID de producto único, aconseja mantenerlo sin cambios durante las actualizaciones y dice que el mismo producto debe conservar el mismo ID en países o idiomas. Ese principio es valioso más allá de un pienso: una identidad estable permite que las descripciones, precios y atributos cambien sin romper la conexión con el elemento subyacente.

• Identidad de origen: qué registro de proveedores produjo el valor
• Identidad empresarial: el producto canónico del comerciante y SKU
• Identidad comercial: un GTIN u otro identificador reconocido cuando sea aplicable
• Identidad de la plataforma: el producto de destino y la variante IDs
• Identidad de la relación: el vínculo revisado entre un producto, modelo, categoría o aplicación

Crear un modelo de atributo gobernado

Antes de fusionar archivos, definir los campos que el negocio realmente necesita. Dar a cada atributo un nombre claro, tipo de datos, unidad, valores permitidos, regla de propiedad y regla de validación. Un diámetro debe ser numérico con una unidad explícita. Una marca debe referirse a una entidad de marca canónica. Una propiedad sí o no debe aceptar seis ortografías de sí

Mantenga el modelo práctico. Comience con los atributos que afectan la compra, ajuste, descubrimiento, cumplimiento, stock o realización. Las notas sólo para proveedores pueden permanecer como evidencia fuente sin convertirse en campos orientados al cliente. El propósito no es crear el esquema más grande; es hacer que los hechos importantes sean lo suficientemente consistentes para usar.

Shopify models a product as a container with options and variations, where a variety represents a specific purchasable combination and carries values values such as price, inventory and codede. Por lo tanto, la hoja de cálculo plana de un proveedor debe ser mapeado deliberadamente en campos de nivel de producto y de la variante en lugar de copiar columna para columna.

1. Enumerar las decisiones que los clientes y el personal necesitan los datos para apoyar.
2. Definir campos canónicos, unidades y valores controlados para esas decisiones.
3. Mapa de cada columna proveedor a un campo canónico o un campo sólo evidencia.
4. Preserve el valor original al lado del valor normalizado.
5. Validar los campos requeridos y la singularidad de identificador antes de fusionarse.
6. Enviar conflictos no resueltos a revisar en lugar de elegir silenciosamente.

Normalizar los valores sin destruir la fuente

La normalización hace que valores equivalentes sean comparables. Puede estandarizar el espacio blanco, caso, puntuación, unidades, formatos de fecha y vocabulario conocido. “Acero inoxidable”, “SS” y el código de material aprobado de un proveedor pueden mapear a un valor de material canónico, siempre que el mapeo sea documentado y realmente equivalente.

Nunca sobreescribir la fuente cruda. Almacene el valor original, valor normalizado, regla de transformación, fuente, tiempo de importación y estado de confianza o revisión. Esto hace que los errores sean reversibles y da a un revisor suficiente contexto para decidir si una asignación propuesta es segura.

La conversión de unidad necesita la misma disciplina. Mantenga la medición y unidad suministradas, registre el valor convertido y aplique precisión apropiada. Redondear una dimensión técnica para la visualización no debe alterar el valor exacto utilizado para el ajuste, fabricación o compra.

Resolver duplicados con evidencia, no semejanza de título

Los duplicados potenciales deben ser marcados a partir de múltiples señales: identificadores estables, números de piezas del fabricante, marca, dimensiones, estructura variante, relaciones con los proveedores y otros atributos aprobados. Un título compartido o una descripción similar puede identificar a los candidatos, pero no debe autorizar una fusión.

Defina lo que una fusión significa. A veces dos filas de proveedores representan el mismo artículo comercial de diferentes fuentes y pueden vincularse a un registro canónico. A veces son alternativas equivalentes que deben seguir siendo productos separados. A veces una fila representa un producto padre, mientras que otra representa una variante de compra. Estas son relaciones diferentes y no deben colapsarse en una sola suposición.

Cuando la evidencia conflictos, mantenga ambas afirmaciones con sus fuentes y marque el campo para su revisión. Un revisor debe ver exactamente qué registros discrepan, los valores implicados, la fecha de evidencia y los destinos de abajo afectados por una decisión.

Mantener datos, relaciones y datos comerciales separados

Los hechos del producto describen el artículo: material, dimensiones, marca y atributos técnicos. Las relaciones lo conectan a categorías, modelos, aplicaciones, accesorios o alternativas. Los datos comerciales cubren el precio, la disponibilidad, el impuesto, el costo del proveedor y el cumplimiento. Cada grupo puede tener una fuente diferente de verdad y frecuencia de actualización.

Por ejemplo, un ERP puede poseer stock y precio mientras que una fuente de fabricante aprobada posee dimensiones. Un flujo de trabajo de información de producto puede poseer títulos y categorías normalizados. Shopify puede seguir siendo el destino principal. La separación de estas responsabilidades impide que un archivo de proveedor descriptivo sobrescriba el inventario en vivo o un pienso de inventario de la eliminación del contenido de producto aprobado.

El vocabulario del producto de Schema.org refleja esta distinción proporcionando propiedades para identificadores de productos, marca, categoría, material, modelo y ofertas. Un modelo estructurado no prueba que una reclamación es correcta, pero ayuda a los sistemas a llevar diferentes tipos de información de producto sin reducir todo a la prosa.

Un ejemplo concreto: combinando tres catálogos de encarcelamiento

Imagínese que un comerciante recibe tres archivos de piezas de excavadora bajo custodia. El primero utiliza números de fabricante, el segundo utiliza SKUs proveedor, y el tercero describe aplicaciones de máquina en una columna de notas. Los tres contienen rodillos, idlers y piñones, pero sus nombres de categoría y dimensiones difieren.

El flujo de trabajo importa cada archivo en un área de estadificación y asigna una identidad fuente a cada fila. mapea sinónimos de categoría en categorías canónicas revisadas, convierte las mediciones en una unidad común preservando los originales y separa los modelos de máquinas de los títulos de producto. El identificador exacto coincide automáticamente con los registros de enlaces; los partidos probables se convierten en candidatos de revisión.

Un rodillo con el mismo número de fabricante y dimensiones en dos fuentes puede estar vinculado a un producto canónico mientras que conserva ambas ofertas de proveedores. Un rodillo visualmente similar con una medición diferente del agujero permanece separado. Una aplicación modelo reclamada sin identificador de soporte o relación revisada se almacena como evidencia no verificada y no se publica como una reclamación de ajuste.

El registro aprobado puede entonces enviar contenido de almacén a Shopify mientras mantiene el ID de producto Shopify y variantes, valores operativos de NetSuite o Sage 200, y el rastro de evidencia detrás de cada atributo enriquecido. Más tarde las actualizaciones del proveedor coinciden con el registro de fuente correcto en lugar de confiar en cualquier título que sea presente.

Publicar cambios mediante una cola de revisión controlada

Grupo propuso cambios por riesgo. Formatear y aprobar cartografías de vocabulario puede ser bajo riesgo. Cambios de identidad, registros fusionados, reclamaciones de compatibilidad, dimensiones, precio y disponibilidad merecen cheques más fuertes. Un lote debe mostrar cuántos registros cambiarán, qué campos están afectados y qué destinos recibirán la actualización.

El revisor necesita el valor actual, el valor propuesto, las pruebas de origen y la razón del cambio. La aprobación debe aplicarse a un registro y destino definidos, no otorgar un cheque en blanco para futuras importaciones. Los registros fallidos o rechazados permanecen visibles con una razón clara para que el mismo error no se repita en el siguiente archivo.

Cuando un sistema externo es la fuente de la verdad, Shopify documenta un flujo de trabajo de sincronización de estado completo para datos ERP o PIM y mutaciones específicas cuando Shopify posee el registro. Elegir los asuntos de dirección correcta porque un reemplazo completo y una actualización a nivel de campo tienen consecuencias muy diferentes.

Medir si el registro del producto se convirtió en más útil

Cuenta los resultados de calidad de datos en lugar del número de valores generados. Las medidas útiles incluyen registros con identidad estable, terminación requerida atribuida, candidatos duplicados resueltos, conflictos pendientes de revisión, relaciones con pruebas y actualizaciones de destino confirmadas.

Luego conecta mejoras de datos a viajes reales. ¿Puede un filtro de cliente en el atributo? ¿Puede la búsqueda distinguir las variantes? ¿Puede el personal reconciliar una actualización del proveedor? ¿La página de aterrizaje coincide con la alimentación del producto? Google advierte que la información de producto inexacta, desaparecida o conflictiva puede causar desaprobaciones, elegibilidad limitada o pantallas incorrectas, lo que hace que el diagnóstico de alimentación sea una señal de calidad útil en lugar de un problema de marketing separado.

M.I.A.I Inteligencia de Producto se construye para este trabajo: normalización de atributos, relaciones de entidad, enriquecimiento respaldado por pruebas y revisión de calidad de datos. El objetivo es un conocimiento coherente del producto que puede apoyar el comercio, la búsqueda y la automatización sin desconectar la respuesta de su fuente.

Una lista de verificación práctica de calidad de los datos del producto

• Cada registro tiene una identidad empresarial estable y sus identidades de origen.
• Los campos de nivel de producto y de nivel de variante se mapean deliberadamente.
• Los valores originales permanecen disponibles junto a los valores normalizados.
• Unidades, vocabulario controlado y reglas de transformación son explícitas.
• Los candidatos duplicados requieren pruebas más allá de títulos similares.
• Las reclamaciones en conflicto siguen siendo visibles hasta que se examinan.
• Cada campo tiene un propietario y una dirección de actualización autorizada.
• Destino escribe conserva identificadores de registro de Shopify, NetSuite o Sage.
• Datos publicados, feeds y landing pages están de acuerdo.
• Cada importación produce un registro de auditoría revisado.