Projeto Final, parte 2: Teste A/B e SQL

A pergunta

A sprint final da TripleTen teve quatro entregas. A decomposição e o projeto da Olist estão na parte 1. Aqui ficam as outras duas, que são independentes entre si: um teste A/B de uma loja virtual e uma análise em SQL de um banco de livros. Cada uma tem o seu bloco abaixo, com dados, método, achados e decisão.

Teste A/B do sistema de recomendações

A pergunta do teste

A loja mudou a experiência de compra de parte dos novos usuários da União Europeia e esperava que o grupo B convertesse pelo menos 10% a mais que o A, nos 14 dias depois do cadastro, em três etapas: página do produto, carrinho e compra. O gráfico acima mostra o que aconteceu: o B ficou abaixo do A nas três.

Os dados, e o que o desenho do teste escondia

Quatro arquivos: 14 campanhas de marketing, 58.703 cadastros, 423.761 eventos e 14.525 registros de participantes. Antes de testar qualquer coisa, conferi se o teste seguiu a especificação. Não seguiu:

• Outro teste ao mesmo tempo. 887 participantes (24,14%) estavam também no interface_eu_test, que o enunciado não citava. Tirei só os 431 que receberam a mudança daquele teste: os outros 456 estavam no controle de lá e não viram nada diferente.
• Gente de fora da EU. 194 participantes eram de outras regiões e saíram.
• Metade do tamanho e grupos desiguais. Ficaram 3.050 participantes, 50,83% dos 6.000 previstos, com 74,72% no A e 25,28% no B. O qui-quadrado contra a divisão 50/50 dá p = 3,64e-164: o sorteio não foi meio a meio.
• Dados que acabam antes. O último evento é de 30/12, e não 01/01, e 1.170 participantes (38,36%) não tiveram os 14 dias inteiros, mais no A (42,04%) do que no B (27,50%).
• Um funil que não é sequencial. 653 dos 953 compradores (68,52%) compraram sem passar pelo carrinho, então medi cada etapa sobre o total do grupo, e não sobre a etapa anterior.

Método

A resposta de cada usuário em cada etapa é binária e os grupos são independentes, então usei o teste z de duas proporções, escrito numa função própria, com hipóteses bilaterais. Como são três comparações com os mesmos usuários, apliquei Bonferroni: um resultado só conta abaixo de p = 0,0167. Rodei o teste duas vezes, com todos os participantes e só com quem teve os 14 dias inteiros, e calculei o poder de cada etapa para ver um aumento de 10% com o tamanho real dos grupos.

Achados

• Página do produto: 64,77% no A contra 55,64% no B, uma queda de 9,12 p.p. (p = 0,000006). Significativa, e o teste tinha poder para ver (0,839).
• Carrinho: 30,10% contra 27,76% (p = 0,217). Não significativo.
• Compra: 32,21% contra 28,40% (p = 0,049). Fica abaixo de 5%, mas não do limite de Bonferroni, então não é significativo.
• Com os 14 dias inteiros a decisão é a mesma nas três etapas.
• O "não significativo" não prova ausência de efeito. No carrinho e na compra, o poder para ver um aumento de 10% era de 0,198 e 0,221, contra a referência de 0,8. Mas a diferença vai na direção contrária: os dados não dão nenhum sinal de ganho.

A decisão

Não lançar a mudança, porque nenhum resultado mostra ganho e a única diferença significativa é uma queda. Refazer o teste com a mudança descrita com clareza, divisão 50/50 conferida durante o teste, nenhum outro teste com os mesmos usuários, um período fora das festas de fim de ano, dados coletados até 14 dias depois do último cadastro e uma amostra calculada antes para detectar 10% no carrinho e na compra.

SQL: o mercado de apps de leitura

A pergunta da análise

Com a pandemia as pessoas passaram a ler mais, e várias startups lançaram apps de leitura. Recebi o banco de um desses serviços e respondi cinco perguntas em SQL, para servir de base à proposta de valor de um produto novo nesse mercado.

Os dados

Um banco PostgreSQL com cinco tabelas: 1.000 livros, 636 autores, 340 editoras, 6.456 notas e 2.793 resenhas, com books no centro. Antes das tarefas, conferi as ligações com LEFT JOIN … IS NULL: nenhuma chave sem par. E encontrei a armadilha: juntar ratings e reviews direto pelo livro gera 26.167 linhas, porque cada nota se combina com cada resenha do mesmo livro. Por isso, em todas as tarefas, agreguei cada tabela num CTE antes da junção.

Método

Toda a conta (contagem, média, filtro, ordenação e junção) acontece dentro do SQL; o pandas só mostra o resultado. Um exemplo, a editora com mais livros de mais de 50 páginas: o CTE agrega por editora, o RANK() mostra empates e o SUM() OVER () calcula a participação sobre todas as editoras, antes do LIMIT.

WITH por_editora AS (
    SELECT
        publishers.publisher_id,
        publishers.publisher,
        COUNT(*) AS livros
    FROM books AS books
    JOIN publishers AS publishers ON publishers.publisher_id = books.publisher_id
    WHERE books.num_pages > 50
    GROUP BY publishers.publisher_id, publishers.publisher
)
SELECT
    RANK() OVER (ORDER BY livros DESC)             AS posicao,
    publisher,
    livros,
    ROUND(100.0 * livros / SUM(livros) OVER (), 2) AS pct_dos_livros
FROM por_editora
ORDER BY livros DESC
LIMIT 5;

Achados

• O acervo é recente. 819 dos 1.000 livros (81,9%) saíram depois de 01/01/2000.
• Popularidade não é qualidade. Twilight é o livro com mais resenhas (7) e mais notas (160), mas tem média 3,66, abaixo da média do catálogo (3,9). A correlação entre número de resenhas e nota média é 0,02.
• Nota 5 com poucas notas engana. 44 livros têm média 5, e nenhum passa de 4 notas. Por isso o ranking de autores só considera livros com 50 notas ou mais: só 19 livros passam, e J.K. Rowling/Mary GrandPré lidera com 4,29 sobre 310 notas.
• O catálogo é espalhado. A Penguin Books é a maior editora com só 42 livros (4,23%), seguida da Vintage (31).
• Os leitores escrevem. Os 6 usuários que avaliaram mais de 50 livros escrevem em média 24,33 resenhas, contra 17,19 dos outros 154. Com só 6 pessoas, é uma tendência, não uma regra.

A decisão

Um app que queira competir precisa de acervo atual e de acordos com várias editoras, porque nenhuma passa de 4,23% do catálogo. Deve mostrar a nota média junto com o número de notas e exigir um mínimo de notas nos rankings, para um livro com duas notas 5 não passar à frente de um com 80 notas e média 4,4. E vale investir em resenhas e comunidade, começando pelos leitores mais ativos.

Os dois projetos foram aprovados pelo revisor da TripleTen.

Links

Repositório · Parte 1: recompra na Olist