Teste A/B de Mensagem In-App: o Que Testar e Medir

Mensagem in-app, ou seja, tooltip, modal, banner, painel lateral, checklist e anúncio mostrados a alguém que já está dentro do produto, é uma das superfícies de maior alavancagem num programa de growth experimentation para SaaS e uma das mais fáceis de errar estatisticamente. A armadilha não é o texto da mensagem, é decidir o que medir e quanta paciência o teste realmente exige: a maior parte das mensagens in-app só qualifica uma fatia estreita de usuários que chegaram a um estado específico, o que significa amostra menor, espera maior e custo muito mais alto de espiar cedo do que num teste típico de landing page. Este guia cobre o que conta como mensagem in-app, quando o teste formal se paga em vez de simplesmente publicar, como escolher uma métrica que sobrevive ao escrutínio e o que muda na estatística quando o público está tão fundo no funil.

O que conta como mensagem in-app: uma taxonomia de trabalho

Mensagem in-app cobre um espectro que vai do passivo ao bloqueante, e o formato escolhido já muda o tamanho de efeito que se pode esperar e quanto atrito a mensagem adiciona ao momento que ela interrompe. Segundo uma taxonomia da Appcues sobre os formatos comuns de notificação dentro do produto, o mesmo objetivo de fundo (fazer o usuário notar e agir sobre algo) se expressa em níveis muito diferentes de interrupção:

Dois formatos merecem ser nomeados explicitamente porque aparecem o tempo todo em backlog de growth e quase nunca nas taxonomias: orientação em tela vazia (a mensagem mostrada dentro de uma tela que ainda não tem dado, funcionalmente um tooltip ancorado numa tela em branco) e ajuda em contexto (tooltip ou bloco disponível o tempo todo, acionado pelo usuário e não pelo produto). Os dois contam como mensagem in-app para efeito de teste, apenas são disparados de forma diferente de um convite proativo.

Quando o teste formal se paga em vez de só publicar

Nem toda mensagem in-app precisa de teste controlado. O fator decisivo é o custo de estar errado, não o tamanho do time nem a facilidade de construir a mudança.

• Teste quando a mensagem vai para toda a base ativa, quando ela toca um momento com receita atrelada (convite de upgrade, aviso de paywall), ou quando a escolha intuitiva (mais orientação é sempre melhor) tem um modo de falha plausível, como enterrar um comportamento padrão que já funcionava atrás de um aviso desnecessário.
• Pule o teste formal num ajuste pequeno e reversível de texto numa superfície interna de pouco tráfego, ou num anúncio pontual sobre um recurso que só vai existir por algumas semanas, onde acompanhar uma tendência simples de antes e depois é proporcional ao que está em jogo.

A linha entre os dois é a mesma coberta no guia completo de growth experimentation: impacto, confiança e esforço. Uma mensagem in-app com impacto alto e incerteza real sobre o resultado merece o rigor estatístico que este artigo percorre; uma de impacto baixo não.

Fuja da métrica de vaidade: vista, clicada ou comportamento mudado

O erro mais comum em teste de mensagem in-app espelha o do guia sobre teste A/B de onboarding em SaaS: otimizar pelo que é fácil de medir (a mensagem foi vista, a mensagem foi clicada) em vez do que a mensagem foi construída para causar. A orientação da Amplitude sobre mensagem in-app é explícita sobre essa lacuna, argumentando que a medida real de sucesso é se as mensagens levam a mais adoção do produto, mais retenção e mais conversão, e não o engajamento com a superfície em si. A mesma fonte observa que mensagens in-app alcançam taxas de abertura muito altas simplesmente porque o usuário já está dentro do produto olhando a tela, o que torna “vista” um sinal especialmente fraco de sucesso quando isolado.

Duas perguntas separam uma métrica real de uma de vaidade, para qualquer mensagem in-app: que ação específica, fora da própria mensagem, o usuário deveria tomar por ter visto ela, e essa ação, em alguma janela posterior de medição, aparece como mais retenção, mais uso ou mais receita comparada a quem nunca viu a mensagem. Se nenhuma das duas tem resposta clara antes de o teste começar, a mensagem ainda não está pronta para ser testada, está pronta para virar hipótese primeiro, seguindo a estrutura do guia de como escrever uma hipótese de teste A/B.

A dobra estatística: público pequeno e fundo no funil

Aqui está a parte que a maioria dos conselhos sobre mensagem in-app ignora por completo. Como a mensagem normalmente só qualifica quem chegou a um estado específico (abriu um painel vazio, bateu num limite de uso, ficou numa tela pela primeira vez), o público semanal disponível para o teste é uma fração pequena do tráfego total do produto, exatamente o mesmo problema estatístico coberto no guia de growth experimentation para estágios fundos de PLG em geral. A matemática em si não muda (é o mesmo teste z de duas proporções detalhado no guia de significância estatística), mas a consequência prática é mais aguda aqui do que em quase qualquer outro lugar de um programa de growth: um público qualificado pequeno deixa o teste mais lento e torna muito mais tentador espiar um resultado inicial e ruidoso.

Exemplo trabalhado: um convite de upgrade dentro do produto

Suponha que um SaaS mostre um convite de upgrade a usuários em trial no momento em que eles batem num limite específico de uso. A taxa atual de clique até upgrade entre quem vê esse convite é de 9%, e o time quer detectar uma melhora relativa de 30% numa versão redesenhada do convite (de 9% para cerca de 11,7%), o menor ganho que justifica o esforço de reconstruí-lo. Com 95% de confiança e 80% de poder, bilateral, o mesmo motor de amostra usado em todo este blog devolve 1.997 usuários por variação.

O segmento qualificado (usuários em trial que batem naquele limite) recebe cerca de 140 usuários por semana. Nesse volume, um teste de duas variações precisa de aproximadamente 200 dias, quase sete meses, para acumular a amostra que a conta exige. Esse é o imposto do funil fundo: o mesmo rigor estatístico de qualquer teste de landing page, aplicado a um público que chega muito mais devagar.

Cole os mesmos números na calculadora abaixo para conferir o veredito quando o teste terminar:

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

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.

Ao fim desses cerca de 200 dias, digamos que o controle registrou 180 upgrades em 1.997 usuários expostos (9,01%) e o convite redesenhado registrou 234 em 1.997 (11,72%). Rodando os números exatos no mesmo motor de significância: valor-p bilateral de aproximadamente 0,0051, estatística z de cerca de 2,80, lift relativo de 30,0% e intervalo de confiança de 95% para a diferença de aproximadamente +0,8 a +4,6 pontos percentuais. Como o intervalo inteiro fica acima de zero, o resultado é significativo, com o convite redesenhado como vencedor, exatamente o que colar esses valores na calculadora acima deve confirmar.

Por que a taxa base, e não só o tamanho do público, decide a espera

O mesmo efeito relativo exige uma amostra muito diferente conforme a taxa de conversão base do segmento qualificado. Mantendo a meta fixa em 30% relativo, 95% de confiança, 80% de poder, bilateral:

Taxa base do segmento qualificado	Amostra necessária por variação
3%	6.455
5%	3.780
7%	2.634
9% (este exemplo)	1.997
12%	1.440
15%	1.106
20%	772

O padrão: uma taxa base mais baixa, comum em públicos estreitos e fundos no funil como o do convite de upgrade acima, exige amostra muito maior para detectar o mesmo efeito relativo, porque a diferença absoluta entre as duas taxas encolhe junto com a base. Uma mensagem mostrada a um segmento que converte a 3% precisa de mais de oito vezes a amostra de um que converte a 20%, para a mesma meta de 30% relativo.

Armadilhas de segmentação

A forma mais comum de um time sabotar um teste de mensagem in-app antes de começar é escolher um segmento estreito demais para alcançar significância em tempo razoável, e descobrir o problema só depois de o teste já estar rodando há semanas. Compare o mesmo teste em dois tamanhos de segmento, mantendo tudo o mais (taxa base, efeito mínimo, amostra necessária) idêntico ao exemplo trabalhado acima:

Antes de fechar a regra de segmentação de um teste de mensagem in-app, estime o volume semanal do segmento como ele vai ser de fato definido no lançamento, não o volume do grupo mais amplo de onde ele saiu. Uma regra que soa razoável numa reunião de planejamento (“mostre só para contas perto do limite de uso no plano Pro”) pode cortar em silêncio 70% ou mais do público qualificado em comparação com “contas perto do limite de uso”, transformando um teste de duzentos dias num de dois anos. Quando a conta honesta diz que um segmento não alcança significância em prazo útil, as saídas são as mesmas de qualquer teste subdimensionado de funil fundo: ampliar o segmento, aceitar um efeito mínimo maior (só efeitos grandes vão registrar) ou aceitar que esta mensagem específica não é candidata a teste formal com o tráfego disponível hoje.

Frequência e efeitos de fadiga de mensagem

Um problema de frequência pode invalidar em silêncio um teste bem desenhado no resto. Segundo a orientação da Braze sobre limite de frequência, o excesso sustentado de mensagens corrói a boa vontade que mantém o usuário engajado. Separadamente, fornecedores de mensagem in-app costumam citar um teto prático de cerca de uma a duas mensagens por usuário por sessão, com uma janela mínima de silêncio antes da próxima. Dois modos de falha aparecem especificamente num contexto de teste:

• A fadiga confunde a comparação. Se o volume geral de mensagens muda por razões alheias ao teste (um lançamento acrescenta três anúncios in-app no meio do caminho), a taxa de dispensa e a atenção podem mudar nos dois braços ao mesmo tempo, e a mudança acaba atribuída à variação testada em vez do ruído extra ao redor dela.
• A fadiga distorce o que “vista” significa. Um usuário anestesiado por mensagens frequentes dispensa tudo mais rápido, o que pode fazer métricas de clique e de abertura piorarem ao longo de um teste longo mesmo sem nenhuma queda de qualidade na mensagem, mais uma razão para a métrica que decide o teste ser a ação seguinte, e não o engajamento com a mensagem.

A correção é de processo, não de estatística: mantenha o volume total de mensagens in-app aproximadamente constante nos dois braços durante o teste, e trate um pico de outras mensagens no meio do caminho como motivo para estender o teste ou descartar a janela afetada, a mesma disciplina que vale para qualquer confundimento que chega depois da aleatorização.

Quando usar um bandit

Uma divisão fixa de 50/50 nem sempre é o mecanismo certo para uma mensagem in-app. A comparação completa entre multi-armed bandits e teste A/B trata da troca em profundidade, mas a versão curta para mensagem in-app é esta: o bandit se paga quando a mensagem é de vida curta (um banner sazonal, um anúncio pontual que será aposentado em poucas semanas) e o custo de continuar mostrando a variação mais fraca durante toda a duração da divisão fixa supera o valor de um veredito limpo de significância. Uma mensagem feita para ficar no produto a longo prazo, como um convite de upgrade recorrente ou uma orientação permanente de tela vazia, costuma se beneficiar mais de um teste de divisão fixa que termina com uma resposta real e reutilizável sobre qual versão funciona e por quê.

Checklist: quais mensagens testar primeiro

Nem toda mensagem in-app merece a mesma prioridade num backlog de growth. Um ponto de partida neutro, em ordem aproximadamente decrescente de relação entre impacto e esforço para um SaaS self-serve:

Tipo de mensagem	Onde costuma disparar	Qual métrica “real” acompanhar
Convite de upgrade	Perto de um limite de uso, de um recurso bloqueado ou de uma fronteira de plano	Conversão de trial para pago ou upgrade de plano, não o clique no convite
Descoberta de recurso	Depois que o usuário conclui uma tarefa adjacente que prevê adoção do recurso promovido	Adoção do recurso em 7 ou 14 dias, não impressões do aviso
Orientação em tela vazia	Na primeira vez em que o usuário chega a uma tela ainda sem dado	Conclusão da primeira ação que preenche aquela tela, não tempo olhando para ela
Ajuda em contexto (tooltip, bloco)	Acionada pelo usuário, perto de um controle específico	Taxa de conclusão da tarefa a que a ajuda estava atrelada, não a taxa de abertura da ajuda

Faça isso automático na Donnu

A parte difícil de um teste de mensagem in-app raramente é a mensagem, é rodar estatística honesta sobre um público que já nasce pequeno porque o funil o filtrou antes de a mensagem sequer disparar. É exatamente aí que a tentação de espiar o painel e declarar vencedor cedo fica mais forte, e exatamente aí que fadiga de mensagem e segmento estreito demais podem estragar o resultado sem ninguém perceber até os números serem comparados lado a lado. A Donnu A/B é uma ferramenta bayesiana e client-side de teste A/B para páginas web e interface de produto: dimensiona o teste antes de ele começar, mostra com honestidade quanto tempo a mais um resultado de baixo volume ainda precisa, e só declara vencedor quando a estatística sustenta, o mesmo motor usado em todos os números deste artigo.

Comece um teste grátis de 14 dias e leve essa disciplina para o próximo convite de upgrade, orientação de tela vazia ou anúncio de recurso que você ia publicar no palpite. Para a base estatística por trás de cada número deste artigo, veja o guia de significância estatística e a calculadora de tamanho de amostra.

Referências

• Appcues. In-App Notifications: 8 Types, Best Practices, and Examples. appcues.com/blog/in-app-notifications.
• Braze. Frequency Capping: What It Is, How It Works and Best Practices. braze.com/resources/articles/whats-frequency-capping.
• Amplitude. In-App Messaging: What It Is and How to Do It. amplitude.com/explore/product/in-app-messaging.
• Miller, E. How Not To Run an A/B Test (o problema do peeking), 2010. evanmiller.org.

Leia também

Continue pelos fundamentos em que esta peça se apoia: o guia completo de growth experimentation para SaaS, o teste A/B de onboarding em SaaS e o teste A/B do fluxo de trial para pago. Para o risco de espiar o resultado que este artigo insiste em citar, veja o problema do peeking em testes A/B. Versão em inglês: In-App Messaging A/B Tests.