За процента на отпадане е нужен един бит, а не проследяване

До 28 август този сайт не показваше процент на отпадане, а страницата „За нас“ казваше, че това е нарочно: за него би била нужна сесия, проследявана през няколко отваряния на страници, а за това би бил нужен банер за съгласие.

Първата половина беше вярна. Втората престана да е вярна в момента, в който започнахме да записваме страниците на излизане, и никой не обнови изречението.

Защо не можеше просто да се изчисли

Има таблица с преходите от страница към страница. Тя изглежда като всичко, което е нужно за процента на отпадане: посещение, което минава от една страница към друга, не е отпадане, значи се броят посещенията без преходи.

Това не работи и причината е в три реда от кода за записване. Преходът се отхвърля, когато двете страници са еднакви, когато между тях са минали повече от тридесет минути и след триста нови двойки за един брояч в един ден. Всяко правило е правилно за целта на таблицата — да показва коя страница към коя води — и всяко прави една истинска втора страница невидима.

Същевременно посещението, за целите на преброяването му, трае един час: толкова живее редът в таблицата на живо. Така числителят би използвал една дефиниция за посещение, а знаменателят — друга. Числото нямаше да е леко погрешно, а щеше да е без никаква опора.

Какво все пак казаха данните

На 27 и 28 август имаше 8 669 посещения и 2 817 прехода, значи средно 1,32 страници на посещение. 99 от 572 брояча изобщо са записали преход.

Причината не е изключен превключвател — записването на пътищата по подразбиране е включено и е активно при всичките 166 453 брояча. Тези сайтове наистина са единични страници: профилни страници, едностранични сайтове, галерия със снимки в чужда платформа. При повечето от тях процентът на отпадане ще показва близо сто процента и това ще е вярно.

Един бит и никакво ново събиране на данни

Посещението и без това има ред за един час. Сега този ред носи още едно нещо: дали това посещение изобщо е видяло втора, различна страница. Стойността се задава в командата, която се изпълнява така или иначе, без допълнителна заявка:

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

Цялата хитрост е в реда на тези присвоявания. Базата данни ги изчислява отляво надясно, така че url все още съдържа предишния адрес, когато се прави сравнението. Сложете url първо и редът сравнява новия адрес със себе си, битът остава нула завинаги, а процентът на отпадане показва сто процента за всички. Това е грешка, която изглежда точно като правдоподобен резултат, затова си струваше да се докаже на ред за еднократна употреба, преди да ѝ се доверим.

Когато часът изтече, нощното почистване преброява изтичащите редове — колко посещения, колко от тях с повече от една страница — записва по един ред за брояч и ден и изтрива редовете. Битът живее един час. Без бисквитка и без нищо, което да го надживее.

Какво важи по принцип

Интересният въпрос никога не е бил как да се проследи сесия. Въпросът беше кое от нещата, които вече записваме, случайно отговаря на въпроса и дали отговорът му е закотвен към същата дефиниция като въпроса.

Два източника, които и двата изглеждат така, сякаш мерят посещения, единият с правило от тридесет минути, а другият с правило от шестдесет, ще дадат съотношение, което е число и не означава нищо. По-лесно е да се добави един бит към ред, който вече съществува, отколкото по-късно да се обяснява защо процентът е такъв, какъвто е.