Datos de try-on virtual para merchandising: lo que las sesiones de tonos revelan sobre la demanda

La mayoría de los equipos de belleza tratan el try-on como una funcionalidad de conversión y se quedan ahí. Pero cada sesión produce algo que merchandising rara vez tiene: un registro de lo que las clientas quisieron ver en sí mismas antes de decidir nada. Los datos de try-on virtual para merchandising son ese registro — los tonos previsualizados, comparados, abandonados y llevados al carrito — y responden preguntas que los reportes de ventas responden demasiado tarde, o nunca.

Este artículo cubre qué son realmente esos datos en una integración por API basada en foto frente a un SDK para navegador, qué señales vale la pena registrar y cómo leerlas sin convertir la curiosidad en un pronóstico.

Cómo se ven los datos en cada integración

La forma de tu conjunto de datos depende de cómo se entrega el try-on, así que decide esto antes de diseñar dashboards.

La API basada en foto

Con MaIA Try-On como API, la clienta envía una foto, el labial o la base se renderiza sobre ella y la imagen vuelve. Las paletas se calibran con los productos reales de la marca dentro de un proyecto, lo que significa que cada solicitud ya lleva una identidad a nivel de SKU — no un código hex abstracto que alguien inventó. Tu servidor ve cada llamada: qué producto, qué tono, qué sesión, en qué orden. Es el registro de merchandising más limpio posible, porque es del lado del servidor por construcción.

El SDK para navegador

El SDK, en acceso anticipado desde septiembre de 2026, cubre trece productos — labial, base, rubor, polvo facial, corrector de ojeras, sombra, máscara de pestañas, maquillaje de cejas, delineador, bronceador, contorno, iluminador, delineador de labios — más un Full Look combinado, en modo de cámara en vivo o modo foto, con cualquier color #RRGGBB, alojado por la propia marca. En modo de cámara en vivo el renderizado ocurre localmente en el navegador y no se sube nada, así que no hay registro en el servidor de los fotogramas. Lo que sí tienes es tu propia telemetría de front-end: la marca aloja el SDK, así que la marca decide qué eventos emitir a su stack de analítica. Si quieres datos de merchandising del SDK, tienes que instrumentarlo deliberadamente. Si la diferencia entre los dos modelos de entrega todavía es difusa para tu equipo, la comparación en try-on por foto vs try-on con AR es un buen punto de partida.

Señales que vale la pena capturar

Resiste la tentación de registrar todo. Cinco tipos de evento concentran casi todo el valor para merchandising:

• Tono previsualizado. Producto, SKU, categoría, marca de tiempo, ID de sesión.
• Secuencia de tonos. El orden dentro de una sesión. El segundo y el tercer tono probados te dicen qué no entregó el primero.
• Tiempo de permanencia. Cuánto tiempo se quedó un tono en pantalla antes del siguiente. Mucha permanencia en un tono que nunca convierte es un problema distinto al de un tono que nadie abre.
• Último tono antes de salir o de agregar al carrito. El campo más útil de todo el conjunto.
• Solicitudes fuera de paleta. En el SDK, cualquier color #RRGGBB es renderizable. Si las clientas insisten en empujar hacia un tono que tu paleta no tiene, eso es una brecha de surtido expresada en valores de color.

Mantén los IDs de sesión seudónimos y separados de la imagen en sí. Estás construyendo un conjunto de datos de merchandising, no un archivo de rostros.

Convertir los datos de try-on virtual para merchandising en decisiones

Surtido y análisis de brechas

Ordena los tonos por vistas previas y luego por vistas previas por conversión. Un tono con mucho volumen de vistas previas y conversión débil suele estar mal descrito en la página o junto a un vecino casi idéntico que gana la comparación. Un grupo de solicitudes de color fuera de paleta alrededor de una familia de tonos que no tienes en stock es el argumento más claro para una extensión de línea que vas a obtener de datos propios.

Ordenar la página de producto

La mayoría de los selectores de tono están ordenados por código de SKU o fecha de lanzamiento, es decir, de forma arbitraria. Reordenar por volumen de vistas previas para el segmento que está navegando en ese momento pone a los probables ganadores en la primera fila y acorta la comparación. La misma lógica aplica a las páginas de categoría y a los módulos de "compra el look" alimentados por una vista previa de Full Look.

Stock y asignación

El volumen de vistas previas se mueve antes que la venta, porque previsualizar no exige ningún compromiso y comprar sí. Trátalo como un indicador adelantado para inspeccionar, no como un pronóstico en el que confiar: las clientas prueban tonos atrevidos que jamás comprarían, y los rojos muy previsualizados pueden convertirse en reposiciones de nudes. Úsalo para marcar SKUs para revisión humana antes de una compra, no para dimensionar la compra automáticamente.

Lanzamientos y lecturas regionales

Para una línea nueva, los datos de vistas previas existen desde el primer día, mientras que los datos de ventas necesitan semanas. Compara las distribuciones de vistas previas entre regiones, canales y fuentes de tráfico antes de comprometer presupuesto de campaña a un tono estrella elegido en una reunión.

Unir el try-on con el perfil de belleza

El try-on te dice qué se probó. No te dice quién lo probó. Emparejar la sesión con un perfil de belleza de MaIA Scan — tono y subtono de piel, tipo y condición de la piel, atributos del cabello, cada uno con un puntaje de confianza — convierte un conteo plano de vistas previas en uno segmentado: qué grupos de subtono gravitan hacia qué familia de tonos, dónde las vistas previas cruzan hacia el rango de profundidad equivocado, qué perfiles nunca encuentran una coincidencia y se van.

Dos precauciones. Une perfiles solo cuando la clienta haya dado su consentimiento, y guarda el perfil como atributos estructurados en lugar de conservar la foto. Y trata los atributos como características visibles de una imagen: describen lo que muestra la foto, no son una evaluación clínica, y los puntajes de confianza existen precisamente para que los campos de baja certeza puedan excluirse del análisis.

Un primer mes realista

Semana uno: instrumenta los cinco eventos y envíalos a la herramienta de analítica que ya usas. Semana dos: construye una sola tabla — tono, vistas previas, vistas previas por carrito, último tono antes de salir. Semana tres: elige los tres peores casos y cambia algo concreto, como el orden en la página o el nombre del tono. Semana cuatro: vuelve a leer la misma tabla. Resiste los dashboards hasta que hayas actuado sobre una tabla simple al menos una vez; los resultados varían con el catálogo, el tráfico y el canal de cada marca, y la única forma de conocer los tuyos es medir los propios.

¿Quieres empezar a recolectar la señal? Crea una cuenta y obtén tu API key, o habla con el equipo de B4A sobre el acceso anticipado al SDK.