Mapeo de atributos entre sistemas: cómo transformar el modelo de datos del PIM para cada destino

Cada sistema que recibe datos del PIM tiene su propio esquema, su propia lógica y sus propias restricciones. Por eso, integrar no es copiar atributos de un lado a otro, sino construir capas de transformación que permitan adaptar el modelo de datos del PIM a cada destino sin romper el maestro, sin duplicar lógica y sin volver inmanejable el mantenimiento.

Cuando trabajo en integraciones entre PIM, eCommerce, ERP, marketplaces, POS o middleware, hay una idea que aparece todo el tiempo: el modelo de datos del PIM no viaja intacto a ningún destino. Y no debería. El PIM puede ser la fuente de verdad de la información de producto, pero cada sistema que consume esos datos espera otra cosa. Algunos piden nombres de campos distintos. Otros exigen estructuras propias. Otros combinan atributos que en el PIM están separados. Y otros directamente necesitan que los valores lleguen transformados antes de aceptarlos.

Por eso, para mí, el mapeo de atributos no es una tarea menor ni una simple tabla de equivalencias. Es una decisión de arquitectura. Si se resuelve mal, la integración queda frágil, acoplada a un solo canal y difícil de mantener. Si se resuelve bien, el PIM sigue siendo el maestro mientras cada destino recibe exactamente la forma de dato que necesita.

El PIM puede ser la fuente de verdad sin convertirse en una copia forzada del esquema de cada canal.

Mapear no es copiar campos

Uno de los errores más comunes es pensar que integrar consiste en tomar un atributo del PIM y enviarlo a un campo equivalente del sistema destino. A veces eso pasa. Pero muchas veces no. Hay destinos que esperan un solo campo donde el PIM tiene tres. Otros necesitan listas de opciones externas para valores que dentro del PIM están resueltos como texto controlado. Otros obligan a combinar atributos, cambiar formatos o adaptar estructuras completas según categoría, familia o tipo de producto.

Ahí es donde se ve que mapear no es trasladar, sino interpretar. El PIM organiza la información de producto según su propio modelo: atributos, familias, variantes, categorías, canales y reglas. El destino la organiza con otra lógica. Un eCommerce puede necesitar metafields. Un marketplace puede exigir atributos obligatorios por categoría. Un ERP puede esperar estructuras más rígidas. Un POS puede consumir solo una parte mínima del producto. Un catálogo impreso puede requerir feeds preparados para maquetación.

Eso significa que entre el modelo fuente y el modelo destino siempre hay una distancia que alguien tiene que resolver. Y esa resolución, si está bien hecha, no rompe el maestro. Lo traduce.

El problema de mapear cada destino como una excepción

Cuando un proyecto arranca, es tentador resolver rápido. Se crea un integrador, se escriben equivalencias directas, se agregan algunas condiciones especiales para ciertas familias y se empuja el dato al destino. El problema aparece después. Llega un nuevo canal, cambia una categoría, aparecen nuevos atributos, se redefine una familia o se suma una segunda marca, y toda la lógica empieza a repartirse en scripts, funciones aisladas y excepciones que ya nadie puede seguir con claridad.

En ese punto, el problema no es solo técnico. También es operativo. Cada cambio empieza a dar miedo porque nadie sabe del todo qué otra cosa puede romper. Lo que parecía un conector simple se convierte en una acumulación de reglas sueltas.

Yo trato de evitar eso desde el principio. Si el mapeo de atributos va a vivir, tiene que poder crecer sin volverse opaco. Y para eso hace falta pensar la transformación como una capa propia, no como una serie de parches alrededor del transporte.

Cuando el mapeo queda escondido entre condiciones sueltas, cada nuevo canal deja de ser una integración y pasa a ser una deuda técnica.

Pensar el mapeo como una capa de transformación

Para mí, una integración madura no conecta directamente el PIM con el destino. Entre ambos tiene que existir una capa que traduzca. Esa capa toma el modelo maestro y lo adapta según reglas explícitas: nombres de campo, estructuras, tipos de dato, valores permitidos, taxonomías, unidades, formatos, atributos compuestos o requerimientos específicos del canal.

La ventaja de trabajar así es que el PIM no necesita deformarse para parecerse al destino. Y el destino no obliga a que el modelo maestro pierda coherencia para poder publicar. Cada uno conserva su lógica, y la transformación resuelve la distancia entre ambos.

En la práctica, eso también permite sostener mejor el catálogo. El dato central sigue siendo uno, pero puede expresarse de formas distintas sin perder identidad. Para mí, ese es el punto más importante.

En varios casos de CRITERIA se trabajó justamente así: el dato maestro se saneó, se modeló en el PIM y después se construyeron integraciones específicas para cada salida. En COFLEX, por ejemplo, se desarrolló un integrador entre Sales Layer y Commercetools con tareas de extracción, transformación e ingesta; en LEURU se armó un ecosistema con salidas distintas hacia SAP, VTEX, Retail Pro, GS1, Producteca y catálogo; y en Grupo Forem se configuraron integraciones hacia dos instancias diferentes de Shopify Plus con requerimientos propios en metafields y listas de publicación.

Qué conviene definir antes de empezar a mapear

Antes de escribir una sola línea de transformación, hay algunas preguntas que conviene resolver. No porque formen una metodología rígida, sino porque evitan improvisar el modelo mientras la integración ya está corriendo.

Qué recibe realmente el sistema destino

Muchas veces el destino no necesita “el producto completo”, sino una vista específica de ese producto. Puede requerir identificación, títulos, imágenes y poco más. O puede necesitar categorías, relaciones, variantes, atributos técnicos, compatibilidades y estructura editorial. Si eso no se define bien desde el principio, se termina llevando más información de la necesaria o, peor, modelando mal la salida.

Qué parte del modelo del PIM es canónica

No todos los campos dentro del PIM tienen el mismo peso. Algunos son nucleares y deberían mantenerse estables. Otros existen para enriquecer. Otros sirven solo para ciertos canales. Si eso no está claro, el mapeo se vuelve confuso porque no distingue entre lo que pertenece al maestro y lo que solo existe como preparación de salida.

Qué reglas son comunes y cuáles son específicas

Hay transformaciones que aplican a todos los destinos: limpieza de texto, formatos, normalización de ciertas unidades, validaciones mínimas. Y hay otras que son exclusivas de un canal: una taxonomía externa, ciertos metafields, un formato particular de nombre o una lógica de publicación específica. Separar esas dos capas evita repetir lógica y ayuda mucho a mantener.

Los patrones de mapeo que más se repiten

Más allá de la plataforma, hay ciertos patrones que aparecen una y otra vez cuando el modelo del PIM tiene que hablar con otros sistemas.

Mapeo uno a uno

Es el caso más simple: un atributo del PIM viaja a un campo del destino con poca o ninguna transformación. Aun así, no conviene asumir equivalencia automática. Siempre hay que revisar tipo de dato, obligatoriedad, formato y longitud esperada.

Mapeo de varios atributos hacia un solo campo

Esto pasa mucho en títulos, descripciones cortas, resúmenes comerciales o campos heredados de sistemas más rígidos. En esos casos, la transformación no es solo concatenar strings. Hay que definir orden, prioridad, separadores y comportamiento cuando faltan valores.

Mapeo de un atributo hacia varios destinos posibles

Un mismo atributo del PIM puede terminar publicado de formas distintas según el canal. Puede ir como campo principal en un eCommerce, como metafield en otro sistema o como parte de un feed de marketplace. Eso obliga a pensar el atributo como dato canónico, pero no como forma final única.

Mapeo condicionado por familia o categoría

Este es uno de los patrones más importantes. No todos los atributos aplican a todos los productos. Hay canales que piden conjuntos distintos de campos según la familia, la categoría o el tipo de producto. Eso significa que el mapeo no puede ser completamente plano. Tiene que saber cuándo un atributo aplica, cuándo es obligatorio y cuándo directamente no corresponde enviarlo.

Mapeo con transformación de vocabulario

También es muy frecuente que un valor correcto dentro del PIM no coincida con el valor aceptado por el sistema destino. Pasa con colores, materiales, estados, categorías, tipos de producto o etiquetas de canal. Ahí entran las tablas de equivalencia, los diccionarios de transformación o las reglas de adaptación semántica. El dato interno sigue siendo válido, pero necesita otra forma para poder circular.

El atributo puede ser correcto dentro del PIM y seguir siendo inválido para el destino si no pasa por una traducción de contexto.

¿Cómo construir una capa de transformación mantenible?

Para mí, la clave está en no mezclar todo. Cuando una integración se vuelve difícil de sostener, casi siempre es porque la lógica quedó acoplada: autenticación, transporte, transformación, reglas de negocio y manejo de errores viven en el mismo lugar.

Yo prefiero trabajar con capas separadas. Por un lado, una definición clara del origen. Por otro, reglas de transformación. Después, adaptadores por destino. Y recién ahí la parte de transporte o publicación. Eso permite que, si cambia un canal, no haya que reescribir toda la integración, sino tocar solamente la parte que traduce hacia ese esquema.

También ayuda mucho evitar que todo quede hardcodeado. No todas las equivalencias tienen que vivir dentro del código. Muchas pueden resolverse con configuraciones, estructuras declarativas, tablas de mapeo o perfiles reutilizables. Cuanto más visible y explícita queda la lógica de transformación, más fácil es mantenerla.

¿Qué pasa cuando aparecen nuevos canales?

Un mapeo bien resuelto no es el que funciona con un solo destino. Es el que permite agregar uno nuevo sin romper lo anterior. Y eso pasa más seguido de lo que parece. Un cliente arranca con web y después suma marketplace. O arranca con marketplace y más adelante necesita catálogo impreso. O incorpora POS, B2B, brand portal o un nuevo canal regional.

Si la lógica estaba acoplada a un solo esquema, crecer duele. Si en cambio el modelo maestro se mantuvo limpio y las transformaciones se pensaron como capas adaptables, el trabajo nuevo consiste en sumar otra vista del mismo dato, no en rearmar toda la integración.

Eso, para mí, es una buena señal de salud arquitectónica: el sistema puede crecer porque la lógica no depende de una sola salida.

Lo que cambia cuando el mapeo está bien resuelto

Cuando esta capa está bien diseñada, el beneficio no es solo técnico. Se nota en toda la operación. El equipo entiende mejor qué dato gobierna qué salida. Los cambios en el PIM no generan miedo automático a romper integraciones. Los nuevos canales se pueden sumar con menos fricción. Las reglas de publicación se vuelven más trazables. Y el modelo maestro conserva su consistencia sin deformarse para parecerse a cada consumidor.

Ahí es cuando el mapeo deja de ser una tarea silenciosa de backend y pasa a convertirse en una pieza central de la arquitectura del dato. Porque, al final, integrar bien no es obligar a todos los sistemas a hablar el mismo idioma. Es construir una capa de traducción lo bastante clara como para que cada uno reciba lo que necesita sin comprometer la coherencia del maestro.

Integrar bien no es copiar atributos desde el PIM hacia otros sistemas. Es traducir el modelo maestro con criterio, de forma controlada y extensible, para que cada destino pueda consumir la información que necesita sin obligar al catálogo central a deformarse en el proceso.