Piloto de try-on virtual em 90 dias: escopo, métricas e critérios de decisão

A maioria dos projetos de prova virtual não fracassa por tecnologia: fracassa porque nunca se definiu o que estava sendo testado. Um piloto de try-on virtual bem montado não busca "lançar a funcionalidade": busca responder, em um prazo fechado, se a prova de cor move uma métrica concreta do negócio e se a operação de cor é sustentável. Este artigo propõe uma estrutura de 90 dias pensada para times de e-commerce, CRM e produto que precisam levar uma decisão fundamentada ao comitê.

Qual hipótese um piloto de try-on virtual deve testar

Antes de escolher a ferramenta, escreva a hipótese em uma frase. Alguns exemplos que vemos em marcas de beleza:

• "As visitas à página de batons que experimentam uma cor adicionam ao carrinho com mais frequência do que as que não experimentam."
• "A prova de cor reduz as perguntas sobre tom que chegam ao atendimento."
• "O tráfego de campanha que chega a uma experiência de prova deixa mais contatos identificados do que o que chega a uma landing estática."

Uma hipótese por piloto. Se você tentar validar conversão, retenção e geração de leads ao mesmo tempo, vai terminar com três resultados ambíguos em vez de um claro. Defina também qual resultado faria você abandonar a ideia: esse limiar, escrito antes de começar, é o que evita discussões políticas na semana 12.

Escolher a forma de entrega conforme o escopo

O MaIA Try-On existe em duas formas, e cada uma serve a pilotos diferentes.

API por foto

A cliente envia uma foto, o produto — batom ou base — é renderizado sobre ela e a imagem volta pronta para ser exibida. É o caminho mais rápido quando o piloto roda em um canal onde você não controla o front-end: WhatsApp, um fluxo de CRM, um microsite de campanha, um tablet na loja. Não exige que o time de front-end abra o tema do e-commerce. As paletas são calibradas com base nos produtos reais da marca dentro de um projeto, então a cor que a cliente vê corresponde ao SKU que ela vai comprar. Você pode conferir o funcionamento na página de prova virtual de maquiagem.

SDK no navegador (acesso antecipado)

O SDK roda no domínio da marca e cobre treze produtos — batom, base, blush, pó, corretivo para olheiras, sombra, máscara de cílios, sobrancelhas, delineador, bronzer, contorno, iluminador e lápis de boca — além de um Full Look combinado. Funciona no modo ao vivo pela câmera, com a renderização feita localmente no navegador e sem envio da imagem, ou no modo foto, com qualquer cor #RRGGBB. É a opção para um piloto de página de produto ou de look completo, e está em acesso antecipado desde setembro de 2026, concedido por conta. Importante para o planejamento: os outros onze produtos e o Full Look são exclusivos do SDK; a API por foto cobre batom e base.

Se você ainda está comparando abordagens de prova, o artigo sobre prova virtual por foto em comparação com outras formas de prova ajuda a situar cada uma antes de comprometer sprints.

Escopo mínimo: catálogo, canal e público

Um piloto não precisa de todo o catálogo. Precisa de cor suficiente para que a prova seja útil e de foco suficiente para que o resultado seja legível.

• Catálogo: uma família de produto com muitos tons, idealmente batom ou base. Entre 12 e 30 tons costuma ser suficiente para que a cliente encontre algo próximo do que procura.
• Canal: um só. Página de produto, campanha paga, WhatsApp ou loja física. Misturar canais no mesmo piloto mistura também as causas de qualquer variação.
• Público: se o canal permitir, divida o tráfego. Um grupo com prova de cor, outro sem. Sem comparação, qualquer número do piloto será anedótico.

Documente também quem aprova a cor. A calibração da paleta é uma tarefa de marketing de produto, não de engenharia: alguém do time de marca precisa validar que cada tom renderizado representa o SKU.

Métricas e critérios de decisão

Meça em três camadas, e combine com o time como cada uma é calculada antes da semana 1:

1. Adoção. Qual porcentagem das visitas ao canal abre a prova e quantos tons cada sessão experimenta. Se a adoção é baixa, o problema quase sempre é de posicionamento e de chamada para ação, não do render.
2. Comportamento. Adição ao carrinho, avanço para o checkout e conversão do grupo que experimentou em comparação com o que não experimentou. Observe também o tom mais experimentado versus o tom mais comprado: essa diferença é insumo direto para compras e sortimento.
3. Operação. Consumo de créditos, erros por foto de má qualidade, tempo do time de marca para aprovar paletas, tickets de suporte sobre cor.

Evite importar promessas de conversão de terceiros para o seu caso de negócio. Os resultados variam com o catálogo, o tráfego e o canal de cada marca; o objetivo do piloto é produzir o seu próprio número, não confirmar o de outra pessoa.

Um cronograma de 90 dias

• Semanas 1–2: hipótese, métrica única, limiar de decisão, seleção de canal e família de produto. Conta criada e chave de API gerada.
• Semanas 3–5: integração técnica e calibração da paleta com o time de marca. Testes internos com fotos reais de clientes do segmento-alvo.
• Semanas 6–10: piloto no ar com divisão de tráfego. Nada de mudanças de escopo no meio do caminho.
• Semanas 11–12: leitura dos resultados, custo por sessão de prova e decisão: escalar para mais SKUs e canais, ajustar o posicionamento ou parar.

Erros comuns que custam o trimestre

Esconder a prova abaixo da dobra. Lançar com tons não aprovados. Não instrumentar os eventos antes de abrir o tráfego. E o mais frequente: encerrar o piloto sem um critério escrito, o que transforma uma decisão de negócio em uma discussão de opiniões.

Pronto para montar o seu? Crie uma conta, compre créditos e gere sua chave na documentação da API, ou fale com o time da B4A para definir o escopo do piloto junto com o seu catálogo.