Automatización de archivos planos: gestión de publicaciones de productos en varios marketplaces de Amazon

El sistema de archivos planos de Amazon es la interfaz más completa para gestionar publicaciones de productos en bloque en un catálogo extenso y una de las menos documentadas para operar en varios marketplaces. Cada marketplace utiliza una versión de plantilla distinta, exige campos diferentes y aplica sus propias reglas de validación, a menudo para el mismo producto de la misma categoría. Gestionar publicaciones en diez marketplaces a partir de una única fuente de datos de productos requiere un enfoque sistemático para las diferencias entre plantillas, la traducción de atributos y el ciclo de carga, validación y corrección.

Este artículo describe el flujo de trabajo con archivos planos que usamos para gestionar catálogos en varios marketplaces: cómo difieren las plantillas, dónde aporta más la automatización y dónde sigue siendo inevitable intervenir manualmente.

Qué son los archivos planos

Un archivo plano, o flatfile, es una hoja de cálculo delimitada por tabulaciones que Amazon utiliza para crear y actualizar publicaciones de productos en bloque. Cada fila representa un producto y cada columna, un atributo. La plantilla, descargada desde la sección Catalog > Add Products via Upload de Seller Central, define qué columnas son obligatorias, cuáles son opcionales y los valores válidos para cada campo.

El sistema de archivos planos es anterior a la Listings Items API de SP-API y sigue siendo la interfaz principal para la edición en bloque dentro de Seller Central. En cuanto a la API, Amazon declaró obsoletos los feeds de fichas de producto en archivos planos y XML en marzo de 2024, con su retirada prevista para el 30 de junio de 2025, en favor de la Listings Items API basada en JSON y JSON_LISTINGS_FEED; las cargas de archivos planos a través de Seller Central no se vieron afectadas. Para un vendedor con más de unas pocas docenas de SKU en varios marketplaces, un flujo de trabajo en bloque es prácticamente indispensable y, en nuestro sistema, el archivo plano es la interfaz principal de gestión del catálogo.

Pero, en la práctica, la documentación de Amazon sobre archivos planos está fragmentada y a menudo desactualizada. La especificación más reciente de una plantilla es la propia plantilla, recién descargada para el marketplace y la categoría que se gestionan. Depender de plantillas guardadas o documentación de hace seis meses es una fuente constante de errores de carga.

Diferencias entre las plantillas de los marketplaces

Las diferencias estructurales entre plantillas son mayores de lo que espera la mayoría de los vendedores cuando empieza a operar en varios marketplaces. No son simples traducciones de los mismos campos.

La plantilla estadounidense de ropa para una categoría puede tener cincuenta columnas de atributos. La alemana equivalente puede tener sesenta, incluidos campos sin equivalente estadounidense, como declaraciones específicas de cumplimiento sobre sustancias químicas exigidas por la normativa de la UE o requisitos de etiquetado energético aplicables a ciertos productos. La japonesa puede estructurar de otra forma las variaciones de talla y color y utilizar nombres de temas de variación distintos de los reconocidos por la versión estadounidense.

Los valores válidos de un campo suelen variar según el marketplace, aunque el nombre del campo sea el mismo. item_type_keyword acepta cadenas distintas en .com y .co.uk. Los valores de color_name se validan contra una lista específica de cada marketplace; un color que supera la validación en Estados Unidos puede rechazarse en Alemania o Japón porque no coincide con los valores aprobados para ese mercado. Esos rechazos no siempre quedan claros en el informe de errores: se recibe un error genérico de atributo, no una indicación directa de que el valor no está en la lista aprobada.

Las versiones de las plantillas se actualizan sin aviso. Amazon publica periódicamente nuevas versiones para una categoría, añadiendo campos obligatorios o declarando obsoletos otros. Si carga datos con una versión que ya no es vigente, la carga puede completarse, pero la publicación puede no indexarse correctamente o algunos atributos pueden ignorarse sin aviso. Descargamos plantillas nuevas al principio de cualquier actualización importante del catálogo, en lugar de reutilizar versiones guardadas.

Conversiones entre sistemas de tallas

En ropa y calzado, convertir los sistemas de tallas es una de las tareas que más trabajo requiere al gestionar catálogos en varios marketplaces. Los sistemas estadounidense, europeo, británico y japonés no son directamente equivalentes y las tablas de conversión varían según el tipo de producto.

Un zapato de mujer de talla estadounidense 8 suele corresponder a una talla británica 6 y europea 39 en las tablas de conversión habituales (las tablas de las marcas pueden diferir en media talla), pero una camisa de mujer de talla mediana estadounidense puede corresponder a una 38 o 40 europea según las convenciones de la marca. No hay una tabla universal. El enfoque correcto es mantener una correspondencia maestra de tallas por tipo de producto y marca, validada contra la guía de tallas del fabricante específico.

Los campos size_name y size_system de Amazon deben completarse correctamente de forma conjunta para que la publicación aparezca en los filtros de navegación propios del marketplace. Una publicación cargada con una talla estadounidense en size_name, pero sin declarar size_system, puede tratarse como una cadena sin formato y, según nuestra experiencia, puede no aparecer en las búsquedas filtradas por talla. Esto no siempre resulta evidente en la confirmación de carga: la publicación se crea correctamente, pero el filtro de tallas no funciona.

En el marketplace japonés, el sistema de tallas difiere tanto del europeo como del estadounidense en muchas categorías. Las tallas de ropa japonesas utilizan un sistema numérico propio. Las de calzado se expresan en centímetros. El campo size_map_unit_of_measure era obligatorio en las plantillas japonesas con las que trabajamos y no aparecía en sus equivalentes estadounidenses o europeos; su ausencia provocaba fallos de procesamiento sin aviso cuando se reutilizaban plantillas entre mercados. Los nombres de los campos varían según el tipo de producto y la versión de la plantilla, así que compruebe los encabezados de columna y los valores válidos de la plantilla que realmente descargue.

Límites de palabras clave del backend

Las palabras clave del backend, es decir, los términos de búsqueda enviados en el campo generic_keyword, tienen límites de caracteres distintos entre marketplaces, y también varía el tipo de límite.

Amazon.com impone un límite de 249 bytes al campo generic_keyword combinado. Amazon.de también aplica un límite en bytes, pero el alemán contiene más caracteres multibyte que el inglés: una cadena que cabe en inglés dentro del límite estadounidense en bytes puede superar el límite alemán en bytes al traducirse. Amazon.co.jp aplica límites que interactúan con la codificación japonesa: un solo kanji ocupa tres bytes en UTF-8, por lo que la capacidad efectiva de palabras clave en japonés es bastante menor que la que sugiere el límite en bytes medido con caracteres latinos.

En la práctica, el límite de palabras clave es una de las variables de menor impacto en el rendimiento de las publicaciones en varios marketplaces. Hemos observado que la optimización excesiva de las palabras clave del backend, llenando el campo hasta el límite exacto en bytes, ofrece rendimientos decrecientes frente a optimizar el título visible, los puntos destacados y la descripción para las búsquedas en lenguaje natural. Los límites en bytes son una restricción que respetar, no una variable de rendimiento que maximizar.

El enfoque práctico es mantener un conjunto de palabras clave específico de cada marketplace para cada producto, ajustado a los límites de ese mercado, y verificar el número de bytes mediante código en lugar de hacerlo visualmente. Una función sencilla de Python que codifique la cadena y mida su longitud en bytes frente al límite del marketplace detecta errores de truncamiento antes de la carga.

El flujo de automatización

La idea central de la automatización de archivos planos es que las diferencias entre marketplaces son principalmente estructurales, no semánticas. El producto es el mismo: sus dimensiones, materiales, uso previsto y características principales no cambian. Lo que cambia es cómo debe representarse esa información en el formato de plantilla de cada marketplace.

Mantenemos una hoja maestra de datos de productos con todos los atributos en un formato neutro: dimensiones en el sistema métrico, tallas en el sistema original del fabricante, palabras clave en el idioma de origen y categorías asociadas a una taxonomía interna neutra. Los archivos planos de cada marketplace se generan a partir de esa hoja mediante una capa de transformación que gestiona las diferencias estructurales de cada mercado objetivo.

La capa de transformación es un script, escrito en Python en nuestro caso, que asocia cada atributo maestro con la columna correspondiente de cada marketplace, convierte tallas, transforma la taxonomía de categorías a la estructura de nodos de navegación del marketplace y valida cada campo antes de generar el archivo de salida. Los campos que requieren revisión manual —textos traducidos, declaraciones de cumplimiento propias del marketplace y atributos normativos de cada país— se marcan en la salida en lugar de completarse automáticamente.

El ciclo de descarga, edición y carga está semiautomatizado. Las descargas se realizan mediante scripts que utilizan la Reports API de SP-API, que ofrece GET_FLAT_FILE_OPEN_LISTINGS_DATA y otros tipos de informes relacionados. El procesamiento de la descarga, la comparación con la hoja maestra y la generación del archivo de carga están automatizados. La carga en sí y la revisión del informe de procesamiento son manuales, no porque sea imposible automatizarlas, sino porque el costo de un error en una carga masiva justifica una revisión humana antes de enviar los archivos a Amazon.

Tipos de fallos habituales

Los errores de carga se dividen en tres categorías: fallos de validación, de procesamiento y silenciosos.

Los fallos de validación son los más sencillos: el informe de carga devuelve mensajes explícitos que identifican la fila y el campo que fallaron. Las causas más habituales son valores no válidos en campos con vocabulario controlado (size_name, color_name, item_type_keyword), campos obligatorios ausentes para la versión específica de la plantilla y límites de bytes superados en palabras clave o descripciones.

Los fallos de procesamiento ocurren cuando la carga supera la validación, pero la publicación no se actualiza como se esperaba. Entre las causas habituales están los errores de relaciones de variación —un ASIN hijo enviado sin su padre correspondiente o un padre cuyo tema de variación no coincide con los atributos del hijo— y los conflictos de nodos de navegación, donde el nodo enviado no coincide con la clasificación existente de un ASIN ya establecido.

Los fallos silenciosos son los más difíciles de detectar. La carga se completa, el informe de procesamiento no muestra errores, pero la publicación se comporta incorrectamente. Una talla que no aparece en los filtros de navegación. Un término de búsqueda que no se indexa. Una relación de variación que aparece en el backend, pero no se muestra correctamente en la tienda. Estos fallos requieren comparar los atributos de las publicaciones activas con los valores enviados mediante la Catalog Items API, no mediante una inspección visual de la tienda.

La defensa práctica contra los fallos silenciosos es una verificación posterior a la carga: obtener mediante la API los datos de las publicaciones activas de cada ASIN afectado dentro de las veinticuatro horas siguientes, compararlos con los valores enviados y señalar las diferencias. No es un paso complejo, pero distingue un proceso de gestión de catálogo fiable de otro que exige auditorías manuales constantes para detectar cambios inexplicables que ningún informe de errores anunció.