Lunes por la mañana, 09:12. En la bandeja compartida hay tres archivos nuevos de proveedores. El primero llama a la columna Color, el segundo Colour, el tercero simplemente col. La misma silla de comedor aparece en los tres archivos, pero con tres EAN distintos, uno de ellos vacío. Y estos son solo 3 de los 40 proveedores que tiene que procesar esta semana.
En el proveedor A el color se llama antracita, en el B gris oscuro, en el C DK-GREY. La medida aparece como DIM_MM 620x820x450 en un archivo y como tres columnas sueltas en otro. Puede cruzarlo todo a mano y perder buena parte de su semana cortando y pegando, alimentando el creciente caos de Excel de su lista de productos, o dejar que un sistema deduplique los archivos hasta un único registro por producto. Pero con una sola condición: que en cada valor todavía pueda ver qué proveedor lo aportó.
Por qué los archivos de proveedores nunca encajan solos
Cada mayorista entrega los datos tal y como le conviene a su sistema. Los nombres de columna difieren, las grafías difieren, las unidades difieren. Algunos campos están vacíos, faltan EAN o aparecen en notación científica porque Excel hizo de las suyas. No hay un estándar común, y tampoco lo habrá: no va a obligar a 40 proveedores a usar su plantilla.
Eso no es un incidente, sino una situación permanente. Los datos de producto envejecen sin parar: entran productos nuevos, cambian los proveedores y varían las especificaciones, así que lo que hoy es correcto, dentro de un trimestre ya está en parte desfasado. Quien quiere unificar decenas de archivos de proveedores en un golden record con procedencia por campo, no necesita un proyecto puntual, sino un proceso.
// proveedor-a.csvsku;titulo;Color;precio;ean// proveedor-b.csvart_nr;descripcion;Colour;price;barcode// proveedor-c.csvref;nombre;kl;bruto// Color, Colour y kl son el mismo campo
Sin estándar común: cada mayorista nombra la columna de otra manera.
- Para cada archivo de proveedor, un ritual propio de cortar y pegar
- La misma silla tres veces en su catálogo, con tres precios
- Un precio incorrecto en vivo y nadie sabe ya qué fuente lo aportó
- Una sola ruta fija: emparejar, normalizar, unificar
- Un registro por producto, deduplicado por SKU, EAN, código de barras e IA
- En cada valor, visible qué proveedor ganó y por qué
Paso 1: deduplicar los productos repetidos
Unificar empieza por reconocer. El mismo producto suele estar en varios archivos, y rara vez con exactamente la misma clave. En la literatura especializada esto se llama entity resolution o record linkage: los registros se enlazan por códigos de producto, nombres y atributos para formar una única source of truth, donde el emparejamiento probabilístico asigna pesos a la comparación de cada campo.
En la práctica eso significa: primero claves duras como SKU, EAN y código de barras, y allí donde faltan o se contradicen, un emparejamiento por título, marca y especificaciones. Así, ese EAN vacío del proveedor C no se queda fuera sin más, sino que se enlaza en función de lo que sí coincide.
Paso 2: normalizar a TU estructura
Aquí es donde a menudo se tuerce. La tentación es adoptar la estructura del proveedor, porque ya existe. Pero entonces acaba teniendo un catálogo con 47 maneras de escribir el color. Purple, lila y violeta son la misma casilla del filtro para su cliente. DK-GREY, gris oscuro y antracita también.
Normalizar significa reducir esas 47 grafías a sus propios 12 colores estándar, y que 620x820x450 en milímetros encaje limpiamente en sus propios campos de alto, ancho y fondo. Su estructura de tienda existente es el punto de partida, y las nuevas fuentes se acoplan a ella. Así que no empieza de cero: el sistema lee cómo está montado su catálogo y adapta los datos de proveedor a esa estructura.
Paso 3: unificar datos de proveedores en el golden record
Ahora que los duplicados están emparejados y los campos normalizados, tiene que elegir. Si tres proveedores aportan un precio, un plazo de entrega y una descripción, ¿cuál gana? En Master Data Management esto se llama survivorship: a partir de los registros emparejados se consolida por campo el valor más fiable en un único golden record. Informatica y Data Ladder describen exactamente estos tres pasos: matching, merging y survivorship.
El survivorship es un conjunto de reglas. El proveedor principal gana en precio, el fabricante gana en especificaciones, la descripción más larga gana en texto. Bien. Pero en cuanto ese registro está en su tienda, surge la verdadera pregunta.
Tome una sola lámpara colgante que aparece en tres archivos. Nombres distintos, tres grafías para el color, tres notaciones de medidas y un EAN vacío en el tercero. Haga clic y observe cómo las tres filas en bruto se funden en un único golden record:
{"titulo": "Lámpara colgante ovalada 60 cm","color": "Negro","alto": "22 cm", "ancho": "60 cm", "fondo": "22 cm","ean": "8712345678901",// fuente por campo: A · B · enlazado pese a EAN vacío}
Haga clic para alternar: tres grafías del color pasan a ser Negro, y el EAN vacío se enlaza por lo que sí coincide.
Un golden record que nadie puede controlar ni corregir no es una source of truth. Es un amasijo fusionado en el que solo le queda confiar.
Procedencia por campo: por qué el origen de cada valor marca la diferencia
Suponga que hay un precio incorrecto en vivo. Con una importación de caja negra solo sabe que el precio es de 149 euros. No cuál de los 40 proveedores lo aportó, ni si una automatización o una sugerencia de IA lo modificó, ni si alguien lo sobrescribió a mano. Está atascado.
La data provenance responde exactamente a esa pregunta: ¿de dónde viene este valor? Proveedores de catálogos de datos como Atlan matizan la distinción: la provenance trata sobre el origen, la confianza y la evidencia, mientras que el lineage trata sobre cómo fluyen y cambian los datos. A nivel de campo, ve la fuente de cada valor. Y eso no es un detalle menor: sin procedencia no puede rastrear un error hasta quién o qué lo causó, y cada corrección se convierte en una conjetura.
Con procedencia por campo, en ese precio de 149 euros ve si vino del proveedor B, si una automatización lo redondeó, si la IA lo propuso, o si un compañero lo fijó a mano. Y puede intervenir: un valor manual gana, y un campo se puede bloquear para que la siguiente importación no lo sobrescriba de nuevo.
Control de calidad y el último paso hacia su tienda
La unificación solo está completa cuando las desviaciones se eliminan antes de que lleguen a su tienda. Un precio que de golpe es diez veces mayor, un stock negativo, una medida que no cuadra: eso debe frenarlo en la puerta, no descubrirlo por una devolución. Y compensa, porque los datos de producto erróneos le cuestan un cliente que se marcha y una devolución que podría haber evitado. Cada desviación que frena antes de la tienda se paga sola.
El último paso es la salida. Las fuentes las conecta mediante feeds de proveedores, SFTP, correo, ERP y API REST, y al otro lado los registros limpios se publican en vivo en su tienda online. Por el camino, cada foto de proveedor se convierte a WebP en el tamaño adecuado para cada ubicación, hasta un 98 por ciento más ligera, y las fotos duplicadas se almacenan una sola vez. Las páginas más rápidas cuentan para Google: según web.dev, un buen LCP se sitúa en 2,5 segundos o menos.
- Unificar datos de proveedores es una cadena: emparejar, normalizar a su estructura y unificar con survivorship.
- Deduplicar por SKU, EAN, código de barras e IA convierte 40 archivos en un registro por producto.
- Normalice a su propio estándar: 47 grafías de color pasan a ser sus 12 colores.
- Sin procedencia por campo, un golden record es una caja negra en la que, ante un error, se queda sin respuestas.
- Los valores manuales ganan y los campos se pueden bloquear para que la siguiente importación no los sobrescriba.
