बाउंस रेट के लिए एक बिट काफ़ी है, ट्रैकर नहीं

28 अगस्त तक यह वेबसाइट बाउंस रेट नहीं दिखाती थी, और परिचय पेज कहता था कि ऐसा जान-बूझकर है: इसके लिए कई पेज व्यू तक एक सेशन का पीछा करना पड़ता, और उसके लिए सहमति बैनर की ज़रूरत होती।

पहली आधी बात सच थी। दूसरी आधी बात उसी पल सच नहीं रही, जब हमने एग्ज़िट पेज दर्ज करना शुरू किया, और किसी ने वह वाक्य अपडेट नहीं किया।

इसे सीधे हिसाब से क्यों नहीं निकाला जा सकता था

पेज से पेज तक के ट्रांज़िशन की एक टेबल है। वह बाउंस रेट के लिए ज़रूरी हर चीज़ जैसी दिखती है: जो विज़िट एक पेज से दूसरे पेज पर जाती है, वह बाउंस नहीं है, तो बस बिना ट्रांज़िशन वाली विज़िट गिननी हैं।

यह काम नहीं करता, और इसकी वजह रिकॉर्ड करने वाले कोड की तीन लाइनों में है। ट्रांज़िशन तब छोड़ दिया जाता है, जब दोनों पेज एक ही हों, जब उनके बीच तीस मिनट से ज़्यादा बीत गए हों, और किसी काउंटर पर एक दिन में तीन सौ नई जोड़ियों के बाद। हर नियम उस काम के लिए सही है, जिसके लिए यह टेबल है — यह दिखाना कि कौन-सा पेज किस पेज तक ले जाता है — और हर नियम एक असली दूसरे पेज को अदृश्य कर देता है।

उधर किसी विज़िट को गिनने के लिए वह एक घंटे तक चलती है: लाइव टेबल में उसकी पंक्ति इतनी ही देर रहती है। यानी अंश में विज़िट की एक परिभाषा होती और हर में दूसरी। संख्या थोड़ी-सी गलत नहीं होती, उसका कोई आधार ही नहीं होता।

डेटा ने क्या बताया

27 और 28 अगस्त को 8,669 विज़िट और 2,817 ट्रांज़िशन हुए, यानी औसतन हर विज़िट में 1.32 पेज। 572 में से सिर्फ़ 99 काउंटरों ने कोई भी ट्रांज़िशन दर्ज किया।

इसकी वजह कोई बंद स्विच नहीं है — पाथ रिकॉर्डिंग डिफ़ॉल्ट रूप से चालू रहती है, और सभी 1,66,453 काउंटरों पर यह चालू है। ये वेबसाइटें सच में एक ही पेज की हैं: प्रोफ़ाइल पेज, एक पेज वाली वेबसाइटें, किसी और के प्लेटफ़ॉर्म पर तस्वीरों की गैलरी। इनमें से ज़्यादातर के लिए बाउंस रेट सौ प्रतिशत के करीब दिखेगी, और वह सही होगी।

एक बिट, और कोई नया डेटा संग्रह नहीं

एक विज़िट के लिए एक घंटे तक एक पंक्ति पहले से मौजूद रहती है। अब उसमें एक चीज़ और रहती है: क्या इस विज़िट ने कभी कोई दूसरा, अलग पेज देखा। यह मान उसी स्टेटमेंट के अंदर सेट होता है, जो वैसे भी चलता है, बिना किसी अतिरिक्त क्वेरी के:

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

इन असाइनमेंट का क्रम ही पूरी तरकीब है। डेटाबेस इन्हें बाएँ से दाएँ लागू करता है, इसलिए तुलना के समय url में अभी भी पिछला पता होता है। अगर url को पहले रख दिया जाए, तो पंक्ति नए पते की तुलना उसी से करती है, बिट हमेशा शून्य रहता है, और बाउंस रेट सबके लिए सौ प्रतिशत दिखती है। यह ऐसी गड़बड़ी है, जो बिल्कुल एक विश्वसनीय नतीजे जैसी दिखती है, इसीलिए उस पर भरोसा करने से पहले इसे एक अस्थायी पंक्ति पर साबित करना ज़रूरी था।

घंटा पूरा होने पर रात की सफ़ाई प्रक्रिया खत्म होने वाली पंक्तियों को गिनती है — कितनी विज़िट, उनमें से कितनी एक से ज़्यादा पेज वाली — हर काउंटर और दिन के लिए एक पंक्ति लिखती है, और पंक्तियों को हटा देती है। बिट एक घंटा जीता है। कोई कुकी नहीं, और ऐसा कुछ नहीं, जो उससे ज़्यादा देर टिके।

आम सबक

दिलचस्प सवाल कभी यह नहीं था कि सेशन को ट्रैक कैसे किया जाए। सवाल यह था कि जो चीज़ें हम पहले से दर्ज करते हैं, उनमें से कौन-सी इस सवाल का जवाब देती है, और क्या उसका जवाब उसी परिभाषा से बँधा है, जिससे सवाल बँधा है।

विज़िट मापते हुए लगने वाले दो स्रोत, एक तीस मिनट के नियम के साथ और दूसरा साठ मिनट के, ऐसा अनुपात देंगे, जो संख्या तो है, लेकिन जिसका कोई मतलब नहीं। पहले से मौजूद पंक्ति में एक बिट जोड़ना, बाद में यह समझाने से आसान है कि दर जो है, वह क्यों है।