Marketplace en VTEX: la calidad del catálogo se decide cuando entra el dato

Cuando un marketplace suma sellers, el catálogo crece con cada fuente que se integra. Cada seller llega con sus propios nombres para las categorías, sus propias marcas y su propia manera de escribir los atributos.

En una auditoría de arquitectura a un marketplace con varios años de operación sobre VTEX, encontramos un ejemplo pequeño que explica buena parte del problema. El atributo de memoria RAM de los productos de tecnología tenía valores como "8 gigas", "dieciséis" y "otros", junto a números simples como "32". Basta imaginar a dos sellers que escriben "64 GB" y "64GB": para una persona describen lo mismo y para el sistema son dos valores distintos.

La consecuencia aparece en el storefront. El filtro muestra una lista larga de opciones que se superponen, y esa lista afecta tanto la experiencia de navegación como la búsqueda.

La limpieza corrige lo visible, no lo que sigue entrando

Normalizar esos valores es posible, pero es un trabajo de gran escala. Primero hay que decidir qué atributos corresponden a cada categoría y qué valores se permiten en cada uno. Después hay que completar la información que los sellers no enviaron.

Sin embargo, si el portal con el que los sellers cargan sus productos sigue aceptando texto libre, la limpieza se deshace con cada carga nueva. En ese marketplace había dos formas de cargar, la manual y la masiva, y ninguna consultaba los valores que ya existían en VTEX antes de aceptar el dato.

Por eso el trabajo se divide en dos frentes que corren en paralelo: homologar lo que ya está en el catálogo y cerrar la puerta a que los valores nuevos entren sin control. El segundo frente es el que evita repetir el primero.

Cerrar esa puerta tiene una mecánica concreta. Para un atributo con valores definidos, la integración lee los que existen en el marketplace y solo acepta uno de ellos. Si un seller necesita un valor que no existe, lo solicita y el marketplace decide si lo crea. Es una práctica básica de integración de datos: quien recibe la información define qué formato acepta.

El mapeo determina cuánto catálogo entra sin intervención

Cuando un seller se integra con un marketplace en VTEX, su catálogo se relaciona con el del marketplace mediante tres mapeos: categorías, marcas y especificaciones (los atributos que describen un producto, como memoria, color o material). En ese punto se acumulan las diferencias entre cada fuente y la estructura común.

La calidad del mapeo tiene un efecto directo en la operación. Los productos cuya información coincide con la estructura del marketplace pueden aprobarse de forma automática. Los que llegan con una categoría sin correspondencia o con un atributo incompleto quedan en aprobación manual.

Con cientos o miles de productos nuevos por día, revisar todo a mano no es viable. Así, un mejor mapeo implica menos productos atrapados y un equipo de operaciones que dedica su tiempo a las excepciones. El mapeo de marcas mostraba el mismo patrón en pequeño: una misma marca llegaba con variaciones de escritura y cada variación terminaba registrada como una marca distinta.

Cuánto aprobar de forma automática es una decisión de equilibrio. Más automatización acelera el ingreso y reduce el control de calidad. Más revisión manual protege el catálogo y exige más personas. Para decidirlo con datos propusimos un tablero de salud de sellers que reúne cuántos sellers están activos, cuántos productos esperan aprobación, en qué categorías y con qué márgenes.

Una decisión en la raíz del árbol se hereda a todo lo que cuelga de él

En el catálogo auditado había atributos creados en niveles altos del árbol de categorías. Como las categorías hijas heredan los atributos de las superiores, el atributo color aparecía en productos donde no aporta nada. Cada ingreso nuevo bajo esa categoría arrastraba el mismo campo.

El criterio que aplicamos es crear cada atributo en la categoría de nivel más bajo donde realmente se usa, y asociar cada producto a la categoría más específica que le corresponde.

La profundidad del árbol sigue la misma lógica. Recomendamos mantenerlo en tres o cuatro niveles. Lo que aparece a partir del cuarto suele ser una característica del producto, y se resuelve mejor como atributo que como categoría.

Un valor mal escrito o un atributo en el nivel equivocado no se queda donde nació. Se propaga a cada producto que entra después, y corregirlo obliga a revisar todo lo que se construyó encima.

Reglas que conviene fijar antes de incorporar al siguiente seller

Si el objetivo es que el catálogo siga creciendo sin que el equipo tenga que volver a limpiarlo, estas son las decisiones que el marketplace debe dejar escritas:

• Qué categorías puede usar un seller y cómo se relacionan con las que él maneja.

• Qué atributos tiene cada categoría y qué valores se permiten en cada uno.

• Quién decide si se crea un valor, una marca o una categoría nueva, y con qué criterio.

• Qué nivel de coincidencia permite aprobar un producto de forma automática y qué se revisa a mano.

• Qué ocurre cuando la información recibida no tiene una correspondencia directa.

Cada seller que se integra sin esas reglas agrega valores que habrá que homologar más tarde, y el costo de hacerlo crece con el tamaño del catálogo.

Antes de sumar al próximo seller, conviene revisar si el portal de carga acepta hoy cualquier valor. Si tu marketplace opera sobre VTEX y quieres ordenar cómo entra la información, puedes conocer cómo trabajamos en VTEX.