गेस्ट WiFi प्रदाते बदलणे: मल्टि-साइट ठिकाणांसाठी मायग्रेशन चेकलिस्ट

अनेक ठिकाणी पसरलेल्या (मल्टी-साइट) व्हेन्यूजमध्ये गेस्ट WiFi प्रोव्हायडर्स बदलण्यासाठी गेस्ट डेटा एक्सपोर्ट करणे, RFC 2865 आणि RFC 2866 अंतर्गत क्लाउड RADIUS कॉन्फिगर करणे आणि टप्प्याटप्प्याने रोल आउट करण्यापूर्वी 14 दिवसांचा पायलट चालवणे आवश्यक आहे. Cisco Meraki किंवा HPE Aruba सारख्या वेंडर्सचे विद्यमान हार्डवेअर कोणतीही उपकरणे न बदलता इंटिग्रेट होते, तर 30 दिवसांच्या ओव्हरलॅपमध्ये समांतर रिपोर्टिंग राखल्याने अखंडित सेवा सुरक्षित राहते.

गेस्ट WiFi प्रोव्हायडर बदलताना प्रत्यक्षात काय करावे लागते?

गेस्ट WiFi प्रोव्हायडर बदलताना प्रामुख्याने तीन गोष्टी बदलतात: तुमचा गेस्ट डेटा, तुमचे नेटवर्क सेट्स आणि तुमचे रिपोर्टिंग. तुमचे अ‍ॅक्सेस पॉईंट्स आहेत तिथेच राहतात. Purple च्या Guest WiFi सारख्या क्लाउड ओव्हरलेसह, नवीन प्रोव्हायडर तुमच्याकडे आधीपासून असलेल्या हार्डवेअरवरच काम करतो. त्या हार्डवेअरमध्ये Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet यांचा समावेश आहे. यामागील सविस्तर कारण तुमच्या पुढील WiFi अपग्रेडसाठी नवीन हार्डवेअरची आवश्यकता का नाही यात स्पष्ट केले आहे.

गेस्ट WiFi मायग्रेशनमधील बहुतेक काम तीन संकल्पनांवर अवलंबून असते:

• कॅप्टिव्ह पोर्टल: अभ्यागतांना ऑनलाइन जाण्यापूर्वी दिसणारे साइन-इन पेज.
• वॉल्ड गार्डन (Walled garden): साइन-इन करण्यापूर्वी डिव्हाइस ज्या डोमेन्सपर्यंत पोहोचू शकते त्यांची सूची, जेणेकरून पोर्टल आणि कोणतीही सोशल लॉगिन पेजेस लोड होऊ शकतील.
• RADIUS: RFC 2865 मध्ये परिभाषित केलेला प्रोटोकॉल, ज्याचा वापर अ‍ॅक्सेस पॉईंट्स डिव्हाइसला प्रवेश द्यायचा की नाही हे सर्व्हरला विचारण्यासाठी करतात. त्याचा अकाउंटिंग विस्तार, RFC 2866, सेशनची सुरुवात, समाप्ती आणि कालावधी सर्व्हरला कळवतो.

यात दोन मोठ्या त्रुटी महत्त्वाच्या ठरतात: डार्क डे आणि लॉस्ट लिस्ट. डार्क डे म्हणजे एखादी सेटिंग चुकल्यामुळे गेस्ट ऑनलाइन येऊ न शकणारी साइट. लॉस्ट लिस्ट म्हणजे असा मार्केटिंग डेटाबेस ज्यावर तुम्ही यापुढे ईमेल पाठवू शकत नाही, कारण संमतीचा पुरावा (कन्सेंट एव्हिडन्स) जुन्या प्रोव्हायडरकडेच राहिला. खालील कामाचा क्रम या दोन्ही समस्या टाळण्यासाठी तयार केला गेला आहे.

गेस्ट WiFi प्रोव्हायडर बदलण्यापूर्वी तुम्हाला कशाची आवश्यकता आहे?

तुमच्या कराराच्या तारखा आणि डेटा क्लॉजेस

नेटवर्कपासून नव्हे, तर जुन्या करारापासून सुरुवात करा. तीन तारखा शोधा: नोटीसची अंतिम मुदत, सेवा समाप्तीची तारीख आणि डेटा परत मिळण्याची कोणतीही अंतिम मुदत. GDPR आर्टिकल 28(3)(g) अंतर्गत, कंट्रोलर म्हणून तुमच्या निवडीनुसार, प्रोसेसरने सेवेच्या शेवटी वैयक्तिक डेटा हटवला पाहिजे किंवा परत केला पाहिजे. नोटीस देण्यापूर्वी, जुन्या प्रोव्हायडरला लेखी स्वरूपात कळवा आणि डेटा "परत" मिळवण्याचा पर्याय निवडा.

नवीन सेवा थेट सुरू होणे आणि जुनी सेवा समाप्त होणे या दरम्यान किमान 30 दिवसांच्या ओव्हरलॅपचे नियोजन करा. नंतर स्पष्ट केलेल्या समांतर रिपोर्टिंग रनसाठी तुम्हाला या ओव्हरलॅपची आवश्यकता असते. नोटीस कालावधी 90 दिवसांचा असल्यास, उलट मोजा: पहिल्या पंधरवड्यात एक्सपोर्ट, 45 व्या दिवसापर्यंत पायलट, आणि 75 व्या दिवसापर्यंत अंतिम टप्पा.

प्रत्येक साइटची इन्व्हेंटरी

जे तुम्ही पाहू शकत नाही त्याचा कटओव्हर तुम्ही क्रमाने करू शकत नाही. प्रत्येक साइटसाठी एक पंक्ती (row) आणि हे स्तंभ (columns) असलेली एक शीट तयार करा:

• अ‍ॅक्सेस पॉईंट वेंडर आणि कंट्रोलर किंवा डॅशबोर्ड (उदा. Cisco Meraki डॅशबोर्ड, HPE Aruba Central, Ruckus SmartZone).
• अतिथी SSID नावे आणि गेस्ट ट्रॅफिक ज्यावर कार्यरत आहे असा कोणताही VLAN (व्हर्च्युअल LAN, एक स्वतंत्र नेटवर्क सेगमेंट).
• त्या साइटवरील फायरवॉल आणि ब्रॉडबँड लाइनची मालकी कोणाकडे आहे.
• एक नियुक्त स्थानिक संपर्क जो फोनवर पोर्टल लोड होत असल्याची खात्री करू शकेल.
• व्यवसायाचे पीक टाईम्स (ट्रेडिंग पीक्स) आणि ब्लॅकआउट तारखा.

जुन्या प्रोव्हायडरकडून स्पष्ट व अचूक (क्लीन) डेटा एक्सपोर्ट

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

फील्ड	तुम्हाला याची आवश्यकता का आहे	विनंती करावयाचा फॉरमॅट
ईमेल ॲड्रेस	मार्केटिंग आणि डुप्लिकेशन टाळण्यासाठी (डी-डुप्लिकेशन) प्रायमरी की	UTF-8 CSV, प्रति रो एक रेकॉर्ड
मोबाइल नंबर	SMS मार्केटिंग आणि मॅचिंग	ITU-T E.164 आंतरराष्ट्रीय फॉरमॅट
प्रति चॅनेल संमती (कन्सेंट) फ्लॅग	PECR अंतर्गत ईमेल आणि SMS संमती वेगवेगळ्या आहेत	प्रति चॅनेल एक true/false कॉलम
संमतीचा टाइमस्टॅम्प	संमती कधी दिली गेली हे सिद्ध करतो (GDPR Article 7(1))	UTC ऑफसेटसह ISO 8601
संमतीचे शब्द किंवा आवृत्ती	व्हिजिटरला काय सांगण्यात आले होते हे सिद्ध करतो	अर्काइव्ह केलेल्या पोर्टल कॉपीशी मॅप केलेला व्हर्जन ID
Capture साइट	संमती ज्या ठिकाणी गोळा केली गेली, त्या ठिकाणाशी (व्हेन्यूशी) जोडते	तुमच्या इन्व्हेंटरीशी जुळणारा साइट ID
संमती मागे घेणे आणि अनसबस्क्राइब्स	ज्यांनी ऑप्ट-आउट केले आहे त्यांना ईमेल पाठवण्यापासून प्रतिबंधित करते	तारखांसह स्वतंत्र सप्रेशन फाइल
भेटींचा इतिहास	रिपोर्ट रिकन्सिलिएशनसाठी बेसलाइन	प्रति साइट मासिक एकूण आकडेवारी, मागील 13 महिने

डेटा आल्यावर रो (ओळींची) संख्या तपासा. जुना डॅशबोर्ड 2,00,000 प्रोफाइल्स दाखवत असल्यास आणि फाइलमध्ये 1,60,000 असल्यास, कोणत्याही गोष्टीवर अंतिम स्वाक्षरी करण्यापूर्वी याचे कारण विचारा.

संमतीचा पुरावा जो स्थलांतरानंतरही वैध राहतो

GDPR Article 7(1) नुसार जिथे डेटा प्रोसेसिंग हे संमतीवर आधारित असते, तिथे कंट्रोलरने ते सिद्ध करणे आवश्यक आहे. ICO चे संमती मार्गदर्शन त्या रेकॉर्डमध्ये काय असावे हे स्पष्ट करते: कोणी संमती दिली, कधी, कशी, त्यांना काय सांगितले गेले आणि त्यांनी संमती मागे घेतली आहे का. "marketing = yes" असा कॉलम असलेली ईमेल ॲड्रेसेसची स्प्रेडशीट यापैकी कोणत्याही निकषांची पूर्तता करत नाही.

तीन पायऱ्यांद्वारे संमती विनाखंडितपणे पुढे नेली जाते:

1. जुन्या पोर्टलवरील मजकूर अर्काइव्ह करा. साइन-इन पेज आणि प्रायव्हसी नोटीसच्या प्रत्येक व्हर्जनचे तारखेसह स्क्रीनशॉट घ्या आणि प्रत्येक स्क्रीनशॉट संमती व्हर्जन फील्डशी मॅप करा.
2. संमती कोणाच्या नावे आहे ते तपासा. GDPR Recital 42 सांगते की डेटा सब्जेक्टला किमान कंट्रोलरची ओळख माहित असावी. तुमच्या व्हेन्यू ब्रँडला दिलेली संमती पुढे चालू राहते. जुन्या प्रोव्हायडरच्या स्वतःच्या मार्केटिंगसाठी दिलेली संमती पुढे चालू राहत नाही.
3. प्रथम सप्रेशन लिस्ट इंपोर्ट करा. ज्यांनी अनसबस्क्राइब केले आहे त्यांनी पहिल्या दिवसापासूनच नवीन सिस्टममध्ये अनसबस्क्राइब राहिलेले पाहिजे.

टाइमस्टॅम्प किंवा मजकुराची आवृत्ती नसलेले रेकॉर्ड्स मार्केटिंगसाठी वापरले जाऊ शकत नाहीत. ते डिलीट करण्याऐवजी मार्केटिंग संमती नसलेले कॉन्टॅक्ट्स म्हणून इंपोर्ट करा, जेणेकरून भेटींचा इतिहास सुरक्षित राहील.

तुम्ही प्रत्येक साइटनुसार अतिथी WiFi चे स्थलांतर कसे चालवाल?

पायरी 1: ॲक्सेस पॉइंटला हात लावण्यापूर्वी लिस्ट इंपोर्ट करा

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

Purple Engage हे CRM आणि मार्केटिंग प्लॅटफॉर्म्ससह समाकलित होते. तुमचे ईमेल प्लॅटफॉर्म अनसबस्क्राइब्ससाठी सिस्टम ऑफ रेकॉर्ड असल्यास, ते पहिल्या मोहिमेनंतर नव्हे, तर आधी कनेक्ट करा.

पायरी 2: कॅप्टिव्ह पोर्टल, वॉल्ड गार्डन आणि RADIUS सेटिंग्ज तयार करा

तुमच्याकडे आधीपासून असलेल्या ॲक्सेस पॉइंट्सवर Purple Access हे कॅप्टिव्ह पोर्टल आणि क्लाउड RADIUS हाताळते. प्रति ब्रँड एक पोर्टल टेम्पलेट तयार करा, त्यानंतर ते प्रत्येक साइटनुसार क्लोन करा जेणेकरून साइट ID सुरुवातीपासूनच योग्य राहील. जाणीवपूर्वक निवडलेल्या ऑप्ट-इन्ससह प्रति चॅनेल एक नवीन संमती मजकूर लिहा आणि गो-लाइव्ह होण्यापूर्वी त्याची आवृत्ती रेकॉर्ड करा.

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

पायरी 3: एका पायलट साइटचे कटओव्हर करा

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

किमान चार उपकरणांवर चाचणी करा: एक चालू iPhone, एक चालू Android फोन, एक Windows लॅपटॉप आणि एक macOS लॅपटॉप. तुम्ही देत असलेल्या प्रत्येक साइन-इन पद्धतीची चाचणी घ्या. त्यानंतर वेव्ह 1 पूर्वी पायलट 14 दिवस चालू ठेवा, कारण काही त्रुटी केवळ प्रत्यक्ष लोड असतानाच समोर येतात.

पायरी 4: टप्प्याटप्प्याने (वेव्ह्समध्ये) कटओव्हर करा

साइट्सचे गट करा जेणेकरून प्रत्येक वेव्ह तुम्ही आधीच सिद्ध केलेले कॉन्फिगरेशन पुन्हा वापरेल. हा निर्णय मॅट्रिक्स क्रम ठरवतो.

साइट प्रोफाइल	वेव्ह	कारण
प्रातिनिधिक साइट, सामान्य हार्डवेअर, IT जवळ	पायलट	30 ऐवजी एकाच साइटवर कॉन्फिगरेशनमधील त्रुटी शोधून काढते
पायलटसारखाच कंट्रोलर किंवा डॅशबोर्ड	वेव्ह 1	सिद्ध झालेले टेम्पलेट, सर्वात कमी जोखीम
वेगळा हार्डवेअर व्हेंडर	स्वतःचा पायलट, नंतर पुढील वेव्ह	वॉल्ड गार्डन आणि RADIUS सिंटॅक्स व्हेंडरनुसार बदलतात
हंगामी किंवा कमी व्यापाराच्या साइट्स	वेव्ह 1 किंवा 2	एखादी त्रुटी राहिल्यास कमी अभ्यागतांवर परिणाम होतो
फ्लॅगशिप किंवा सर्वाधिक महसूल देणाऱ्या साइट्स	अंतिम वेव्ह	सर्वात जास्त सिद्ध झालेले कॉन्फिगरेशन मिळते
योजनेदरम्यान इव्हेंट किंवा पीक तारखा असलेल्या साइट्स	पीक तारखांच्या दोन्ही बाजूंच्या 7-दिवसांच्या बफरच्या बाहेर	तुमच्या सर्वात व्यस्त काळात चेंज फ्रीझचे उल्लंघन नाही

प्रत्येक वेव्हमध्ये अशी संख्या ठेवा जी तुमची टीम एका शिफ्टमध्ये पडताळू शकेल. वेव्ह बंद करण्यापूर्वी प्रत्येक साइटवर पोर्टल लोड होत असल्याची खात्री स्थानिक संपर्काने केली पाहिजे.

प्रत्यक्ष उदाहरण परिस्थिती: 30 हॉटेल्सचा समूह

खालील आकडेवारी हे एक प्रत्यक्ष कार्यप्रणालीचे उदाहरण आहे, कोणतेही वास्तविक डिप्लॉयमेंट नाही. एका 30-हॉटेल्सच्या समूहाने 22 ठिकाणांवर Cisco Meraki वर आणि आठ ठिकाणांवर HPE Aruba वर अतिथी WiFi सुरू ठेवले आहे. त्यांच्या करारामध्ये 90 दिवसांच्या नोटीस कालावधीची अट आहे. तुम्ही आमच्या Hotels पृष्ठावर या क्षेत्राबद्दल अधिक वाचू शकता.

केलेली कारवाई. समूहाने Article 28 अंतर्गत "return" पर्याय निवडला आणि पहिल्याच दिवशी नोटीस दिली. दुसऱ्या आठवड्यात 2,10,000 रेकॉर्ड्ससह डेटा एक्सपोर्ट प्राप्त झाला. त्यापैकी, 31,000 रेकॉर्ड्समध्ये संमतीचा टाइमस्टॅम्प नव्हता आणि ते गैर-मार्केटेबल म्हणून Purple Engage मध्ये इंपोर्ट केले गेले. हा पायलट 14 दिवसांसाठी 120-खोल्यांच्या एका Meraki हॉटेलमध्ये चालवला गेला. उर्वरित Meraki हॉटेल्स डॅशबोर्ड टेम्पलेट्सचा वापर करून 10 आणि 11 च्या दोन टप्प्यांत स्थलांतरित करण्यात आले. Aruba इस्टेटचा स्वतःचा पायलट होता, त्यानंतर सातच्या एकाच टप्प्यात स्थलांतर झाले.

परिणाम. सर्व 30 हॉटेल्स सातव्या आठवड्यापर्यंत नवीन पोर्टलवर आले. कोणत्याही साइटवर सर्वात मोठा व्यत्यय फक्त 12 मिनिटांचा होता, जो रात्रभराच्या चेंज विंडो दरम्यान घडला. पायलटमधील दैनंदिन साइन-इन्स जुन्या प्रदात्याच्या आकड्यांशी 3% च्या मर्यादेत जुळले. जुना करार अतिरिक्त शिल्लक असलेल्या 40 दिवसांच्या ओव्हरलॅपसह समाप्त झाला.

नवीन अहवाल जुन्या अहवालांशी जुळतात हे तुम्ही कसे सिद्ध कराल?

पायलटमध्ये दोन्ही सिस्टीम्स समांतरपणे चालवा

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

• दैनिक साइन-इन्स.
• युनिक व्हिजिटर्स.
• नवीन विरुद्ध परत येणारे (रिटर्निंग) व्हिजिटर्स.
• सरासरी सेशन कालावधी.
• मार्केटिंग ऑप्ट-इन दर.

Purple चे WiFi Analytics हे प्रत्येक साइटनुसार आणि संपूर्ण इस्टेटमध्ये रिपोर्ट करते. सेशनचा कालावधी RADIUS अकाउंटिंगवर अवलंबून असतो, त्यामुळे त्या आकड्यावर विश्वास ठेवण्यापूर्वी अकाउंटिंग रेकॉर्ड्स येत आहेत का ते तपासा.

एकूण आकड्यांवर नव्हे, तर व्याख्यांवर ताळमेळ घाला

पहिल्या दिवशी एकूण आकडे क्वचितच जुळतात, आणि ती स्वतःमध्ये एक त्रुटी नसते. बहुतांश तफावत वेगवेगळ्या व्याख्यांमुळे निर्माण होते. एक प्रदाता प्रत्येक डिव्हाइस असोसिएशनला व्हिजिट म्हणून मोजू शकतो. दुसरा केवळ प्रमाणीकृत सेशन्स मोजतो. एक जण 30 मिनिटांमधील सेशन्स एकत्र करू शकतो, तर दुसरा कदाचित तसे करणार नाही.

प्रत्येक प्रदात्याची व्याख्या लिहून ठेवा, आणि मग योग्य घटकांची तुलना करा. डिव्हाइस गोपनीयता वैशिष्ट्ये देखील परत येणाऱ्या व्हिजिटर्सच्या संख्येवर परिणाम करतात. Apple ने iOS 14 मध्ये प्रायव्हेट ॲड्रेसेस आणले, आणि Android हे Android 10 पासून डिफॉल्टनुसार ॲड्रेसेस यादृच्छिक (randomises) करते. केवळ MAC ॲड्रेसद्वारे परत येणाऱ्या व्हिजिटर्सना ओळखणारा प्रदाता, साइन-इन ओळखीशी जुळवून घेणाऱ्या प्रदात्यापेक्षा कमी रिटर्न्स नोंदवेल.

सुरू करण्यापूर्वी एक सहनशीलता (tolerance) मर्यादा निश्चित करा, उदाहरणार्थ दैनिक साइन-इन्सवर 5%. आधीच एक संख्या मान्य केल्याशिवाय, प्रत्येक तफावत हा चर्चेचा मुद्दा बनतो.

नोटीस कालावधी संपण्यापूर्वी मंजुरी (साइन ऑफ) घ्या

एका पानाचे साइन-ऑफ तयार करा: तुलना केलेले मेट्रिक्स, प्रत्येक प्रदात्याची व्याख्या, तफावत आणि त्याचे स्पष्टीकरण. IT, मार्केटिंग आणि प्रोक्योरमेंट विभागांची त्यावर स्वाक्षरी घ्या. त्यानंतर जुन्या प्रदात्याकडून ऐतिहासिक अहवालांचा अंतिम एक्सपोर्ट घ्या, जेणेकरून वर्ष-दर-वर्ष तुलना स्थलांतरानंतरही शक्य होईल.

प्रत्यक्ष उदाहरण: 120-स्टोअर्सची रिटेल साखळी

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

काय केले गेले. पायलट स्टोअरमध्ये असे आढळले की Android उपकरणांवर सोशल लॉगिन अयशस्वी झाले. वॉल्ड गार्डनमध्ये पोर्टल डोमेन होते, परंतु आयडेंटिटी प्रोव्हायडरचे साइन-इन डोमेन नव्हते. IT ने वेव्ह १ पूर्वी हे दुरुस्त केले. पॅरलल रिपोर्टिंगमध्ये, जुन्या प्रोव्हायडरने Purple पेक्षा दररोज १८% जास्त भेटी दाखवल्या. जुन्या प्रोव्हायडरने प्रत्येक असोसिएशनची मोजणी केली होती. Purple ने ऑथेंटिकेटेड सेशन्स मोजले. केवळ ऑथेंटिकेटेड सेशन्सवर जुनी एक्स्पोर्ट पुन्हा चालवल्याने हा फरक २% पर्यंत कमी झाला.

परिणाम. सर्व १२० दुकाने चार साप्ताहिक टप्प्यांत (वेव्ह्स) स्थलांतरित झाली. कामाच्या वेळेत कोणत्याही दुकानाचे गेस्ट WiFi बंद पडले नाही. जुना करार संपण्याच्या तीन आठवडे आधी, मान्य केलेल्या ५% मर्यादेच्या तुलनेत २% च्या फरकावर रिकन्सिलिएशन मंजूर करण्यात आले.

कॅप्टिव्ह पोर्टल मायग्रेशन दरम्यान ॲक्सेस पॉइंटच्या कोणत्या सेटिंग्ज सर्वाधिक वेळा बिघडतात?

बहुतेक समस्या या काही मोजक्या सेटिंग्जमुळे उद्भवतात. हा तक्ता त्या प्रत्येकाची, त्याची लक्षणे आणि उपायांची माहिती देतो.

Setting	Symptom when wrong	Fix
वॉल्ड गार्डनमध्ये नवीन पोर्टल डोमेन गहाळ असणे	फोन कनेक्ट होतो, पोर्टल कधीही लोड होत नाही	Purple च्या व्हेंडर मार्गदर्शकातील प्रत्येक डोमेन जोडा, त्यानंतर जुन्या प्रोव्हायडरचे डोमेन काढून टाका
वॉल्ड गार्डनमध्ये सोशल लॉगिन डोमेन गहाळ असणे	ईमेल साइन-इन कार्य करते, सोशल लॉगिन अयशस्वी होते	व्हेंडर मार्गदर्शकामध्ये सूचीबद्ध केलेले आयडेंटिटी प्रोव्हायडर डोमेन जोडा
RADIUS शेअर्ड सिक्रेट जुळत नाही	साइन-इन स्वीकारले जाते, डिव्हाइस कधीही ऑनलाइन होत नाही	कंट्रोलर आणि नवीन सर्व्हर दोन्हीवर सिक्रेट पुन्हा प्रविष्ट करा
RADIUS अकाउंटिंग अक्षम केले आहे	साइन-इन्स दिसतात, सेशनचा कालावधी शून्य दिसतो	अंतरिम अपडेट्ससह अकाउंटिंग (RFC 2866) सक्षम करा
फायरवॉल RADIUS पोर्ट्स ब्लॉक करत आहे	केवळ एकाच साइटवर साइन-इन टाइम आउट होते	आउटबाउंड UDP 1812 आणि 1813 ना अनुमती द्या, जे RFC 2865 आणि RFC 2866 मध्ये नियुक्त केलेले पोर्ट्स आहेत
साइट आयडेंटिफायर चुकीच्या पद्धतीने मॅप केले आहे	सेशन्स चुकीच्या व्हेन्यूसाठी नोंदवले जातात	कंट्रोलरचा साइट आयडेंटिफायर Purple च्या साइट ID शी जुळवा
एका ॲक्सेस पॉइंट ग्रुपवर जुने रिडायरेक्ट शिल्लक राहिले आहे	निम्म्या साइटवर जुने पोर्टल दिसते	केवळ डीफॉल्टच नव्हे, तर प्रत्येक SSID आणि ॲक्सेस पॉइंट ग्रुपचे ऑडिट करा
जुन्या प्रोव्हायडरकडून सेशन टाइमआउट कॉपी केले आहे	भेटीदरम्यान पाहुण्यांना पुन्हा प्रॉम्प्ट केले जाते	टाइमआउट तुमच्या भेटीच्या कालावधीनुसार सेट करा; How to Implement Time and Bandwidth Restrictions on Guest WiFi पहा

जुन्या प्रोव्हायडरच्या अंतर्गत असलेली धोरणे (पॉलिसीज)

काही प्रोव्हायडर तुमच्या हार्डवेअरवर नव्हे, तर स्वतःच्या क्लाउडमध्ये कंटेंट फिल्टरिंग किंवा बँडविड्थ मर्यादा लागू करतात. तुम्ही बदल करता तेव्हा ही धोरणे कोणतीही पूर्वसूचना न देता बंद होतात. जुन्या प्रोव्हायडरने लागू केलेल्या प्रत्येक धोरणाची यादी तयार करा आणि कटओव्हर करण्यापूर्वी त्यातील प्रत्येकाची पुन्हा रचना करा. नाईट-टाइम व्हेन्यूजमध्ये ही समस्या सर्वाधिक उद्भवते, जसे की Nightclub and late-night venue WiFi providers: content filtering, peak capacity and staff access स्पष्ट करते.

घड्याळ आणि प्रमाणपत्राच्या समस्या

RADIUS अकाउंटिंग आणि पोर्टल प्रमाणपत्रे ही दोन्ही अचूक वेळेवर अवलंबून असतात. चुकीचे घड्याळ असलेला कंट्रोलर चुकीच्या दिवसावर नोंदवले जाणारे सेशन रेकॉर्ड तयार करतो. पायलट सुरू करण्यापूर्वी प्रत्येक कंट्रोलर एका विश्वासार्ह NTP (नेटवर्क टाइम प्रोटोकॉल) स्रोताकडे निर्देशित करा.

स्विच करण्यासाठी किती खर्च येतो आणि त्या बदल्यात तुम्हाला काय मिळते?

बजेटसाठी खर्चाचे घटक

सध्याच्या हार्डवेअरवरील स्विचमध्ये खर्चाचे चार घटक असतात, आणि यांपैकी एकही हार्डवेअरचा नसतो:

• ओव्हरलॅप परवाना. किमान 30 दिवसांसाठी दोन्ही प्रोव्हायडर्सना पैसे देण्याचे नियोजन करा.
• प्रति साइट IT वेळ. टेम्पलेट-आधारित डॅशबोर्ड पायलट प्रोजेक्टनंतर हा वेळ लक्षणीयरित्या कमी करतात. स्टँडअलोन कंट्रोलर्सवरील साइट्ससाठी जास्त वेळ लागतो.
• डेटा शुद्धीकरण (डेटा क्लीन्सिंग). संमतीच्या आवृत्त्या मॅप करणे, डुप्लिकेट रेकॉर्ड्स काढणे आणि सप्रेशन लिस्ट लोड करण्याचे काम कोणालातरी करावे लागते.
• स्थानिक पडताळणी. प्रत्येक साइटवरील एक नियुक्त व्यक्ती त्या दिवशी पोर्टल लोड होत असल्याची खात्री करते.

Purple तीन प्लॅन्सद्वारे परवाने देते: Connect, Capture आणि Engage. खरेदी विभागाने कटओव्हरपासूनच्या संपूर्ण वर्षासाठी खर्च न काढता ओव्हरलॅप कालावधीनुसार आवश्यक असलेल्या प्लॅनची किंमत ठरवली पाहिजे.

तुम्हाला काय परत मिळते

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

तसेच, तुम्ही मोठ्या प्रमाणावर सिद्ध झालेल्या प्लॅटफॉर्मचा भाग बनता. Purple 90 हून अधिक देशांमधील 80,000+ ठिकाणी कार्यरत आहे आणि वर्षाला 500 दशलक्ष युजर्स व लॉगइन्स हाताळते. Purple 99.999% अपटाइम देते, ISO 27001 प्रमाणपत्र धारण करते आणि GDPR चे पालन करते.

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

गेस्ट WiFi प्रोव्हायडर Purple वर स्विच करण्यासाठी आम्हाला नवीन अ‍ॅक्सेस पॉइंट्सची आवश्यकता आहे का?

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

स्विच केल्यानंतर आम्ही आमच्या अस्तित्वात असलेल्या गेस्ट लिस्टला ईमेल पाठवणे सुरू ठेवू शकतो का?

होय, जर संमतीचा पुरावा लिस्टसोबत ट्रान्सफर होत असेल तर. GDPR कलम 7(1) नुसार तुम्हाला संमती सिद्ध करणे आवश्यक असते, त्यामुळे प्रत्येक रेकॉर्डसाठी टाइमस्टॅम्प, चॅनेल, कॅप्चर साइट आणि अभ्यागताने पाहिलेला मजकूर आवश्यक असतो. Purple Engage तो इतिहास जोडून संमती असलेले रेकॉर्ड्स इंपोर्ट करते. पुराव्याशिवाय असलेले रेकॉर्ड्स नॉन-मार्केटेबल म्हणून इंपोर्ट केले जावेत. तुमच्या ब्रँडऐवजी जुन्या प्रोव्हायडरला त्याच्या स्वतःच्या नावावर दिलेली संमती ट्रान्सफर होत नाही.

मल्टि-साइट गेस्ट WiFi मायग्रेशनसाठी किती वेळ लागतो?

20 ते 150 साइट्सच्या बहुतांश इस्टेट्ससाठी सहा ते आठ आठवड्यांचे नियोजन करा. यामध्ये दोन आठवड्यांची निर्यात, 14 दिवसांचा पायलट आणि तुमच्या टीमद्वारे एका शिफ्टमध्ये व्हेरिफाय करता येईल अशा आकाराच्या कटओव्हर लहरी (waves) समाविष्ट आहेत. क्लाउड डॅशबोर्ड शेअर करणाऱ्या साइट्स अधिक वेगाने स्थलांतरित होतात कारण एक सिद्ध टेम्पलेट अनेकांसाठी लागू होते. पॅरेलल रिपोर्टिंगसाठी किमान 30 दिवसांचा ओव्हरलॅप ठेवून, तुमच्या जुन्या कराराच्या नोटीस तारखेपासून योजनेची सुरुवात करा.

कटओव्हर दरम्यान आमच्या साइट्स ऑफलाइन जातील का?

नाही, तुम्ही पायलट-नंतर-वेव्ह्ज या क्रमाचे पालन केल्यास असे होणार नाही. मिनिटांत रोलबॅक करण्यासाठी जुने कॉन्फिगरेशन सेव्ह करून, प्रत्येक साइट तिच्या सर्वात शांत ट्रेडिंग अवर्सदरम्यान बदलली जाते. बहुतांश व्यत्यय कंट्रोलरला नवीन सेटिंग्ज पाठवण्यासाठी जेवढा वेळ लागतो तेवढाच वेळ टिकतात. दीर्घकाळासाठी आऊटेज निर्माण करणाऱ्या त्रुटी, जसे की गहाळ वॉल्ड गार्डन डोमेन्स किंवा ब्लॉक केलेले RADIUS पोर्ट्स, संपूर्ण इस्टेटऐवजी पायलट साइटवरच पकडले जातात.

प्रोव्हायडर्स दरम्यान गेस्ट डेटा स्थलांतरित करणे GDPR चे पालन करते का?

होय, जेव्हा तुम्ही कंट्रोलर म्हणून काम करता आणि दोन्ही प्रोव्हायडर्स करारांतर्गत प्रोसेसर्स म्हणून काम करतात. GDPR कलम 28(3)(g) नुसार जुन्या प्रोसेसरने सेवेच्या शेवटी, तुमच्या पसंतीनुसार, वैयक्तिक डेटा परत करणे किंवा हटवणे आवश्यक आहे. नोटीस देण्यापूर्वी लेखी स्वरूपात "परत करा" (return) निवडा. सप्रेशन सूची प्रथम सोबत घ्या, जेणेकरून ज्यांनी ऑप्ट आउट केले आहे ते ऑप्ट आउटच राहतील. Purple हे GDPR चे पालन करते आणि ISO 27001 प्रमाणित आहे.

जुन्या प्रोव्हायडरकडे अजूनही असलेल्या डेटाचे काय होते?

तुमचा करार GDPR कलम 28 चे पालन करत असल्यास, सेवा संपल्यानंतर जुन्या प्रोव्हायडरने तो डेटा हटवणे आवश्यक आहे. तुम्ही तुमच्या निर्यातीची पडताळणी केल्यानंतर आणि रिपोर्टिंग साइन-ऑफ पूर्ण केल्यानंतर डेटा हटवल्याची लेखी खात्री मागा. ऐतिहासिक रिपोर्ट्सची अंतिम निर्यात आधीच घ्या, कारण वर्ष-दर-वर्षाची तुलना त्या इतिहासावर अवलंबून असते. नियामक किंवा अभ्यागताने विचारणा केल्यास डेटा प्रक्रिया करण्याच्या नोंदींसोबत डेटा हटवल्याची खात्री (confirmation) ठेवा.

Purple चे रिपोर्ट्स आमच्या जुन्या प्रोव्हायडरच्या आकडेवारीशी जुळतात हे आम्ही कसे सिद्ध करू?

पायलट साइटवर 14 दिवस दोन्ही सिस्टीम्स समांतरपणे चालवा आणि पाच निकषांची तुलना करा: दैनंदिन साइन-इन्स, युनिक व्हिजिटर्स, नवीन विरूद्ध परत येणारे, सेशनचा कालावधी आणि ऑप्ट-इन दर. बहुतांश तफावती या व्हिजिटच्या वेगवेगळ्या व्याख्यांमुळे येतात, सदोष डेटाने नाही. प्रत्येक प्रोव्हायडरच्या व्याख्येचे दस्तऐवजीकरण करा, आगाऊ स्वरूपात 5% सारखी टॉलरन्स मर्यादा मान्य करा आणि जुना करार संपण्यापूर्वी साइन ऑफ करा.

Purple आमच्या सध्याच्या CRM आणि ईमेल प्लॅटफॉर्मशी कनेक्ट होऊ शकते का?

होय, Purple CRM आणि मार्केटिंग प्लॅटफॉर्मसह इंटिग्रेट होते. इम्पोर्ट केलेले गेस्ट प्रोफाइल्स, नवीन साइन-इन्स आणि संमतीतील बदल तुमची मार्केटिंग टीम आधीच वापरत असलेल्या सिस्टीममध्ये प्रवाहित होऊ शकतात. तुमच्या पहिल्या पोस्ट-मायग्रेशन मोहिमेपूर्वी इंटिग्रेशन कनेक्ट करा, जेणेकरून कोणत्याही बाजूने केलेले अनसबस्क्राइब पहिल्या ईमेलपासूनच लागू केले जाईल. हे WiFi साइन-इन आणि ईमेलवर एकच संमती रेकॉर्ड ठेवते, जी ICO च्या संमती विषयक मार्गदर्शक तत्त्वांची तुमच्याकडून अपेक्षा असते.