Un taux de rebond demande un bit, pas un traceur

Jusqu’au 28 août, ce site n’affichait pas de taux de rebond, et la page « à propos » disait que c’était volontaire : il faudrait une session suivie sur plusieurs pages, et donc une bannière de consentement.

La première moitié était vraie. La seconde a cessé de l’être au moment où nous avons commencé à enregistrer les pages de sortie, et personne n’a corrigé la phrase.

Pourquoi il n’était pas calculable tel quel

Il existe une table des transitions d’une page à l’autre. Elle a tout l’air de ce qu’un taux de rebond demande : une visite qui passe d’une page à une autre n’est pas un rebond, donc il suffit de compter les visites sans transition.

Cela ne marche pas, et la raison tient en trois lignes du code d’enregistrement. Une transition est écartée quand les deux pages sont la même, quand plus de trente minutes se sont écoulées entre elles, et au-delà de trois cents nouvelles paires sur un compteur en un jour. Chaque règle est juste pour ce à quoi la table sert — montrer quelle page mène à quelle autre — et chacune rend invisible une vraie deuxième page.

Or une visite, pour pouvoir être comptée, dure une heure : c’est la durée de vie de la ligne dans la table en direct. Le numérateur utiliserait donc une définition de la visite et le dénominateur une autre. Le nombre n’aurait pas été légèrement faux, il aurait été sans ancrage.

Ce que les données disaient tout de même

Les 27 et 28 août, il y a eu 8 669 visites et 2 817 transitions, soit 1,32 page par visite en moyenne. 99 compteurs sur 572 ont enregistré une transition.

Ce n’est pas un interrupteur éteint : l’enregistrement des parcours est activé par défaut, et les 166 453 compteurs l’ont activé. Ces sites sont vraiment d’une seule page : des profils, des pages uniques, une galerie sur la plateforme d’un autre. Le taux de rebond de la plupart tournera autour de cent pour cent, et ce sera exact.

Un bit, et aucune collecte nouvelle

Une visite possède déjà une ligne pendant une heure. Elle porte maintenant une chose de plus : cette visite a-t-elle jamais vu une deuxième page, différente. La valeur est posée dans l’instruction qui s’exécute de toute façon, sans requête supplémentaire :

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

L’ordre de ces affectations, c’est toute l’astuce. La base les évalue de gauche à droite, donc url contient encore l’adresse précédente au moment de la comparaison. Mettez url devant et la ligne compare la nouvelle adresse avec elle-même : le bit reste à zéro pour toujours et le taux de rebond affiche cent pour cent pour tout le monde. C’est une panne qui ressemble exactement à un résultat plausible, et c’est pourquoi il valait la peine de le prouver sur une ligne jetable avant d’y croire.

L’heure écoulée, le nettoyage nocturne compte les lignes qui expirent — combien de visites, combien à plusieurs pages — écrit une ligne par compteur et par jour, puis les supprime. Le bit vit une heure. Aucun cookie, et rien qui lui survive.

Ce qui se généralise

La question intéressante n’a jamais été de savoir comment suivre une session. C’était de savoir laquelle des choses que nous notons déjà répond par hasard à la question, et si la réponse est arrimée à la même définition que la question.

Deux sources qui semblent toutes deux mesurer des visites, l’une avec une règle de trente minutes et l’autre de soixante, donneront un rapport qui est un nombre et ne veut rien dire. Il est plus simple d’ajouter un bit à une ligne qui existe déjà que d’expliquer, plus tard, pourquoi le taux est ce qu’il est.