Receba seu design grátis
· Otimização · 4 min de leitura

Teste A/B de capturas de tela com Product Page Experiments

Teste A/B de capturas de tela com Product Page Experiments
TL;DR. Product Page Experiments é a ferramenta gratuita de teste A/B da Apple para capturas de tela do App Store. Funciona, mas é lenta se usada de forma descuidada. Execute com uma hipótese clara sobre uma variável por vez, dê a ela o tamanho de amostra necessário e você terá resultados direcionais limpos em duas semanas. Execute com cinco variáveis e 50% de tráfego em cada uma e você terá ruído por seis semanas.

Product Page Experiments (PPE) foi lançado no iOS 15 e desde então é a forma padrão de fazer teste A/B de metadados do App Store. Você configura um controle mais até três variantes de tratamento, aloca tráfego, escolhe o nível de confiança e a Apple indica o vencedor. A infraestrutura é sólida; a disciplina em como usá-la nem sempre.

O que o PPE realmente mede

O PPE mede impressões e conversões na própria página do produto. Especificamente:

  • Impressões: usuários que chegaram à sua página do produto.
  • Conversões: usuários que tocaram em Obter/Comprar após chegar.

Ele NÃO mede o clique no resultado de busca (se os usuários tocam no seu resultado de pesquisa para chegar à página). Para isso você precisaria testar a visualização do resultado de busca, que usa os primeiros 3 painéis da sua localidade padrão. O PPE pode testar o carrossel completo, mas só mede o que acontece depois que o usuário já está na página.

Isso importa porque mudanças nos painéis 4-10 afetam apenas a conversão da página do produto, enquanto mudanças nos painéis 1-3 afetam tanto o clique no resultado de busca quanto a conversão da página. O PPE mede o segundo, não o primeiro.

A regra de "uma variável por vez"

A tentação é mudar o carrossel inteiro entre variantes. Não faça isso. Se a variante A tem novas legendas, nova inclinação de dispositivo e uma nova paleta, e a variante A vence — você não sabe qual mudança causou o ganho. Também não consegue raciocinar sobre transferir o aprendizado para o próximo teste.

Disciplina: mude uma coisa por teste. Nova legenda no painel 1, todo o resto igual. Nova cor de fundo, legendas idênticas. Nova ordem de painéis, conteúdo idêntico. Lento, mas cada teste gera um aprendizado sobre o qual você pode construir. Iteração rápida sobre ruído não é progresso.

Tamanho de amostra: a parte que a maioria das equipes subestima

O PPE usa teste de hipótese frequentista padrão. O tamanho de amostra necessário depende de:

  • Sua taxa de conversão de base (tipicamente 1-5% para apps gratuitos, menor para pagos).
  • O efeito mínimo detectável que importa para você (5% de ganho relativo, 10%, 20%?).
  • Seu tráfego para a página do produto.

Ordem de grandeza: detectar um ganho relativo de 10% em uma conversão de base de 3% exige ~20.000 impressões por variante com 95% de confiança. Se o seu app recebe 2.000 impressões na página do produto por semana, isso equivale a 10 semanas por teste. A maioria dos apps indie não tem tráfego para rodar testes estatisticamente limpos com efeitos pequenos. Opções honestas:

  • Teste apenas mudanças grandes — troca de paleta, ordem de painéis, tom de legenda fundamentalmente diferente. Esses testes atingem significância rápido porque o tamanho do efeito é maior.
  • Reduza a alocação de tráfego para uma ou duas variantes em vez de três.
  • Aceite resultados direcionais, não significativos. Se uma variante está vencendo consistentemente por 4 semanas com 70% de confiança, publique-a e faça um teste diferente depois.

O design de teste que funciona

  1. Escolha uma hipótese. "Legendas maiores no painel 1 vão melhorar a conversão porque miniaturas comprimem legendas menores até ficarem ilegíveis." Uma suposição específica, não "vamos ver o que funciona".
  2. Projete a variante A: uma mudança. Mesmo carrossel, só a legenda do painel 1 é alterada. Todo o resto idêntico.
  3. Aloque 50% para o controle, 50% para a variante. Testes de dois braços atingem significância mais rápido do que três ou quatro braços.
  4. Defina a duração do teste com antecedência. "Vamos rodar por 4 semanas ou até atingir 95% de significância, o que ocorrer primeiro." Resista à tentação de espiar e parar cedo.
  5. Documente o resultado. Seja vitória, derrota ou resultado inconclusivo — anote. Você irá repetir o mesmo teste seis meses depois se não fizer isso.

O que testar, em ordem de prioridade

  1. Legenda do painel 1. Maior impacto porque o painel 1 domina tanto as miniaturas de busca quanto a primeira impressão da página do produto.
  2. Ordem dos painéis. Especificamente: com qual funcionalidade você abre?
  3. Paleta do carrossel / escuro vs claro. Grande efeito, rápido de testar.
  4. Inclinação / orientação do dispositivo. Efeito menor, mas barato de configurar.
  5. Tom da legenda (imperativo vs descritivo). "Registre suas corridas" vs "Suas corridas, registradas". Efeito menor, sinal mais difícil de ler com clareza.

Pare de testar fontes, variações mínimas de cor ou conteúdo dos painéis 8-10. Esses testes quase nunca atingem significância e os efeitos são pequenos o suficiente para que a vitória não valha o orçamento do teste.

Localização no PPE

O PPE suporta variantes por localidade. Se você rodar um teste na sua localidade padrão e publicar o vencedor, ainda precisará aplicar manualmente a mudança em cada variante localizada do painel. Escolha uma localidade com tráfego suficiente para atingir significância (geralmente en-US) e trate o resultado como um guia direcional global para as outras localidades. Não rode 39 experimentos separados.

Erros comuns

  • Espiar e parar cedo. A significância oscila aleatoriamente durante um teste. Parar no momento em que uma variante parece estar vencendo leva a conclusões erradas. Defina uma duração mínima e respeite-a.
  • Testar variáveis demais. Redesigns completos não podem ser testados via A/B de forma limpa. Você precisa de um teste separado para o novo design geral (multivariável, aceite alguma confusão de variáveis) seguido de testes de iteração de variável única no vencedor.
  • Rodar testes em períodos de ruído sazonal. Black Friday, destaque no App Store, campanhas de marketing — tudo isso adiciona tráfego e ruído. Evite testar nesses períodos, a menos que você controle os picos.
  • Ignorar a localidade. Um resultado de teste nos EUA nem sempre se generaliza para o Japão. Use-o como hipótese inicial, não como resposta definitiva.

O que fazer este mês

  1. Estime o tamanho de amostra necessário. Insira seu tráfego e conversão de base em uma calculadora de tamanho de amostra antes de configurar o teste.
  2. Escolha uma hipótese. Escreva-a em uma frase.
  3. Projete A vs B com uma variável alterada. Configure no App Store Connect.
  4. Defina a duração e coloque a data de encerramento no calendário.
  5. Documente o resultado independentemente do desfecho.

Leia a seguir

Abrir o editor →