Atributos requeridos por marketplace: por qué la misma ficha no sirve para todos los canales
Cada marketplace tiene sus propias reglas de publicación. Una guía práctica para entender qué datos hay que preparar específicamente para cada canal.
Cuando una empresa empieza a vender en varios marketplaces, suele aparecer una expectativa bastante lógica: si el producto ya tiene una ficha completa, deberíamos poder enviar esa misma información a todos los canales y publicar.
En la práctica, no funciona así.
Una ficha puede estar perfectamente completa para el eCommerce propio y, aun así, no estar lista para un marketplace. Puede faltar un atributo obligatorio, la categoría puede no corresponder, un valor puede tener un formato que el canal no acepta o las variantes pueden necesitar otra estructura.
La razón es simple: cada marketplace tiene su propia manera de clasificar, describir y validar los productos. No cambia el producto; cambia el modelo de información que espera recibir cada canal.
Por eso, cuando trabajamos con un PIM, el objetivo no debería ser crear una ficha universal que se copie sin modificaciones. Lo que buscamos es mantener una base de producto consistente y distintas representaciones adaptadas a cada destino.
¿Qué es un atributo requerido por un marketplace?
Un atributo requerido es un dato que el marketplace necesita para aceptar, clasificar o mostrar correctamente un producto dentro de una categoría determinada.
Puede ser algo evidente, como la marca, el material o la talla. Pero también puede ser información que nuestro equipo nunca necesitó para la tienda propia: tipo de cierre, género recomendado, sistema de tallas, cantidad de unidades, potencia, compatibilidad, acabado o determinadas dimensiones.
Además, los requisitos no suelen ser iguales para todo el catálogo. La categoría o el tipo de producto determina buena parte de los atributos que hay que completar.
Esto cambia la lógica de trabajo. Antes de preguntarnos si una ficha está completa, tenemos que preguntarnos: ¿está completa para qué canal?
En Amazon, por ejemplo, los atributos cambian según el tipo de producto seleccionado y se distinguen entre requeridos, recomendados y el conjunto completo disponible. La propia plataforma explica que esos atributos también intervienen en la búsqueda y los filtros que utilizan los compradores.
Mercado Libre trabaja igualmente con categorías y atributos asociados a ellas, por lo que el modelo de publicación necesita contemplar la clasificación del producto y los campos correspondientes al destino.
Un producto puede estar listo para el eCommerce y todavía no estar preparado para Mercado Libre, Amazon, Falabella u otro marketplace.
El marketplace no pregunta solamente «¿qué producto es?». También necesita saber «¿cómo debo clasificarlo, validarlo y hacerlo encontrable dentro de mi propio catálogo?».
¿Por qué una misma ficha no sirve para todos los marketplaces?
Porque una ficha de producto y una publicación en un marketplace no son exactamente lo mismo.
La ficha del PIM puede reunir toda la información maestra del artículo. El listing o publicación es la versión de esa información preparada según las reglas de un canal concreto.
Pensemos en una mochila. En nuestro PIM podemos tener correctamente organizados su SKU, GTIN, marca, capacidad, material, color, dimensiones, imágenes y descripción.
Con eso conocemos el producto.
Pero un marketplace puede pedir además un tipo de mochila definido dentro de su propia taxonomía, un valor normalizado para el color, una edad recomendada o una característica específica de esa categoría. Otro canal puede estructurar el mismo producto de manera diferente y solicitar otros atributos.
El producto no cambió. Cambió la estructura de información del sistema que lo recibe.
Es bastante parecido a preparar un mismo contenido editorial para varias salidas. El texto puede ser el mismo, pero un libro impreso, un EPUB y un audiolibro no necesitan exactamente el mismo archivo de producción. La obra se conserva; la preparación para el canal cambia.
¿Qué datos deberían mantenerse comunes y cuáles deberían adaptarse?
Una forma práctica de ordenar este problema es separar la información en dos capas.
La primera es la información maestra del producto: los datos que describen qué es y que deberían conservar su significado en todo el ecosistema.
La segunda es la información específica del canal: los campos, valores y formatos que necesitamos para que esa base pueda publicarse correctamente en un marketplace determinado.
| Área | Información maestra | Adaptación por canal |
|---|---|---|
| Identificación | SKU, GTIN, marca, modelo | Identificadores o asociaciones propias del marketplace |
| Clasificación | Familia o categoría interna | Categoría del canal |
| Atributos | Material, color, medidas, capacidad | Atributos y valores aceptados por el marketplace |
| Contenido | Nombre, descripción, beneficios | Título o contenido específico |
| Variantes | Relación padre-hijo | Estructura de variación admitida |
| Imágenes | Recursos aprobados | Orden, cantidad o asociación específica |
| Logística | Peso y dimensiones | Campos requeridos por la operación del canal |
La clave está en no caer en ninguno de los dos extremos: ni duplicar todo el catálogo para cada marketplace ni obligar a todos los canales a consumir una única ficha rígida.
El modelo más ordenado es mantener una fuente central y construir desde ahí las adaptaciones necesarias.
Centralizar la información no significa publicar exactamente lo mismo en todas partes. Significa mantener una fuente común desde la cual podamos generar versiones consistentes para cada canal.
La categoría del marketplace define buena parte del trabajo
Antes de pensar qué campos vamos a enviar, necesitamos saber dónde debe quedar clasificado el producto.
La categoría no es solamente una carpeta. En muchos marketplaces funciona como una puerta de entrada al modelo de datos: al definir qué tipo de producto estamos publicando, también definimos qué atributos corresponden.
Por eso, una de las primeras tareas es realizar un mapeo taxonómico:
Categoría del PIM → Categoría del marketplace
Nuestra estructura interna podría ser:
Calzado > Deportivo > Running
El marketplace puede utilizar otra jerarquía, otro nivel de profundidad o incluso una forma diferente de agrupar esos mismos productos.
No hay ningún problema en que las taxonomías sean distintas. Lo importante es documentar la correspondencia.
El error aparece cuando asumimos que ambas estructuras son equivalentes y publicamos sin mapearlas.
Elegir la categoría correcta no solo determina dónde aparecerá el producto. También puede determinar qué información tendremos que completar para poder publicarlo.
¿Qué diferencia hay entre atributos obligatorios, recomendados y condicionales?
No todos los atributos tienen el mismo peso.
Un atributo obligatorio debe estar completo para que el producto pueda publicarse en determinadas condiciones.
Un atributo recomendado puede no bloquear la publicación, pero mejora la descripción del producto y puede intervenir en la búsqueda, los filtros o la comparación.
También podemos encontrarnos con atributos condicionales: campos que pasan a ser necesarios solamente cuando se cumple cierta condición.
Por ejemplo, Amazon documenta precisamente esta lógica en sus atributos de producto y advierte que los requisitos se actualizan, por lo que recomienda trabajar con plantillas recientes. También señala que los atributos completos participan en la visibilidad de búsqueda, los filtros y el contexto que utiliza su asistente de compra Rufus.
Esto es importante porque la completitud debería evaluarse por canal y por categoría, no solamente como una cifra general para todo el producto.
Podemos tener un artículo con todos sus atributos internos completos y descubrir que todavía le falta información específica para un marketplace.
Un mismo atributo puede necesitar varias representaciones
Una de las situaciones más frecuentes no es que falte el dato, sino que el canal espera recibirlo de otra forma.
Supongamos que tenemos:
Color comercial: Verde bosque
Ese valor puede ser perfectamente válido dentro del catálogo.
Pero un canal puede aceptar solamente «Verde», otro puede necesitar «Verde oscuro» y otro puede trabajar con un código determinado.
En el PIM podríamos conservar:
- Color comercial: Verde bosque.
- Color normalizado: Verde.
- Valor canal A: Verde oscuro.
- Valor canal B: GREEN.
La solución no es modificar el dato maestro hasta que coincida con cada marketplace.
La solución es mantener el significado original y crear equivalencias para los destinos que lo necesiten.
Esto también ocurre con tallas, materiales, unidades de medida, acabados, edades recomendadas, tipos de producto y muchas otras características.
Adaptar un dato a un marketplace no significa cambiar lo que significa. Significa traducirlo al vocabulario y al formato que entiende ese canal.
¿Por qué el tipo de atributo también importa?
No alcanza con tener el dato. También necesitamos que esté estructurado de una manera que podamos transformar.
Si almacenamos «12 kg» en un único campo de texto, nosotros entendemos perfectamente qué significa. Pero un marketplace puede necesitar dos elementos independientes: el número 12 y la unidad kg.
Lo mismo sucede con otros casos:
- «Rojo, azul y verde» en texto libre frente a una selección múltiple.
- «Sí» escrito como texto frente a un atributo booleano.
- «30 × 20 × 10 cm» frente a tres campos independientes.
- varias características mezcladas en una descripción frente a atributos separados.
Cuanto más estructurada está la información en el PIM, más fácil resulta adaptarla a los distintos modelos de los canales.
Por eso, el diseño de atributos tiene consecuencias directas sobre la capacidad de distribuir el catálogo.
¿Qué deberíamos revisar en Mercado Libre, Amazon y otros marketplaces?
No conviene memorizar una lista universal de atributos. Los requisitos dependen del canal, la categoría y el tipo de producto.
Lo que sí podemos sistematizar es qué preguntas tenemos que responder antes de publicar.
Mercado Libre
Antes de preparar la salida, necesitamos identificar la categoría correspondiente y revisar los atributos asociados.
Las preguntas básicas son:
- ¿A qué categoría de Mercado Libre corresponde este producto?
- ¿Qué atributos solicita esa categoría?
- ¿Qué valores acepta?
- ¿Cuáles describen al producto y cuáles a la variante?
- ¿Tenemos esos datos en el PIM?
- ¿Necesitamos transformarlos antes de enviarlos?
El trabajo no consiste solamente en conectar campos. Muchas veces también tenemos que definir equivalencias entre vocabularios y formatos.
Amazon
En Amazon, el tipo de producto también determina buena parte de la estructura necesaria.
Conviene distinguir dos conceptos que pueden confundirse:
Información del producto: describe qué es el artículo.
Información de la oferta: describe las condiciones en las que un vendedor lo comercializa.
Esta separación es útil porque evita intentar administrar desde el PIM datos que quizás pertenecen al ERP, al marketplace o a otro sistema.
Antes de publicar, necesitamos comprobar:
- qué tipo de producto corresponde;
- qué identificadores necesita;
- qué atributos son requeridos;
- qué variantes admite;
- qué información pertenece al producto;
- qué información pertenece a la oferta.
¿Y Falabella u otros marketplaces?
La lógica es la misma: consultar la estructura vigente del canal y construir el mapeo desde esa fuente.
No deberíamos basar una integración en una plantilla antigua o en lo que recordamos de un proyecto anterior.
Los requisitos del canal deben tratarse como información que necesita mantenimiento.
Hoy un atributo puede ser opcional y mañana pasar a ser requerido. Una categoría puede reorganizarse. Una lista de valores puede cambiar.
Eso implica que el mapeo PIM-marketplace también forma parte del mantenimiento habitual del catálogo.
Las variantes son otro punto donde una ficha universal suele fallar
Los productos con variantes agregan otra capa de complejidad.
Dentro del PIM podemos tener un producto padre con diferentes combinaciones de color y talla. Cada SKU hijo conserva sus identificadores y sus valores diferenciadores, mientras hereda otros datos del padre.
El marketplace puede necesitar esa estructura de otra manera.
Puede definir:
- qué atributos generan variantes;
- qué combinaciones están admitidas;
- qué información debe permanecer en el producto padre;
- qué campos corresponden al SKU hijo;
- qué identificador necesita cada variante;
- qué imagen debe asociarse con cada combinación.
Por eso, no alcanza con preguntar si tenemos talla y color.
También necesitamos saber en qué nivel están almacenados y cómo espera recibirlos el canal.
Una matriz de atributos por canal evita empezar de cero cada vez
Cuando gestionamos varios marketplaces, una matriz sencilla puede ahorrar bastante trabajo.
| Campo del PIM | Tipo | Canal A | Canal B | Transformación |
|---|---|---|---|---|
| SKU | Texto | Requerido | Requerido | Ninguna |
| GTIN | Identificador | Según producto | Según producto | Validación |
| Color | Lista | Mapear | Mapear | Tabla de equivalencias |
| Material | Lista | Según categoría | Según tipo | Normalización |
| Título | Texto | Versión específica | Versión específica | Regla de composición |
| Categoría interna | Relación | Categoría destino | Tipo de producto | Mapeo |
| Imagen principal | Recurso | Sí | Sí | Orden o formato |
Yo agregaría algunas columnas más para el trabajo cotidiano:
- obligatoriedad;
- responsable del dato;
- formato esperado;
- valores permitidos;
- regla de transformación;
- acción si el campo está vacío;
- fecha de última revisión.
De esa manera, cuando aparece un rechazo, no tenemos que reconstruir toda la lógica desde cero. Podemos localizar rápidamente qué regla falló.
Mi proceso para preparar un catálogo para un nuevo marketplace
Antes de conectar nada, seguiría este orden:
- Definir el surtido. Decidir qué productos realmente van a publicarse en ese canal.
- Mapear las categorías. Relacionar la taxonomía interna con la del marketplace.
- Relevar atributos. Identificar cuáles son obligatorios, recomendados o condicionales.
- Detectar brechas. Comparar los requisitos con la información que ya existe en el PIM.
- Normalizar valores. Resolver vocabularios, unidades y formatos incompatibles.
- Diseñar transformaciones. Documentar cómo se convierte cada dato.
- Calcular la completitud por canal. Un producto no debería considerarse listo si le falta información necesaria para ese destino.
- Probar una muestra representativa. Incluir productos simples, variantes y categorías diferentes.
- Registrar rechazos. Convertir los errores del marketplace en mejoras del dato o del mapeo.
Este último punto es especialmente importante.
Si corregimos un valor directamente en el marketplace pero no actualizamos el PIM o la regla de transformación, probablemente el problema vuelva a aparecer en la siguiente sincronización.
Corregir manualmente una publicación resuelve un producto. Corregir el dato o el mapeo resuelve el proceso.
Un caso real: una fuente central para destinos distintos
En un proyecto de indumentaria con múltiples marcas, el PIM debía abastecer varios destinos desde una única fuente de producto.
La información tenía que alimentar un eCommerce, un sistema de punto de venta, un servicio para gestionar códigos GTIN, un marketplace mediante una plataforma de sindicación y otros canales de catálogo.
Eso obligó a trabajar con diferentes taxonomías, normalizar productos padre y variantes de talla y, sobre todo, definir qué información necesitaba cada salida y de qué manera debía recibirla.
El resultado no fue una ficha idéntica enviada varias veces.
Fue un maestro centralizado capaz de producir distintas representaciones del mismo producto sin perder consistencia.
Ese es, para mí, uno de los usos más claros de un PIM: no obligar a todos los canales a hablar el mismo idioma, sino conservar el significado del dato mientras lo traducimos correctamente para cada destino.
¿Qué deberíamos revisar antes de publicar en un marketplace?
Antes de considerar un producto listo, esta es la checklist que usaría:
- ¿Tiene asignada la categoría correcta del marketplace?
- ¿Conocemos los atributos obligatorios de esa categoría o tipo de producto?
- ¿Los valores cumplen el formato y vocabulario aceptados?
- ¿Los atributos condicionales están contemplados?
- ¿El título y el contenido están preparados para ese canal?
- ¿Las variantes respetan la estructura requerida?
- ¿Cada SKU tiene sus identificadores correspondientes?
- ¿Las imágenes están asociadas al producto y variante correctos?
- ¿Los datos logísticos provienen del sistema adecuado?
- ¿La completitud se mide específicamente para ese destino?
- ¿Existe un proceso para registrar rechazos y devolver las correcciones al PIM?
La documentación del marketplace sigue siendo la referencia para decidir qué exige cada canal. La checklist nos ayuda a convertir esos requisitos en un proceso repetible.
La misma ficha no sirve para todos los marketplaces porque cada canal clasifica, valida y utiliza la información de producto de una manera diferente. Eso no significa que tengamos que mantener varios catálogos desconectados. La forma más ordenada de trabajar es conservar un dato maestro confiable y construir desde ahí las representaciones que necesita cada destino. Cuando categorías, atributos, equivalencias y transformaciones están documentados, publicar en un nuevo marketplace deja de ser una sucesión de excepciones y empieza a convertirse en un proceso que podemos mantener y escalar.
