Dados de try-on virtual para merchandising: o que as sessões de tons revelam sobre a demanda

A maioria das equipes de beleza trata o try-on como um recurso de conversão e para por aí. Mas cada sessão produz algo que o merchandising raramente tem: um registro do que as clientes quiseram ver em si mesmas antes de decidir qualquer coisa. Dados de try-on virtual para merchandising são esse registro — os tons experimentados, comparados, abandonados e levados ao carrinho — e respondem a perguntas que os relatórios de vendas respondem tarde demais, ou nunca.

Este artigo cobre o que esses dados de fato são em uma integração por API baseada em foto versus um SDK no navegador, quais sinais valem a pena registrar e como lê-los sem transformar curiosidade em previsão.

Como os dados se parecem em cada integração

O formato do seu dataset depende de como o try-on é entregue, então decida isso antes de desenhar dashboards.

A API baseada em foto

Com o MaIA Try-On como API, a cliente envia uma foto, o batom ou a base é renderizado sobre ela e a imagem volta. As paletas são calibradas para os produtos reais da marca dentro de um projeto, o que significa que cada requisição já carrega uma identidade no nível do SKU — não um código hex abstrato que alguém inventou. O seu servidor vê cada chamada: qual produto, qual tom, qual sessão, em que ordem. Esse é o log de merchandising mais limpo possível, porque é server-side por construção.

O SDK no navegador

O SDK, em acesso antecipado desde setembro de 2026, cobre treze produtos — batom, base, blush, pó facial, corretivo para olheiras, sombra, máscara de cílios, maquiagem de sobrancelha, delineador, bronzer, contorno, iluminador, lápis de boca — mais um Full Look combinado, em modo câmera ao vivo ou modo foto, com qualquer cor #RRGGBB, hospedado pela própria marca. No modo câmera ao vivo, a renderização acontece localmente no navegador e nada é enviado, então não existe registro dos frames no servidor. O que você tem é a sua própria telemetria de front-end: a marca hospeda o SDK, então a marca decide quais eventos emitir para o seu stack de analytics. Se quiser dados de merchandising do SDK, precisa instrumentá-lo deliberadamente. Se a diferença entre os dois modelos de entrega ainda está nebulosa para a sua equipe, a comparação em try-on por foto vs try-on com AR é um bom ponto de partida.

Sinais que valem a pena capturar

Resista a registrar tudo. Cinco tipos de evento carregam quase todo o valor de merchandising:

• Tom visualizado. Produto, SKU, categoria, timestamp, ID da sessão.
• Sequência de tons. A ordem dentro de uma sessão. O segundo e o terceiro tons experimentados dizem o que o primeiro não entregou.
• Tempo de permanência. Quanto tempo um tom ficou na tela antes do próximo. Permanência longa em um tom que nunca converte é um problema diferente de um tom que ninguém abre.
• Último tom antes da saída ou da adição ao carrinho. O campo mais útil de todo o conjunto.
• Pedidos fora da paleta. No SDK, qualquer cor #RRGGBB pode ser renderizada. Se as clientes insistem em puxar para um tom que a sua paleta não tem, isso é uma lacuna de sortimento declarada em valores de cor.

Mantenha os IDs de sessão pseudonimizados e separados da imagem em si. Você está construindo um dataset de merchandising, não um arquivo de rostos.

Transformar dados de try-on virtual para merchandising em decisões

Sortimento e análise de lacunas

Classifique os tons por prévias e depois por prévias por conversão. Um tom com volume alto de prévias e conversão fraca geralmente está mal descrito na página ou ao lado de um vizinho quase idêntico que vence a comparação. Um aglomerado de pedidos de cor fora da paleta em torno de uma família de tons que você não tem em linha é o argumento mais claro para uma extensão de linha que você vai conseguir de dados próprios.

Ordenar a página de produto

A maioria dos seletores de tom é ordenada por código de SKU ou data de lançamento, ou seja, arbitrariamente. Reordenar por volume de prévias para o segmento que está navegando naquele momento coloca os prováveis vencedores na primeira linha e encurta a comparação. A mesma lógica vale para páginas de categoria e para os módulos de "compre o look" alimentados por uma prévia de Full Look.

Estoque e alocação

O volume de prévias se move antes do sell-through, porque experimentar na prévia não custa nada para a cliente e comprar custa. Trate-o como um indicador antecedente a inspecionar, não como uma previsão em que confiar: as clientes experimentam tons ousados que jamais comprariam, e vermelhos com muitas prévias podem virar reposição de nudes. Use-o para sinalizar SKUs para revisão humana antes de uma compra, não para dimensionar a compra automaticamente.

Lançamentos e leituras regionais

Para uma linha nova, os dados de prévia existem desde o primeiro dia, enquanto os dados de venda levam semanas. Compare as distribuições de prévias entre regiões, canais e fontes de tráfego antes de comprometer verba de campanha com um tom herói escolhido em reunião.

Cruzar o try-on com o perfil de beleza

O try-on diz o que foi experimentado. Não diz quem experimentou. Parear a sessão com um perfil de beleza do MaIA Scan — tom e subtom de pele, tipo e condição da pele, atributos de cabelo, cada um com um score de confiança — transforma uma contagem chapada de prévias em uma contagem segmentada: quais grupos de subtom gravitam para qual família de tons, onde as prévias cruzam para a faixa errada de profundidade, quais perfis nunca encontram um match e vão embora.

Duas cautelas. Só cruze perfis quando a cliente tiver dado consentimento, e armazene o perfil como atributos estruturados em vez de guardar a foto. E trate os atributos como características visíveis de uma imagem — eles descrevem o que a foto mostra, não são uma avaliação clínica nem substituem um profissional de saúde, e os scores de confiança existem justamente para que campos de baixa certeza possam ser excluídos da análise.

Um primeiro mês realista

Semana um: instrumente os cinco eventos e envie-os para a ferramenta de analytics que você já usa. Semana dois: monte uma tabela — tom, prévias, prévias por carrinho, último tom antes da saída. Semana três: escolha os três piores casos e mude algo concreto, como a ordem na página ou o nome dos tons. Semana quatro: releia a mesma tabela. Resista aos dashboards até ter agido sobre uma tabela simples pelo menos uma vez; os resultados variam com o catálogo, o tráfego e o canal de cada marca, e o único jeito de conhecer os seus é medir os seus.

Pronto para começar a coletar o sinal? Crie uma conta e gere sua chave de API, ou fale com a equipe da B4A sobre o acesso antecipado ao SDK.