Funil de Vendas e Teste A/A/B

A pergunta

Uma startup de produtos alimentícios queria entender o que os usuários fazem dentro do aplicativo, e as duas perguntas saem do mesmo log de eventos. A primeira é o funil de vendas: por onde a pessoa passa até comprar, quantas chegam lá e em que etapa ficam presas. A segunda é um teste A/A/B. Os designers querem trocar a fonte do aplicativo inteiro, e os gerentes acham que o desenho novo vai intimidar o usuário.

Dois grupos de controle ficaram com a fonte antiga (246 e 247) e um grupo de teste recebeu a nova (248). Ter dois controles não é redundância, é controle de qualidade: se dois braços com exatamente o mesmo tratamento já diferem entre si, a divisão está torta e nenhuma diferença contra o grupo de teste prova alguma coisa.

Os dados

Um log de 244.126 eventos com quatro colunas: nome do evento, identificador do usuário, carimbo de tempo em segundos e grupo do experimento. São cinco eventos: tela principal, ofertas, carrinho, pagamento concluído e Tutorial.

O arquivo cobre de 25/07 a 07/08/2019, mas a coleta só fica completa em 01/08. Nos sete dias anteriores o volume sobe de 11 para 2.030 eventos por dia, e em 01/08 salta para 36.141. Antes de cortar escrevi a regra: completo é o primeiro dia que alcança 50% da mediana dos dias seguintes e fica acima disso até o fim. Rodei a mesma regra de 10% a 90% e, na medida de volume, a data não saiu de 01/08. O corte custou 2.826 eventos (1,16%) e só 17 usuários (0,23%), porque quase todo mundo que aparecia antes voltou a aparecer depois. Ficaram 240.887 eventos e 7.534 usuários.

Método, e por que este método

Num log de evento, duplicado precisa de definição antes de virar contagem. Quem volta três vezes à tela principal gera três linhas legítimas. Por isso só tratei como suspeita a linha idêntica nas quatro colunas, carimbo incluído, e fixei em 1% da base o limite para remover sem investigar, antes de ver o número. Eram 413 linhas (0,17%), concentradas no Tutorial e no pagamento e nunca a mais de quatro linhas de distância no arquivo, o que tem cara de reenvio da coleta.

Para fixar a ordem do funil fui ao relógio em vez de confiar no nome das telas. Para cada usuário peguei o primeiro instante de cada evento e comparei os pares com uma régua definida antes: só existe ordem se A vier antes de B em pelo menos 90% dos casos. A tela principal passa com folga, vindo primeiro em 93,73% a 94,97% dos pares. Depois dela a sequência se desfaz. Ofertas contra carrinho dá 54,91% contra 44,14%, quase cara ou coroa, e carrinho e pagamento disparam no mesmo segundo para 49,77% dos usuários, coisa que um carimbo em segundos não separa. Por isso usei o funil estrito, em que cada etapa conta só quem tem todas as anteriores, e a conversão entre as etapas do meio deve ser lida como presença nos conjuntos, sem garantia de trajeto. O Tutorial ficou de fora: alcança 840 usuários (11,15%) e é o primeiro evento registrado de 93,45% deles. É tela de entrada.

No experimento escrevi o z-test de proporções à mão. O denominador é o total de usuários de cada grupo, e não quem chegou a alguma tela, porque filtrar por evento condicionaria a amostra a algo que a própria fonte pode ter afetado. Primeiro veio o teste A/A entre os controles, depois o 248 contra cada controle e contra os dois somados. São 20 testes, e com alfa de 5% a chance de pelo menos um falso positivo fica na casa dos 64%, então corrigi por Bonferroni para 0,0025.

Achados

Dos 7.419 usuários que abrem a tela principal, 4.482 chegam às ofertas (60,41%), 3.580 ao carrinho (79,88%) e 3.429 ao pagamento (95,78%). O funil perde 3.990 pessoas, e 2.937 delas somem no primeiro degrau. Esse degrau é o pior nas duas réguas ao mesmo tempo, em taxa e em gente, e isso não era obrigatório, porque um degrau pode ter a pior taxa e custar pouca gente quando a etapa anterior já é pequena. No outro extremo, quem chega ao carrinho quase sempre paga: são 151 pessoas perdidas na última etapa. Do primeiro evento até o pagamento chegam 45,51% da base.

O teste A/A passou. Nenhum dos cinco eventos diferiu entre 246 e 247, com menor p-valor de 0,1146, e isso autoriza o resto do experimento.

A fonte nova não mudou nada mensurável. Nenhum dos 20 testes deu significativo, nem a 5% nem com a correção, e o menor p-valor foi 0,0784, no carrinho contra o 246, com 2,48 pontos de diferença. Contra o 247 o mesmo evento cai para 0,78 ponto (p = 0,5786), e contra os controles somados o p-valor sobe para 0,1818 em vez de descer. Se a fonte tivesse efeito, ele apareceria com tamanho parecido contra os dois controles e ficaria mais nítido com o dobro da amostra. Aconteceu o contrário, então aquele 0,0784 era característica do sorteio do 246.

A decisão que habilita

Não implementar a fonte nova, e o motivo é de custo e não de estatística. O teste não encontrou efeito em direção nenhuma: nem o ganho que justificaria a troca aparece, nem o receio dos gerentes se confirma. Quando o dado não decide, decide a assimetria, e trocar a fonte do aplicativo inteiro tem custo certo e benefício não medido.

Direcionar o esforço para a passagem da tela principal para as ofertas, onde estão 2.937 dos 3.990 usuários perdidos, e não gastar energia com o pagamento, que já converte 95,78%.

Três limites acompanham a decisão. A análise fala de sete dias, não de catorze. Os braços ficaram com 1,09% de desvio, acima da régua de 1% que eu tinha escrito, embora o qui-quadrado de aderência não encontre divisão desigual (p = 0,7554). Essa folga custa um pouco de poder, então o que se sustenta é a ausência de evidência de diferença, e não a igualdade dos grupos. Por fim, o log não tem campo que diga por que alguém desistiu. A hipótese para o primeiro degrau, a de que o usuário abre o aplicativo e não encontra caminho para o catálogo, só se testa instrumentando eventos de navegação e tempo de tela, que hoje não existem.

Links

Repositório