रियल यूज़र मॉनिटरिंग मुझे क्या बता सकती है—और क्या नहीं

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

इसी वजह से मैंने Amazon CloudWatch Real User Monitoring (RUM) तैयार किया। इसका नाम डेटा से मिलने वाले भरोसे से ज़्यादा निश्चित सुनाई देता है, इसलिए साफ़ कहना ज़रूरी है कि यह व्यवस्था क्या बता सकती है और क्या नहीं।

सहमति पर आधारित सीमित संकेत

ब्राउज़र इंटीग्रेशन को जानबूझकर सीमित रखा गया है। वेबसाइट पहले पूछती है; आगंतुक की अनुमति के बाद ही AWS क्लाइंट लोड होता है। मना करने पर कोई RUM डेटा नहीं भेजा जाता। विकल्प ब्राउज़र में सहेजा जाता है और बाद में वापस लिया जा सकता है।

सहमति वाले सत्रों में से केवल एक नमूना चुना जाता है: पाँच प्रतिशत। यह सैंपलिंग सेटिंग है, इस बात की गारंटी नहीं कि पाँच प्रतिशत लोगों की गिनती होगी। चयन संभाव्यता पर आधारित है, और जो लोग सहमति नहीं देते वे RUM डेटा में शामिल नहीं होते।

कॉन्फ़िगरेशन में पेज-व्यू और सत्र घटनाओं पर ध्यान है। सत्र रिकॉर्डिंग, RUM कुकीज़, X-Ray और त्रुटि, HTTP तथा प्रदर्शन संग्रह बंद हैं। AWS घटनाओं को US East (N. Virginia) क्षेत्र में 30 दिनों तक रखता है। नेटवर्क अनुरोध में IP पता आवश्यक रूप से दिखाई देता है; घटना डेटा में पेज-पथ, समय, ब्राउज़र और डिवाइस की तकनीकी जानकारी तथा छद्मनाम सत्र या Cognito पहचानकर्ता भी हो सकते हैं। पेज-पथ में URL के क्वेरी पैरामीटर शामिल नहीं होते।

यह संकेत आगंतुकों की गिनती नहीं है

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

मैं इन मापों को अलग रखूँगा। RUM नमूने में आई ब्राउज़र गतिविधि समझने में मदद कर सकता है। मौजूदा सर्वर-साइड काउंटर अनुरोधों को फ़िल्टर करके लगाए गए अनुमान ही रहेंगे, सत्यापित पहचान नहीं। CDN अनुरोधों में फ़ाइलें और स्वचालित ट्रैफ़िक भी शामिल होते हैं। इन सभी को एक “आगंतुक” संख्या में जोड़ना नतीजे को कम ईमानदार बनाएगा, अधिक उपयोगी नहीं।

लागत सुरक्षा की सीमाएँ हैं

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

डिज़ाइन में एक अलार्म है जो आने वाली घटनाओं में तेज़ उछाल देखता है, और एक Lambda फ़ंक्शन है जो guest role पर स्पष्ट IAM रोक लगा सकता है। अलार्म और IAM बदलाव लागू होने के बाद इससे आगे का डेटा भेजना रोका जा सकता है। पहले से स्वीकार की गई घटनाएँ वापस नहीं ली जा सकतीं, और निगरानी तथा रोक दोनों में लागू होने का समय लगता है। यह सुरक्षा उपाय है, खर्च की पक्की सीमा नहीं।

मैं AWS बदलावों के लिए मौजूदा खाते-व्यापी मासिक रोक भी रखता हूँ और हर AWS बदलाव से पहले नई लागत समीक्षा चाहता हूँ। ये नियंत्रण मददगार हैं, लेकिन कोई भी वास्तविक समय में बिल की सटीक सीमा की गारंटी नहीं देता। अलार्म प्रतिक्रिया देने से पहले अचानक आई घटनाओं की लहर खर्च बढ़ा सकती है। यह बचा हुआ जोखिम निर्णय का हिस्सा है; भरोसा दिलाने वाला डैशबोर्ड इसे खत्म नहीं कर सकता।

सुविधा चालू है, लेकिन प्रमाण अभी जुटाने हैं

सहमति क्लाइंट और स्थानीयकृत गोपनीयता सूचना पहले से वेबसाइट पर हैं। क्लाइंट पहले अनुमति माँगता है और आगंतुक के “Allow” चुनने के बाद ही AWS SDK लोड करता है। सक्रियण रनबुक के अनुसार, 11 नवंबर 2026 को सीमित RUM डेटा-संग्रह अनुमति खोली गई। पाँच प्रतिशत सत्र-सैंपलिंग केवल सहमति के बाद लागू होती है; इससे सभी आगंतुकों की गिनती नहीं होती।

इससे पता चलता है कि डेटा भेजने का रास्ता खुला है, यह नहीं कि लाइव संकेत कैसा दिखता है। मैंने अभी वास्तविक ब्राउज़र घटनाओं की पुष्टि या उनसे बने बिल की जाँच नहीं की है। अलार्म सीमा का लाइव परीक्षण भी नहीं किया। तय ट्रिपवायर 60 सेकंड में कम से कम 20 एकत्रित घटनाओं पर नज़र रखता है और Lambda फ़ंक्शन से guest role पर IAM रोक लगाने को कहता है। पहले से स्वीकार घटनाएँ हटाई नहीं जा सकतीं; निगरानी, सूचना और IAM बदलाव लागू होने में समय लेते हैं। रोक लगने से पहले अचानक आया उछाल खर्च बढ़ा सकता है।

ट्रिपवायर प्रतिक्रिया का एक उपयोगी तरीका है, खर्च की पक्की सीमा नहीं। खाते की मौजूदा मासिक सुरक्षा-रोक सीमा पहुँचने पर आगे के एजेंट बदलाव रोकती है; यह सटीक बिल की गारंटी नहीं देती और पहले से चल रही सेवाएँ बंद नहीं करती। वास्तविक घटना मात्रा और लागत की पुष्टि होने तक इन सीमाओं को हर RUM नतीजे के साथ स्पष्ट रखना चाहिए।

मैं माप को सीमित और समझने योग्य रखना चाहता हूँ: पहले सहमति माँगना, सहमति देने वाले सत्रों के छोटे हिस्से का नमूना लेना, सर्वर और CDN के मौजूदा माप अलग रखना और साफ़ बताना कि डेटा तथा सुरक्षा उपाय क्या गारंटी नहीं देते।