Teste A/B para E-commerce Headless — Como Funciona no Hydrogen, commercetools, Saleor & Stacks Personalizados

O comércio headless é agora o padrão para marcas D2C sérias de médio e grande porte. O frontend (React, Vue, Astro, personalizado) vive separadamente do backend de comércio (Shopify, commercetools, Saleor, BigCommerce). Obtém-se performance, flexibilidade de design, e uma experiência de desenvolvimento limpa. Também se obtém uma relação diferente com as ferramentas de teste A/B, porque a maioria delas foi construída assumindo que tens um tema.

Esta página explica a diferença arquitetural entre testar numa loja baseada em tema e testar numa montra headless, percorre como a integração funciona em cada stack principal, e mostra o que muda quando decides entre experimentação do lado do cliente e do lado do servidor. É um explicador, não um ranking de ferramentas.

O que muda quando vais headless

Se já instalaste uma ferramenta de testes A/B numa theme Shopify Liquid ou num site WooCommerce, o fluxo era simples. Colas um snippet no header da theme, guardas, pronto. Esse fluxo assume três coisas, todas elas desaparecem no comércio headless.

Não há editor de theme. As plataformas monolíticas vêm com um ponto de integração conhecido: o header da theme. No headless, o teu frontend é uma aplicação personalizada construída em React, Vue, Next.js, Hydrogen, ou outra framework à tua escolha. O snippet de teste tem de ser integrado no código da tua aplicação ou carregar de uma CDN. É uma decisão única que o teu programador toma, mas é uma decisão, não um passo de colar e partir.

A pipeline de build é tua. O Hydrogen constrói com Vite. Uma storefront commercetools usa frequentemente Next.js. Os frontends Saleor são tipicamente Next.js ou Nuxt. Cada projeto tem o seu próprio bundler, grafo de dependências e target de deployment. Uma ferramenta de teste que envia uma única tag de script drop-in funciona em todo o lado. Uma ferramenta que requer instalação de SDK e configuração de bundler funciona em algumas stacks e não noutras.

O rendering acontece de forma diferente. Numa loja Shopify monolítica, o HTML é renderizado pelos servidores da Shopify. O JavaScript executa no browser, e o teste client-side é a escolha óbvia. No headless, podes usar server-side rendering (Next.js SSR), geração de site estático (Hydrogen, Astro), regeneração incremental, ou rendering puramente client-side. Cada um muda onde deve acontecer a atribuição de variante. Esta torna-se a decisão central para testes A/B headless, e cobrimos isso abaixo.

Como funcionam os testes A/B em cada stack headless principal

Shopify Hydrogen

O Hydrogen é a framework React da Shopify para storefronts headless, deployed no Oxygen. Usa Remix por baixo e renderiza server-side. Para testes A/B, tens dois caminhos:

• Client-side: Carrega o snippet de teste no layout raiz (root.tsx). A atribuição de variante executa no browser após hidratação. Funciona para qualquer teste ao nível da UI (hero, layout PDP, posicionamento CTA, trust badges). É o que a maioria das equipas escolhe.
• Server-side: Usa as funções loader do Hydrogen para fazer fetch das atribuições de variante da API da tua ferramenta de teste, depois passa-as como props aos componentes renderizados. Zero flicker, maior esforço de implementação.

Nota que a app de testes A/B nativa da Shopify não funciona no Hydrogen. É construída apenas para themes Liquid.

commercetools (com qualquer frontend)

O commercetools é um backend de comércio headless. O frontend é tipicamente Next.js, Nuxt, ou personalizado. A abordagem de teste depende do frontend, não do commercetools em si. A maioria das equipas coloca um snippet no HTML head do frontend e executa client-side. Server-side é possível chamando a API da ferramenta de teste das funções server do teu frontend.

Saleor

O Saleor é uma plataforma de comércio headless open-source com uma implementação de referência de storefront Next.js ou React. O backend Saleor não dita a abordagem de teste. Client-side via snippet no _app.tsx ou layout raiz é o padrão standard.

BigCommerce headless

O BigCommerce suporta headless via a sua storefront de referência Catalyst Next.js ou qualquer frontend personalizado. Mesmo padrão que os outros: snippet client-side na raiz Next.js, opcionalmente server-side via API para variantes SSR.

Next.js personalizado, Remix, Astro, SvelteKit

Qualquer frontend de comércio personalizado funciona da mesma forma. Coloca o snippet de teste no componente raiz ou layout. Se precisas de variantes server-side (tipicamente para páginas de checkout onde o flicker é inaceitável), chama a API de teste nas tuas funções server e passa os resultados como props.

Server-side vs client-side no headless: quando escolher cada um

O headless dá-te uma escolha arquitetural real entre testes server-side e client-side. Numa loja Shopify Liquid a questão mal se aplica. No headless aplica-se.

Testes client-side funcionam em todas as stacks headless. A configuração demora minutos (cola um snippet no layout raiz), o editor visual mantém-se disponível, e os marketeers podem executar testes sem envolvimento da engenharia. Ferramentas nesta categoria incluem Varify.io, VWO, AB Tasty, e Convert. O pequeno risco é flicker em redes lentas, que uma boa implementação anti-flicker reduz para menos de 30 milissegundos.

Testes server-side funcionam melhor em stacks SSR ou SSG como Hydrogen, Next.js SSR, e Astro. A decisão de variante acontece antes do HTML chegar ao browser, por isso o flicker é zero. O custo é esforço de implementação: cada teste requer integração SDK, mudanças na pipeline de deployment, e lógica backend para rotear variantes. Ferramentas nesta categoria incluem GrowthBook, Optimizely Full Stack, e LaunchDarkly Experimentation. Este é o caminho certo quando tens capacidade de engenharia e um teste crítico de checkout ou de lógica backend onde o flicker é inaceitável.

Para cerca de 80% dos testes A/B de comércio headless, client-side é a escolha certa. As exceções são testes críticos de checkout onde o flicker importa e testes de lógica backend como motores de preços ou algoritmos de recomendação. Para esses, setups server-side ou híbridos fazem sentido. A nossa comparação client-side vs server-side tem o breakdown completo.

Como o Varify.io se integra com uma montra headless

Três razões pelas quais o Varify.io se adequa bem ao comércio headless.

• Um snippet, qualquer frontend. Um snippet JavaScript de 11,5 KB adicionado uma vez no seu layout raiz. Funciona em React, Vue, Astro, SvelteKit, Hydrogen, Next.js e qualquer outra coisa que carregue JavaScript num browser. Sem instalação de SDK, sem configuração de bundler, sem pacote específico do framework para manter atualizado.
• Consciente de SPA. As lojas headless são tipicamente single-page applications. O Varify deteta mudanças de rota no React Router, roteamento Next.js e navegação Hydrogen, e reaplica variantes na nova página automaticamente. Não é necessária configuração manual de SPA.
• Sem cookies, sem porta de consentimento. A atribuição de variantes usa localStorage, que funciona independentemente do estado do banner de consentimento e independentemente do Safari ITP. Isto importa para lojas headless com alto tráfego móvel e base de clientes da UE. Veja testes A/B sem cookies para os detalhes da arquitetura.

A integração típica numa montra Next.js ou Hydrogen parece-se com isto:

// app/layout.tsx ou root.tsx
<script
  async
  src="https://cdn.varify.io/snippet/YOUR_ID.js"
/>

Esta é toda a integração para a maioria das montras headless. Uma vez que o snippet esteja ativo, os experimentos são geridos no dashboard do Varify, e não são necessárias mais mudanças de código para novos testes.

Para páginas críticas de performance onde a cintilação é inaceitável, o Varify também suporta chamar a API de atribuição a partir de código server-side e injetar dados de variantes no render HTML inicial. A maioria das equipas não precisa disto, e o padrão client-side é suficiente para a maioria dos testes.