Uma taxa de rejeição precisa de um bit, não de um rastreador

Até 28 de agosto este sítio não mostrava taxa de rejeição, e a página «sobre» dizia que era de propósito: seria preciso uma sessão seguida ao longo de várias páginas, e isso pediria um aviso de consentimento.

A primeira metade era verdade. A segunda deixou de o ser no momento em que começámos a registar páginas de saída, e ninguém corrigiu a frase.

Porque não dava para calcular sem mais

Existe uma tabela de transições de página para página. Parece tudo o que uma taxa de rejeição precisa: uma visita que passa de uma página para outra não é uma rejeição, portanto basta contar as visitas sem transição.

Isso não funciona, e a razão está em três linhas do código que regista. Uma transição é descartada quando as duas páginas são a mesma, quando entre elas passaram mais de trinta minutos, e a partir de trezentos pares novos num contador num dia. Cada regra está certa para aquilo a que a tabela serve — mostrar que página leva a qual — e cada uma torna invisível uma segunda página verdadeira.

Entretanto uma visita, para efeitos de a contar, dura uma hora: é o tempo de vida da linha na tabela em direto. O numerador usaria assim uma definição de visita e o denominador outra. O número não teria ficado ligeiramente errado, teria ficado sem amarra.

O que os dados diziam apesar disso

A 27 e 28 de agosto houve 8.669 visitas e 2.817 transições, ou seja 1,32 páginas por visita em média. 99 de 572 contadores registaram alguma transição.

Não é um interruptor desligado: o registo de percursos vem ligado por omissão e os 166.453 contadores têm-no ligado. Esses sítios são mesmo de uma só página: perfis, páginas únicas, uma galeria na plataforma de outra pessoa. A taxa de rejeição da maioria andará perto dos cem por cento, e estará certa.

Um bit, e nenhuma recolha nova

Uma visita já tem uma linha durante uma hora. Passa a levar mais uma coisa: se esta visita chegou a ver uma segunda página, diferente. O valor é posto dentro da instrução que corre de qualquer maneira, sem consulta adicional:

ON DUPLICATE KEY UPDATE mehr = mehr | (url <> VALUES(url)),
                        last_seen = UNIX_TIMESTAMP(), url = VALUES(url)

A ordem dessas atribuições é o truque todo. A base avalia-as da esquerda para a direita, portanto url ainda guarda o endereço anterior quando a comparação acontece. Ponha-se url à frente e a linha compara o endereço novo consigo próprio, o bit fica a zero para sempre e a taxa de rejeição marca cem por cento para toda a gente. É uma avaria que se parece exatamente com um resultado plausível, e por isso valeu a pena prová-la numa linha descartável antes de confiar nela.

Passada a hora, a limpeza noturna conta as linhas que expiram — quantas visitas, quantas delas de várias páginas — escreve uma linha por contador e dia, e apaga-as. O bit vive uma hora. Nenhum cookie, e nada que lhe sobreviva.

O que se generaliza

A pergunta interessante nunca foi como seguir uma sessão. Foi qual das coisas que já anotamos responde por acaso à pergunta, e se a resposta está presa à mesma definição que a pergunta.

Duas fontes que parecem ambas medir visitas, uma com uma regra de trinta minutos e outra de sessenta, dão um quociente que é um número e não significa nada. Sai mais barato acrescentar um bit a uma linha que já existe do que explicar, mais tarde, porque é que a taxa é a que é.