Achar onde a jornada perde gente com exploração, segmento e funil

Com a página de guia diagnosticada, o relatório padrão parou de responder. Ele diz quantas sessões chegaram ao checkout e quantas compras saíram, mas não diz em qual tela a pessoa desistiu, quanto tempo passou entre uma etapa e outra nem se quem escolheu Pix se comporta como quem escolheu cartão.

O custo de ficar só no relatório é decidir no escuro. A Verde Vivo passou três semanas mexendo na tabela de frete porque a taxa de conversão de 2,0 por cento parecia baixa, quando a perda estava na tela de pagamento. Sem funil, cada hipótese vira uma mudança no site e um mês de espera pelo resultado.

Explorações resolvem isso com um custo próprio: obedecem a regras diferentes dos relatórios, amostram acima de um limite e respeitam a janela de retenção da propriedade. Ao terminar, o funil do checkout da Verde Vivo mostra a etapa da perda por meio de pagamento, e o número que ele entrega vem com a ressalva certa.

Exploração é a área do Analytics onde a pergunta vem antes do relatório. Em vez de abrir uma tabela pronta, a pessoa escolhe as variáveis (dimensões, métricas e segmentos que a aba pode usar), monta a tela e troca de técnica sem perder o que já configurou. As técnicas são: livre, funil, caminho, sobreposição de segmentos, coorte, usuário e valor de vida.

A exploração livre é uma tabela dinâmica: linhas, colunas e valores escolhidos à mão, com filtro e segmento por cima. Ela responde às perguntas que o relatório padrão não aceita, como cruzar cidade com meio de pagamento e ticket médio. É por ali que se testa uma hipótese antes de gastar tempo com um funil.

Relatório e exploração leem os mesmos eventos por regras diferentes, e a página oficial lista as diferenças. Campos que só existem num dos dois. Filtros de exploração que distinguem maiúsculas de minúsculas. Segmentos e comparações convertidos com perda ao passar de um lado para o outro. A retenção de dados limita o período da exploração e não o do relatório agregado. As últimas 48 horas podem divergir entre os dois.

Segmento é o subconjunto que a exploração enxerga, e o escopo dele muda a resposta. Segmento de usuário traz todos os eventos de quem cumpriu a condição em algum momento, inclusive as visitas de antes. Segmento de sessão traz só as sessões em que a condição ocorreu. Segmento de evento traz só os eventos que a cumprem, sem o resto da sessão.

Na prática, a escolha do escopo é a pergunta. "Quem já pagou com Pix" é segmento de usuário e inclui as sessões de pesquisa antes da compra. "Sessões em que alguém escolheu Pix" é segmento de sessão e serve para medir o checkout daquele dia. "Eventos de pagamento com Pix" é segmento de evento e serve para contar e somar, não para descrever comportamento.

Funil é a técnica que ordena etapas e mede quem passa de uma para a outra. Funil fechado exige entrar pela primeira etapa; funil aberto aceita quem entra em qualquer ponto. Cada etapa pode ser "seguida indiretamente" (com outras ações no meio) ou "seguida diretamente", e pode receber um limite de tempo entre uma etapa e a seguinte. A tabela mostra usuários por etapa, taxa de conclusão, abandono e tempo decorrido.

Duas decisões definem o que o funil mede. A primeira é o escopo do funil: usuários que completam as etapas em qualquer sessão, ou só dentro da mesma sessão. A segunda é a última etapa: se ela é um evento que depende de algo fora do navegador, como a confirmação do pagamento, o funil dentro da sessão vai chamar de abandono o que é só espera.

Exploração de caminho responde à pergunta inversa: dado um evento, o que vem depois ou o que veio antes. Ela desenha uma árvore de eventos ou de páginas a partir de um ponto de partida ou de chegada, e é a ferramenta para descobrir para onde vai quem sai da tela de pagamento sem comprar: para o carrinho, para o guia de frete ou para fora do site.

Sobreposição de segmentos cruza poucos segmentos por vez e mostra quem pertence a mais de um, no molde de um diagrama de conjuntos. Exploração de usuário lista identificadores individuais com a linha do tempo de eventos de cada um. Ela vale para depurar um caso, nunca para identificar uma pessoa: o Analytics não guarda nome, e dados modelados de consentimento não aparecem ali.

Amostragem é o limite que a exploração precisa declarar. Na propriedade padrão, a consulta que passa de 10 milhões de eventos é amostrada; no Analytics 360, o limite é 1 bilhão. O ícone no alto da exploração diz se o resultado é completo. Explorações sem amostragem existem só no 360, com cota de 20.000 tokens por propriedade por dia e 5.000 por consulta, em resultados somente leitura que expiram em 50 dias.

Quando a pergunta ultrapassa esse teto, a resposta está no BigQuery, que recebe os eventos brutos sem amostragem, sem linha (other) e sem as adições do Google: nada de modelagem de consentimento, nada de atribuição orientada por dados. O capítulo 29 monta essa exportação; aqui basta saber que a exploração amostrada é boa para achar a etapa e ruim para fechar o número do mês.

Armadilha comum: montar o funil fechado dentro da sessão com purchase como última etapa numa loja que aceita Pix e boleto, ler 60 por cento de abandono na tela de pagamento e mandar o desenvolvedor reescrever o checkout. O evento purchase só chega quando o pagamento confirma, e boa parte das confirmações vem depois de a aba fechar. O funil mediu espera e chamou de desistência.

Foi o que aconteceu na Verde Vivo. Marina montou o funil fechado no escopo da sessão, com view_item, add_to_cart, begin_checkout, add_payment_info e purchase, nos 30 dias de agosto. Das 82.000 sessões do mês, 3.600 chegaram à tela de pagamento e 1.287 terminaram com purchase na mesma sessão: 64 por cento de abandono na etapa final, o pior número do funil.

O número era falso na parte que importava. Caio já enviava purchase pelo servidor, só na confirmação do pagamento, e a loja fechou agosto com 1.650 pedidos pagos. Os 363 pedidos que faltavam no funil, 22 por cento do total, foram confirmados depois da sessão: 283 por Pix, pago pelo aplicativo do banco com a aba fechada, e 80 por boleto, compensados um ou dois dias depois.

A correção teve duas partes. Caio criou o evento pedido_criado, disparado no navegador no instante em que o pedido é gerado, e Marina o colocou como última etapa do funil dentro da sessão; purchase virou etapa de um segundo funil, aberto, com escopo entre sessões e prazo de 7 dias. A perda real na tela de pagamento passou a 43 por cento, e os 400 pedidos criados e nunca pagos ganharam medição própria.

O segmento por meio de pagamento explicou o resto. Nas sessões com cartão, 610 das 880 desistências na tela de pagamento vinham de recusa da operadora, visível num evento de erro que Caio adicionou na mesma semana. Nas sessões com Pix, a desistência era baixa, e o segmento de usuário mostrou que quem pagava depois voltava por um link de e-mail, o que muda a atribuição da venda e reaparece no capítulo 23.

A amostragem não atrapalhou em agosto: a Verde Vivo gera perto de 2,1 milhões de eventos por mês, e a consulta de 30 dias ficou abaixo dos 10 milhões. Quando Marina esticou o mesmo funil para 12 meses, o ícone mudou de cor e o total de purchase divergiu em 4 por cento do relatório. A leitura anual foi para o BigQuery, e a exploração ficou com a pergunta de onde se perde.

Abra a exploração de funil da sua loja com pedido criado, e não pagamento confirmado, como última etapa dentro da sessão, e coloque um segmento por meio de pagamento em cada coluna. O critério de acerto é o ícone de amostragem verde e uma etapa com abandono acima das outras. Anote qual é: o próximo capítulo troca a pergunta "onde perde" por "quem volta", e a resposta exige olhar por coorte.