Como Fazer Testes A/B de Capturas de Tela da App Store para Conversão

Por que testar A/B especificamente as capturas de tela?

Capturas de tela são o ativo de maior alavancagem em uma página de loja. Os próprios dados da Apple sobre Product Page Optimization mostram que as três primeiras capturas de tela impulsionam a maior parte do ganho de conversão de uma página — mais do que o ícone, o subtítulo ou até o vídeo de preview do app. A documentação dos Store Listing Experiments do Google relata o mesmo: vitórias em testes de gráficos normalmente superam vitórias em testes de copy por uma margem ampla.

A razão pela qual as equipes pulam testes de capturas de tela é o atrito. Produzir quatro conjuntos de desafiantes (controle + 3 variantes) × três tamanhos de iPhone × dois tamanhos de iPad × os idiomas para os quais você publica significa dezenas de arquivos por teste. Com uma API de renderização, o atrito desaparece — uma duplicação de template, uma mudança de parâmetro, uma chamada de API.

O que você deve realmente testar?

Teste uma variável por rodada. As variáveis de maior alavancagem, em ordem aproximadamente decrescente de impacto, são:

• O título da primeira captura de tela — visível sem rolar nos resultados de busca
• Funcionalidade de destaque — qual recurso você apresenta primeiro
• Estilo do fundo — cor sólida vs gradiente vs fotográfico
• Frame de dispositivo — com frame vs sem frame, ângulo do mockup
• Posição da legenda — acima, abaixo ou sobreposta
• Cor do elemento de CTA — cor primária da marca vs tom de destaque contrastante

Resista à tentação de testar cinco coisas ao mesmo tempo. Testes multivariados precisam de tráfego que a maioria dos apps não tem, e você acaba com um vencedor que não consegue explicar.

Como gerar variantes programaticamente?

Duplique o template de controle no editor, mude um elemento, salve. Depois renderize cada variante usando o mesmo formato de chamada da API — apenas o templateId muda:

# Render the control + 3 challengers
for VARIANT in control red_cta photo_bg short_headline; do
  curl -X POST https://api.screenshots.live/v1/renders \
    -H "Authorization: Bearer $SCREENSHOTSLIVE_API_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{
      \"templateId\": \"tpl_home_v3_${VARIANT}\",
      \"locales\": [\"en-US\"],
      \"devices\": [\"iphone-6.7\", \"iphone-6.1\"],
      \"outputDir\": \"./variants/${VARIANT}\"
    }"
done

Para a maioria dos testes, renderize apenas os idiomas que o teste realmente alvo. O Product Page Optimization do App Store Connect roda por idioma, então um teste apenas para os EUA só precisa de ativos em en-US.

Como configurar o teste no App Store Connect (PPO)?

O Product Page Optimization da Apple permite testar até três páginas desafiantes contra sua página padrão em um único idioma. A Apple distribui o tráfego aleatoriamente, reporta impressões e taxa de conversão por variante, e mostra intervalos de confiança quando o teste atinge significância.

1. No App Store Connect, abra seu app → Product Page Optimization → Create New Test.
2. Adicione até três variantes da página de produto. Cada variante recebe seu próprio conjunto de capturas de tela, app preview e ícone.
3. Aloque o tráfego. O padrão de 25% por variante (controle + três) funciona para a maioria dos apps.
4. Escolha uma localização. O PPO roda por idioma — o mesmo teste não pode ser aplicado a múltiplos idiomas simultaneamente.
5. Envie para revisão. Cada variante é revisada pela App Review como uma submissão de binário normal.
6. Inicie o teste assim que todas as variantes forem aprovadas.

Veja a página oficial do Apple Product Page Optimization para limites e tempos de revisão atuais.

Como configurar os Google Play Store Listing Experiments?

O fluxo do Google é parecido, mas mais flexível. No Play Console, navegue até Store Presence → Store Listing Experiments → Create Experiment. Escolha:

• Tipo: Default Listing (global) ou Localized Listing (por idioma)
• Ativo: capturas de tela de celular, tablet 7 polegadas, tablet 10 polegadas, feature graphic, ícone
• Variantes: até três desafiantes vs controle
• Divisão de audiência: 25%/25%/25%/25% por padrão, ou personalizada

O Play Console lida com intervalos de confiança automaticamente e sinaliza o vencedor quando o ganho é estatisticamente significativo. Leia a documentação mais recente do Google em Run experiments on your store listing.

De que tamanho de amostra você precisa?

Use uma calculadora padrão de teste z de duas proporções com estes inputs:

• Taxa de conversão de baseline: sua CTR atual da página de produto (tipicamente 25–35% na App Store, 5–10% na Play Store)
• Ganho mínimo detectável: 5% de ganho relativo é uma régua razoável; abaixo de 3% raramente vale o tempo
• Nível de significância: 95% (α = 0,05)
• Poder: 80% (β = 0,20)

Para um baseline de 30% e ganho relativo de 5%, você precisa de aproximadamente 100k–150k impressões por variante. A maioria dos apps com menos de 50k impressões semanais devem rodar testes sequenciais (uma variante por duas semanas, depois a próxima, comparando contra um baseline histórico estável) em vez de concorrentes.

Por quanto tempo você deve rodar um teste?

Pelo menos uma semana inteira. Padrões de conversão variam significativamente por dia da semana e por fonte de tráfego (Search Ads vs orgânico). Sete dias capturam um ciclo semanal completo. Duas semanas é melhor quando o tráfego é baixo. Pare antes apenas se (a) a diferença for esmagadora (>30% de ganho) e (b) o teste tiver rodado por pelo menos sete dias completos. Parar cedo no ruído é a forma mais comum de publicar uma página pior do que a que você começou.

Como ler os resultados sem se enganar?

Use o intervalo de confiança da própria plataforma. Tanto o PPO da Apple quanto os Experiments do Google Play reportam intervalos de confiança de 90% / 95% sobre o ganho da variante em relação ao controle. Se o intervalo cruza zero, o teste é inconclusivo — não publique a desafiante só porque a estimativa pontual é positiva.

Não tente derivar resultados de dados de MMP de terceiros. A variante que um usuário vê é decidida no servidor pela Apple ou Google — seu MMP não consegue ver de qual variante o usuário veio. O dashboard da própria loja é a única fonte de verdade.

O que fazer com o vencedor?

Promova a variante vencedora a padrão. Os templates perdedores não devem ser deletados — guarde-os como pontos de referência e escreva uma nota de uma linha sobre o que mudou e o que você aprendeu. O próximo teste se acumula sobre o último: se um título curto venceu um longo, seu próximo teste pode explorar estilos de ícone dentro do framework de título curto.

Combine este guia com o guia de automação de CI/CD para que as variantes sejam geradas automaticamente a cada release, e o guia de localização para que seu vencedor seja traduzido para mais de 30 idiomas sem precisar testar cada um novamente.