Een bouncepercentage heeft één bit nodig, geen tracker

Tot 28 augustus toonde deze site geen bouncepercentage, en op de over-pagina stond dat dat bewust was: het zou een sessie vragen die over meerdere paginaweergaven gevolgd wordt, en dat zou een toestemmingsbanner vragen.

De eerste helft was waar. De tweede helft hield op waar te zijn op het moment dat we uitstappagina's begonnen vast te leggen, en niemand werkte de zin bij.

Waarom het niet gewoon uit te rekenen viel

Er is een tabel met overgangen van pagina naar pagina. Die lijkt alles te bevatten wat een bouncepercentage nodig heeft: een bezoek dat van de ene pagina naar de andere gaat, is geen bounce, dus tel de bezoeken zonder overgangen.

Dat werkt niet, en de reden staat in drie regels van de vastlegcode. Een overgang valt weg wanneer de twee pagina's dezelfde zijn, wanneer er meer dan dertig minuten tussen zat, en na driehonderd nieuwe paren op één teller op één dag. Elke regel klopt voor waar de tabel voor is — laten zien welke pagina naar welke leidt — en elke regel maakt een echte tweede pagina onzichtbaar.

Ondertussen duurt een bezoek, om er een te tellen, een uur: zo lang blijft de regel in de levende tabel bestaan. De teller zou dus de ene definitie van een bezoek gebruiken en de noemer de andere. Het getal zou niet een beetje fout zijn geweest, het zou nergens aan verankerd zijn geweest.

Wat de gegevens wel zeiden

Op 27 en 28 augustus waren er 8.669 bezoeken en 2.817 overgangen, dus gemiddeld 1,32 pagina per bezoek. 99 van de 572 tellers legden überhaupt een overgang vast.

Dat is geen schakelaar die uitstaat — het vastleggen van paden staat standaard aan, en alle 166.453 tellers hebben het ingeschakeld. Die sites zijn werkelijk één pagina: profielpagina's, eenpaginasites, een fotogalerie op andermans platform. Een bouncepercentage komt voor de meeste ervan dicht bij honderd procent uit, en dat zal kloppen.

Eén bit, en geen nieuwe verzameling

Een bezoek heeft al een uur lang een regel. Die draagt er nu nog één ding bij: of dit bezoek ooit een tweede, andere pagina gezien heeft. De waarde wordt gezet binnen de opdracht die toch al loopt, zonder extra bevraging:

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

De volgorde van die toewijzingen is de hele truc. De database werkt ze van links naar rechts af, dus url bevat nog het vorige adres wanneer de vergelijking loopt. Zet url vooraan en de regel vergelijkt het nieuwe adres met zichzelf, blijft de bit voor altijd nul, en leest het bouncepercentage voor iedereen honderd procent. Dat is een mislukking die er precies uitziet als een geloofwaardige uitkomst, en daarom was het de moeite waard hem op een weggooiregel te bewijzen voordat we erop vertrouwden.

Is het uur om, dan telt de nachtelijke opruiming de verlopende regels — hoeveel bezoeken, hoeveel daarvan meerdere pagina's — schrijft één regel per teller en dag, en verwijdert de regels. De bit leeft een uur. Geen cookie, en niets dat hem overleeft.

Wat in het algemeen geldt

De interessante vraag was nooit hoe je een sessie volgt. Het was welk van de dingen die we al opschrijven de vraag toevallig beantwoordt, en of het antwoord dat het geeft aan dezelfde definitie verankerd is als de vraag.

Twee bronnen die er allebei uitzien alsof ze bezoeken meten, de ene met een regel van dertig minuten en de andere met een van zestig, leveren een verhouding op die een getal is en niets betekent. Het is makkelijker één bit toe te voegen aan een regel die al bestaat dan later uit te leggen waarom het percentage is wat het is.