402 Payment Required की वापसी: HTTP स्टेटस कोड बॉट ट्रैफ़िक के बारे में क्या बताते हैं

ज़्यादातर वेब एनालिटिक्स फ़ैसले क्लाइंट-साइड पर होते हैं, यानी पेज लोड होने और JavaScript चलने के बाद। यह मॉडल चुपचाप यह मान लेता है कि आपके सर्वर तक पहुँचने वाला हर रिक्वेस्ट गिनने लायक है। ऐसा नहीं है। रॉ ट्रैफ़िक का एक बड़ा हिस्सा कभी कुछ रेंडर ही नहीं करता, कभी किसी इंसान का नहीं होता, और उसे कभी भी आपके डैशबोर्ड तक नहीं पहुँचना चाहिए। इसे फ़िल्टर करने का सबसे साफ़ और सबसे जल्दी मिलने वाला सिग्नल वह चीज़ है जो आप पहले से ही हर रिक्वेस्ट पर जनरेट करते हैं: HTTP स्टेटस कोड।

स्टेटस कोड एक फर्स्ट-क्लास एनालिटिक्स सिग्नल हैं

HTTP सिमैंटिक्स स्पेसिफिकेशन (RFC 9110) स्टेटस कोड को तीन अंकों के एक इंटीजर के रूप में परिभाषित करती है जो किसी रिक्वेस्ट का परिणाम बताता है, और इन्हें पाँच वर्गों में बाँटा गया है: 1xx सूचनात्मक, 2xx सफल, 3xx रीडायरेक्शन, 4xx क्लाइंट एरर, और 5xx सर्वर एरर। चूँकि Monoid Cloudflare एज पर चलता है, हम वह स्टेटस कोड देखते हैं जो ऑरिजिन (या खुद एज) किसी भी क्लाइंट स्क्रिप्ट के चलने से पहले लौटाता है। यह क्रम मायने रखता है। ब्राउज़र बीकन द्वारा दर्ज किया गया कोई पेज व्यू तभी अस्तित्व में आ सकता है जब डॉक्युमेंट वाकई 2xx के साथ सर्व और पार्स हुआ हो। लेकिन रिक्वेस्ट स्ट्रीम में सफल डॉक्युमेंट्स से कहीं ज़्यादा कुछ शामिल होता है।

ज़रा सोचिए कि एक सामान्य ऑरिजिन दिन भर में क्या लौटाता है: सफल HTML डॉक्युमेंट्स, कंडीशनल रिक्वेस्ट्स के लिए 304 Not Modified रिस्पॉन्स, कैननिकलाइज़ेशन से आने वाले 301/308 रीडायरेक्ट, प्रोबिंग स्कैनर्स के लिए 404s, और इंसीडेंट्स के दौरान 5xx के उछाल। केवल सफलतापूर्वक रेंडर हुए डॉक्युमेंट्स गिनना और बाकी को नज़रअंदाज़ करना उस संदर्भ को फेंक देता है जो आपके ट्रैफ़िक कर्व में आई विसंगतियों को समझा सकता है।

स्टेटस डिस्ट्रीब्यूशन में बॉट्स कहाँ छिपते हैं

ऑटोमेटेड क्लाइंट्स ब्राउज़र्स से अलग तरह से व्यवहार करते हैं, और स्टेटस कोड इस अंतर को सस्ते में उजागर कर देते हैं। वल्नरेबिलिटी स्कैनर एडमिन पैनल और जाने-पहचाने CMS पाथ खोजते हुए 404 और 403 रिस्पॉन्स के घने क्लस्टर बनाते हैं। आक्रामक क्रॉलर 429 Too Many Requests को नज़रअंदाज़ कर देते हैं — जिसे RFC 6585 में रेट लिमिटिंग के रिस्पॉन्स के रूप में परिभाषित किया गया है — और लगातार भेजते रहते हैं, ऐसा सिग्नेचर बनाते हुए जो कोई इंसानी सेशन कभी नहीं बनाता। नादान स्क्रेपर अक्सर उन रीडायरेक्ट चेन को फॉलो करते हैं जिन्हें असली ब्राउज़र bfcache या हिस्ट्री के ज़रिए शॉर्ट-सर्किट कर देता।

यहाँ 402 Payment Required कोड बहुत कुछ सिखाता है। RFC 9110 साफ़ तौर पर कहती है कि यह भविष्य के इस्तेमाल के लिए आरक्षित है और इसका कोई मानकीकृत अर्थ नहीं है, फिर भी हाल में मीटर्ड API और एजेंट एक्सेस के लिए इसे नए सिरे से ध्यान मिला है। अगर आपका ऑरिजिन 402 भेजना शुरू करे, तो वह ट्रैफ़िक लगभग निश्चित रूप से प्रोग्रामैटिक है, कोई इंसान ब्राउज़ नहीं कर रहा। एक स्टेटस-अवेयर पाइपलाइन किसी मेट्रिक को चुपचाप फुलाने की बजाय उसे उसी हिसाब से टैग कर सकती है।

सिर्फ़ क्लाइंट-साइड एनालिटिक्स यहाँ क्यों ग़लत साबित होता है

एक केवल-JavaScript टूल इसमें से ज़्यादातर देख ही नहीं सकता। अगर कोई रिक्वेस्ट 403 लौटाए, तो कोई एनालिटिक्स स्क्रिप्ट चलती ही नहीं, इसलिए वह इवेंट अदृश्य रहता है — लेकिन आपके इंफ्रास्ट्रक्चर पर पड़ने वाला लोड असली है, और उसके पीछे की मंशा (रेकनेसंस, क्रेडेंशियल स्टफ़िंग, स्क्रेपिंग) अक्सर वही है जिसे आप वाकई जानना चाहते हैं। दूसरी तरफ़, जो टूल बिना स्टेटस के आधार पर फ़र्क किए सर्वर लॉग लाइनें गिनते हैं, वे ओवर-रिपोर्ट करते हैं, हर 301 हॉप और हर 404 प्रोब को "हिट" मानते हुए।

यहाँ काम का बीच का रास्ता है: एज-लेवल स्टेटस क्लासिफिकेशन जो एक प्राइवेसी-फ़र्स्ट काउंटिंग मॉडल को फ़ीड करे:

• असली नेविगेशन के साथ 2xx text/html एक संभावित पेज व्यू है।
• 3xx को डेस्टिनेशन से जोड़ा जाना चाहिए, दोबारा नहीं गिना जाना चाहिए।
• 4xx डायग्नोस्टिक है, ऑडियंस नहीं — इसे अलग से दिखाएँ।
• 5xx एक रिलायबिलिटी पैनल पर होना चाहिए, जिसे सफल व्यूज़ में किसी भी गिरावट से जोड़ा जाए।

बिना किसी को ट्रैक किए यह सब करना

इसमें से किसी भी चीज़ के लिए विज़िटर की पहचान करने की ज़रूरत नहीं है। स्टेटस कोड, मेथड, रिस्पॉन्स क्लास, और मोटा-मोटा टाइमिंग रिक्वेस्ट-रिस्पॉन्स एक्सचेंज के गुण हैं, किसी इंसान के नहीं। Monoid कभी कुकीज़ सेट नहीं करता, कभी localStorage नहीं पढ़ता, और कभी डिवाइस फ़िंगरप्रिंटिंग नहीं करता। यह जानने के लिए हमें किसी स्थिर पहचानकर्ता की ज़रूरत नहीं कि 03:00 UTC पर आया 429s का उछाल ऑडियंस से नहीं बल्कि ऑटोमेशन से आया — स्टेटस डिस्ट्रीब्यूशन खुद ही यह बता देता है। यह डेटा मिनिमाइज़ेशन है जो हमारे पक्ष में काम कर रहा है: सबसे कम पर्सनल सिग्नल ही ट्रैफ़िक क्वालिटी के लिए सबसे ईमानदार सिग्नलों में से एक भी है।

इसका एक कम्प्लायंस फ़ायदा भी है। एज पर नॉन-ह्यूमन ट्रैफ़िक फ़िल्टर करने का मतलब है कि एनालिटिक्स स्टोर में शुरू से ही कम फ़र्ज़ी इवेंट्स दाख़िल होते हैं, जिससे दर्ज डेटा उसके बताए गए उद्देश्य के करीब बना रहता है। GDPR के स्टोरेज-लिमिटेशन और पर्पस-लिमिटेशन सिद्धांतों (आर्टिकल 5(1)(c) और 5(1)(e)) के तहत, कचरा डेटा इकट्ठा ही न करना, उसे इकट्ठा करके बाद में फेंकने से सख़्ती से बेहतर है।

व्यावहारिक निष्कर्ष

अगर आप एनालिटिक्स बनाते या परखते हैं, तो तीन सवाल पूछिए। क्या यह स्टेटस कोड देखता है, या सिर्फ़ रेंडर हुए डॉक्युमेंट्स? क्या यह रिलायबिलिटी सिग्नल्स (5xx) को ऑडियंस सिग्नल्स (2xx) से अलग करता है? और क्या यह बिना किसी पहचानकर्ता के बॉट फ़िल्टरिंग हासिल करता है? जो पाइपलाइन तीनों का जवाब "हाँ" में देती है, वह आपको एक साथ साफ़-सुथरे आँकड़े और छोटी प्राइवेसी सरफ़ेस दोनों देती है — जो, इस बार के लिए, एक ही फ़ैसला है।

स्रोत

• RFC 9110: HTTP Semantics (Status Codes)
• RFC 6585: Additional HTTP Status Codes (429, 431)
• MDN: HTTP response status codes
• GDPR Article 5: Principles relating to processing of personal data