गguest WiFi RFP आवश्यकता: ऑनबोर्डिंग, सुरक्षा आणि अ‍ॅनालिटिक्समध्ये काय नमूद करावे

गेस्ट WiFi RFP ने पाच क्षेत्रांमध्ये मोजता येण्याजोग्या आवश्यकता निर्धारित केल्या पाहिजेत. ऑनबोर्डिंग: कॅप्टिव्ह पोर्टल, संमती संकलन आणि WCAG 2.2 ॲक्सेसिबिलिटी. सुरक्षा: IEEE 802.1X, RADIUS, Passpoint आणि WPA3. हार्डवेअर: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist आणि Ubiquiti UniFi साठी नामांकित सपोर्ट. अनुपालन: GDPR, PCI DSS v4.0 आणि प्रोटेक्टिव्ह DNS. ॲनालिटिक्स: एक्स्पोर्ट करण्यायोग्य फर्स्ट-पार्टी डेटा. पुराव्याच्या आधारे बोलीदारांना गुण द्या.

गेस्ट WiFi RFP मध्ये प्रत्यक्षात कशाचा उल्लेख असणे आवश्यक आहे?

गेस्ट WiFi RFP "पाहुण्यांसाठी विनामूल्य WiFi" सारख्या मोघम माहितीचे अशा आवश्यकतांमध्ये रूपांतर करतो ज्या बोलीदार पूर्ण करू शकतो किंवा त्यात अपयशी ठरू शकतो. लोक कसे जोडले जातात, ट्रॅफिक कसे सुरक्षित केले जाते आणि प्लॅटफॉर्म कोणत्या हार्डवेअरवर चालला पाहिजे हे ते परिभाषित करते. तसेच वैयक्तिक डेटा कसा हाताळला जातो आणि तुम्हाला कोणता रिपोर्टिंग परत मिळतो हे देखील ते निश्चित करते.

कमकुवत RFP सहसा एकाच प्रकारे अपयशी ठरतात. ते मानकांऐवजी वैशिष्ट्यांची यादी करतात, ज्यामुळे प्रत्येक बोलीदार "होय" असे उत्तर देतो आणि सर्व प्रतिसाद एकसारखे दिसतात. यावरील उपाय म्हणजे प्रत्येक रेषेला एक नामांकित मानक, तुम्हाला अपेक्षित असलेला पुरावा आणि पायलट चाचणी जोडणे होय.

अनेक ठिकाणे असलेल्या मालमत्तेसाठी, RFP कंत्राटाच्या कालावधीसाठी तुमचे ऑपरेटिंग मॉडेल देखील निर्धारित करतो. कॅप्टिव्ह पोर्टल हे एक वेब पेज आहे जे डिव्हाइसला इंटरनेट ॲक्सेस मिळण्यापूर्वी दिसते. तुम्ही प्रत्येक साइटवर एकच कॅप्टिव्ह पोर्टल आणि एक संमती नोंद चालवू शकता. दुसरा पर्याय म्हणजे प्रत्येक हार्डवेअर व्हेंडरसाठी वेगळी सेटअप असणे. विखुरलेली मालमत्ता नंतर एकत्र करण्यासाठी आता एकाच मानकाचा उल्लेख करण्यापेक्षा खूप जास्त खर्च येतो.

ही मार्गदर्शिका तुम्हाला आवश्यकतांचे शब्दरचना, स्कोरिंग मॅट्रिक्स आणि पायलट चाचण्या देते. हॉटेल्स, रिटेल, हेल्थकेअर, ट्रेन, स्टेडियम आणि सार्वजनिक क्षेत्रातील ठिकाणांसाठी तुम्ही वापरू शकाल असा गेस्ट WiFi RFP टेंम्प्लेट म्हणून याकडे पहा.

गेस्ट WiFi RFP लिहिण्यापूर्वी तुम्हाला कशाची गरज आहे?

पहिल्या मसुद्यापूर्वी पाच इनपुट्स गोळा करा. यातील प्रत्येक गोष्ट कंत्राट दिल्यानंतर बदल करण्याच्या विनंत्यांचा सामान्य स्त्रोत रोखते.

• प्रत्येक ठिकाणानुसार हार्डवेअरची यादी. प्रत्येक साइटवर ॲक्सेस पॉइंट (AP) व्हेंडर, मॉडेल, व्यवस्थापन प्लॅटफॉर्म आणि फर्मवेअरची नोंद घ्या. प्रत्येक साइट क्लाउड डॅशबोर्ड वापरते की ऑन-प्रीमिस कंत्रोलर वापरते याची नोंद घ्या. आमचे मार्गदर्शक WLC (वायरलेस LAN कंट्रोलर) म्हणजे काय आणि तुम्हाला अजूनही त्याची गरज आहे का? यातील फरक स्पष्ट करते.
• प्रकारानुसार ठिकाणांची यादी. उभ्या प्रकारानुसार आणि आकारानुसार साइट्सचे गट करा, कारण स्टेडियमचा आतील भाग आणि हॉटेलच्या लॉबीसाठी वेगळ्या ऑनबोर्डिंगची आवश्यकता असते. प्रत्येक ठिकाण ज्या लोकांसाठी आहे त्यांची नावे नोंदवा: पाहुणे, खरेदीदार, प्रवासी, चाहते, रुग्ण किंवा भेट देणारे.
• डेटा मॅप. डेटा कंट्रोलर म्हणून कोण काम करेल, कोणत्या सिस्टम्सना WiFi डेटा मिळेल आणि तुम्ही तो किती काळ ठेवाल हे ठरवा. RFP बाहेर जाण्यापूर्वी तुमच्या डेटा संरक्षण अधिकाऱ्याने यावर स्वाक्षरी केली पाहिजे.
• तुमच्या पेमेंट सीमा. कार्डद्वारे पेमेंट स्वीकारणारी प्रत्येक साइट सूचीबद्ध करा. पेमेंट साधने गेस्ट ट्रॅफिकसह स्विचेस किंवा सर्किट्स शेअर करतात का ते नोंदवा. हे तुमचे PCI DSS स्कोप परिभाषित करते.
• यशाची मानके. तुम्ही रिपोर्ट कराल अशा संख्यांवर सहमती दर्शवा, जसे की लॉगिन, ऑप्ट-इन दर, पुन्हा भेट देणारे अभ्यागत आणि सपोर्ट तिकिटे. त्यानंतर बिडर्स त्यांचे रिपोर्टिंग यापैकी प्रत्येक कसे जनरेट करते ते दाखवू शकतात.

सुरुवातीपासूनच IT, सुरक्षा, डेटा सुरक्षा, मार्केटिंग आणि व्हेन्यू ऑपरेशन्स टीम्सना समाविष्ट करा. गेस्ट WiFi या सर्व पाचही टीम्सना स्पर्श करते. एका टीमने लिहिलेली आवश्यकता अनेकदा दुसऱ्या टीमला अडथळा ठरते.

तुम्ही विभागांनुसार गेस्ट WiFi RFP आवश्यकता कशा लिहाल?

RFC 2119 मधील कन्व्हेन्शनचे अनुसरण करून प्रत्येक आवश्यकता "must" किंवा "should" सह लिहा. "must" ही पास-किंवा-फेल अट आहे. "should" ला गुण दिले जातात. बिडर्सना प्रत्येक ओळीचे उत्तर पुराव्यासह देण्यास सांगा: एक दस्तऐवज, प्रमाणपत्र, संदर्भ साइट किंवा लाइव्ह प्रात्यक्षिक.

ऑनबोर्डिंग आणि कॅप्टिव्ह पोर्टल आवश्यकता

ऑनबोर्डिंग ही अशी जागा आहे जिथे गेस्ट तुमच्या नेटवर्कचे मूल्यमापन करतात आणि जिथे तुमच्या संमतीचे रेकॉर्ड तयार होतात. ही कॅप्टिव्ह पोर्टल RFP चेकलिस्ट महत्त्वाच्या बाबींचा समावेश करते.

• लॉगिन पद्धती. प्लॅटफॉर्मने ईमेल, सोशल लॉगिन, SMS आणि ॲक्सेस कोडला सपोर्ट केला पाहिजे, जो प्रति व्हेन्यू कॉन्फिगर करण्यायोग्य असावा.
• जाणीवपूर्वक निवडीचे ऑप्ट-इन्स. मार्केटिंग संमती ही एक वेगळी, अनटिक केलेली निवड असावी, जी नियम व अटींच्या स्वीकृतीसह कधीही एकत्रित केलेली नसावी. GDPR कलम 7 मध्ये संमती स्पष्ट असणे आणि ती काढून घेणे देण्याइतकेच सोपे असणे आवश्यक आहे.
• ॲक्सेसिबिलिटी. कॅप्टिव्ह पोर्टलने WCAG 2.2 पातळी AA चे पालन केले पाहिजे.
• विश्वासार्ह पोर्टल शोध. प्लॅटफॉर्मने कॅप्टिव्ह पोर्टल API (RFC 8908) आणि DHCP कॅप्टिव्ह पोर्टल पर्यायाला (RFC 8910) सपोर्ट केला पाहिजे. दोन्ही आधुनिक उपकरणांना रीडायरेक्ट लूपशिवाय लॉगिन पेज शोधण्यास मदत करतात.
• पुन्हा भेट देणाऱ्या अभ्यागतांची ओळख. iOS 14 आणि Android 10 व पुढील आवृत्त्या डीफॉल्टनुसार यादृच्छिक (randomised) MAC पत्ते वापरतात. डिव्हाइसच्या हार्डवेअर पत्त्यावर अवलंबून न राहता ते पुन्हा भेट देणाऱ्या गेस्टला कसे ओळखतात हे बिडर्सना विचारा.
• केंद्रीय नियंत्रण. मुख्य कार्यालयाने प्रत्येक व्हेन्यूसाठी स्थानिक ओव्हरराइड्ससह, ब्रँडिंग, नियम आणि संमतीचा मजकूर मध्यवर्तीपणे व्यवस्थापित केला पाहिजे.

Purple गेस्ट WiFi कॅप्टिव्ह पोर्टलमध्ये जाणीवपूर्वक निवडीचे ऑप्ट-इन्स समाविष्ट करते आणि संपूर्ण मालमत्तेमध्ये ते मध्यवर्तीपणे व्यवस्थापित करते.

ऑथेंटिकेशन, RADIUS आणि Passpoint आवश्यकता

RADIUS हा एक प्रोटोकॉल आहे ज्याचा वापर AP द्वारे मध्यवर्ती सर्व्हरला डिव्हाइसला प्रवेश द्यायचा की नाही हे विचारण्यासाठी केला जातो. हे RFC 2865 मध्ये परिभाषित केले आहे. RFC 2866 मध्ये परिभाषित केलेले RADIUS अकाऊंटिंग, सत्र सुरू होणे, थांबणे आणि डेटा वापर रेकॉर्ड करते. मल्टी-व्हेन्यू मालमत्तेसाठी, खालील बाबी नमूद करा.

• रिडंडन्सीसह क्लाउड RADIUS. एखादे डेटा सेंटर त्रुटीग्रस्त झाल्यासही ऑथेंटिकेशन कार्य करत राहिले पाहिजे. आर्किटेक्चर आणि 12 महिन्यांची मोजलेली उपलब्धता मागा.
• एनक्रिप्टेड RADIUS ट्रान्सपोर्ट. जिथे RADIUS सार्वजनिक इंटरनेट ओलांडते, तिथे RadSec (RADIUS ओव्हर TLS, RFC 6614) किंवा एनक्रिप्टेड टनेलची आवश्यकता असावी.
• डायनॅमिक ऑथोरायझेशन. प्लॅटफॉर्मने रीकनेक्ट करण्यास सक्ती न करता सत्र समाप्त किंवा बदलण्यासाठी CoA मेसेज (RFC 5176) पाठवले पाहिजेत.
• विभागीकरण (Segmentation). गेस्ट ट्रॅफिक हा स्वतःच्या VLAN वर असावा, जो कर्मचारी आणि पेमेंट सिस्टीमपासून वेगळा केलेला एक लॉजिकल नेटवर्क विभाग आहे. गेस्ट डिव्हाइसेसना एकमेकांशी संपर्क साधण्यापासून रोखण्यासाठी क्लायंट आयसोलेशन असणे आवश्यक आहे.
• ओपन नेटवर्क्सवर एनक्रिप्शन. Enhanced Open (ऑपर्च्युनिस्टिक वायरलेस एनक्रिप्शन, RFC 8110) सह WPA3 असणे आवश्यक आहे. हे शेअर केलेल्या पासवर्डशिवाय प्रत्येक कनेक्शन एनक्रिप्ट करते.
• आवश्यकतेनुसार वैयक्तिक कळा (Individual keys). iPSK (आयडेंटिटी प्री-शेअर की) शेअर केलेल्या नेटवर्कवर प्रत्येक व्यक्तीला किंवा डिव्हाइसला स्वतःचा WiFi पासवर्ड देते. हे दीर्घकाळ राहणारे पाहुणे, प्रदर्शक आणि इव्हेंट क्रू यांच्यासाठी सुयोग्य आहे. Purple हे SecurePass द्वारे प्रदान करते.

Passpoint, ज्याला Hotspot 2.0 देखील म्हटले जाते, ते IEEE 802.11u वर आधारित आहे. हे डिव्हाइसला कोणत्याही कॅप्टिव्ह पोर्टलशिवाय आपोआप नेटवर्क शोधण्याची आणि जोडण्याची अनुमती देते. ऑथेंटिकेशन हे IEEE 802.1X वर चालते, जे पोर्ट-आधारित नेटवर्क ॲक्सेस कंट्रोलचे मानक आहे, ज्यामुळे क्रेडेंशियल्स एनक्रिप्टेड राहतात. Wireless Broadband Alliance द्वारे संचलित OpenRoaming, हे Passpoint वर बनवलेले फेडरेशन आहे. हे लोकांना त्यांच्याकडे आधीपासून असलेल्या आयडेंटिटीसह सहभागी नेटवर्क्समध्ये सामील होण्याची अनुमती देते.

पहिल्या टप्प्यात Passpoint आणि OpenRoaming ला "आवश्यक" (should) आवश्यकता म्हणून निर्दिष्ट करा, ज्यामध्ये किमतीचा रोडमॅप समाविष्ट असेल. Purple हे OpenRoaming ला सपोर्ट करते, ज्यामुळे परत येणारे पाहुणे तुमच्या ठिकाणी आपोआप कनेक्ट होऊ शकतात.

RFP मध्ये स्टाफ WiFi चा देखील समावेश असल्यास, Microsoft Entra ID, Okta आणि Google Workspace सोबत इंटिग्रेशन असणे आवश्यक करा. यामुळे नवीन जॉइन होणारे, बदलणारे आणि सोडणारे कर्मचारी मॅन्युअल पासवर्ड बदलांशिवाय नेटवर्क ॲक्सेसशी सुसंगत राहतात.

हार्डवेअर-न्यूट्रल AP सुसंगतता

"प्रमुख एंटरप्राइझ हार्डवेअरशी सुसंगत" याला गुण देता येत नाहीत. करारादरम्यान तुम्ही वापरत असलेल्या किंवा स्वीकारू शकणाऱ्या प्रत्येक प्लॅटफॉर्मचे नाव द्या. नंतर प्रत्येकावर समान पाच क्षमता असणे आवश्यक करा.

1. बाह्य कॅप्टिव्ह पोर्टल सपोर्ट.
2. RADIUS ऑथेंटिकेशन आणि अकाउंटिंग.
3. वॉल गार्डन: पोर्टल आणि सोशल लॉगिनसाठी आवश्यक असणारी डोमेन्सची प्री-लॉगिन अनुमती सूची (allow list).
4. CoA सपोर्ट, किंवा सत्रे समाप्त करण्यासाठी दस्तऐवजीकृत पर्याय.
5. प्रकाशित इंटिग्रेशन मार्गदर्शक आणि त्या प्लॅटफॉर्मवर किमान एक थेट संदर्भ (live reference).

व्हेंडर	RFP मध्ये नाव द्यावयाचा मॅनेजमेंट प्लॅटफॉर्म	मागवायचा किमान पुरावा
Cisco Meraki	Meraki डॅशबोर्ड	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
HPE Aruba	HPE Aruba नेटवर्किंग सेंट्रल किंवा मोबिलिटी कंट्रोलर	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
Ruckus	RUCKUS SmartZone किंवा RUCKUS One	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
Juniper Mist	Juniper Mist क्लाउड	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
Ubiquiti UniFi	UniFi नेटवर्क ॲप्लिकेशन	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
Cambium	cnMaestro	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
Extreme	ExtremeCloud IQ	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
Fortinet	FortiGate इंटिग्रेटेड वायरलेस कंट्रोलर	इंटिग्रेशन मार्गदर्शक, थेट संदर्भ, तुमच्या फर्मवेअरवर पायलट
प्रत्येक बोलीदाराला ते सपोर्ट करत असलेल्या फर्मवेअर रेंज नमूद करण्यास सांगा, आणि नंतर तुमच्या स्वत:च्या सिस्टीमविरुद्ध त्यांची चाचणी घ्या. Purple हे हार्डवेअर-अॅग्नोस्टिक आहे आणि सर्व आठ प्लॅटफॉर्मवर क्लाउड ओव्हरले म्हणून चालते. यात जुनी सिस्टीम काढून नवीन बसवण्याची (rip and replace) गरज नाही. तुमच्या पुढील WiFi अपग्रेडसाठी नवीन हार्डवेअरची आवश्यकता का नाही यात व्यावसायिक बाबींचे स्पष्टीकरण दिले आहे. Ruckus मालमत्तांसाठी, Ruckus SmartZone आणि RUCKUS One गेस्ट WiFi विरुद्ध एक्सटर्नल कॅप्टिव्ह पोर्टल प्लॅटफॉर्म पहा.

GDPR च्या आवश्यक अटी

गेस्ट WiFi मोठ्या प्रमाणावर वैयक्तिक डेटा गोळा करतो, त्यामुळे करारामध्ये या अटी असणे आवश्यक आहे.

• GDPR मधील कलम 28 चे पालन करणारा डेटा प्रोसेसिंग करार, ज्यामध्ये उद्देश, सुरक्षा, सब-प्रोसेसर्स आणि डेटा हटवणे (deletion) या बाबी समाविष्ट आहेत.
• प्रत्येक ऑप्ट-इनसाठी टाइमस्टॅम्प, वर्डिंग व्हर्जन आणि चॅनेल दर्शवणारे सहमतीचे रेकॉर्ड, जे मागणीनुसार एक्सपोर्ट केले जाऊ शकतात.
• कलम 5(1)(e) मधील स्टोरेज मर्यादा तत्त्वानुसार, स्वयंचलित हटवण्याच्या (deletion) सुविधेसह कॉन्फिगर करण्यायोग्य रिटेंशन.
• एका व्यक्तीचा डेटा शोधण्यासाठी, एक्सपोर्ट करण्यासाठी आणि हटवण्यासाठी डेटा सब्जेक्ट टूल्स. कलम 12(3) अंतर्गत तुम्ही एका महिन्याच्या आत विनंत्यांना प्रतिसाद दिला पाहिजे.
• कलम 33(2) च्या आवश्यकतेनुसार, प्रोसेसरकडून कोणत्याही विलंबाशिवाय उल्लंघनाची सूचना (Breach notification). त्यानंतर कलम 33(1) अंतर्गत नियामकाला सूचित करण्यासाठी तुमच्याकडे 72 तास असतात.
• आंतरराष्ट्रीय ट्रान्सफर. बोलीदाराने डेटा कोठे ठेवला जातो आणि यूके किंवा EEA बाहेर कोणत्याही प्रोसेसिंगसाठी ट्रान्सफर मेकॅनिझम काय आहे हे नमूद केले पाहिजे.
• कलम 32 साठी सुरक्षिततेचा पुरावा, आदर्शपणे ISO 27001 प्रमाणपत्र.

Purple हे ISO 27001 प्रमाणित आहे आणि GDPR, CCPA व Cyber Essentials चे पालन करते.

PCI DSS च्या आवश्यक अटी

गेस्ट WiFi कधीही तुमच्या कार्डधारक डेटा एन्व्हायर्नमेंट (CDE) च्या आत नसावा. CDE मध्ये कार्ड डेटा स्टोअर, प्रोसेस किंवा ट्रान्समिट करणाऱ्या सिस्टीम्सचा समावेश होतो. PCI DSS v4.0 तुम्हाला सेगमेंटेशनद्वारे स्कोप कमी करण्याची अनुमती देते, परंतु ते कार्य करते हे तुम्हाला सिद्ध करावे लागेल.

• गेस्ट ट्रॅफिक कधीही CDE मधून जात नाही, याची लेखी पुष्टी बोलीदाराने केली पाहिजे आणि डिझाइनचे दस्तऐवजीकरण केले पाहिजे.
• डिझाइनने तुमच्या सेगमेंटेशन पेनिट्रेशन टेस्टला सपोर्ट केला पाहिजे, जे आवश्यकता 11.4.5 अंतर्गत किमान दर 12 महिन्यांनी आवश्यक आहे.
• कॅप्टिव्ह पोर्टलवर कोणताही कार्ड डेटा एंटर केला जाऊ नये. कोणत्याही पेड ॲक्सेससाठी PCI DSS चे पालन करणाऱ्या पेमेंट प्रदात्याचा वापर केला पाहिजे, ज्याचे अटेस्टेशन ऑफ कॉम्प्लायन्स (Attestation of Compliance) पुरवले गेले पाहिजे.
• आवश्यकता 11.2.1 अंतर्गत अनधिकृत वायरलेस ॲक्सेस पॉईंट्ससाठी तुमची त्रैमासिक चाचणी अजूनही गेस्ट क्षेत्रांना समाविष्ट करते.

प्रोटेक्टिव्ह DNS च्या आवश्यक अटी

प्रोटेक्टिव्ह DNS हे अशा डोमेन्सचे निरसन (resolving) करण्यापासून उपकरणांना थांबवते जे मालवेअर, फिशिंग किंवा कमांड-ॲन्ड-कंट्रोल सर्व्हर होस्ट करण्यासाठी ओळखले जातात. यूके नॅशनल सायबर सिक्युरिटी सेंटर (NCSC) सार्वजनिक क्षेत्रातील संस्थांना प्रोटेक्टिव्ह DNS सेवा प्रदान करते. खालील गोष्टी नमूद करा.

• थ्रेट फीड्स. बोलीदाराने त्याचे थ्रेट इंटेलिजन्स स्रोत आणि ते किती वेळा अपडेट होतात हे नमूद केले पाहिजे.
• प्रत्येक ठिकाणानुसार (venue) कॅटेगरी फिल्टरिंग, उदाहरणार्थ लायब्ररी आणि कौटुंबिक क्षेत्रांमध्ये अडल्ट कंटेंट ब्लॉक करणे.
• ब्रँडेड ब्लॉक पेज जे भेट देणाऱ्या वापरकर्त्याला एखादी साइट का ब्लॉक केली गेली याचे कारण सांगते.
• एन्क्रिप्टेड DNS पॉलिसी. सर्व्हिस HTTPS (RFC 8484) द्वारे DNS आणि TLS (RFC 7858) द्वारे DNS कसे हाताळते ते नमूद करा, जे फिल्टरिंग बायपास करू शकते.
• लॉग रिटेंशन आपल्या GDPR वेळापत्रकाशी जुळलेले असणे आवश्यक आहे. लॉग-इन केलेल्या ओळखीशी जोडलेले DNS लॉग हे वैयक्तिक डेटा असतात.
• दरमहा रिपोर्टिंग प्रति ठिकाण (venue) ब्लॉक केलेल्या धोक्यांचे.

Purple चे सुरक्षा ॲड-ऑन्स हे SecurePass, Verify आणि Shield आहेत. वरील कलमांच्या संदर्भात प्रत्येकाच्या प्रात्यक्षिकासाठी (demonstration) विचारा.

ॲनालिटिक्स आणि एकत्रीकरण (integration) आवश्यकता

एंटरप्राइज गेस्ट WiFi खरेदीमध्ये सहसा ॲनालिटिक्सला कमी महत्त्व दिले जाते, तरीही येथूनच तुम्हाला परतावा (return) मिळतो. खालील गोष्टी स्पष्ट करा.

• प्रति ठिकाण आणि इस्टेटनुसार मेट्रिक्स: युनिक व्हिजिटर्स, नवीन विरूद्ध परत येणारे व्हिजिटर्स, ड्वेल टाइम, भेट देण्याची वारंवारता आणि पीक अव्हर्स.
• डॅशबोर्ड आणि शेड्यूल केलेले रिपोर्ट्स, रोल-बेस्ड ॲक्सेससह जेणेकरून व्हेन्यू मॅनेजर्सना फक्त त्यांची स्वतःची साइट दिसेल.
• एकत्रीकरण तुमच्या CRM आणि मार्केटिंग प्लॅटफॉर्मसह, API किंवा नॅटिव्ह कनेक्टर्सद्वारे. संमतीची स्थिती (consent status) प्रत्येक रेकॉर्डसोबत गेली पाहिजे.
• डेटा मालकी. तुमच्याकडे फर्स्ट-पार्टी डेटाची मालकी असते. CSV किंवा JSON मधील संपूर्ण एक्सपोर्ट कोणत्याही वेळी आणि बाहेर पडताना, कोणत्याही अतिरिक्त शुल्काशिवाय उपलब्ध असावा.

Purple WiFi Analytics या मेट्रिक्सचा प्रति ठिकाण रिपोर्ट देते आणि CRM व मार्केटिंग प्लॅटफॉर्मसह समाकलित होते.

सर्व्हिस लेव्हल्स आणि सर्टिफिकेशन्स

• उपलब्धता. सर्व्हिस क्रेडिट्ससह मासिक अपटाइम SLA ची आवश्यकता ठेवा. Purple चे प्लॅटफॉर्म 99.999% अपटाइमवर चालते.
• सपोर्ट. तास, तीव्रतेनुसार रिस्पॉन्स टाइम आणि नाव दिलेला एस्केलेशन कॉन्टॅक्ट निर्दिष्ट करा.
• सर्टिफिकेशन्स. ISO 27001 ची आवश्यकता ठेवा. वैयक्तिक डेटा हाताळणाऱ्या UK मध्यवर्ती सरकार करारांसाठी procurement policy note 09/14 अंतर्गत Cyber Essentials आवश्यक आहे.
• स्केल संदर्भ. तुमच्या आकाराचे संदर्भ मागा. Purple 90 हून अधिक देशांमध्ये 80,000+ लाइव्ह व्हेन्यू चालवते आणि 2024 मध्ये 440 दशलक्ष लॉगिन हाताळले (Purple चा स्वतःचा डेटा).

आवश्यकता स्कोअरिंग मॅट्रिक्स

क्षेत्र	आवश्यकता	प्राधान्य	मागवण्यासाठी पुरावा
ऑनबोर्डिंग	स्वतंत्र, अनटिक केलेले मार्केटिंग ऑप्ट-इन	असणे आवश्यक आहे	पोर्टल स्क्रीनशॉट आणि नमुना संमती एक्सपोर्ट
ऑनबोर्डिंग	WCAG 2.2 AA कॅप्टिव्ह पोर्टल	असणे आवश्यक आहे	स्वतंत्र ॲक्सेसिबिलिटी ऑडिट रिपोर्ट
ऑथेंटिकेशन	फेलओव्हरसह क्लाउड RADIUS	असणे आवश्यक आहे	आर्किटेक्चर डायग्राम आणि 12 महिन्यांचा उपलब्धता डेटा
ऑथेंटिकेशन	RadSec किंवा एन्क्रिप्टेड RADIUS टनेल	असणे आवश्यक आहे	डिझाइन दस्तऐवज
ऑथेंटिकेशन	Passpoint आणि OpenRoaming	असावे	लाइव्ह संदर्भ साइट
एन्क्रिप्शन	WPA3 आणि एन्हान्स्ड ओपन	असावे	तुमच्या AP वर पायलट टेस्ट
हार्डवेअर	तुम्ही चालवत असलेल्या प्रत्येक प्लॅटफॉर्मसाठी नामनिर्देशित सपोर्ट	असणे आवश्यक आहे	एकत्रीकरण मार्गदर्शक आणि पायलट निकाल
GDPR	कलम 28 DPA आणि रिटेंशन नियंत्रणे	असणे आवश्यक आहे	स्वाक्षरी केलेले DPA आणि रिटेंशन सेटिंग्ज डेमो
PCI DSS	CDE बाहेर गेस्ट ट्रॅफिक	असणे आवश्यक आहे	सेगमेंटेशन डिझाइन आणि चाचणी सपोर्ट स्टेटमेंट
प्रोटेक्टिव्ह DNS	ब्लॉक पेजसह थ्रेट आणि कॅटेगरी फिल्टरिंग	सार्वजनिक क्षेत्रासाठी आवश्यक, इतरत्र असावे	लाइव्ह ब्लॉक चाचणी आणि नमुना मासिक अहवाल
ॲनालिटिक्स	एक्झिटवर पूर्ण डेटा एक्सपोर्ट	आवश्यक (Must)	कॉन्ट्रॅक्ट क्लॉज आणि नमुना एक्सपोर्ट फाइल
सर्व्हिस	सर्व्हिस क्रेडिटसह अपटाइम SLA	आवश्यक (Must)	SLA शेड्युल

बिडर काम पूर्ण करू शकतो की नाही हे तुम्ही कसे तपासाल?

दोन टप्प्यांत मूल्यमापन करा: आधी कागदोपत्री, नंतर पायलट. कागदोपत्री टप्प्यात कोणतीही "आवश्यक" (must) अट पूर्ण न झाल्यास तो बिडर बाद केला जातो. उर्वरित "हवी असलेली" (should) अटी तुमच्या प्राधान्यांनुसार वेट करा. एक सामान्य विभागणी म्हणजे सुरक्षा आणि अनुपालन ३०%, ऑनबोर्डिंग २०%, हार्डवेअर १५%, ॲनालिटिक्स १५%, सर्व्हिस १०% आणि कमर्शियल्स १०%.

वेगवेगळ्या हार्डवेअर प्लॅटफॉर्मवरील दोन किंवा अधिक ठिकाणांवर ३० दिवसांचा पायलट चालवा. यापैकी प्रत्येकाची चाचणी घ्या आणि ते पास झाले की नापास, याची नोंद ठेवा.

• कॅप्टिव्ह पोर्टल iOS, Android, Windows आणि macOS वर पहिल्याच वेळी दृश्यमान होते.
• दुसऱ्या भेटीदरम्यान परत येणाऱ्या पाहुण्याची (guest) ओळख पटवली जाते.
• संमती एक्सपोर्ट टाइमस्टॅम्प आणि शब्दरचना व्हर्जन दाखवते.
• हटवण्याच्या (erasure) विनंतीमुळे ती व्यक्ती प्लॅटफॉर्मवरून आणि तुमच्या कनेक्ट केलेल्या CRM वरून हटवली जाते.
• सिम्युलेट केलेल्या RADIUS फेलओव्हरदरम्यान ऑथेंटिकेशन सुरू राहते.
• CoA मेसेज पुन्हा कनेक्ट न करता सत्र (session) संपवतो.
• ओळखलेले टेस्ट डोमेन तुमच्या ब्रँडेड पेजसह ब्लॉक केले जाते.
• गेस्ट VLAN कडून पेमेंट नेटवर्कवर कनेक्शनचा प्रयत्न अयशस्वी होतो.

थ्रूपूट आणि कव्हरेजची चाचणी प्लॅटफॉर्मपेक्षा स्वतंत्रपणे करा. इंटरनेटसाठी WiFi: हे कसे कार्य करते आणि काय तपासायचे यामध्ये मूलभूत गोष्टी समाविष्ट आहेत.

व्यवहारात हे कसे दिसते?

खालील तीन परिस्थिती या सामान्य खरेदी पद्धतींवरून तयार केलेली प्रातिनिधिक उदाहरणे आहेत. या ग्राहकांच्या केस स्टडीज नाहीत.

दोन हार्डवेअर प्लॅटफॉर्मवरील ४५ हॉटेल्सचा समूह

परिस्थिती. समूहाने ३० हॉटेल्समध्ये Cisco Meraki आणि १५ अधिग्रहित ठिकाणांवर HPE Aruba चालवले. प्रत्येक मालमत्तेचे स्वतःचे कॅप्टिव्ह पोर्टल होते. १५ अधिग्रहित ठिकाणांवर, मार्केटिंग संमती अटींच्या स्वीकृतीसह समाविष्ट (bundled) केली होती.

काय केले गेले. RFP मध्ये दोन्ही प्लॅटफॉर्मना "आवश्यक" (must) अटी म्हणून नाव दिले गेले. यासाठी एक पोर्टल, एक संमती रेकॉर्ड आणि स्वतंत्र ऑप्ट-इन आवश्यक होते. पायलटमध्ये प्रत्येक प्लॅटफॉर्मवरील एका हॉटेलचा समावेश होता.

निकाल. पाचपैकी दोन बिडर्स हार्डवेअरच्या अटीत नापास झाले कारण ते फक्त एकाच प्लॅटफॉर्मला सपोर्ट करत होते. विजेत्या ओवरलेने सर्व १५ Aruba ठिकाणांना त्यांच्या विद्यमान APs वर कायम ठेवले. गो-लाइव्ह होण्यापूर्वी सर्व १५ ठिकाणांवर समाविष्ट केलेली संमती हटवली गेली.

PCI DSS स्कोपमधील १२० दुकानांची रिटेल साखळी

परिस्थिती. जुन्या दुकानांमध्ये पेमेंट टर्मिनल्स गेस्ट APs सोबत स्विचेस शेअर करत होते. त्यामुळे गेस्ट WiFi साखळीच्या PCI DSS मूल्यांकनामध्ये समाविष्ट होते.

काय केले गेले. RFP मध्ये डॉक्युमेंटेड सेगमेंटेशन डिझाइन आणि 11.4.5 पेनिट्रेशन टेस्टसाठी लिखित सपोर्ट आवश्यक होता. यात कॅप्टिव्ह पोर्टलवर कार्ड एंट्रीवरही बंदी घातली गेली.

निकाल. सर्व १२० दुकानांमध्ये वार्षिक सेगमेंटेशन चाचणी यशस्वी झाली. गेस्ट WiFi हे PCI DSS च्या स्कोपमधून बाहेर पडले, ज्यामुळे असेसॉरला पुनरावलोकन कराव्या लागणाऱ्या सिस्टम्सची मर्यादा कमी झाली.

२५ ग्रंथालये आणि क्रीडा केंद्रे असलेली परिषद (council)

परिस्थिती. परिषदेला कुटुंबांसाठी सुरक्षित सार्वजनिक WiFi, Cyber Essentials आणि सुलभ प्रवेश असलेले लॉगिन पेज आवश्यक होते.

काय केले गेले. मुलांच्या क्षेत्रांसाठी श्रेणी फिल्टरिंग आणि एनक्रिप्टेड DNS पॉलिसीसह प्रोटेक्टिव्ह DNS ही एक "अत्यावश्यक" गोष्ट होती. कौन्सिलच्या रिटेंशन शेड्यूलनुसार DNS लॉग 90 दिवसांसाठी ठेवण्यात आले होते.

निकाल. सातपैकी तीन बोलीदाते WCAG 2.2 गेटमध्ये अपयशी ठरले. पायलट दरम्यान, एका शॉर्टलिस्ट केलेल्या बोलीदात्याचे फिल्टरिंग DNS over HTTPS द्वारे बायपास केले गेले, ज्यामुळे त्यांना स्पर्धेतून बाहेर काढण्यात आले.

गेस्ट WiFi खरेदीमध्ये काय चूक होते आणि तुम्ही ती कशी सुधारू शकता?

प्रत्येक बोलीदाता "होय" असे उत्तर देतो

कारण: आवश्यकतांमध्ये मानकांऐवजी वैशिष्ट्यांचे वर्णन असते. उपाय: प्रत्येक ओळीसाठी RFC, IEEE मानक किंवा GDPR लेखाचे नाव द्या आणि पुराव्याची मागणी करा.

कॅप्टिव्ह पोर्टल दिसण्यात अपयशी ठरते

कारण: अपूर्ण वॉल्ड गार्डन किंवा कमकुवत कॅप्टिव्ह पोर्टल डिटेक्शन. उपाय: RFC 8908 आणि RFC 8910 सपोर्टची आवश्यकता ठेवा आणि पायलटमध्ये चार ऑपरेटिंग सिस्टीमची चाचणी घ्या.

अभ्यागतांची संख्या जास्त फुगलेली दिसते

कारण: रँडम केलेल्या MAC ॲड्रेसमुळे एकच डिव्हाइस अनेक उपकरणांसारखे दिसते. उपाय: लॉगिन ओळखीच्या आधारावर ओळखण्याची आवश्यकता ठेवा आणि परत येणाऱ्या अभ्यागतांची गणना कशी केली जाते याचे स्पष्टीकरण बोलीदात्यांकडून मागा.

संमती कायदेशीरदृष्ट्या टिकत नाही

कारण: अटींसह बंडल केलेले ऑप्ट-इन्स, किंवा दाखवलेल्या शब्दांचा कोणताही रेकॉर्ड नसणे. उपाय: वेगळे, अनटिक केलेले ऑप्ट-इन्स आणि व्हर्जन केलेले संमती रेकॉर्ड आवश्यक करा.

तुम्ही सिस्टीम सोडूसकत नाही

कारण: कोणताही डेटा एक्सपोर्ट क्लॉज नसणे. उपाय: सिस्टीम सोडताना विनामूल्य CSV किंवा JSON मध्ये पूर्ण एक्सपोर्ट आवश्यक करा.

करार नवीन हार्डवेअर घेण्यास भाग पाडतो

कारण: व्हेंडर एकाच AP ब्रँडशी जोडलेला असणे. उपाय: तुम्ही चालवत असलेल्या प्रत्येक प्लॅटफॉर्मचे नाव देणारा हार्डवेअर-न्यूट्रल क्लॉज ठेवा.

याचा खर्च किती येतो आणि तुम्हाला त्यातून काय परत मिळते?

सहा खर्चाच्या घटकांसाठी बजेट ठरवा: सॉफ्टवेअर परवाने, कोणतेही हार्डवेअर, इन्स्टॉलेशन, इंटरनेट सर्किट्स, सपोर्ट आणि तुमच्या स्वतःच्या टीमचा वेळ. तुम्ही निवडलेली आर्किटेक्चर मुख्य फरक ठरवते.

दृष्टिकोन	हार्डवेअर खर्च	मल्टी-व्हेंडर इस्टेट	संमती आणि डेटा	प्रत्येक ठिकाणावरील बदल
विद्यमान APs वर क्लाउड ओव्हरले (Purple)	काहीही नाही: विद्यमान APs वर चालते	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet मधील एकच पोर्टल	मध्यवर्ती संमती रेकॉर्ड आणि तुमच्या मालकीचा फर्स्ट-पार्टी डेटा	विद्यमान APs वर SSID आणि RADIUS कॉन्फिगरेशन
AP व्हेंडरचे बिल्ट-इन कॅप्टिव्ह पोर्टल	सध्याच्या प्लॅटफॉर्मवर काहीही नाही	प्रत्येक हार्डवेअर प्लॅटफॉर्मसाठी एक वेगळे पोर्टल	संमती आणि अभ्यागत डेटा प्रत्येक प्लॅटफॉर्मवर स्वतंत्रपणे ठेवला जातो	प्रत्येक प्लॅटफॉर्मवर पुनरावृत्ती केलेले कॉन्फिगरेशन
रिप-अँड-रिप्लेस मॅनेज्ड नेटवर्क	प्रत्येक ठिकाणी नवीन APs आणि परवाने	संपूर्ण इस्टेटमध्ये एकाच हार्डवेअर व्हेंडरची सक्ती	प्रदात्याच्या कराराच्या अटींद्वारे निर्धारित	प्रत्येक साइटवर नवीन AP इन्स्टॉलेशन

बोलीदात्यांना एकाच आधारावर किंमत देण्यास सांगा: पूर्ण कालावधीसाठी प्रति ठिकाण निश्चित वार्षिक किंमत. ऑनबोर्डिंग, सपोर्ट, अपडेट्स आणि एक्झिट कॉस्ट आयटमइज्ड असण्याची आवश्यकता ठेवा. Purple तीन प्लॅन्ससाठी कोट करते, Connect, Capture आणि Engage, ज्यामध्ये SecurePass, Verify आणि Shield हे सुरक्षा ॲड-ऑन्स आहेत.

हा परतावा चार ठिकाणांवरून मिळतो. तुम्हाला कायदेशीर संमतीचे समर्थन असलेला फर्स्ट-पार्टी डेटा मिळतो. कर्मचार्‍यांचे नियोजन करण्यासाठी तुम्हाला पीक अव्हर्स आणि ड्वेल टाइम दिसतो. ओव्हरलेमुळे तुमचा हार्डवेअरवरील खर्च वाचतो. एकापेक्षा जास्त प्लॅटफॉर्म्स ऐवजी तुम्हाला सपोर्ट करण्यासाठी एकच प्लॅटफॉर्म मिळतो. Purple ने 2012 पासून, 80,000+ पेक्षा जास्त लाइव्ह वेन्यूजमध्ये हे प्रदान केले आहे.

वारंवार विचारले जाणारे प्रश्न

गेस्ट WiFi प्लॅटफॉर्म आमच्याकडे आधीपासून असलेल्या ॲक्सेस पॉइंट्सवर चालू शकतो का?

होय. Purple हे हार्डवेअर-अॅग्नॉस्टिक आहे आणि Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet वर क्लाउड ओव्हरले म्हणून चालते. तुमचे APs रेडिओ आणि ट्रॅफिक हाताळणे सुरू ठेवतात. Purple कॅप्टिव्ह पोर्टल, क्लाउड RADIUS, संमतीच्या नोंदी आणि ॲनालिटिक्स प्रदान करते. तुमच्या RFP मध्ये, तुम्ही वापरत असलेल्या प्रत्येक प्लॅटफॉर्मचे नाव द्या आणि कंत्राट देण्यापूर्वी तुमच्या स्वतःच्या फर्मवेअरवर पायलटची आवश्यकता ठेवा.

आम्ही RFP मध्ये व्हेंडर्सना गेस्ट WiFi ची किंमत कशी मागावी?

कंत्राटाच्या संपूर्ण कालावधीसाठी प्रति वेन्यू निश्चित वार्षिक किंमत मागा, ज्यामध्ये ॲड-ऑन्स स्वतंत्रपणे नमूद केलेले असतील. बोली लावणाऱ्यांनी ऑनबोर्डिंग, सपोर्ट, सॉफ्टवेअर अपडेट्स आणि बाहेर पडताना डेटा एक्सपोर्ट यांचा समावेश करणे आणि हार्डवेअरचा कोणताही खर्च नमूद करणे आवश्यक करा. Purple हे Connect, Capture आणि Engage या तीन प्लॅन्सवर आधारित दरपत्रक देते, ज्यामध्ये SecurePass, Verify आणि Shield हे सिक्युरिटी ॲड-ऑन्स आहेत. यामुळे तुम्हाला प्रत्येक रेषेची तुलना करणे सोपे जाते.

आमचे गेस्ट WiFi नेटवर्क PCI DSS च्या कक्षेत येते का?

ते तुमच्या कार्डधारक डेटा वातावरणापासून वेगळे केले असल्यास ते कक्षेत असू नये. PCI DSS v4.0 तुम्हाला सेगमेंटेशनद्वारे व्याप्ती कमी करण्याची अनुमती देते, परंतु ते कार्य करते हे तुम्हाला सिद्ध करावे लागेल. आवश्यकता 11.4.5 नुसार दर 12 महिन्यांनी किमान एकदा सेगमेंटेशन नियंत्रणांचे पेनिट्रेशन टेस्टिंग आवश्यक आहे. गेस्ट ट्रॅफिक कधीही पेमेंट सिस्टीममधून जात नाही आणि कॅप्टिव्ह पोर्टलवर कोणताही कार्ड डेटा प्रविष्ट केला जात नाही हे स्पष्ट करा.

GDPR अंतर्गत गेस्ट WiFi डेटासाठी डेटा कंट्रोलर कोण आहे?

सामान्यतः तुम्ही कंट्रोलर असता आणि WiFi व्हेंडर हा तुमचा प्रोसेसर असतो. त्यामुळे कंत्राटामध्ये उद्देश, सुरक्षा, सब-प्रोसेसर्स, हटवणे आणि उल्लंघन सूचना समाविष्ट करणारा कलम 28 डेटा प्रोसेसिंग करार असणे आवश्यक आहे. तुमच्या RFP मध्ये एक्सपोर्ट करता येण्याजोग्या संमतीच्या नोंदी आणि कॉन्फिगर करण्यायोग्य रिटेंशनची देखील आवश्यकता असणे आवश्यक आहे. कलम 12(3) द्वारे निर्धारित एका महिन्याच्या अंतिम मुदतीत ॲक्सेस आणि इरेजर्स विनंत्यांना प्रतिसाद देण्यासाठी साधने जोडा.

आम्हाला पहिल्या दिवसापासून Passpoint किंवा OpenRoaming ची गरज आहे का?

नाही, परंतु तुम्ही दोन्हीसाठी किंमत निश्चित केलेला रोडमॅप मागितला पाहिजे. संमती आणि फर्स्ट-पार्टी डेटा कॅप्चर करण्यासाठी कॅप्टिव्ह पोर्टल हा पहिल्या भेटीचा योग्य अनुभव राहतो. Passpoint आणि OpenRoaming त्यानंतर परत येणाऱ्या पाहुण्यांना कोणत्याही लॉगिन पेजशिवाय, एनक्रिप्टेड 802.1X ऑथेंटिकेशन वापरून आपोआप कनेक्ट होऊ देतात. Purple हे OpenRoaming ला सपोर्ट करते, त्यामुळे तुम्ही नंतर त्याच कंत्राटात स्वयंचलित कनेक्शन जोडू शकता.

प्रोटेक्टिव्ह DNS हा गेस्ट WiFi कंत्राटाचा भाग असावा का?

होय, विशेषतः सार्वजनिक-क्षेत्र आणि कौटुंबिक ठिकाणांसाठी. प्रोटेक्टिव्ह DNS उपकरणांना मालवेअर, फिशिंग आणि कमांड-अँड-कंट्रोल सर्व्हरशी जोडलेल्या डोमेनपर्यंत पोहोचण्यापासून रोखते. हे प्रत्येक ठिकाणानुसार श्रेणी फिल्टरिंग देखील लागू करू शकते. परिषद, ग्रंथालये आणि आरोग्यसेवा साइट्ससाठी हे "अनिवार्य" करा. तुमच्या GDPR वेळापत्रकानुसार ब्रँडेड ब्लॉक पेज, एन्क्रिप्टेड DNS पॉलिसी, मासिक रिपोर्टिंग आणि लॉग रिटेंशन आवश्यक आहे.

अतिथी WiFi प्लॅटफॉर्म बदलल्याने किती व्यत्यय येतो?

जेव्हा नवीन प्लॅटफॉर्म ओव्हरले म्हणून चालतो, तेव्हा बदलणे हा प्रत्येक ठिकाणचा कॉन्फिगरेशन बदल असतो, हार्डवेअर प्रोजेक्ट नाही. Purple सध्याच्या पायाभूत सुविधांवर लेयर करते, त्यामुळे तुमचे AP, केबलिंग आणि सर्किट्स जाग्यावरच राहतात. वेगवेगळ्या हार्डवेअरवर दोन ठिकाणी 30 दिवसांचे पायलट रन करा, नंतर टप्प्याटप्प्याने रोल आउट करा. प्रथम बाहेर जाणाऱ्या प्लॅटफॉर्मवरून संमतीच्या नोंदी एक्सपोर्ट करा, जेणेकरून कोणतेही कायदेशीर ऑप्ट-इन गमावले जाणार नाहीत.

आमच्या AP व्हेंडरच्या प्लॅटफॉर्ममध्ये तयार केलेले कॅप्टिव्ह पोर्टल का वापरू नये?

कारण इन-बिल्ट पोर्टल ऑनबोर्डिंग, संमती आणि डेटाला एकाच हार्डवेअर ब्रँडशी जोडते. अधिग्रहण आणि रीफ्रेश चक्रांनंतर, मल्टी-वेन्यू इस्टेट क्वचितच एकाच प्लॅटफॉर्मवर राहतात. एक स्वतंत्र प्लॅटफॉर्म हार्डवेअर काहीही असले तरी, प्रत्येक साइटवर एक कॅप्टिव्ह पोर्टल, एक संमती नोंद आणि एक ॲनालिटिक्स व्ह्यू ठेवते. ते तुमच्या डेटाचे आणि भविष्यातील प्रत्येक हार्डवेअर रीफ्रेशच्या वेळी तुमच्या वाटाघाटीच्या स्थानाचे संरक्षण करते.