Teste A/B no front resolve botão e headline. Preço, frete, algoritmo e onboarding pedem experimento no código. Veja como o VWO Feature Management and Experimentation funciona.
Índice do artigo
- VWO Testing x VWO FME: qual a diferença?
- O que é uma feature flag?
- Como o SDK do VWO FME funciona
- trackEvent: só conta o que importa ao experimento
- Rastreamento assíncrono x síncrono
- Gateway Service: quando é obrigatório
- REST API e automação de flags
- Integrações com analytics e CDP
- Os erros que mais aparecem
- Perguntas frequentes sobre VWO FME
A maior parte dos programas de CRO no Brasil para no teste visual: troca de cor, de texto, de ordem de bloco. É um bom começo. Mas as hipóteses de maior impacto quase sempre vivem no backend: regra de frete grátis, preço exibido, ordenação de busca, fluxo de cadastro. Para essas, o caminho é experimentação server-side.
VWO Testing x VWO FME: qual a diferença?
O VWO tem duas frentes. O VWO Testing é o produto de testes visuais e client-side, instalado por snippet no site. O VWO FME (Feature Management and Experimentation) é voltado a desenvolvedores: SDKs para ligar funcionalidades por flag, fazer rollout controlado, rodar testes A/B no código e rastrear eventos.
Em uma frase: VWO Testing muda o que o usuário vê na página; VWO FME muda o que o produto faz.
O que é uma feature flag?
Uma feature flag é um interruptor no código que decide, em tempo de execução, qual versão de uma funcionalidade cada usuário recebe. Com ela você lança para 5% da base, compara com o controle, amplia se der certo e desliga em segundos se der errado, sem novo deploy.
Como o SDK do VWO FME funciona
O fluxo do SDK tem quatro etapas: inicialização, avaliação da flag, rastreamento de eventos e tratamento de atributos do usuário, com comunicação assíncrona com o backend do VWO.
Na prática, você inicializa com o Account ID e a SDK key, cria um contexto do usuário (ID e atributos), verifica se a flag está ativa para ele e registra o evento de conversão.
const vwoClient = await vwo.init({
accountId: 'SEU_ACCOUNT_ID',
sdkKey: 'SUA_SDK_KEY'
});
const context = { id: 'user_123' };
const flag = await vwoClient.getFlag('novo_checkout', context);
if (flag.isEnabled()) {
// renderiza o novo checkout
}
vwoClient.trackEvent('compra_concluida', context);
Há SDKs para Node.js e JavaScript de navegador, PHP, Python, React (com componente VWOProvider), entre outras linguagens, e apps de exemplo para Android TV, Apple Watch e Apple TV.
trackEvent: só conta o que importa ao experimento
Os eventos enviados com trackEvent só são reportados ao VWO se forem relevantes para experimentos em andamento. Isso reduz ruído e custo de coleta, mas tem uma consequência: o VWO FME não é seu analytics. O registro completo de eventos continua no GA4 ou no seu data warehouse.
Rastreamento assíncrono x síncrono
Por padrão, as chamadas de rastreamento são disparadas sem esperar resposta do servidor, para não afetar a latência da aplicação. Quando a integridade do dado é crítica (conciliação financeira, por exemplo), dá para ativar o modo síncrono, que espera a resposta e permite detectar falha e tentar de novo.
Regra prática: assíncrono para interação de usuário, síncrono só para eventos que precisam de confirmação de entrega.
Gateway Service: quando é obrigatório
O Gateway Service é um componente opcional instalado na sua infraestrutura. Ele passa a ser obrigatório quando você usa pré-segmentação por localização ou user agent, precisa de targeting avançado ou usa SDKs thin-client (como o de Go).
REST API e automação de flags
As REST APIs do FME permitem criar, consultar, atualizar e excluir feature flags programaticamente, o que abre espaço para integrar o ciclo de experimentação ao pipeline de CI/CD e à infraestrutura como código. Há ainda uma extensão para VS Code e um servidor MCP que permite gerenciar flags a partir de assistentes de código com IA.
Integrações com analytics e CDP
Os SDKs do FME oferecem um callback que recebe as propriedades do VWO (flag, variação, usuário) e permite repassá-las para qualquer ferramenta: analytics, monitoramento, CDP ou mensageria. É por ele que você envia ao GA4 a informação de qual variação o usuário viu, e analisa o experimento também no seu próprio dado.
Se você usa GTM, o caminho é empurrar essa informação para a camada de dados e deixar o contêiner distribuir.
Os erros que mais aparecem
- Usar o VWO FME como analytics principal, esperando ver eventos que não pertencem a experimentos.
- ID de usuário instável (muda entre sessões), fazendo a mesma pessoa cair em variações diferentes.
- Pré-segmentação por localização sem Gateway Service configurado.
- Flag de experimento esquecida no código depois da decisão, virando dívida técnica.
- Nenhum envio da variação para o GA4, impedindo análise cruzada.
Perguntas frequentes sobre VWO FME
O que é o VWO FME?
É o produto de Feature Management and Experimentation do VWO, com SDKs para feature flags, rollout controlado, testes A/B no código e rastreamento de eventos.
Qual a diferença entre teste A/B client-side e server-side?
O client-side altera a página no navegador depois que ela carrega; o server-side decide a variação no código, antes da resposta, sem efeito de flicker e com acesso a regras de negócio.
Quais linguagens o VWO FME suporta?
Entre outras, Node.js/JavaScript, PHP, Python e React, além de exemplos para plataformas como Android TV e Apple TV.
O VWO FME tem API?
Sim, REST APIs para criar, consultar, atualizar e excluir feature flags.
Quando o Gateway Service é necessário?
Em pré-segmentação por localização ou user agent, targeting avançado e SDKs thin-client.
Como enviar a variação do VWO para o GA4?
Pelo callback de integração dos SDKs, repassando flag e variação para a camada de dados ou diretamente para o GA4.