Try-on virtual na página de produto: como integrar sem SDK e sem app

A página de produto (PDP) é onde a dúvida de cor aparece com mais força: a pessoa gosta do batom, mas não sabe se aquele tom funciona nela. Colocar um try-on virtual na página de produto é uma forma direta de responder essa pergunta no exato momento da decisão, sem tirar o visitante do site e sem pedir que ele instale nada.

Este artigo mostra como essa integração funciona quando o try-on é entregue por API e baseado em foto, o que o time precisa preparar de cada lado e como medir se valeu a pena.

Por que a PDP é o lugar certo para o try-on

No funil de um e-commerce de beleza, a PDP concentra três problemas ao mesmo tempo: escolha de cor, insegurança sobre o resultado e comparação entre variantes. Um seletor de swatches resolve parcialmente — mostra o pigmento, mas não mostra o pigmento naquela pessoa.

Quando a cliente consegue ver o produto aplicado na própria foto antes de adicionar ao carrinho, três coisas mudam na prática:

• A escolha entre variantes deixa de ser um chute entre nomes de tons.
• O tempo na página vira tempo de decisão, não de hesitação.
• A expectativa sobre o produto chega mais próxima do que será recebido em casa.

Não prometemos números aqui — cada catálogo e cada base de clientes se comportam de um jeito. Mas a hipótese é testável, e a PDP é o lugar mais barato de testar.

Como funciona um try-on virtual na página de produto por foto

O MaIA Try-On é uma API baseada em foto. O fluxo, do ponto de vista do seu front-end, é simples:

1. A visitante envia ou tira uma foto no próprio navegador.
2. Seu back-end chama a API enviando a imagem e o identificador do produto ou da cor.
3. A API devolve a imagem com o produto renderizado no rosto.
4. Você exibe o resultado ao lado do seletor de variantes, com a opção de trocar de tom e repetir.

Não há SDK para embutir, nem câmera ao vivo, nem app. Isso tem uma consequência prática importante: a mesma integração que roda na PDP roda em um e-mail com link, em um anúncio, em uma landing de campanha ou no WhatsApp, porque o que circula é uma imagem, não um componente proprietário preso a um dispositivo.

Foto ou AR?

É uma escolha de arquitetura, não uma limitação disfarçada. Try-on por câmera ao vivo exige SDK, permissões, dispositivo compatível e manutenção contínua; try-on por foto exige uma chamada de API. Discutimos as diferenças com mais calma em try-on virtual por foto vs AR try-on. Para PDP em mobile web — onde está a maior parte do tráfego de beleza no Brasil — a barreira de entrada mais baixa costuma valer mais do que o efeito espelho.

O que preparar antes de integrar

1. Calibrar as cores do seu catálogo

Batom é só um exemplo de categoria. O que faz o try-on parecer crível é a calibração das paletas com os produtos reais da marca, feita dentro de um projeto. Sem isso, o render vira uma aproximação genérica e a cliente percebe. Separe referências confiáveis de cada tom: códigos, fotos de swatch consistentes e, se existir, medições de cor.

2. Mapear SKU, variante e paleta

Na PDP, cada variante precisa ter um identificador estável que o seu back-end saiba traduzir para a paleta correspondente na API. Esse mapeamento é onde a maioria dos projetos trava — não pela dificuldade técnica, mas porque o catálogo costuma ter nomes de cor inconsistentes entre ERP, PIM e site.

3. Definir a experiência de upload

Oriente a foto: rosto de frente, luz uniforme, sem óculos escuros, sem filtro pesado. Uma linha de instrução e um exemplo visual resolvem boa parte dos resultados ruins. Defina também o que acontece quando a foto não serve — uma mensagem clara pedindo outra imagem é melhor do que um render estranho.

4. Tratar a imagem como dado sensível

Decida antes: a foto é armazenada ou descartada após o render? Quem tem acesso? O que aparece na política de privacidade e no aviso na tela? Alinhe com o jurídico no início, não na véspera do go-live.

Onde o try-on conversa com o resto da jornada

O try-on responde "como fica em mim". Ele não responde "o que combina comigo" nem "qual base é a minha". Para isso existem outras peças que se encaixam na mesma PDP:

• A análise de pele e cabelo por selfie devolve um perfil de beleza em JSON, com tom e subtom de pele, tipo e condição de pele, atributos de cabelo e um nível de confiança por campo — útil para pré-selecionar tons antes mesmo do try-on.
• O MaIA Beauty Advisor usa esse perfil para recomendar produtos do próprio catálogo, no WhatsApp, na página de produto ou no chat.

A combinação natural é: perfil → recomendação de tons → try-on da opção recomendada. Mas não é obrigatório começar assim. Muitas marcas colocam primeiro o try-on em uma categoria única, aprendem com o comportamento real e só depois ampliam.

Como medir

Evite medir só "quantas pessoas usaram". Vale instrumentar:

• Taxa de uso do try-on entre visitantes da PDP.
• Conversão de quem usou versus quem não usou, na mesma página e no mesmo período.
• Número de tons testados por sessão (indicador de exploração de catálogo).
• Troca e devolução por motivo de cor, comparando SKUs com e sem try-on.

O último é o mais lento de apurar e o mais convincente na reunião de budget.

Começando pequeno

Um bom piloto é: uma categoria, um conjunto de tons calibrados, uma PDP, quatro a seis semanas de leitura. Do lado técnico, é conta criada, créditos comprados, chave de API gerada e uma chamada no back-end.

Crie sua conta e gere sua chave na documentação da API ou fale com o time da B4A para calibrar as paletas do seu catálogo.