iOS15: teste A/B da sua página de produto

Como a Apple anunciou uma série de mudanças e melhorias futuras na App Store que ajudarão os desenvolvedores a direcionar melhor seus aplicativos para os usuários, fazer com que seus aplicativos sejam descobertos por mais pessoas e até mesmo destacar que tipo de eventos estão acontecendo em seus aplicativos para atrair novos usuários para baixe aplicativos e incentive os usuários existentes a retornar. A App Store permitirá que você teste A/B os elementos visuais das páginas de produtos do seu aplicativo para tentar obter melhores resultados e melhorar a taxa de conversão de download do aplicativo.

O teste A/B da App Store ajudará você a melhorar sua estratégia de ASO, você poderá experimentar diferentes ícones de aplicativos, capturas de tela e visualizações (vídeos) em suas páginas de produtos da App Store. Você também poderá comparar o desempenho das páginas de produtos para ver o que converte melhor.

Como utilizar o teste A/B para novos recursos do iOS15?

O novo recurso de teste A/B da App Store permitirá que você teste até 3 elementos diferentes. Você verá os resultados dos principais KPIs de ASO na seção App Analytics do App Store Connect, como o número de impressões ou as taxas de conversão. Você poderá compará-los com o desempenho da página original do produto.

No entanto, a página de produto personalizada (CPP) não incluirá testes A/B nativos, mas permitirá que as equipes de marketing móvel executem os testes manualmente. Como lembrete, sob a nova configuração, se você utilizar uma página de produto personalizada (CPP) e direcionar todo o tráfego pago de UA para uma das 35 páginas de produto personalizadas disponíveis, a parte restante do tráfego, o fim natural (tráfego de navegação e pesquisa) vai parar na sua página de produto padrão.

Para saber mais sobre o crescimento móvel do iOS15, consulte " Como os novos recursos do iOS15 impulsionam o crescimento móvel? " de nossos artigos anteriores.

Clique em " Saiba mais " para impulsionar seus negócios de aplicativos e jogos com o serviço de promoção de aplicativos ASO World agora.

Otimização de página de produto (PPO)

Em breve, os desenvolvedores terão uma maneira simplificada de testar as alterações em seus conjuntos de ideias. Historicamente, os desenvolvedores iOS precisavam implantar totalmente as alterações criativas na iOS App Store e, em seguida, medir o tráfego antes e depois da implantação. Esse processo nem sempre fornece o melhor insight, pois as tendências e o tráfego podem mudar significativamente desde o período de pré-implantação até o período pós-implantação. A otimização da página do produto permitirá que o teste A/B seja realizado em tempo real diretamente na página do produto padrão do aplicativo.

Usando a Otimização de página de produto, os desenvolvedores podem testar variações de ícones de aplicativos, capturas de tela e vídeos de visualização. A Apple permitirá que três tratamentos diferentes sejam aplicados de uma só vez, com duração máxima de 90 dias para cada teste.

Embora possa ser tentador testar o maior número possível de alterações, a Apple recomenda limitar o número de alterações criativas por teste - uma prática recomendada para qualquer iteração de teste. Ao limitar as variáveis, é mais fácil isolar quais alterações específicas levarão aos melhores resultados. Para ver o desempenho e compará-lo com uma linha de base, os desenvolvedores podem acessar esses testes no App Analytics.

Página de produto personalizada (CPP)

Um novo recurso empolgante para desenvolvedores por trás do iOS 15 são as Páginas de Produto Personalizadas. As páginas de produtos personalizados são uma nova maneira de selecionar listas para que sejam relevantes em diferentes demografias ao mesmo tempo. Essa nova ferramenta permitirá que os desenvolvedores mostrem o posicionamento mais relevante para diferentes grupos de usuários, todos apontando para o mesmo aplicativo.

A Apple permitirá até 35 páginas personalizadas exclusivas de produtos, cada uma fornecendo informações sobre vários recursos por meio de diferentes capturas de tela, visualizações de aplicativos e texto promocional. Os desenvolvedores podem direcionar o tráfego para a página de produto apropriada usando URLs exclusivos que serão colocados em anúncios relevantes ou depoimentos de terceiros.

Os dados de desempenho para páginas de produtos personalizados também estarão disponíveis no App Analytics. A visualização de página segmentada fornecerá dados acionáveis ​​sobre impressões, downloads de aplicativos, taxa de conversão de instalação de aplicativos e taxas de retenção.

Análise de aplicativos

Além de fornecer aos desenvolvedores mais ferramentas para otimizar seu desempenho, as novas métricas permitirão que eles entendam o desempenho de maneiras que o App Analytics não podia fornecer antes. Ao contrário do Google, que está mudando muitas de suas métricas relatadas com o novo Google Play Developer Console em 2020, a Apple manterá métricas familiares, como o número de impressões e unidades de aplicativos, enquanto adiciona novas.

Os desenvolvedores agora terão um painel de pré-encomenda dedicado separado por métricas familiares, como território e tipo de dispositivo - o tipo de dispositivo agora inclui macOS para aplicativos compatíveis. Na guia de métricas, as encomendas podem ser visualizadas em um gráfico de linhas ao longo do tempo para ver o engajamento no início da encomenda até o dia anterior ao lançamento.

A receita é outra nova métrica que os desenvolvedores podem visualizar por meio do App Analytics, bem como "Vendas" e "Compras no aplicativo". Mais informações sobre como os aplicativos geram lucros podem ajudar os desenvolvedores a entender melhor como otimizar para aumentar as taxas de compra.

A Apple também adicionará "Atualizações" e "Redownloads" ao App Analytics, ambas métricas não relatadas anteriormente. Isso permitirá que os desenvolvedores visualizem não apenas os primeiros downloads por meio de "Unidades de aplicativos", mas também o total de downloads e possam distinguir entre usuários novos e recorrentes. Em última análise, os desenvolvedores terão insights não apenas sobre o envolvimento de novos usuários, mas também sobre o envolvimento contínuo dos usuários existentes por meio de atualizações e downloads de novos usuários existentes.

Para saber mais sobre a estratégia de engajamento do usuário, você pode conferir " Como a estratégia de engajamento do usuário móvel impulsiona seu negócio de aplicativos ?" de nossos artigos anteriores.

Teste A/B: iOS15 vs. Play Store

Desde maio de 2015, a Google Play Store permite que os desenvolvedores realizem testes A/B por meio do Google Play Experiments, fornecendo aos desenvolvedores uma ferramenta valiosa para desenvolver sua estratégia de otimização da loja de aplicativos. Os testes A/B estarão disponíveis no iOS15 em breve para que os desenvolvedores do iOS não precisem mais implantar novas versões e comparar métricas de antes e depois para medir como as alterações nas páginas de produtos afetam a taxa de conversão da página do produto.

No entanto, por mais empolgante que pareça, a plataforma de testes A/B da Apple não será idêntica à do Google. As incertezas acarretadas podem facilmente levar a muitas complicações potenciais. É importante abordá-los com antecedência e planejar adequadamente com antecedência. A equipe técnica da ASOWorld espera 7 diferenças fundamentais abaixo para você se preparar.

1. Disponibilidade de dados

O teste A/B é um método de pesquisa quantitativa. Isso significa que as estatísticas por trás de cada teste são seu sangue vital. Se você coletar e analisar dados suficientes, obterá resultados de testes confiáveis ​​para validar ou rejeitar cientificamente certas hipóteses. As ideias por trás dessas hipóteses são, em última análise, o que impulsiona o CRO. É por isso que todo o CRO mudará quando o teste A/B na App Store tiver uma quantidade e forma de dados diferentes em comparação com a Play Store.

Aqui estão as diferenças mais importantes que você deve estar ciente.

• Significado estatístico

O Google fornece um nível de significância estatística de 90% para os resultados dos testes, enquanto permanece um mistério se a Apple fornecerá algo comparável. De fato, não se sabe se eles fornecerão intervalos de confiança, pois o anúncio deles não menciona esse tópico (ainda).

• Histórico de desempenho

O Google mostra um gráfico que mapeia continuamente o tempo limite de execução de cada variante de teste. Você pode optar por visualizar o desempenho anterior para obter informações mais detalhadas, se necessário.

A Apple, por outro lado, não tem evidências de que eles ofereçam um recurso semelhante. Eles apenas mencionam que você pode "comparar o desempenho [das variantes de teste] com a página original do produto durante todo o teste". Ainda não foi determinado se essa comparação se aplica ao desempenho atual e ao passado.

• Completude dos dados de desempenho

O Google mostra apenas o número de instalações, instalações dimensionadas e diferenças de taxa de conversão (CVR) entre as variantes de teste. Portanto, você só pode estimar o quão bem ou mal eles se comparam. Em vez disso, a Apple exibe o tamanho do tráfego (impressões) e o CVR exato para cada variante em cima das diferenças (melhorias) do CVR. Isso significa que cabe a você investigar as versões individuais ou comparar entre elas.

2. Seleção de ativos

No Google Play, todos os recursos localizáveis, exceto o título/nome do aplicativo, estão qualificados para testes A/B. Mais importante, eles incluem elementos visuais e textuais. Isso fornece capacidade suficiente para uma estratégia de CRO extremamente versátil.

Por outro lado, apenas ativos visuais na App Store foram identificados como elegíveis para testes A/B. Eles são Ícone, Capturas de tela e Pré-visualização (Vídeos). Nenhum insight adicional foi fornecido sobre ativos de texto.

No entanto, observando os diferentes recursos permitidos na Otimização da página do produto e nas páginas personalizadas do produto, pode não haver nenhum. Especificamente, a Apple menciona o texto promocional associado ao último, mas não ao primeiro. Aqui estão os fatores a serem considerados para este fato.

• A Apple considerou ativos de texto e decidiu permitir texto promocional personalizado. É improvável que eles os tenham esquecido no desenvolvimento ou lançamento dos recursos do iOS 15. Esta é uma evidência de que a Apple ignorou intencionalmente os testes A/B de ativos de texto.

• A Apple anunciou duas páginas de produtos otimizadas e personalizadas para páginas de produtos na mesma seção na WWDC21, após a WWDC21, e em seu site. No entanto, o texto promocional está listado especificamente para o segundo recurso. Esta é outra evidência de que a Apple omitiu intencionalmente os ativos de texto dos testes A/B.

• Portanto, há pelo menos duas evidências de que a Apple não nos permitirá testar ativos de texto - pelo menos não imediatamente com o iOS 15.

Claro, isso ainda não foi confirmado. No entanto, em caso de dúvida, é mais seguro se preparar para o pior cenário. Se isso for verdade, você terá uma seleção muito mais restrita de ativos para escolher nos testes A/B na App Store em comparação com a Play Store.

3. Personalização

Isso também está relacionado à relação entre a presença da loja de aplicativos personalizada e os testes A/B: embora você certamente possa executar experimentos em listagens personalizadas da Play Store, ainda é um desafio saber se o mesmo é verdade nas páginas de produtos personalizados. Nesse caso, as possibilidades para iOS CRO seriam bastante expandidas, por exemplo, usando algo como "otimização de página de produto personalizada" - mas isso é um grande "se".

Na verdade, algumas evidências podem sugerir que é improvável que isso aconteça. Conforme mencionado anteriormente, o texto promocional demonstra a desconexão entre as páginas personalizadas do produto e a otimização da página do produto, pois pode ser personalizado, mas não testado A/B. Outra prova é o App Icon, que é testável, mas não personalizável. Portanto, se o teste A/B pudesse ser executado em páginas de produtos personalizados, a loja de aplicativos se tornaria intoleravelmente inconsistente.

Aqui está o problema: não parece que a Apple permite. Isso significa que eles simplesmente não permitem nenhum cruzamento entre os dois recursos. Portanto, é seguro dizer que não podemos esperar testes A/B de páginas de produtos personalizados.

Embora o texto e os ícones promocionais sejam a diferença entre os dois recursos, eles se misturam em capturas de tela e visualizações. Com alguma sorte, a Apple nos permitirá testar um desses dois ativos, ou ambos, em uma página de produto personalizada. Por mais improvável que esse cenário pareça, ainda é uma possibilidade lógica que não deve ser descartada prematuramente.

4. Teste de ícones

Um ícone é um importante ativo visual de um aplicativo que expressa seu senso de identidade. Se alguma coisa, deve ser um ativo consistente nas lojas de aplicativos. Infelizmente, esse não é o caso.
Primeiro, você pode fazer upload de novos ícones para teste apenas no Google Play, mas não na App Store. A Apple exigirá que todas as variantes do ícone (no dispositivo e na loja) sejam adicionadas ao binário do aplicativo com antecedência e revisadas com a nova versão do aplicativo. Portanto, se forem rejeitados ou atrasados, os testes A/B serão afetados.

Em segundo lugar, novamente relacionado aos requisitos binários do aplicativo, enquanto o Google permite alterações independentes entre ativos no dispositivo e na loja, a Apple impõe algum nível de dependência de ícones entre eles. Especificamente, se você aplicar uma variante de ícone da App Store por meio da Otimização de página de produto, a variante de ícone correspondente no dispositivo substituirá automaticamente o ícone original.

5. Escalabilidade

A localização é uma parte importante do ASO, especialmente para CROs, e é por isso que é essencial poder executar testes A/B em páginas de produtos localizadas. Mais importante ainda, quanto mais testes de localização você puder executar ao mesmo tempo, mais eficiente será em escalar seu CRO geral.

No Google Play, são permitidos até cinco desses testes (sem incluir detalhes personalizados do produto). Na Apple App Store, o número é desconhecido. Se for o mesmo, você pode dimensionar o CRO da mesma maneira nas duas lojas, para que não exija muitos ajustes. Por outro lado, se uma loja permitir que um número significativamente maior de testes sejam executados simultaneamente do que a outra, você precisará planejar com antecedência e considerar as diferenças entre elas para tomar uma decisão informada.

Por que isso importa? Dois fatores.

Em um padrão ASO

Se você puder atualizar seu CRO para sua loja de aplicativos, poderá aprender rapidamente o que funciona e o que não funciona. Quanto mais você aprender, mais informadas serão suas decisões. É por isso que a escalabilidade diferente pode levar a diferentes níveis de desempenho do CRO. Em última análise, a produção de ativos, recursos humanos, tempo e esforço terão valores diferentes entre as lojas de aplicativos. Eles devem então ser gerenciados de maneiras diferentes.

Em ASOs incomuns, como eventos sazonais ou casos especiais, como pandemias de COVID-19.

Imagine que você tenha 3 meses para testar 10 localizações de todos os ativos antes de lançar uma campanha crítica e relevante. Para a mesma ideia ou hipótese, você precisaria de duas rodadas de 5 experimentos de localização na Play Store para cobrir todo o conteúdo. Se cada rodada levar três semanas para produzir resultados estatisticamente significativos, você precisará de 1,5 mês para concluir uma série completa.

Isso significa que um prazo de três meses permitiria testar duas ideias antes do lançamento. Se a Apple permitir que menos de cinco testes sejam executados simultaneamente nas mesmas condições, 10 localizações por três meses é demais. Você precisa testar menos ideias, precisa de menos localizações ou precisa de mais tempo.

6. Flexibilidade de configuração

O grau de flexibilidade que você tem na configuração de testes A/B também varia de uma loja de aplicativos para outra. Na verdade, a diferença será causada por dois fatores.

Ativos individuais

Enquanto o Google permite testes A/B para ativos visuais e de texto, a Apple só permite que você teste o primeiro. Isso significa que, mesmo que você possa transformar uma ideia, conceito, mensagem ou hipótese em uma cópia atraente, você não pode configurá-la como um teste. Isso é apenas metade da flexibilidade do Google Play.

Combinações de ativos

As configurações de teste no Google Play podem se tornar mais flexíveis quando vários recursos são combinados. Especificamente, você pode ter experimentos de combinação de texto-texto, visual-visual ou visual-texto. Na App Store, também é possível combinar vários ativos em um teste (caso contrário, a Apple não sugeriria limitá-los). Mas a melhor coisa que você pode fazer é configurar apenas experimentos de combinação visual-visual.

Então, o que fazemos quando não somos tão flexíveis? Adicione profundidade. Não usar ativos de texto para teste significa testar mais com ativos visuais.

Para saber mais sobre a página de produto personalizada do iOS15, você pode verificar " Como preparar suas páginas de produtos personalizados (CPPs) da App Store para iOS 15 ASO? " de nossos artigos anteriores.

7. Liberdade Criativa

O teste A/B envolve mais do que apenas os fatores técnicos que afetam o CRO. Além do design, configuração e premissas do teste, ele também deve abranger ideias, conceitos e histórias criativas. Isso é o que se traduz em ativos tangíveis da loja de aplicativos, que você deve carregar antes que qualquer teste possa ser executado. Portanto, é importante ter liberdade criativa suficiente para permitir que ideias ousadas e inovadoras sejam testadas e, por sua vez, contribuam para o aprimoramento do CVR.

É claro que a Apple e o Google permitem graus variados dessa liberdade criativa. Na Play Store, os recursos de teste nunca parecem estar sujeitos ao escrutínio do Google. Todas as políticas e diretrizes de metadados se aplicam aos detalhes do produto, não aos experimentos de detalhes do produto. Portanto, é seguro dizer que, desde que você não aplique uma variante "arriscada", poderá testar quase qualquer coisa com qualquer ativo qualificado sem restrições.

Como configurar o teste A/B na App Store

Aprender é mais importante do que testar

A separação entre história e storytelling não é possível na App Store. De acordo com o anúncio da Apple, todas as variantes de teste separadas serão analisadas de forma independente. Se você testar uma ideia corajosa e ousada, mas arriscada com eles e eles forem rejeitados, você nunca saberá se a ideia funcionou. Você só saberá que a implementação não. Além disso, o cronograma de testes será adiado. É por isso que você precisa lidar com menos liberdade criativa nos testes A/B da App Store em comparação com a Play Store.

Sua estratégia de CRO deve ser mais conservadora na App Store e mais agressiva na Play Store. Isso significa:

• Explorando ideias ousadas no Android e integrando-as no iOS

Experimentos de detalhes de mercadorias devem ser um campo de testes para ideias ousadas e arriscadas, porque permitem um maior grau de liberdade criativa. Horas extras, você pode apontar relativamente quais são bons para o CRO. Em seguida, você pode testar e aprender quais métodos estão disponíveis para apresentar essas ideias publicamente - qualquer método que o Google permitir que você use.

Esse aprendizado pode ser consolidado ainda mais com a otimização da página do produto. Se você achar que o Google adota a iteração de ativos, dadas suas diretrizes e políticas semelhantes, a Apple provavelmente também a adotará. É assim que você pode testar ideias ousadas na App Store com risco mínimo de rejeição.

• Executando testes no iOS passo a passo de ideias seguras a ousadas

Enquanto espera que os testes A/B da Play Store "liderem o caminho", os testes A/B da App Store podem ser executados de forma independente para "encontrar o caminho. Comece com ideias seguras, depois passe para ideias mais arriscadas até chegar à "área restrita . O CRO levará mais tempo, mas pelo menos você não ficará preso esperando pelos resultados dos testes do Android ou será enganado por suposições não testadas.

Chaves a serem lembradas ao realizar testes A/B

Alocação de público-alvo entre a versão atual e as variantes. Ao decidir a porção de tráfego a ser alocada para cada variante, tenha em mente sua taxa de conversão atual, a hipótese a ser testada, os elementos envolvidos e a significância estatística (atualmente 90% nas experiências do Google Play).

Divida a duração do teste. Deixe o teste ser executado por pelo menos sete dias para evitar picos sazonais que possam afetar seus resultados. Os testes devem ser executados até que um público potencial considerável entre em todas as variantes do teste.

Instalação mínima para cada variante. Para obter dados importantes sobre os resultados de desempenho dos testes a/b, você precisa prestar atenção à quantidade necessária de instalações. Isso está altamente correlacionado com a taxa de instalação diária do aplicativo.

Localização de teste . É altamente recomendável localizar seus testes A/B em um país específico. Experimentos mundiais/globais podem ser enganosos, pois cada país tem um desempenho criativo diferente.

Mudanças fechadas podem não levar a muito aprendizado. No entanto, todos os elementos da sua ideia devem ser testados para melhorar continuamente a página da sua loja.

Resumo

Esses são apenas alguns dos novos recursos e capacidades anunciados na WWDC21. O teste A/B tem sido historicamente uma tarefa mais complexa na iOS App Store do que os recursos experimentais do Google Play - essas novas ferramentas serão as melhorias que os desenvolvedores do iOS esperavam.

Os dados de desempenho acessíveis a partir do App Analytics, da otimização da página do produto e das páginas personalizadas do produto, bem como a análise do usuário e os dados de atividade, fornecerão aos desenvolvedores as informações de que precisam para continuar crescendo.

Testamos para saber quais ideias podem melhorar o CVR e, em seguida, aprendemos como implementar essas ideias sem violar a política. Como listamos acima, você pode planejar com antecedência o modelo de teste A/B do iOS15.