Teste A/B de Recomendação de Produto: Converte Mesmo?
Teste recomendação de produto: a métrica que engana, canibalização, o controle honesto, custo de latência e como dimensionar o experimento.
📚 Este artigo faz parte do guia Otimização de Checkout: o Playbook de Teste A/B.
Um teste A/B de recomendação de produto compara uma versão da loja com sugestões automáticas contra outra sem elas (ou com uma lógica de sugestão diferente), para descobrir se a personalização gera pedido novo ou apenas move a mesma venda de lugar. É um dos testes em que a métrica que a ferramenta mostra na tela principal é justamente a que mais engana. Este artigo faz parte do playbook completo de otimização de checkout e cobre o que testar, qual métrica decide, como montar um controle honesto, quanto tráfego o experimento exige e as armadilhas específicas da personalização.
O que um bloco de recomendação de produto realmente faz
Um bloco de recomendação resolve um problema concreto: numa loja com catálogo grande, a maior parte dos produtos nunca é vista, e o visitante que não encontra o item certo sai sem comprar. A recomendação abrevia essa busca. O problema é que ela faz isso ocupando espaço numa página que já tinha um objetivo, e nem sempre o desvio de atenção compensa.
Três posições concentram a maior parte das implementações, e cada uma testa uma hipótese diferente:
- Na página de produto. A hipótese é de descoberta: “este item não é bem o que você quer, veja alternativas parecidas”. Ajuda quem chegou por busca genérica e atrapalha quem já decidiu.
- No carrinho. A hipótese é de ticket: “quem levou isto também levou aquilo”. É a posição com maior chance de aumentar valor do pedido e maior risco de adicionar fricção na etapa mais sensível do funil.
- Depois da compra (confirmação ou e-mail). A hipótese é de recompra: nenhum risco para o pedido atual, efeito medido no próximo ciclo. É a posição mais segura e a mais lenta de avaliar.
A métrica que engana: clique no widget
Toda ferramenta de recomendação mostra, no painel inicial, a taxa de clique no bloco e a receita atribuída a ele. Os dois números quase sempre parecem excelentes, e nenhum dos dois responde a pergunta do teste.
A taxa de clique mede atratividade visual, não incremento. Um carrossel bem desenhado recebe cliques em qualquer loja. A receita atribuída é pior, porque incorpora um pressuposto silencioso: que a compra feita depois de um clique no widget não teria acontecido sem ele. Na prática, boa parte dela teria.
Isso tem nome: canibalização. Três formas comuns:
- O visitante já ia comprar o produto A, clica numa recomendação, compra o produto B. A loja registra uma venda atribuída à recomendação, e o total de pedidos não mudou.
- O visitante compraria de qualquer jeito, e o item recomendado é mais barato que o original. A recomendação aparece como vitória e o ticket cai.
- O visitante entra numa espiral de navegação entre produtos sugeridos, não decide nada e sai. Nenhum painel de widget registra esse caso.
A leitura correta ignora completamente quem clicou e compara todos os visitantes de cada variação: quantos pedidos por visitante, quanta receita por visitante. É a única forma de medir incremento em vez de atribuição.
O controle honesto: mais vendidos contra algoritmo
O segundo erro estrutural desse tipo de teste é a escolha do controle. Comparar “com recomendação” contra “sem nada” mede o valor de ocupar aquele espaço com qualquer coisa, não o valor da personalização. Uma lista estática de mais vendidos da categoria é um controle forte e barato: entrega produtos com prova social alta, estoque garantido e zero latência extra.
| Lógica de recomendação | O que ela usa | Quando costuma ganhar | Custo e risco |
|---|---|---|---|
| Mais vendidos da categoria | Histórico agregado de vendas | Catálogo pequeno, tráfego novo, produtos de giro rápido | Praticamente nenhum; é o controle a bater |
| Regras manuais (curadoria) | Relações definidas por quem conhece o catálogo | Catálogos com relação óbvia entre itens (kits, acessórios) | Custo de manutenção; envelhece em silêncio |
| Comprado junto (colaborativo) | Coocorrência de itens em pedidos anteriores | Catálogos grandes com histórico volumoso | Cold start em produto novo; reforça o que já vende |
| Baseado em comportamento da sessão | Navegação recente do próprio visitante | Sessões longas de exploração | Depende de dado pessoal; exige base legal na LGPD |
| Modelo preditivo por perfil | Combinação de histórico, perfil e contexto | Bases logadas grandes e recorrentes | Infraestrutura, latência e menor explicabilidade |
Uma consequência prática dessa tabela: se a sua loja ainda não tem um bloco de mais vendidos bem posicionado, esse é o teste a rodar primeiro. Ele é mais barato, mais rápido de implementar e estabelece a linha de base contra a qual qualquer algoritmo vai ter que provar valor depois.
Dimensionando o teste
Ajuste a taxa de pedido atual, o ganho mínimo que justificaria manter a recomendação (incluindo o custo mensal da ferramenta) e o tráfego semanal real:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Um exemplo trabalhado com números reais
Uma loja converte 2,2% dos visitantes em pedido e recebe 50.000 visitas por semana. O time quer ligar um bloco de recomendação na página de produto.
Detectar uma melhora relativa de 8% (de 2,2% para 2,376%), a 95% de confiança e 80% de poder, exige 113.296 visitantes por variação, o que leva cerca de 32 dias. Mirando 12% relativo (de 2,2% para 2,464%), o requisito cai para 51.299 por variação e o teste fecha em cerca de 15 dias. Repare no tamanho desses números: é por isso que testes de recomendação com poucos milhares de visitantes por lado terminam quase sempre inconclusivos, e o time acaba decidindo pela taxa de clique do widget, que é exatamente o que não se deve fazer.
Suponha que o teste rodou até 52.000 visitantes por variação e fechou com 1.144 pedidos no controle (2,20%) contra 1.248 na variação com recomendação (2,40%). Rodando os quatro números no motor de significância do blog: z = 2,15, valor-p ≈ 0,0315, com intervalo de confiança de 95% da diferença entre +0,02 e +0,38 ponto percentual, e melhora relativa observada de +9,1%. O resultado é significativo, e o intervalo é um lembrete importante de quão impreciso um resultado significativo pode ser: o ganho verdadeiro pode ser tão pequeno quanto 0,02 ponto, praticamente nada.
O ganho paga a ferramenta?
Essa é a pergunta que fecha o teste. Sobre 52.000 visitas, o ganho de 2,20% para 2,40%, com ticket médio de R$ 180, gera R$ 18.720 de receita incremental no período do teste. Isso é receita, não lucro: descontada a margem bruta e o custo mensal da ferramenta de recomendação, o número real fica bem menor.
E é aqui que o limite inferior do intervalo faz diferença. Se o ganho verdadeiro estiver perto de +0,02 ponto em vez de +0,20, a receita incremental cai para cerca de um décimo desse valor, o que pode não pagar nem a assinatura da ferramenta. Para decisão de investimento, use o limite inferior; para priorizar o próximo teste, use o ponto central. O guia de significância estatística detalha como ler cada um desses números.
Teste pontual ou holdout permanente
Recomendação é uma das poucas alavancas de e-commerce em que vale manter um grupo de controle depois de o teste terminar. A razão é simples: o algoritmo muda sozinho. Ele reaprende com os pedidos novos, reage a mudanças de catálogo e de estoque, e o que funcionava em março pode estar neutro em setembro sem que ninguém tenha alterado uma linha de configuração.
Um teste pontual responde “ligar a recomendação foi melhor que não ligar, naquelas semanas”. Um holdout permanente, uma fatia pequena e fixa do tráfego (tipicamente entre 2% e 5%) que nunca vê a recomendação, responde uma pergunta diferente e mais durável: “quanto o algoritmo está entregando neste trimestre”. É a mesma lógica de guarda que times de e-mail marketing usam para medir o efeito de uma régua de automação ao longo do tempo.
| Teste pontual (A/B) | Holdout permanente | |
|---|---|---|
| Pergunta que responde | Vale ligar? | Quanto está valendo agora? |
| Duração | Semanas, até fechar a amostra | Contínuo, lido por trimestre |
| Fatia de tráfego no controle | 50% | Entre 2% e 5% |
| Custo | Metade do tráfego sem a alavanca por semanas | Uma fatia pequena permanentemente sem a alavanca |
| Quando usar | Antes de contratar ou implementar | Depois de a alavanca virar parte da loja |
O custo do holdout é real e precisa ser dito com honestidade: se a recomendação de fato converte melhor, você está deixando dinheiro na mesa naquela fatia pequena, todos os dias. A contrapartida é saber, com número em vez de fé, se a ferramenta que você paga todo mês continua entregando. Como a fatia é pequena, a leitura leva mais tempo para acumular amostra, então trate o holdout como um relatório trimestral, não como um painel para olhar toda segunda-feira.
Guardas obrigatórias
| Guarda | Por que monitorar | Sinal de alerta |
|---|---|---|
| Ticket médio | A recomendação pode substituir um item caro por um barato | Pedidos sobem e a receita por visitante fica igual ou cai |
| Tempo de carregamento | O bloco quase sempre vem de um serviço externo | A variação com recomendação carrega perceptivelmente mais devagar, sobretudo em conexão móvel |
| Taxa de devolução | Compra por sugestão tem mais chance de não ser o que a pessoa queria | Devolução sobe na variação vencedora nas semanas seguintes |
| Ruptura de estoque | O algoritmo tende a concentrar tráfego nos mesmos produtos | Itens recomendados esgotam e o bloco passa a sugerir indisponíveis |
| Diversidade do catálogo vendido | Recomendação colaborativa reforça o que já vende | A cauda longa some das vendas e a loja fica dependente de poucos itens |
A guarda de latência merece destaque porque é a mais frequentemente esquecida. Um bloco que adiciona requisições e JavaScript depois do conteúdo principal cobra um pedágio em toda visita, inclusive nas que nunca olharam o carrossel. Se o bloco atrasar a renderização do produto, parte do ganho de descoberta volta como abandono por lentidão, e o teste mede a soma dos dois efeitos sem separar um do outro.
Personalização, dado pessoal e LGPD
Recomendação baseada em mais vendidos ou em coocorrência de pedidos trabalha com dado agregado. Recomendação baseada no comportamento individual do visitante, ou no histórico de um cliente identificado, trata dado pessoal, e no Brasil isso exige base legal e transparência segundo a LGPD (Lei 13.709/2018).
Duas implicações práticas para o desenho do teste: a variação personalizada precisa respeitar a mesma política de consentimento da variação de controle (se a personalização depende de cookies que parte dos visitantes recusa, essa parte se comporta como controle e dilui o efeito medido), e o aviso ao usuário sobre o uso dos dados precisa ser igual nos dois lados, senão a diferença de consentimento vira uma variável de confusão que nenhuma calculadora corrige depois.
Armadilhas específicas do teste de recomendação de produto
- Efeito de novidade. Um carrossel novo atrai atenção pela simples novidade nas primeiras semanas, especialmente entre clientes recorrentes. Rode o teste por pelo menos dois ciclos semanais completos e confira se o efeito se mantém no segundo.
- Ligar recomendação na loja inteira de uma vez. Produz um número agregado que não diz onde ela funciona. Teste por posição.
- Cold start em produto novo. Algoritmos colaborativos não sabem recomendar o que ainda não foi comprado, e produtos recém-lançados ficam invisíveis exatamente quando mais precisam de exposição.
- Trocar o algoritmo no meio do teste. É a versão de personalização de mudar o limiar no meio: os visitantes do começo viram um produto diferente dos do fim, dentro da mesma variação.
- Ler o resultado só no agregado. O efeito costuma ser positivo em quem chega por busca genérica e neutro ou negativo em quem chega por busca de produto específico. Declare esses segmentos antes de rodar, como recomendado nos erros comuns de teste A/B.
Faça isso automático na Donnu
Testar recomendação de produto exige três coisas ao mesmo tempo: amostra grande o bastante para um efeito pequeno sobre uma taxa base baixa, leitura por pedido e receita por visitante em vez de clique no widget, e um intervalo de confiança honesto para comparar com o custo real da ferramenta.
A Donnu A/B entrega isso no seu site: snippet leve que não atrasa a página de produto, dimensionamento automático de amostra e estatística bayesiana sem inventar certeza. Comece um teste grátis de 14 dias e descubra se a sua recomendação gera venda nova ou só muda de lugar a venda que já existia.
Leia também: Otimização de Checkout: o Playbook de Teste A/B · Teste A/B de Página de Produto · Teste A/B de Upsell e Cross-Sell
Referências
- Baymard Institute. Checkout Usability Research. Base de problemas de usabilidade documentados em pesquisa de e-commerce em larga escala, incluindo navegação e descoberta de produto. baymard.com/research/checkout-usability.
- Baymard Institute. Cart Abandonment Rate Statistics. Média de 50 estudos sobre abandono de carrinho e distribuição dos motivos de abandono. baymard.com/lists/cart-abandonment-rate.
- Kohavi, R., Tang, D. & Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020, sobre efeito de novidade, métricas de guarda e leitura por segmento. Material de apoio em experimentguide.com.
- Brasil. Lei Geral de Proteção de Dados Pessoais (Lei 13.709/2018). Base legal e transparência no tratamento de dado pessoal, o que inclui personalização baseada em comportamento individual. planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.
Perguntas frequentes
- Qual métrica decide um teste de recomendação de produto?
- Pedido por visitante e receita por visitante, nunca o clique no bloco de recomendação. A taxa de clique no widget é a métrica que a ferramenta de recomendação mostra primeiro e a que sempre parece boa, porque qualquer bloco visualmente atraente recebe cliques. O que ela não separa é se aquele clique gerou uma compra nova ou apenas desviou uma compra que já ia acontecer. Só a métrica no fim do funil, medida sobre todos os visitantes da variação e não só sobre quem clicou, responde isso.
- O que é canibalização num teste de recomendação?
- É quando a recomendação captura uma compra que aconteceria de qualquer forma, geralmente substituindo o produto que a pessoa já tinha decidido comprar por outro sugerido. O painel do widget registra isso como uma vitória, porque houve clique e houve venda atribuída ao bloco. No agregado da loja, porém, o número de pedidos não muda e o ticket pode até cair, se o item recomendado for mais barato que o original. Por isso a leitura correta compara todos os visitantes de cada variação, não os compradores atribuídos ao widget.
- Personalização com algoritmo bate uma lista de mais vendidos?
- Nem sempre, e essa é a comparação honesta que muitos testes evitam fazer. Uma lista curada de mais vendidos da categoria é um controle forte: ela já entrega produtos com prova social alta e disponibilidade garantida, sem custo de infraestrutura e sem latência extra. Um algoritmo de recomendação precisa vencer esse controle, não uma página vazia. Se o seu teste compara personalização contra nenhuma recomendação, ele mede o valor de ter um bloco, não o valor do algoritmo.
- Quanto tráfego um teste de recomendação exige?
- Bastante, porque o efeito esperado costuma ser pequeno e a taxa base de pedido é baixa. Com a matemática deste blog, uma loja que converte 2,2% e quer detectar uma melhora relativa de 8% precisa de cerca de 113.296 visitantes por variação. Mirando 12% relativo, o requisito cai para cerca de 51.299 por variação, o que com 50.000 visitas semanais fecha em torno de 15 dias. Testes de recomendação com poucos milhares de visitantes por lado quase sempre terminam inconclusivos.
- Bloco de recomendação atrasa a página e isso afeta o teste?
- Sim, e esse é um custo que raramente entra na conta. A maior parte dos blocos de recomendação carrega de um serviço externo, depois do conteúdo principal, e adiciona requisições e JavaScript à página. Se a variação com recomendação fica perceptivelmente mais lenta, parte do ganho de descoberta é devolvida em abandono por lentidão, principalmente em conexão móvel. Meça o tempo de carregamento por variação como métrica de guarda, e prefira carregar o bloco de forma que ele nunca bloqueie a renderização do produto principal.