Teste A/B na App Store (ASO): o que dá e o que não dá
Teste A/B de ficha da loja explicado: o que Google Play e App Store deixam testar, como cada uma decide o vencedor e como dimensionar o teste direito.
📚 Este artigo faz parte do guia Teste A/B em Apps Mobile: o Guia Completo (iOS + Android).
Teste A/B na loja de aplicativos é um teste que a plataforma roda na sua ficha, antes de qualquer instalação, e é medido por um número só: a conversão de visualização da ficha em instalação. Não é o mesmo mecanismo de um teste A/B dentro do app, não usa o seu código e nenhuma ferramenta de terceiro roda isso por você. Este artigo faz parte do guia completo de teste A/B em apps mobile e cobre o que Google Play e App Store realmente deixam testar, como cada uma decide um vencedor, como dimensionar um teste de loja com números reais, e as armadilhas que fazem uma ficha “vencedora” não mover instalação nenhuma depois de publicada.
Onde o teste de ficha fica no funil
Tudo o que um time de app pode testar se divide em duas zonas, separadas pela própria instalação.
O que cada loja deixa testar
As duas plataformas são parecidas no espírito e diferentes na cobertura. Ambas rodam o experimento sobre tráfego real da loja, dividem esse tráfego elas mesmas e reportam a conversão de cada variação. O que você tem permissão de variar é onde elas se separam.
| Google Play (experimentos de ficha) | App Store (Product Page Optimization) | |
|---|---|---|
| Ativos visuais testáveis | Ícone, imagem de destaque, capturas de tela, vídeo de prévia | Ícone, capturas de tela, prévias do app |
| Texto da ficha testável | Sim, as descrições do app | Não, o recurso não cobre nome, subtítulo nem descrição |
| Onde se configura | Google Play Console | App Store Connect |
| Tráfego usado | Tráfego real de busca e navegação do Google Play | Tráfego real da App Store, com fatia configurável para o teste |
| Duração máxima | O Google documenta parada automática em 6 meses | A Apple documenta até 90 dias |
| Métrica reportada | Cliques de instalação por variação, com intervalo de confiança | Taxa de conversão de cada tratamento contra o original |
| Localização | Experimentos configurados por localização da ficha | Tratamentos podem ser localizados por mercado |
Duas consequências saem dessa tabela. Primeira: se a sua hipótese é sobre palavras (“chamar de agenda em vez de lista de tarefas aumenta a instalação?”), o Google Play responde isso nativamente e a App Store não; no iOS você teria que mudar os metadados e comparar períodos, o que não é experimento controlado. Segunda: teste de ícone é a única hipótese que as duas lojas respondem do mesmo jeito, e é por isso que ícone é o primeiro teste mais comum nas duas plataformas.
Existe ainda um recurso da Apple que muita gente confunde com teste: as páginas de produto personalizadas, versões alternativas da sua página com URLs próprias, usadas para casar uma campanha específica com uma mensagem específica. São ferramenta de segmentação, não experimento: não há divisão aleatória nem grupo de controle. Use-as para alinhar tráfego pago à página que ele encontra, e use o Product Page Optimization quando quiser comparação controlada.
O que não dá para testar na loja
A lista do que fica de fora dos experimentos nativos merece ser dita com todas as letras, porque boa parte do conteúdo de ASO passa por cima dela:
- Preço e faixas de compra no app. Não fazem parte de nenhum dos dois experimentos. Experimento de preço vive no seu backend ou numa estratégia promocional, e carrega considerações próprias de comunicação e de isonomia.
- Palavras-chave dos metadados como teste controlado. Você pode mudar as palavras-chave e observar o que acontece, mas nenhuma das lojas divide tráfego entre dois conjuntos de palavras-chave, então o que você tem é uma comparação antes e depois contaminada por sazonalidade, movimento de concorrente e oscilação de ranqueamento.
- Categoria e classificação indicativa. Configuração, não criativo.
- O app em si. Qualquer coisa depois da instalação é teste de feature flag, não teste de loja.
- Comparação entre lojas. Uma variação que vence no Google Play não diz nada estatisticamente válido sobre a App Store. Públicos diferentes, layout de página diferente, mistura de tráfego diferente. Rode cada teste onde ele pertence.
Como as lojas decidem um vencedor, e por que ainda assim fazer a conta
As duas plataformas reportam a própria estimativa de confiança, e as duas são honestas em dizer que um resultado dentro da faixa de incerteza não é resultado. Isso é genuinamente útil e também é onde a maioria dos times para de pensar, o que é um erro por duas razões.
A primeira é que o veredito embutido da loja responde “essa diferença se distingue do ruído”, não “quanto tempo vou esperar e se essa espera vale a pena”. Só o cálculo de amostra responde a segunda pergunta antes de você comprometer semanas de tráfego de loja com um teste.
A segunda é que tráfego de loja não é seu para aumentar sob demanda. Num site você pode apontar anúncios para uma página e acelerar o teste. Numa ficha, o experimento consome impressões orgânicas na velocidade em que a loja as manda, o que significa que um teste de ficha sem poder estatístico não só falha, ele falha devagar.
Dimensione antes de subir
Coloque a taxa de conversão atual da sua ficha, a melhora mínima que valeria publicar e as visualizações semanais:
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
Pegue uma ficha convertendo 28% das visualizações em instalação, um valor plausível para um app estabelecido com encaixe claro de categoria. Três efeitos alvo, com 95% de confiança e 80% de poder, produzem compromissos bem diferentes:
| Melhora buscada | Nova taxa | Amostra por variação | A 10.000 visualizações/semana | A 50.000 visualizações/semana |
|---|---|---|---|---|
| +5% relativo | 29,4% | 16.388 | 23 dias | 5 dias |
| +10% relativo | 30,8% | 4.155 | 6 dias | 2 dias |
| +15% relativo | 32,2% | 1.872 | 3 dias | 1 dia |
Leia essa tabela antes de desenhar o criativo, não depois. Perseguir +5% relativo numa ficha que recebe 10.000 visualizações por semana é comprometer mais de três semanas de tráfego de loja com uma comparação só; perseguir +15% com um conceito de ícone genuinamente diferente fecha em dias. É a mesma troca entre ambição e paciência de qualquer teste, e a versão geral dela está em CRO para sites de baixo tráfego.
Agora o lado do resultado. Suponha que o teste tenha rodado até 30.000 visualizações por variação e produzido 8.400 instalações no controle (28,0%) contra 8.820 no tratamento (29,4%), exatamente o +5% relativo da primeira linha. Rodando isso no mesmo motor de significância usado em todo este blog: z = 3,79, valor-p de aproximadamente 0,00015, com intervalo de confiança da diferença de +0,68 a +2,12 pontos percentuais. O intervalo nunca toca o zero, então o tratamento converte melhor mesmo. Repare em como a afirmação honesta é modesta: a melhora está entre cerca de dois terços de ponto e dois pontos de conversão, e não “o ícone novo aumentou as instalações em 5%” dito como certeza.
Confira o mesmo cálculo, ou os números do seu teste:
Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.
As armadilhas específicas de teste de loja
Sazonalidade come efeito pequeno. A mistura de tráfego da loja muda com feriado, destaque editorial da plataforma, lançamento de concorrente e campanha paga que você está rodando em outro canal. Um teste que atravessa um pico da categoria inteira está comparando duas variações sob condições que nenhuma das duas vai encontrar depois. Prefira uma janela estável e trate como provisório qualquer resultado achado só durante período anômalo.
A origem do tráfego não é constante. Quem chega por busca do nome da sua marca se comporta diferente de quem está navegando um ranking de categoria, que se comporta diferente de quem tocou num anúncio. Se o teste roda enquanto uma campanha paga empurra tráfego atípico para a página, a variação vencedora é a que serve àquela mistura, não necessariamente à sua mistura normal.
Localização não é tradução. Um conjunto de capturas de tela que vence num mercado frequentemente perde em outro, porque as convenções visuais, o conjunto de concorrentes e os motivos para instalar mudam. Rode o teste por localização em vez de generalizar o vencedor de um mercado para todos. No Brasil isso importa mais do que parece: a ficha em português disputa atenção com um conjunto de concorrentes que muitas vezes nem existe no mercado de origem do app.
Instalação não é o objetivo. Esta é a armadilha mais cara da lista. Uma ficha agressiva, que promete mais do que o produto entrega, aumenta com confiabilidade a conversão em instalação e derruba com a mesma confiabilidade a retenção em 7 dias, porque recruta gente que o produto nunca iria satisfazer. É por isso que a métrica de guarda abaixo importa mais que a métrica primária.
A métrica de guarda: a retenção da coorte que o teste recrutou
As duas lojas reportam conversão em instalação e param por aí, o que é razoável, já que elas não enxergam dentro do seu app. Você enxerga. Marque a coorte de instalação por variação do teste na sua própria analítica e compare retenção em 1 e em 7 dias entre elas, ao lado do veredito de conversão da loja.
A regra a adotar: publique a variação que vence em usuários retidos, não em instalações. Se a variação B aumenta a conversão em instalação em 5% relativo e derruba a retenção em 7 dias em mais que isso em termos relativos, B é uma ficha pior que por acaso parece melhor no painel da loja. É o mesmo raciocínio de métrica de guarda de qualquer experimento, tratado em erros comuns em testes A/B.
Checklist de pré-voo do teste de ficha
| Item | Confirmar antes de subir |
|---|---|
| Hipótese escrita | Uma afirmação específica de por que o ativo novo deveria converter melhor, não “vamos tentar um ícone mais moderno” |
| Efeito escolhido antes | A melhora mínima que vale publicar, traduzida em amostra e prazo com a calculadora acima |
| Uma variável por vez (quando der) | Ícone e capturas mudados juntos dizem que o pacote venceu, não qual parte venceu |
| Janela estável | Sem destaque de plataforma, pico sazonal ou campanha paga incomum inflando a página |
| Por localização | Teste configurado para o mercado que você quer mudar, não um mercado generalizado para todos |
| Guarda de retenção instrumentada | Coorte de instalação marcada por variação na sua analítica antes de o teste começar |
| Verificação pós-publicação | Depois de publicar o vencedor, acompanhe a conversão por um ciclo inteiro para confirmar que o efeito sobrevive fora do teste |
Combinando teste de loja com teste dentro do app
A sequência que funciona é chata e eficaz: conserte primeiro o maior vazamento. Se a sua ficha converte bem e o seu onboarding vaza, um ícone melhor só manda mais gente para um funil quebrado. Se o onboarding está sólido e quase ninguém chega nele, criativo de ficha é o lugar certo para gastar o próximo mês. Meça os dois, decida pela aritmética e rode um teste por vez em cada zona, em vez de quatro testes sobrepostos cujos efeitos você não consegue mais separar.
Para a metade dentro do app dessa dupla, teste A/B de onboarding mobile cobre a métrica de ativação e o viés de sobrevivência que estraga a maioria dos resultados de onboarding.
Faça isso automático na Donnu
Teste de ficha só pode ser rodado pelas próprias plataformas, e este artigo não finge o contrário. O que atravessa as duas zonas é a disciplina: dimensionar o teste antes de rodar, ler o intervalo de confiança em vez do ganho de manchete, e manter sempre uma métrica de guarda logo depois daquela que você está otimizando.
A Donnu aplica exatamente essa disciplina no lado web do seu funil: a landing page que alimenta as instalações, o checkout em webview, a área logada que se abre no navegador. Snippet leve, dimensionamento automático de amostra, estatística honesta, sem certeza inventada. Comece um teste grátis de 14 dias e pare de publicar vencedores que só existem dentro do ruído.
Referências
- Google Play Console. Store listing experiments. Página oficial do experimento nativo de ficha do Google Play, rodado contra tráfego real da loja. play.google.com/console/about/store-listing-experiments.
- Apple. Product Page Optimization. Documentação oficial do recurso do App Store Connect que testa variações de ícone, capturas e prévias contra a página original. developer.apple.com/app-store/product-page-optimization.
- Apple. Custom product pages. Documentação oficial das páginas de produto alternativas com URLs próprias, usadas para segmentação de campanha e não para experimentação. developer.apple.com/app-store/custom-product-pages.
- Google Play Console Help. Run A/B tests on your store listing. Referência de configuração e leitura dos experimentos do Play Console, incluindo métricas alvo, experimentos localizados e a parada automática em seis meses. support.google.com/googleplay/android-developer/answer/12053285.
- Sensor Tower. App Store Optimization: visibility and conversions. Referência de mercado sobre prática de ASO, incluindo teste de elementos visuais da ficha para aumentar conversão. sensortower.com/blog/app-store-optimization-visibility-conversions.
Leia também:
- Teste A/B em Apps Mobile: o guia completo (iOS + Android)
- Teste A/B de Onboarding Mobile: o que realmente melhora a retenção
- Teste A/B Mobile x Web: o que realmente muda
Read in English: App Store A/B Testing (ASO): What You Can and Cannot Test
Perguntas frequentes
- O que exatamente dá para testar A/B numa ficha de loja de aplicativo?
- No Google Play, os experimentos de ficha da loja cobrem os ativos visuais (ícone, imagem de destaque, capturas de tela e vídeo de prévia) e as descrições do app para uma localização específica. Na App Store, o Product Page Optimization cobre só os ativos visuais: ícone, capturas de tela e prévias. A Apple não oferece teste A/B para nome, subtítulo ou descrição por esse recurso. Qualquer coisa fora dessas listas (preço, categoria, palavras-chave do campo de metadados) não é testável pelo experimento nativo da loja.
- Teste de ficha da loja é a mesma coisa que teste A/B dentro do app?
- Não. O teste de ficha roda antes da instalação, na própria página da loja, e é executado e medido pela plataforma, não pelo seu código. A métrica é a conversão de visualização da ficha em instalação. Um teste A/B dentro do app roda depois da instalação, por feature flag remota ou decisão de backend, e mede eventos de produto como ativação, upgrade ou retenção. Respondem perguntas diferentes e normalmente têm donos diferentes.
- Quanto tempo um teste de ficha da loja deve rodar?
- O suficiente para atingir a amostra que a sua taxa base e o efeito buscado exigem, e no mínimo uma semana inteira para cobrir o ciclo de dias úteis e fim de semana. A Apple documenta que um teste de Product Page Optimization pode rodar por até 90 dias. Na prática a restrição que manda é o tráfego da loja: uma ficha com volume modesto de impressões atrás de uma melhora pequena pode precisar de dezenas de milhares de visualizações por variação, o que a calculadora deste artigo torna concreto.
- Por que meu teste na loja venceu e as instalações não subiram depois?
- Três motivos comuns. Primeiro, o efeito era real mas pequeno, e a versão publicada agora disputa com uma sazonalidade que se moveu mais do que o teste. Segundo, o teste rodou sobre uma mistura de tráfego (busca, navegação, indicação externa) que não é a mistura de depois, então o ativo vencedor se comporta diferente em outro público. Terceiro, e mais grave, o ativo vencedor promete demais: sobe a instalação e derruba a retenção. Leia sempre o teste de loja junto de uma métrica de guarda de retenção, nunca só pela conversão em instalação.
- Posso usar a minha própria ferramenta de teste A/B na ficha da loja?
- Não. A página da loja é renderizada pelo Google Play e pela App Store, não pelos seus servidores, então nenhum snippet ou SDK de terceiro divide aquele tráfego. A única forma de testar uma ficha é pelo experimento nativo da loja (experimentos de ficha ou Product Page Optimization). Ferramentas externas ajudam a produzir e pré-triar conceitos de criativo, mas o teste ao vivo só roda dentro da plataforma.
- Vale rodar o mesmo teste no Google Play e na App Store ao mesmo tempo?
- Vale rodar os dois, mas nunca somar os resultados nem tratar um como confirmação do outro. São públicos diferentes, layouts de página diferentes e misturas de tráfego diferentes, e um ícone que vence em uma loja pode perder na outra sem que nada esteja errado. Cada loja é um experimento próprio, com a sua própria amostra e o seu próprio veredito.