Normalización de datos como paso previo a la integración: cómo estandarizar antes de enviar

Antes de conectar un sistema externo al PIM, los datos tienen que pasar por una etapa de normalización. No alcanza con que estén cargados: tienen que estar estandarizados, ser consistentes y quedar listos para circular entre sistemas sin romper filtros, validaciones ni publicaciones. En esta nota, Erwin baja a tierra los patrones de transformación que suele aplicar para alinear vocabulario, formatos y valores antes de integrar.

Cuando trabajo en integraciones entre ERP, PIM, eCommerce, marketplaces o middleware, hay una situación que aparece seguido: alguien dice que los datos ya están listos, pero cuando empezamos a revisarlos aparece otra realidad. El mismo color viene escrito de varias maneras, las unidades mezclan abreviaturas con texto libre, una marca entra con mayúsculas, minúsculas y variantes, y un mismo atributo cambia de formato según el origen. En ese escenario, integrar no es simplemente conectar dos sistemas. Es impedir que el desorden de una fuente se replique y quede automatizado en todo el ecosistema.

Por eso, para mí, la normalización no es un paso decorativo ni una prolijidad previa al desarrollo. Es una condición técnica para que la integración tenga sentido. Si los datos no están estandarizados antes de enviarse, el problema no desaparece cuando llegan al destino. Solo cambia de lugar: termina en el PIM, en el canal de salida, en los filtros del sitio, en los atributos obligatorios de un marketplace o en la lógica del conector.

Integrar datos inconsistentes no acelera nada. Solo hace que los errores viajen más rápido entre sistemas.

¿Por qué normalizar antes de integrar cambia el resultado?

En el ecosistema PIM, normalizar significa estandarizar valores, formatos y criterios de carga para que la información de producto sea consistente, reutilizable y gobernable. El glosario de trabajo del proyecto lo define justamente como el proceso de llevar datos equivalentes a una forma consistente, por ejemplo unificando colores, marcas o unidades de medida para evitar variantes dispersas dentro del catálogo.

Dicho en términos prácticos, si un sistema externo va a enviar productos al PIM, esos datos no deberían ingresar como texto libre desordenado esperando que alguien los acomode después. Lo ideal es que lleguen con estructura y con vocabulario controlado. Y si eso no ocurre en origen, entonces la transformación tiene que suceder en la capa de integración.

Esto no es solamente un tema de limpieza. Afecta directamente la operación. Un color mal normalizado rompe filtros. Una unidad inconsistente arruina comparaciones. Un atributo con formatos mezclados vuelve frágiles las reglas de calidad. Una marca escrita de varias formas fragmenta búsquedas, facetas y reportes. Cuando ese desorden se publica en varios canales, la inconsistencia se multiplica.

El problema de dejar la corrección para después

Una mala práctica bastante habitual es asumir que el sistema destino va a absorber el caos del origen. Como si el PIM pudiera funcionar al mismo tiempo como fuente de verdad, capa de gobierno, interfaz editorial y además mecanismo automático de limpieza de datos.

En la práctica, eso suele generar dos problemas. El primero es operativo: el equipo termina corrigiendo a mano lo que podría haberse transformado antes. El segundo es estructural: el PIM empieza a llenarse de excepciones, parches y campos usados como contención para datos que nunca debieron entrar así.

Yo prefiero pensarlo al revés. Antes de enviar, hay que definir qué significa “dato válido” para ese flujo. Esa definición puede vivir en reglas, tablas de equivalencia, scripts, diccionarios o funciones de transformación. Pero tiene que existir. Si no existe, la integración queda atada a la variabilidad de cada fuente.

¿Qué conviene revisar antes de conectar una fuente externa?

Antes de tocar código, hay una etapa que para mí es central: entender la forma real de los datos. No la forma ideal del documento funcional ni la del archivo de ejemplo, sino la forma real con la que esa fuente viene trabajando.

¿Qué miro primero en una auditoría de entrada?

Arranco revisando cinco cosas:

• Variantes de vocabulario: colores, materiales, marcas, tipos de producto, acabados, géneros, temporadas.
• Formatos mixtos: números como texto, medidas con unidades incrustadas, fechas ambiguas, booleanos expresados de varias formas.
• Campos sobrecargados: un mismo atributo con dos o tres datos metidos en la misma celda.
• Inconsistencias de casing y escritura: tildes, abreviaturas, plurales, errores de tipeo, nombres duplicados con variantes mínimas.
• Niveles de granularidad distintos: una fuente manda “azul”, otra “azul marino” y otra “navy”.

Esa revisión me permite identificar no solo errores, sino patrones. Y cuando encontrás patrones, ya podés empezar a transformar con criterio en lugar de corregir caso por caso.

La normalización empieza mucho antes del script: empieza cuando entendés cómo se comportan de verdad los datos de entrada.

Los patrones de transformación que más suelo aplicar

No hay una receta única, porque cada proyecto tiene su contexto. Pero sí hay un conjunto de transformaciones que aparecen una y otra vez. Son patrones bastante clásicos, y cuanto antes se definan, más robusta queda la integración.

Normalización de vocabulario controlado

Este es probablemente el caso más frecuente. Consiste en tomar valores equivalentes o parecidos y llevarlos a una forma canónica. Por ejemplo, que “negro”, “NEGRO”, “Black” o “neg.” terminen convertidos en un único valor aceptado: “Negro”.

Esto aplica mucho a color, marca, material, acabado, colección, tipo de producto o cualquier atributo que después alimente filtros, facetas o mapeos de canal. En el glosario del proyecto, el concepto de vocabulario controlado está justamente asociado a listas cerradas y estandarizadas para evitar variantes inconsistentes que terminan degradando la calidad del catálogo.

Acá hay una decisión importante: no siempre conviene conservar toda la riqueza caótica del valor original en el campo principal. Muchas veces es mejor definir un valor estandarizado visible y, si hace falta trazabilidad, conservar el original en un campo auxiliar.

Separación de datos nucleados

Otro caso muy común es el de campos que llegan con demasiada información junta. Medida y unidad en el mismo string. Nombre más marca más variante en un solo campo. Tipo de producto mezclado con compatibilidad o con presentación.

Integrar eso tal como llega es hipotecar el modelo de datos. La transformación, en este caso, consiste en separar componentes y distribuirlos en atributos distintos. No siempre se logra de forma perfecta, pero incluso una separación parcial mejora mucho la reutilización posterior.

En proyectos reales esto marca una diferencia fuerte. En el caso de RISOUL, por ejemplo, se trabajó sobre un universo masivo de atributos y datos inconsistentes, reduciendo complejidad, corrigiendo errores y preparando incluso un campo de detalle para concentrar información demasiado específica en lugar de contaminar toda la estructura.

Estandarización de unidades y formatos

Hay pocas cosas que rompan más una integración que mezclar sistemas de medida o formatos de carga sin criterio. Centímetros, milímetros, pulgadas, kilos, gramos, litros, mililitros, todo conviviendo en el mismo atributo o incluso en el mismo campo de texto.

Acá la regla para mí es simple: definir una unidad estándar dentro del modelo y transformar todo hacia ahí antes de enviar. Lo mismo vale para moneda, porcentajes, booleanos, fechas y formatos numéricos. Si una API o un perfil de importación espera un tipo de dato concreto, hay que entregarlo ya en ese formato. No confiar en interpretaciones implícitas del sistema destino.

Limpieza de texto y normalización semántica

Esta capa es menos vistosa, pero muy importante. Incluye trimming de espacios, limpieza de caracteres especiales, unificación de mayúsculas y minúsculas, corrección básica de etiquetas y depuración de valores residuales como “N/A”, “#N/D”, “sin dato” o guiones usados como placeholder.

En catálogos grandes, estas correcciones dejan de ser una cuestión estética y pasan a ser una necesidad operativa. En el caso de Librerías Gandhi, por ejemplo, se trabajó sobre depuración de atributos, unificación de criterios y vocabulario controlado, incluyendo la estandarización de autores y editoriales para evitar dispersión dentro de un catálogo enorme.

Mapeo de equivalencias por canal

No siempre alcanza con normalizar hacia adentro. Muchas veces también hay que preparar equivalencias hacia afuera. Un valor interno puede necesitar una representación distinta según el eCommerce, el marketplace o el sistema de publicación.

En esos casos, a mí me sirve separar dos capas: el valor canónico dentro del modelo y el valor transformado para cada canal. Esa distinción evita que el maestro quede contaminado por requisitos particulares de una sola salida. El glosario del proyecto también refuerza esta idea al definir data mapping como el corazón de toda integración PIM, justamente porque traduce campos y valores entre sistemas distintos.

Normalizar no es solo limpiar antes de entrar. También es preparar el dato para que salga bien hacia cada canal.

Normalizar no es perder información: es volverla gobernable

Este punto me importa bastante porque a veces se malinterpreta. Normalizar no significa empobrecer el dato ni “aplanarlo” sin criterio. Significa hacerlo gobernable. Que un mismo concepto tenga una forma reconocible, que una validación pueda correr bien, que una regla pueda aplicarse, que un filtro devuelva lo que corresponde y que una integración no dependa de cien excepciones.

Cuando el catálogo crece, eso se vuelve crítico. En proyectos con muchas variantes, múltiples marcas, catálogos extensos o varios canales de salida, el desorden se vuelve exponencial si no hay una capa de transformación seria. En un caso fashion con miles de productos padre y decenas de miles de variantes, por ejemplo, fue necesario limpiar y normalizar talles, valores y estructuras antes de poder alimentar correctamente SAP, VTEX, POS, marketplace y catálogo.

El dato normalizado no es el dato “más lindo”. Es el dato que ya puede gobernarse, validarse y circular sin generar excepciones en cada paso.

¿Dónde conviene ejecutar la normalización?

No hay una respuesta universal, porque depende del ecosistema. Pero mi criterio general es que la normalización tiene que vivir lo más cerca posible del punto donde todavía se puede controlar con lógica clara y repetible.

A veces eso ocurre en el ERP. A veces en una planilla intermedia. A veces en un middleware. A veces en un script de ingestión hacia el PIM. Lo que intento evitar es que la corrección quede librada a ajustes manuales recurrentes dentro del sistema destino.

Si la fuente es estable y controlable, conviene corregir en origen. Si la fuente es heterogénea o recibe datos de muchos proveedores, muchas veces la mejor opción es una capa de transformación previa a la ingesta. En cualquier caso, lo importante es que las reglas existan, estén documentadas y no dependan solo de memoria individual.

¿Qué entrego yo cuando dejo resuelta esta parte?

Cuando una etapa de normalización queda bien resuelta, no dejo solamente “un script que transforma”. Suelo dejar varias piezas que hacen sostenible el proceso:

• un criterio de valor canónico por atributo;
• tablas de equivalencia para vocabulario frecuente;
• funciones de transformación reutilizables;
• validaciones para detectar entradas fuera de estándar;
• manejo de excepciones y valores no reconocidos;
• trazabilidad mínima entre dato original y dato transformado.

Eso permite que el flujo no dependa de memoria individual. Y eso, para mí, es parte de una buena integración: no solo que funcione hoy, sino que pueda mantenerse cuando cambie la fuente, el equipo o el canal.

En varios casos del portfolio de trabajo de CRITERIA se ve ese patrón: limpieza de información, redefinición de atributos, vocabulario controlado, saneamiento de estructuras y preparación del dato antes de integrarlo con eCommerce, marketplaces o catálogos. Es una constante porque, en la práctica, sin eso la integración hereda los problemas del origen.

Lo que mejora cuando este paso se hace bien

Cuando la normalización está bien pensada, todo lo demás mejora. El PIM recibe datos más limpios. Las familias y atributos responden mejor. Los canales publican con menos rechazo. Los filtros del sitio funcionan mejor. Las reglas de calidad detectan problemas reales en lugar de ruido. Y el equipo deja de gastar horas corrigiendo inconsistencias que podrían haberse evitado antes.

En otras palabras: la integración deja de ser un simple traslado de datos y pasa a convertirse en una capa real de orden. Ahí es cuando el trabajo técnico empieza a impactar de verdad en la operación.

Antes de enviar datos al PIM, no me interesa solo que pasen. Me interesa que lleguen con una forma que el ecosistema pueda sostener. Porque una integración bien hecha no conecta sistemas por conectar: conecta estructuras que ya están listas para convivir sin romperse entre sí.