A visszafordulási arányhoz egy bit kell, nem követőkód
Augusztus 28-ig ez a weboldal nem mutatott visszafordulási arányt, és a Rólunk oldal azt írta, hogy ez szándékos: ehhez egy munkamenetet kellene több oldalmegtekintésen át követni, ahhoz pedig hozzájárulási sáv kellene.
Az első fele igaz volt. A második fele abban a pillanatban megszűnt igaznak lenni, amikor elkezdtük rögzíteni a kilépési oldalakat, és senki sem frissítette a mondatot.
Miért nem lehetett egyszerűen kiszámolni
Van egy tábla az oldalak közötti átmenetekről. Úgy tűnik, minden benne van, ami egy visszafordulási arányhoz kell: az a látogatás, amely egyik oldalról a másikra lép, nem visszafordulás, tehát elég megszámolni az átmenet nélküli látogatásokat.
Ez nem működik, és az ok a rögzítő kód három sorában rejlik. Egy átmenet elvész, ha a két oldal azonos, ha több mint harminc perc telt el közöttük, illetve egy számlálónál egy napon háromszáz új pár után. Mindegyik szabály helyes arra, amire a tábla szolgál — megmutatni, melyik oldal melyikhez vezet —, és mindegyik láthatatlanná tesz egy valódi második oldalt.
Közben egy látogatás a számlálás szempontjából egy óráig tart: ennyi ideig él a sora az élő táblában. A számláló tehát a látogatás egyik meghatározását használná, a nevező egy másikat. A szám nem kicsit lett volna hibás, hanem nem lett volna mihez kötni.
Amit az adatok elárultak
Augusztus 27-én és 28-án 8 669 látogatás és 2 817 átmenet volt, vagyis átlagosan 1,32 oldal látogatásonként. Az 572 számlálóból mindössze 99 rögzített egyáltalán átmenetet.
Ez nem egy kikapcsolt kapcsoló — az útvonalak rögzítése alapértelmezés szerint be van kapcsolva, és mind a 166 453 számlálónál engedélyezve van. Ezek a weboldalak valóban egyoldalasak: profiloldalak, egyoldalas weboldalak, egy képgaléria valaki más platformján. A legtöbbjüknél a visszafordulási arány közel száz százalék lesz, és ez helyes is lesz.
Egy bit, új adatgyűjtés nélkül
Egy látogatásnak már most is van egy órára szóló sora. Ez most eggyel több dolgot hordoz: azt, hogy a látogatás látott-e valaha egy második, eltérő oldalt. Az érték annak az utasításnak a belsejében áll be, amely amúgy is lefut, külön lekérdezés nélkül:
ON DUPLICATE KEY UPDATE mehr = mehr | (url <> VALUES(url)),
last_seen = UNIX_TIMESTAMP(), url = VALUES(url)
Ezeknek az értékadásoknak a sorrendje az egész trükk. Az adatbázis balról jobbra értékeli ki őket, így url még az előző címet tartalmazza, amikor az összehasonlítás lefut. Ha url kerül előre, a sor az új címet önmagával hasonlítja össze, a bit örökre nulla marad, és a visszafordulási arány mindenkinél száz százalék lesz. Ez olyan hiba, amely pontosan úgy néz ki, mint egy hihető eredmény, ezért érdemes volt egy eldobható soron bizonyítani, mielőtt megbíztunk benne.
Amikor lejár az óra, az éjszakai takarítás megszámolja a lejáró sorokat — hány látogatás, és közülük hány többoldalas —, számlálónként és naponként egy sort ír, majd törli a sorokat. A bit egy óráig él. Nincs süti, és semmi, ami túlélné.
Ami ebből általánosítható
Az érdekes kérdés sosem az volt, hogyan kövessünk egy munkamenetet. Hanem az, hogy a már amúgy is feljegyzett dolgaink közül melyik válaszol véletlenül a kérdésre, és hogy a válasza ugyanahhoz a meghatározáshoz kötődik-e, mint a kérdés.
Két forrás, amely látszólag egyaránt látogatásokat mér, az egyik harmincperces, a másik hatvanperces szabállyal, olyan arányt ad, amely szám ugyan, de semmit sem jelent. Könnyebb egy bitet hozzáadni egy már létező sorhoz, mint később megmagyarázni, miért annyi az arány, amennyi.