Calibración de color en la prueba virtual de maquillaje: cómo llevar tus SKUs al render

La parte difícil de una prueba virtual de maquillaje no es el render: es el color. La calibración de color en la prueba virtual de maquillaje es el trabajo de traducir cada SKU real —un labial, una base, un rubor— a un valor que el motor pueda pintar sobre el rostro de la clienta con fidelidad suficiente para que la decisión de compra tenga sentido. Si ese paso se hace rápido y sin criterio, la experiencia funciona técnicamente y falla comercialmente: la clienta prueba, compra, recibe el producto y descubre otro tono.

Por qué el color decide el resultado de la experiencia

Una prueba virtual cumple una función concreta: reemplazar la incertidumbre de comprar maquillaje sin tocarlo. Esa función depende por completo de que el tono mostrado en pantalla se parezca al tono del producto en el rostro. Cuando no se parece, la marca no gana una herramienta de conversión; gana un canal nuevo de expectativas incumplidas y de contactos al soporte.

Hay tres fuentes de ruido que conviene separar desde el inicio:

• El producto real: el mismo labial cambia según la cantidad aplicada, la base del labio y el acabado.
• La referencia que usa la marca: packshots retocados, fotos de campaña con luz de estudio y swatches de catálogo rara vez coinciden entre sí.
• La pantalla de la clienta: brillo, modo oscuro y perfil de color del dispositivo varían y no se controlan.

No se pueden eliminar los tres. Se puede, en cambio, fijar el primero y el segundo con un proceso disciplinado, y aceptar el tercero como margen conocido.

Calibración de color en la prueba virtual de maquillaje: qué se decide en cada camino

MaIA Try-On existe en dos formas, y la calibración se organiza distinto en cada una.

La API por foto

En la prueba virtual de maquillaje por foto, la clienta envía una imagen, el producto —labial o base— se renderiza sobre ella y la imagen vuelve lista para mostrar. Las paletas se calibran contra los productos reales de la marca dentro de un proyecto. Es decir: no se trata de elegir un hex al azar, sino de construir, junto con el equipo, la correspondencia entre cada SKU del catálogo y su representación en el render.

Ese modelo encaja bien cuando el canal no es un navegador controlado por la marca: WhatsApp, una campaña, un flujo de CRM, una app propia. La contrapartida es que labial y base son los productos cubiertos por la API; el resto del catálogo no se renderiza por esa vía.

El SDK en el navegador

El SDK de navegador, 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 y delineador de labios— más un Full Look combinado, en modo ao vivo pela cámara (todo se procesa localmente en el navegador, sin subir la foto) o en modo foto. Acepta cualquier color en formato #RRGGBB y lo aloja la propia marca en su dominio.

Esa libertad es la ventaja y también la responsabilidad: si el equipo puede pasar cualquier hex, alguien tiene que decidir cuál. Ahí es donde el proceso de calibración deja de ser un detalle técnico y pasa a ser una tarea de producto. Si todavía estás comparando formatos, el artículo sobre prueba virtual por foto frente al try-on AR ayuda a ubicar cada opción.

Un proceso de calibración en cinco pasos

1. Definir el alcance real del catálogo

No se calibran 400 SKUs en la primera semana. Elige las líneas que concentran la duda de tono: la familia de labiales más vendida, el rango de bases, las sombras del lanzamiento. El resto entra en olas posteriores.

2. Fijar una referencia única por SKU

Antes de discutir hex, decide qué imagen manda. Lo habitual es usar una captura controlada del producto aplicado —misma luz, mismo fondo, misma cámara, mismas pieles de referencia— en lugar de las fotos de campaña. Documenta esa condición de captura: es el estándar al que volverás cada vez que alguien diga "se ve raro".

3. Proponer la primera versión del color

De la referencia sale un valor inicial por SKU. En el SDK, ese valor es un #RRGGBB configurable. En la API, la paleta se arma contra los productos reales dentro del proyecto. En ambos casos, guarda el valor con el código de SKU, no con el nombre comercial: los nombres cambian y se repiten entre colecciones.

4. Revisar con quien conoce el producto

La validación no es del equipo de ingeniería. Siéntate con maquilladores, el equipo de producto o quien entrena a las vendedoras y revisa el render en varios tonos de piel y en varios dispositivos. Las correcciones que salen de esa sesión suelen ser pocas, pero son las que evitan reclamos.

5. Versionar y gobernar

Trata la paleta como un artefacto con dueño y con historial: quién aprobó cada tono, cuándo cambió, qué reformulación lo motivó. Cuando entra una colección nueva, el proceso ya existe y la calibración deja de ser un proyecto para volverse una rutina del lanzamiento.

Errores que se repiten

• Usar el packshot como fuente de verdad. El empaque y el producto aplicado casi nunca comparten tono.
• Validar solo en un tono de piel. Un labial se comporta distinto sobre labios de distinta profundidad; probar en un único rostro esconde la mitad de los problemas.
• Mezclar acabado con color. Un mate y un satinado del mismo pigmento no se leen igual en pantalla; anota el acabado como atributo aparte del hex.
• No comunicar el margen. Un aviso breve de que la pantalla puede variar es honesto y reduce la fricción posterior.

Una vez calibrada la paleta, el color deja de ser un debate y se vuelve un dato más del catálogo, reutilizable en la página de producto, en campañas y en la conversación con la clienta.

¿Quieres probarlo con tus propios SKUs? Crea tu cuenta y tu clave en la documentación de la API, o habla con nuestro equipo para armar la paleta de tu marca.