Gestionar un catálogo en tres marketplaces al mismo tiempo: lo que nadie ve detrás del botón “publicar”
Publicar simultáneamente en varios marketplaces exige mucho más que un clic. Acá describo el trabajo real de adaptación de datos por canal, las validaciones que realizo antes de publicar y los controles necesarios para sostener un catálogo consistente.
Desde afuera, publicar un producto en varios marketplaces parece un proceso bastante directo. El producto ya existe, tiene nombre, descripción, imágenes y precio. En teoría, solo habría que seleccionar los canales y presionar un botón.
Esa es la parte visible.
Detrás del botón “publicar” hay que decidir en qué categoría vivirá el producto dentro de cada marketplace, qué atributos debe completar, cómo se representarán sus variantes, qué imágenes cumplen las reglas del canal y qué información necesita transformarse antes de enviarla.
Un mismo producto puede estar perfectamente enriquecido dentro del PIM y, sin embargo, ser rechazado en Mercado Libre, quedar incompleto en Falabella y publicarse con una clasificación incorrecta en Amazon.
Por eso, cuando trabajo con varios marketplaces al mismo tiempo, no pienso en tres copias de la misma ficha. Pienso en tres representaciones diferentes construidas a partir de un producto maestro.
Publicar en tres marketplaces no significa enviar tres veces la misma ficha. Significa traducir un mismo producto a tres modelos de catálogo diferentes.
¿Cuál es la diferencia entre un producto y una publicación?
Dentro del PIM gestionamos el producto como una entidad central. Allí concentramos su identificación, sus atributos, sus variantes, sus relaciones, sus activos digitales y la información necesaria para distribuirlo.
En un marketplace, en cambio, gestionamos un listing: una publicación creada de acuerdo con las reglas de una categoría, un país, un idioma y un canal determinados.
La diferencia parece pequeña, pero modifica todo el enfoque.
El producto puede tener un nombre maestro que sirve para identificarlo dentro de la organización. El listing necesita un título adaptado al canal. El producto pertenece a una taxonomía interna; la publicación debe ubicarse en una categoría propia de Mercado Libre, Falabella o Amazon. El producto puede tener diez imágenes válidas, pero cada plataforma puede tener un límite menor o requerir otro orden, proporción o tipo de imagen principal.
El PIM preserva la identidad y la coherencia del producto. La capa de distribución transforma esa información para que cada marketplace pueda recibirla y mostrarla correctamente.
La fuente puede ser única. La salida no tiene por qué ser idéntica.
Tres marketplaces implican tres formas de interpretar el producto
Mercado Libre, Falabella y Amazon organizan sus catálogos mediante taxonomías y modelos de atributos propios. No usan las mismas categorías, no solicitan exactamente la misma información y tampoco representan de igual manera las variantes, los títulos o los activos digitales.
Una familia definida en el PIM como “Zapatillas deportivas”, por ejemplo, puede relacionarse con tres categorías distintas y con tres conjuntos diferentes de atributos obligatorios.
El trabajo no consiste solamente en encontrar una categoría que se parezca. Hay que comprobar que esa categoría represente correctamente la naturaleza del producto y que habilite los atributos necesarios para describirlo.
Una clasificación incorrecta puede provocar:
- Atributos obligatorios que no corresponden al producto.
- Filtros de navegación inadecuados.
- Variantes imposibles de representar.
- Rechazos durante la carga.
- Menor encontrabilidad dentro del marketplace.
- Información presentada en una sección equivocada de la ficha.
En Mercado Libre, la categoría seleccionada determina buena parte de los atributos aplicables a la publicación. Falabella también relaciona cada categoría con un conjunto específico de atributos y valores permitidos. Amazon utiliza categorías y tipos de producto para definir la información que debe completar el vendedor.
La categorización no puede quedar para el final como una tarea administrativa. Es una decisión estructural que condiciona todo lo que podremos publicar después.
¿Cómo se mapean las categorías entre el PIM y cada marketplace?
Cuando preparo un catálogo para varios marketplaces, construyo una matriz de correspondencias entre la taxonomía interna y las categorías de cada canal.
Puede verse de esta manera:
| Categoría interna | Mercado Libre | Falabella | Amazon |
|---|---|---|---|
| Zapatillas deportivas | Zapatillas deportivas/ Varía según país | Zapatillas deportivas / Varía según el Seller Center | Deporte y ejercicio / Tipo de producto y categoría correspondiente |
| Grifería de cocina | Griferías | Cocina o mejoramiento del hogar | Tipo de producto aplicable |
| Mochilas de trekking | Mochilas deportivas | Deportes y aire libre | Tipo de producto de mochilas |
La matriz no es un documento definitivo. Los marketplaces reorganizan categorías, incorporan atributos y actualizan sus reglas de publicación. Una correspondencia válida hoy puede dejar de ser adecuada después de un cambio en el canal.
Por eso, además del nombre de la categoría, necesito registrar:
- El identificador utilizado por cada marketplace.
- La familia de productos a la que aplica.
- La fecha de la última validación.
- Los atributos obligatorios asociados.
- Las reglas especiales conocidas.
- El responsable de revisar futuros cambios.
El mapeo de categorías es una parte viva del gobierno del catálogo. No es una tabla que se prepara una vez y luego se archiva.
Una categoría mal mapeada no solo ubica el producto en el lugar equivocado. También puede activar atributos, filtros y reglas de publicación que no corresponden.
La misma ficha no alcanza para todos los canales
Una vez definida la categoría aparece el segundo nivel de adaptación: el mapeo de atributos.
¿Por qué el mismo atributo no siempre puede enviarse sin cambios?
El PIM puede almacenar una estructura rica y coherente, pero cada marketplace utiliza una parte distinta de esa información. Además, puede pedir los valores en formatos diferentes.
Un atributo como “Material” parece universal. Sin embargo, un canal puede recibirlo como texto, otro exigir una opción de una lista cerrada y un tercero separar material principal, material exterior y composición.
Lo mismo ocurre con medidas, colores, tallas, capacidad, género, compatibilidad, modelo o tipo de instalación.
Mi tarea consiste en definir:
- Qué atributo del PIM alimenta cada campo del marketplace.
- Si el valor puede enviarse directamente.
- Si requiere una transformación.
- Qué ocurre cuando el dato está vacío.
- Cómo se tratan los valores que no existen en la lista del canal.
- Qué atributos son obligatorios y cuáles mejoran la calidad de la publicación.
El mapeo no consiste en unir columnas con nombres parecidos. Un campo llamado “Color” en dos sistemas puede tener formatos, valores admitidos y usos completamente distintos.
Falabella, por ejemplo, expone mediante su API los atributos correspondientes a cada categoría, indica cuáles son obligatorios y enumera las opciones permitidas cuando corresponde. Su documentación advierte que la omisión de atributos mandatorios explica una parte importante de los errores de carga.
El mapeo no conecta nombres de columnas. Conecta significados, formatos y reglas de negocio entre modelos que no fueron diseñados para ser iguales.
¿Cómo adapto los vocabularios sin perder la consistencia del catálogo?
Los atributos de selección simple o múltiple suelen ser una de las mayores fuentes de trabajo.
En el PIM podemos haber normalizado el color como “Azul marino”. Un marketplace podría aceptar “Azul”, otro “Azul oscuro” y otro esperar un código asociado a una opción de categoría.
El error sería reemplazar el valor maestro para que coincida con un único destino. Eso convertiría las reglas externas de un marketplace en reglas internas del catálogo.
Prefiero mantener un término estable en el PIM y construir equivalencias por canal:
| Valor maestro | Canal A | Canal B | Canal C |
|---|---|---|---|
| Azul marino | Azul | Azul oscuro | Navy |
| Acero inoxidable | Acero inoxidable | Acero | Stainless steel |
| Talle único | Único | Talla única | One size |
Esta capa permite adaptar el lenguaje sin perder la consistencia central.
También evita que cada persona resuelva las equivalencias de una forma distinta. Sin vocabularios controlados, “Azul marino” puede terminar convertido en “Azul”, “Navy”, “Azul oscuro” o “Azul noche” según quién haya preparado la publicación.
El marketplace necesita recibir su propio término permitido. El PIM necesita conservar el significado correcto.
¿El título del producto puede ser igual en los tres marketplaces?
Uno de los errores más frecuentes es reutilizar el nombre maestro como título en todos los canales.
El nombre maestro sirve para identificar el producto dentro de la organización. El título de una publicación tiene otra función: debe ayudar al comprador a reconocer, comparar y encontrar el producto dentro de un marketplace determinado.
Por eso suelo definir fórmulas de título por canal y familia.
Una estructura posible es:
Marca + tipo de producto + modelo + característica principal + variante
Pero el orden, la longitud y los elementos admitidos pueden variar.
Un mismo producto podría publicarse de esta manera:
- Mercado Libre: Zapatillas deportivas Marca Modelo Hombre Azul.
- Falabella: Zapatillas running Marca Modelo para hombre.
- Amazon: Marca Modelo Men’s Running Shoes, Navy Blue.
Por ejemplo, Amazon establece lineamientos específicos para títulos, viñetas, atributos, imágenes y descripciones. Además, considera estos componentes dentro de la calidad general de la página de producto y de su capacidad para aparecer correctamente en búsquedas y filtros.
En otros marketplaces, el título puede generarse a partir de la categoría o de atributos previamente cargados. También puede existir una diferencia entre el título que enviamos y el que finalmente muestra la plataforma.
No se trata de llenar el título con todas las palabras disponibles. Se trata de construir una identificación clara, sin repeticiones innecesarias y con los elementos que ayudan a distinguir esa publicación de otras similares.
¿Por qué las descripciones tampoco deberían copiarse sin adaptación?
Con las descripciones pasa algo parecido: un texto creado para el eCommerce propio puede contener enlaces, formatos, referencias comerciales o estructuras que un marketplace no admite. También puede resultar demasiado largo, demasiado breve o poco útil para la plantilla del canal.
Por eso prefiero separar el contenido en componentes reutilizables:
- Descripción comercial.
- Beneficios principales.
- Características técnicas.
- Instrucciones de uso.
- Información de seguridad.
- Información de garantía.
- Preguntas frecuentes.
- Términos de búsqueda, cuando el canal dispone de ese campo.
Con estos componentes puedo construir versiones diferentes sin reescribir toda la información desde cero.
Como mencione antes, Amazon diferencia el título, las viñetas, la descripción, los atributos estructurados y el contenido enriquecido. No son campos intercambiables: cada uno cumple una función particular dentro de la página de detalle. Mercado Libre y Falabella también presentan el contenido dentro de estructuras propias.
Adaptar el contenido no significa inventar tres historias sobre el producto. Significa organizar la misma verdad de acuerdo con la experiencia de compra de cada canal.
¿Qué ocurre con las variantes de color y talla?
Las variantes son uno de los puntos donde el modelo empieza a tensarse.
Color y talla parecen una combinación sencilla hasta que cada marketplace interpreta las relaciones padre-hijo de una manera diferente.
El PIM puede tener un producto padre con varias variantes. Cada variante posee su SKU, su GTIN, su color, su talla y sus imágenes. El canal puede exigir otra estructura o admitir variantes solamente en determinadas categorías.
Antes de publicar necesito validar:
- Qué atributos pueden actuar como ejes de variación.
- Si la categoría admite variantes.
- Qué registro funciona como producto padre.
- Qué datos se heredan.
- Qué imágenes corresponden a cada variante.
- Qué sucede si una sola variante contiene un error.
- Cómo se desactiva una variante sin eliminar todo el grupo.
En Falabella, por ejemplo, las publicaciones con variantes pueden depender de la creación correcta del SKU padre. En Mercado Libre, la categoría y los atributos disponibles condicionan qué variaciones pueden utilizarse. Amazon también exige relaciones específicas entre productos padre e hijos según el tipo de producto.
Un único error estructural puede afectar a todo el conjunto.
En un catálogo con variantes, el error del producto padre rara vez queda aislado. Puede impedir la publicación de todas las opciones que dependen de él.
Las imágenes también necesitan una estrategia por canal
No todas las imágenes almacenadas en el PIM deben enviarse automáticamente a todos los marketplaces.
Primero necesito identificar la función de cada activo:
- Imagen principal.
- Vista alternativa.
- Detalle.
- Imagen de uso o contexto.
- Infografía.
- Tabla de medidas.
- Imagen del empaque.
- Imagen específica de una variante.
Después verifico formato, resolución, proporción, fondo, contenido permitido y orden.
Amazon, por ejemplo, exige al menos una imagen principal que cumpla sus normas y recomienda incorporar recursos adicionales que ayuden al comprador a evaluar el producto. También puede rechazar, retirar o ajustar imágenes que no cumplan las condiciones establecidas.
Esto obliga a tratar las imágenes como datos. No alcanza con adjuntar archivos al producto. Necesitamos saber qué representa cada imagen y en qué canales puede utilizarse.
El orden también importa. La fotografía elegida como principal en un marketplace puede no ser la más adecuada para otro. Una imagen con texto promocional puede estar permitida en una posición secundaria y ser rechazada como imagen principal.
¿Qué parte del catálogo pertenece al PIM y qué parte pertenece a otros sistemas?
Cuando hablamos de “la ficha” solemos mezclar información que, en realidad, pertenece a capas diferentes.
Identidad del producto: SKU, GTIN, marca, modelo y relaciones entre variantes.
Contenido: títulos, descripciones, atributos, imágenes y documentación.
Oferta: precio, stock, logística, promociones y estado de venta.
Estas capas pueden provenir de sistemas distintos y tener frecuencias de actualización diferentes.
El PIM suele ser la fuente principal del contenido y de buena parte de la identidad comercial. El ERP, el OMS o las herramientas comerciales pueden gestionar precio, stock y pedidos.
Cuando todo se procesa como un único bloque, una actualización de contenido puede sobrescribir información transaccional que no le corresponde. También puede suceder lo contrario: un cambio de stock podría activar una publicación cuyo contenido todavía no está completo.
Cada dato necesita una fuente definida y una regla clara de actualización.
¿Cómo sé si un producto está listo para cada canal?
Un producto puede estar completo para Mercado Libre y todavía no estar listo para Amazon. También puede cumplir los requisitos mínimos de Falabella, pero tener un contenido demasiado pobre para alcanzar una buena calidad de publicación.
Por eso no trabajo con una única métrica general de completitud.
Defino perfiles por canal:
| Control | Mercado Libre | Falabella | Amazon |
|---|---|---|---|
| Categoría mapeada | Obligatorio | Obligatorio | Obligatorio |
| Atributos de categoría | Según categoría | Según categoría | Según tipo de producto |
| Identificador comercial | Según publicación | Según configuración | Según producto y categoría |
| Imágenes válidas | Sí | Sí | Sí |
| Variantes verificadas | Si aplica | Si aplica / Si la categoría las admite | Si aplica |
| Contenido adaptado | Sí | Sí | Sí |
| Estado posterior a la carga | Revisar | Revisar feed y puntaje | Revisar calidad y posibles supresiones |
Falabella incorpora además un puntaje de contenido dentro de su flujo. Su documentación actual indica que el resultado puede influir en la aprobación automática, la revisión manual o el rechazo del producto, y recomienda consultar las reglas aplicables a cada categoría antes de crear la publicación.
La completitud no consiste solamente en rellenar campos obligatorios. También permite determinar si la publicación cuenta con información suficiente para ser encontrada, comparada y comprendida dentro del canal.
Un producto puede ser técnicamente publicable y comercialmente pobre. Esa diferencia importa.
¿Qué sucede después de presionar “publicar”?
El botón publicar inicia un proceso, no lo termina.
Después del envío, cada marketplace puede devolver estados diferentes:
- Publicado.
- Pendiente.
- En revisión.
- Rechazado.
- Publicado con advertencias.
- Inactivo.
- Sin imágenes.
- Sin stock.
- Suprimido por calidad o incumplimiento.
No alcanza con saber que el archivo fue enviado o que la API respondió correctamente. Necesitamos recuperar el estado final y asociarlo con el SKU correspondiente.
Un tablero operativo debería mostrar, como mínimo:
- Productos enviados.
- Productos publicados.
- Productos rechazados.
- Motivo del rechazo.
- Marketplace afectado.
- Fecha del último intento.
- Responsable de resolverlo.
- Próxima acción.
Sin este seguimiento, los errores quedan distribuidos entre correos, archivos y paneles diferentes. El catálogo central parece completo, pero parte del surtido nunca llega a la estantería digital.
La publicación no termina cuando el marketplace recibe los datos. Termina cuando el producto queda activo, visible y correctamente representado.
¿Cómo convierto los errores del marketplace en tareas concretas?
Los marketplaces suelen devolver códigos, referencias internas o mensajes que no siempre son claros para el equipo de contenido.
“Valor inválido” no alcanza como instrucción. Necesitamos saber qué atributo falló, qué valor se envió, qué opciones admite el canal y si el problema afecta a un producto o a toda la familia. Tenemos que saber si puede corregirse en el PIM o en la transformación o si requiere solicitar una nueva marca, categoría u opción.
Cuando un mismo error se repite, no corrijo únicamente las publicaciones afectadas. Reviso la regla.
Si cincuenta productos fallan por el mismo color, probablemente no existen cincuenta errores independientes. Existe una equivalencia de vocabulario incompleta.
Si todas las variantes de una familia son rechazadas, reviso el modelo padre-hijo.
Si un canal empieza a pedir un nuevo atributo obligatorio, actualizo el perfil de completitud y el proceso de enriquecimiento.
Así, el error deja de ser una incidencia aislada y se convierte en información para mejorar el modelo.
¿Cómo se mantiene actualizado un catálogo en tres marketplaces?
Publicar correctamente una vez no garantiza que el catálogo se mantenga correcto.
Los productos cambian. Aparecen nuevas imágenes, se corrige una descripción, se modifica una especificación o se retira una variante. Cada cambio debe propagarse a los canales correspondientes.
En ese momento vuelven a aparecer varias preguntas:
- ¿El cambio fue detectado?
- ¿Se envió a todos los canales que debía?
- ¿Los tres marketplaces lo aceptaron?
- ¿La publicación visible contiene la versión nueva?
- ¿Algún canal conservó la información anterior?
- ¿Alguien modificó el dato directamente en el marketplace?
La consistencia multicanal exige seguir no solamente el estado del producto en el PIM, sino también el estado independiente de cada publicación.
El catálogo maestro puede tener una sola versión confiable. Las publicaciones necesitan, además, un estado independiente por marketplace.
El PIM reduce la duplicación, pero no elimina la adaptación
Un PIM resulta fundamental para centralizar el producto, normalizar los valores y evitar que cada equipo mantenga su propia hoja de cálculo. Sin embargo, no convierte automáticamente una ficha universal en tres publicaciones perfectas.
La operación necesita una capa de distribución capaz de aplicar:
- Mapeos de categorías.
- Mapeos de atributos.
- Equivalencias de valores.
- Fórmulas de títulos.
- Reglas de imágenes.
- Transformaciones de variantes.
- Validaciones de completitud.
- Procesamiento de respuestas y errores.
Esta capa puede resolverse mediante conectores, plataformas de sindicación, middleware o desarrollos específicos.
La elección depende del volumen, la frecuencia de actualización y la complejidad del catálogo. Lo importante es evitar que las reglas queden escondidas en archivos temporales o en el conocimiento de una sola persona.
Lo que aprendí en proyectos reales de sindicación y publicación multicanal
En un proyecto multimarca de indumentaria, el catálogo central debía alimentar un eCommerce, un punto de venta, un sistema de identificación de productos y un marketplace a través de una plataforma intermediaria.
Antes de implementar la integración, fue necesario normalizar miles de productos padre y decenas de miles de variantes. También hubo que diseñar taxonomías diferentes para el eCommerce y el marketplace, decidir qué información necesitaba cada salida y definir cómo se representarían los datos en cada destino.
En otro proyecto, con múltiples marcas de productos para actividades al aire libre, se implementó un PIM y se creó un feed destinado a una plataforma de sindicación. El flujo enviaba únicamente productos nuevos o modificados, pero esa eficiencia dependía de que el catálogo estuviera normalizado y de que las reglas del canal fueran explícitas.
También trabajamos en un proyecto de productos para la construcción, donde necesitaban enviar productos enriquecidos desde el PIM hacia una plataforma intermediaria para su publicación en un marketplace. En esos casos, el integrador debía transmitir datos generales y atributos personalizados según la familia del producto.
En estos casos, la eficiencia de la publicación dependía de decisiones tomadas mucho antes de ejecutar el proceso: modelado, normalización, categorización, identificación y reglas de transformación.
Ninguno de estos proyectos se resolvió agregando un marketplace a una lista y presionando “publicar”. Primero hubo que entender cómo debía verse el producto en cada destino.
¿Cómo organizo la operación para que pueda sostenerse?
Para gestionar varios marketplaces sin convertir cada publicación en una excepción, necesito un proceso repetible.
Primero mantengo un producto maestro con datos normalizados. Después defino las reglas de salida de cada canal. A continuación, valido la completitud, publico y recupero las respuestas.
Finalmente, reviso el resultado visible y convierto los errores recurrentes en mejoras del modelo.
El flujo puede resumirse así:
Producto maestro → selección del surtido → adaptación por canal → validación → publicación → monitoreo → corrección → reconciliación
Lo importante no es eliminar todas las excepciones. Los marketplaces cambian y siempre aparecerán productos particulares.
Lo que importa es que una excepción no obligue a reconstruir manualmente todo el proceso.
El botón “publicar” es apenas el último gesto visible de un trabajo mucho más profundo. Cuando las categorías, los atributos, los vocabularios, las variantes y las reglas de cada marketplace están bien diseñados, publicar deja de ser una sucesión de correcciones urgentes y se convierte en una operación controlada. No envío tres copias del mismo producto: construyo tres publicaciones consistentes sin perder una única fuente de verdad.
