En avvisningsfrekvens kräver en bit, inte en spårare

Fram till den 28 augusti visade den här webbplatsen ingen avvisningsfrekvens, och sidan Om oss sa att det var avsiktligt: det skulle kräva att en session följs över flera sidvisningar, och det skulle kräva en samtyckesruta.

Den första halvan var sann. Den andra halvan slutade vara sann i samma stund som vi började registrera utgångssidor, och ingen uppdaterade meningen.

Varför den inte bara kunde räknas ut

Det finns en tabell över övergångar från sida till sida. Den ser ut att innehålla allt en avvisningsfrekvens behöver: ett besök som går från en sida till en annan är ingen avvisning, så räkna besöken utan övergångar.

Det fungerar inte, och skälet står i tre rader av registreringskoden. En övergång släpps när de två sidorna är samma, när mer än trettio minuter har gått mellan dem, och efter trehundra nya par för en räknare på en dag. Varje regel är rätt för det tabellen är till för — att visa vilken sida som leder till vilken — och varje regel gör en verklig andra sida osynlig.

Samtidigt varar ett besök, när det gäller att räkna det, en timme: så länge överlever raden i den aktiva tabellen. Täljaren skulle alltså använda en definition av ett besök och nämnaren en annan. Siffran hade inte blivit lite fel, den hade saknat förankring.

Vad data faktiskt sa

Under 27 och 28 augusti var det 8 669 besök och 2 817 övergångar, alltså i genomsnitt 1,32 sidor per besök. 99 av 572 räknare registrerade över huvud taget någon övergång.

Det beror inte på att en inställning är avslagen — registrering av klickvägar är på som standard, och alla 166 453 räknare har den aktiverad. De webbplatserna består verkligen av enstaka sidor: profilsidor, ensidiga webbplatser, ett bildgalleri på någon annans plattform. För de flesta av dem kommer avvisningsfrekvensen att ligga nära hundra procent, och det kommer att vara korrekt.

En bit, och ingen ny insamling

Ett besök har redan en rad under en timme. Nu bär den en sak till: om det här besöket någonsin såg en andra, annan sida. Värdet sätts inne i den sats som ändå körs, utan någon extra fråga:

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

Ordningen på de tilldelningarna är hela tricket. Databasen utvärderar dem från vänster till höger, så url innehåller fortfarande den föregående adressen när jämförelsen körs. Sätt url först, så jämför raden den nya adressen med sig själv, biten förblir noll för alltid och avvisningsfrekvensen visar hundra procent för alla. Det är ett fel som ser precis ut som ett rimligt resultat, och därför var det värt att bevisa det på en slängrad innan man litade på det.

När timmen är slut räknar den nattliga städningen de rader som löper ut — hur många besök, hur många av dem med flera sidor — skriver en rad per räknare och dag och raderar raderna. Biten lever en timme. Ingen cookie, och inget som överlever den.

Den allmänna lärdomen

Den intressanta frågan var aldrig hur man spårar en session. Den var vilken av de saker vi redan skriver ner som råkar besvara frågan, och om svaret den ger är förankrat i samma definition som frågan.

Två källor som båda ser ut att mäta besök, den ena med en trettiominutersregel och den andra med en sextiominutersregel, ger en kvot som är en siffra och inte betyder någonting. Det är lättare att lägga till en bit i en rad som redan finns än att senare förklara varför frekvensen är som den är.