Testes de CPP, PPO e Páginas de Listagem

CPP, PPO e Testes de Páginas de Listagem

Use isto para Páginas de Produto Personalizadas da App Store, testes de Otimização de Páginas de Produto, variantes de página de produto, páginas de campanha e planejamento de testes de conversão.

Fluxo de trabalho MCP

1. Use app-store-connect-mcp.
2. Ferramentas CPP/PPO estão planejadas para depois. Se uma ferramenta CPP/PPO existir, leia a página/teste atual antes de editar.
3. Se nenhuma ferramenta MCP CPP/PPO existir no servidor localhost ativo, produza um plano pronto para salvar e diga claramente que o preenchimento ao vivo ainda não está disponível.
4. Nunca sobrescreva metadados da página de produto padrão ao editar um rascunho de CPP/PPO, a menos que o usuário peça explicitamente.

Decida o objeto

• PPO: teste A/B nativo da App Store contra a página de produto padrão.
• CPP: página de produto direcionada para uma campanha, grupo de anúncios, público, cluster de palavras-chave, país, link de criador/parceiro ou momento sazonal.
• Experimento de Página de Listagem do Google Play: use android-aso para experimentos específicos do Play.

Fatos sobre PPO da Apple

• Testa ícones do app, capturas de tela e pré-visualizações do app.
• Até 3 tratamentos por teste.
• Você escolhe a proporção de tráfego que vê os tratamentos do teste.
• Os testes duram até 90 dias ou até serem interrompidos manualmente.
• O App Analytics pode rotular resultados quando a confiança atingir 90%.
• PPO não está disponível para páginas de produto personalizadas, páginas de produto do Apple Watch ou páginas de produto do iMessage.
• As variantes de ícone do app devem estar incluídas no binário atual do app e atender aos requisitos de ícone.

Fatos sobre CPP da Apple

• Até 70 páginas de produto personalizadas por app.
• Cada página pode variar capturas de tela, pré-visualizações do app, texto promocional e palavras-chave.
• CPPs são páginas direcionadas com URLs únicas; não são testes A/B aleatórios.
• CPPs podem ser usados em Apple Ads e podem aparecer em resultados de busca relevantes quando configurados com palavras-chave.
• Os metadados do CPP devem ser aprovados antes de ficarem visíveis.

Framework de design de testes

Escreva a hipótese antes das variantes:

Se [mudarmos], então [métrica] melhorará porque [motivo].

Bons testes:

• Mudam uma coisa principal de cada vez.
• Tornam a variante significativa o suficiente para ser detectada.
• Vinculam cada variante a uma intenção do usuário ou bloqueador de conversão.
• Definem linha de base, métrica de sucesso, local/país alvo e ganho mínimo prático.
• Decidem o limite de confiança e o tempo mínimo de execução antes do lançamento; para PPO, trate 90% de confiança como uma barra mínima prática, a menos que o usuário forneça outro padrão.
• Evitam parar cedo só porque os resultados parecem promissores.
• Documentam o resultado e o aprendizado mesmo quando o teste é inconclusivo.

Priorização de testes

Elemento	Por que testá-lo
Ícone do app	Frequentemente alto impacto na atenção em busca/listagem; requer suporte binário para testes de ícone PPO
Primeira captura de tela	Alto impacto na busca e na varredura da página de produto
Ordem das capturas de tela	Baixo esforço, esclarece a sequência de valor
Estilo/mensagem da captura de tela	Testa benefício vs recurso, prova vs fluxo, ângulo do público
Pré-visualização do app	Útil quando o movimento explica o valor melhor que imagens estáticas

Não prometa percentuais de aumento sem dados específicos do app.

Lista de verificação de estratégia

• Meta: aumento de conversão, relevância de anúncio, lançamento no mercado, campanha sazonal ou adoção de funcionalidade.
• Público: um segmento de intenção por página/tratamento.
• Fonte de tráfego: Search Ads, anúncios em redes sociais, web, influenciador, canal próprio ou teste orgânico.
• Local e país são explícitos.
• Capturas de tela e pré-visualizações do app correspondem à promessa no texto do anúncio/palavra-chave.
• Metadados não fazem afirmações não suportadas pelo app ou pelos recursos.
• As impressões/downloads existentes são suficientes para executar um teste PPO significativo, ou o plano reconhece o risco de amostra pequena.
• O desempenho do CPP é medido por visualizações de página, downloads, conversão e qualidade downstream, não apenas pelo volume de cliques.

Interpretação de resultados

Quando os resultados estiverem disponíveis:

• Verifique confiança, taxa de conversão e intervalo/incerteza de confiança.
• Compare por território, tipo de fonte, dispositivo e localização quando disponível.
• Para CPP, compare qualidade do tráfego e eventos downstream, assinaturas ou vendas, se disponíveis.
• Decida: aplicar vencedor, iterar, manter atual ou executar nova hipótese.
• Não aplique um tratamento se os resultados forem inconclusivos ou se o segmento vencedor não for o segmento alvo.

Saída

# Plano de Teste de Página de Listagem

Tipo:
App:
País:
Local:
Fonte de tráfego:
Meta:
Linha de base:
Métrica de sucesso:

## Hipótese
Se ..., então ..., porque ...

## Estado atual
| Campo | Valor | Notas |
|---|---|---|

## Variantes
| Variante | Mudança | Hipótese | Recursos necessários |
|---|---|---|---|

## Sequência de captura de tela/pré-visualização do app
| Posição | Mensagem | Direção visual | Recurso fonte/status |
|---:|---|---|---|

## Amostragem e tempo
- Impressões diárias:
- Amostra necessária:
- Duração estimada:
- Risco de amostra pequena:

## Interpretação dos resultados
| Variante | Conversão | Confiança | Decisão |
|---|---:|---|---|

## Roteiro
| Mês | Teste | Por quê |
|---|---|---|

## Validação
- Objeto correto selecionado: PPO/CPP/Experimento Play:
- Um público claro:
- Corresponde à promessa do anúncio/palavra-chave:
- Local pronto:
- Recursos disponíveis:
- Revisão/envio necessários:
- Afirmações não suportadas removidas:
- Preenchimento MCP disponível:

Regras

• Mantenha cada variante CPP/PPO focada em uma promessa.
• Não duplique a página padrão sem uma hipótese significativa.
• Não invente métricas de desempenho, dados de público ou resultados de Search Ads.
• Para PPO, defina a linha de base e a métrica de sucesso antes de escrever campos.
• Para CPP, não chame de teste A/B a menos que o tráfego seja randomizado e medido externamente.
• Para experimentos do Play Store, use android-aso.