गेस्ट WiFi प्रोवाइडर बदलना: मल्टी-साइट वेन्यू के लिए माइग्रेशन चेकलिस्ट

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

गेस्ट WiFi प्रोवाइडर स्विच करने में वास्तव में क्या शामिल है?

गेस्ट WiFi प्रोवाइडर स्विच तीन चीज़ों को स्थानांतरित करता है: आपका गेस्ट डेटा, आपकी नेटवर्क सेटिंग्स और आपकी रिपोर्टिंग। आपके एक्सेस पॉइंट वहीं रहते हैं जहाँ वे हैं। Purple के गेस्ट WiFi जैसे क्लाउड ओवरले के साथ, नया प्रोवाइडर आपके पहले से मौजूद हार्डवेयर पर ही काम करता है। उस हार्डवेयर में Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet शामिल हैं। इसके पीछे का तर्क Why your next WiFi upgrade doesn't need new hardware में शामिल किया गया है।

गेस्ट WiFi माइग्रेशन में अधिकांश काम तीन शब्दों से जुड़ा होता है:

• कैप्टिव पोर्टल: साइन-इन पेज जो किसी विज़िटर को ऑनलाइन आने से पहले दिखाई देता है।
• वॉल्ड गार्डन (Walled garden): उन डोमेन की सूची जहाँ कोई डिवाइस साइन-इन से पहले पहुँच सकता है, ताकि पोर्टल और कोई भी सोशल लॉगिन पेज लोड हो सकें।
• RADIUS: RFC 2865 में परिभाषित वह प्रोटोकॉल जिसका उपयोग एक्सेस पॉइंट सर्वर से यह पूछने के लिए करते हैं कि किसी डिवाइस को अनुमति दी जाए या नहीं। इसका अकाउंटिंग एक्सटेंशन, RFC 2866, सेशन शुरू होने, रुकने और उसकी अवधि की रिपोर्ट सर्वर को वापस भेजता है।

दो विफलताएँ जो मायने रखती हैं, वे हैं डार्क डे (dark day) और लॉस्ट लिस्ट (lost list)। डार्क डे वह साइट है जहाँ कोई सेटिंग छूट जाने के कारण गेस्ट ऑनलाइन नहीं आ पाते हैं। लॉस्ट लिस्ट वह मार्केटिंग डेटाबेस है जिसे आप अब ईमेल नहीं भेज सकते क्योंकि सहमति का प्रमाण पुराने प्रोवाइडर के पास ही रह गया था। नीचे दिया गया कार्य क्रम इन दोनों को रोकने के लिए तैयार किया गया है।

गेस्ट WiFi प्रोवाइडर बदलने से पहले आपको क्या चाहिए?

आपके अनुबंध की तारीखें और डेटा क्लॉज

नेटवर्क से नहीं, बल्कि पुराने अनुबंध से शुरुआत करें। तीन तारीखें पता करें: नोटिस की समय सीमा, सेवा समाप्ति की तारीख और डेटा वापसी की कोई भी समय सीमा। GDPR के अनुच्छेद 28(3)(g) के तहत, सेवा समाप्त होने पर एक प्रोसेसर को पर्सनल डेटा को हटाना या वापस करना होगा, जो कंट्रोलर के रूप में आपकी पसंद पर निर्भर करता है। पुराने प्रोवाइडर को लिखें और नोटिस देने से पहले लिखित में "वापसी" (return) का विकल्प चुनें।

नई सेवा के लाइव होने और पुरानी सेवा के समाप्त होने के बीच कम से कम 30 दिनों के ओवरलैप की योजना बनाएँ। आपको बाद में वर्णित समानांतर रिपोर्टिंग चलाने के लिए उस ओवरलैप की आवश्यकता होगी। यदि नोटिस की अवधि 90 दिन है, तो उल्टी गिनती करें: पहले पखवाड़े में एक्सपोर्ट करें, 45वें दिन तक पायलट रन करें, 75वें दिन तक अंतिम चरण पूरा करें।

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

आप उस कटओवर का क्रम तय नहीं कर सकते जिसे आप देख नहीं सकते। प्रत्येक साइट के लिए एक पंक्ति (रो) और इन कॉलम के साथ एक शीट बनाएँ:

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

पुराने प्रदाता से एक स्पष्ट और त्रुटिरहित (क्लीन) एक्सपोर्ट

लिखित रूप में एक्सपोर्ट का अनुरोध करें और फ़ॉर्मेट निर्दिष्ट करें। अस्पष्ट अनुरोध से अस्पष्ट फ़ाइल ही मिलती है। यह तालिका बताती है कि क्या मांगना चाहिए।

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

फ़ाइल प्राप्त होने पर पंक्तियों की संख्या जाँचें। यदि पुराना डैशबोर्ड 200,000 प्रोफ़ाइल दिखाता है और फ़ाइल में 160,000 हैं, तो किसी भी चीज़ को साइन ऑफ़ करने से पहले कारण पूछें।

सहमति के साक्ष्य जो माइग्रेशन के बाद भी मान्य रहें

GDPR अनुच्छेद 7(1) कहता है कि जहाँ डेटा प्रोसेसिंग सहमति पर निर्भर करती है, वहाँ कंट्रोलर को इसे प्रदर्शित करने में सक्षम होना चाहिए। ICO का सहमति मार्गदर्शन बताता है कि उस रिकॉर्ड में क्या शामिल होना चाहिए: किसने सहमति दी, कब, कैसे, उन्हें क्या बताया गया था और क्या उन्होंने सहमति वापस ले ली है। "marketing = yes" कॉलम वाली ईमेल पतों की स्प्रेडशीट इनमें से किसी भी परीक्षण पर खरी नहीं उतरती है।

तीन चरण सहमति को पूरी तरह से सुरक्षित रखते हैं:

1. पुराने पोर्टल के शब्दों को आर्काइव करें। साइन-इन पेज और गोपनीयता नोटिस के प्रत्येक संस्करण का तारीख सहित स्क्रीनशॉट लें, और प्रत्येक को सहमति संस्करण फ़ील्ड से मैप करें।
2. जाँचें कि सहमति किसके नाम पर है। GDPR विचार 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 से डिफ़ॉल्ट रूप से पतों को रैंडमाइज़ करता है। एक प्रदाता जो केवल MAC एड्रेस द्वारा लौटने वाले विज़िटर्स की पहचान करता है, वह साइन-इन पहचान पर मिलान करने वाले प्रदाता की तुलना में कम रिटर्न की रिपोर्ट करेगा।

शुरू करने से पहले एक सहनशीलता सीमा (टॉलरेंस) पर सहमति बनाएं, उदाहरण के लिए दैनिक साइन-इन पर 5%। पहले से सहमत संख्या के बिना, हर अंतर एक बहस बन जाता है।

नोटिस अवधि समाप्त होने से पहले साइन ऑफ़ करें

एक-पेज का साइन-ऑफ़ तैयार करें: तुलना किए गए माप, प्रत्येक प्रदाता की परिभाषा, अंतर और स्पष्टीकरण। IT, मार्केटिंग और प्रोक्योरमेंट से इस पर हस्ताक्षर करवाएं। फिर पुराने प्रदाता से ऐतिहासिक रिपोर्टों का एक अंतिम एक्सपोर्ट लें, ताकि साल-दर-साल तुलना स्विच के बाद भी बनी रहे।

व्यावहारिक परिदृश्य: 120-स्टोर वाली रिटेल चेन

नीचे दिए गए आंकड़े एक व्यावहारिक उदाहरण हैं, कोई वास्तविक डिप्लॉयमेंट नहीं। 120-स्टोर वाली एक फ़ैशन चेन सेंट्रल कंट्रोलर के तहत Ruckus एक्सेस पॉइंट्स संचालित करती है। ग्रुप मार्केटिंग को माइग्रेशन के बाद भी साल-दर-साल ग्राहकों के विज़िट ट्रेंड्स को बनाए रखने की आवश्यकता है। हमारा रिटेल पेज इस सेक्टर को अधिक विस्तार से कवर करता है।

क्या किया गया। पायलट स्टोर में पाया गया कि Android डिवाइसेस पर सोशल लॉगिन काम नहीं कर रहा था। वॉल्ड गार्डन में पोर्टल डोमेन तो थे, लेकिन पहचान प्रदाता (आइडेंटिटी प्रोवाइडर) के साइन-इन डोमेन नहीं थे। IT ने इसे वेव 1 से पहले ठीक कर दिया। पैरेलल रिपोर्टिंग में, पुराने प्रोवाइडर ने Purple की तुलना में 18% अधिक दैनिक विज़िट दिखाए। पुराना प्रोवाइडर हर एसोसिएशन की गिनती करता था। Purple ने प्रमाणित सत्रों (ऑथेंटिकेटेड सेशन्स) की गिनती की। केवल प्रमाणित सत्रों पर पुराने निर्यात को फिर से चलाने से यह अंतर घटकर 2% रह गया।

परिणाम। सभी 120 स्टोर्स को चार साप्ताहिक चरणों (वेव्स) में माइग्रेट किया गया। कारोबारी घंटों के दौरान किसी भी स्टोर में गेस्ट WiFi बंद नहीं हुआ। पुराना अनुबंध समाप्त होने से तीन सप्ताह पहले, 5% की स्वीकृत सहनशीलता (टॉलरेंस) के मुकाबले 2% के अंतर पर समाधान पर हस्ताक्षर किए गए।

कैप्टिव पोर्टल माइग्रेशन के दौरान कौन सी एक्सेस पॉइंट सेटिंग्स सबसे अधिक बार बाधित होती हैं?

अधिकांश समस्याएं कुछ चुनिंदा सेटिंग्स से जुड़ी होती हैं। यह तालिका प्रत्येक सेटिंग, उसके गलत होने पर दिखने वाले लक्षण और समाधान को दर्शाती है।

सेटिंग	गलत होने पर दिखने वाला लक्षण	समाधान
वॉल्ड गार्डन में नए पोर्टल डोमेन मौजूद नहीं हैं	फ़ोन कनेक्ट होता है, पोर्टल कभी लोड नहीं होता	Purple की वेंडर गाइड में दिए गए प्रत्येक डोमेन को जोड़ें, फिर पुराने प्रोवाइडर के डोमेन को हटा दें
वॉल्ड गार्डन में सोशल लॉगिन डोमेन मौजूद नहीं हैं	ईमेल साइन-इन काम करता है, सोशल लॉगिन विफल हो जाता है	वेंडर गाइड में सूचीबद्ध पहचान प्रदाता (आइडेंटिटी प्रोवाइडर) डोमेन को जोड़ें
RADIUS शेयर्ड सीक्रेट बेमेल होना	साइन-इन स्वीकार हो जाता है, डिवाइस कभी ऑनलाइन नहीं होता	कंट्रोलर और नए सर्वर दोनों पर सीक्रेट फिर से दर्ज करें
RADIUS अकाउंटिंग अक्षम होना	साइन-इन दिखाई देते हैं, सत्र की अवधि शून्य दिखाई देती है	अंतरिम अपडेट के साथ अकाउंटिंग (RFC 2866) सक्षम करें
फ़ायरवॉल RADIUS पोर्ट्स को ब्लॉक कर रहा है	केवल एक साइट पर साइन-इन का समय समाप्त (टाइम आउट) हो जाता है	आउटबाउंड UDP 1812 और 1813 की अनुमति दें, जो RFC 2865 और RFC 2866 में निर्दिष्ट पोर्ट हैं
साइट पहचानकर्ता गलत तरीके से मैप किया गया	सत्र गलत वेन्यू के नाम पर दिखाई देते हैं	कंट्रोलर के साइट पहचानकर्ता को Purple साइट ID से मैच करें
पुराने रीडायरेक्ट का एक एक्सेस पॉइंट ग्रुप पर छूट जाना	आधी साइट पर पुराना पोर्टल दिखता है	केवल डिफ़ॉल्ट ही नहीं, बल्कि प्रत्येक SSID और एक्सेस पॉइंट ग्रुप का ऑडिट करें
पुराने प्रोवाइडर से कॉपी किया गया सेशन टाइमआउट	विज़िट के बीच में ही मेहमानों से फिर से विवरण मांगा जाता है	टाइमआउट को अपनी विज़िट की अवधि के अनुसार सेट करें; देखें गेस्ट WiFi पर समय और बैंडविड्थ प्रतिबंध कैसे लागू करें

ऐसी नीतियां जो पुराने प्रोवाइडर के अंदर मौजूद थीं

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

क्लॉक और सर्टिफ़िकेट से जुड़ी समस्याएं

RADIUS अकाउंटिंग और पोर्टल प्रमाणपत्र दोनों ही सही समय पर निर्भर करते हैं। गलत समय वाले कंट्रोलर से ऐसे सत्र रिकॉर्ड बनते हैं जो गलत तारीख पर दर्ज होते हैं। पायलट से पहले प्रत्येक कंट्रोलर को एक विश्वसनीय NTP (नेटवर्क टाइम प्रोटोकॉल) स्रोत पर सेट करें।

स्विच की लागत क्या है, और आपको बदले में क्या मिलता है?

बजट के लिए लागत मदें

मौजूदा हार्डवेयर पर स्विच करने में चार लागत मदें होती हैं, जिनमें से कोई भी हार्डवेयर से संबंधित नहीं है:

• ओवरलैप लाइसेंस। कम से कम 30 दिनों के लिए दोनों प्रदाताओं को भुगतान करने की योजना बनाएं।
• प्रति साइट IT समय। टेम्पलेट-आधारित डैशबोर्ड पायलट के बाद इसे काफी कम कर देते हैं। स्टैंडअलोन कंट्रोलर वाली साइटों में अधिक समय लगता है।
• डेटा क्लींजिंग। किसी को सहमति संस्करणों को मैप करना होगा, डुप्लिकेट रिकॉर्ड हटाने होंगे और सप्रेशन सूची लोड करनी होगी।
• स्थानीय सत्यापन। प्रत्येक साइट पर एक निर्दिष्ट व्यक्ति यह जांच करता है कि तय दिन पर पोर्टल लोड हो रहा है या नहीं।

Purple तीन योजनाओं के माध्यम से लाइसेंस प्रदान करता है: Connect, Capture और Engage। खरीद विभाग को कटओवर से पूरे एक वर्ष के बजाय ओवरलैप अवधि के आधार पर आपकी आवश्यक योजना की कीमत तय करनी चाहिए।

आपको बदले में क्या मिलता है

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

आप बड़े पैमाने पर सिद्ध हो चुके प्लेटफॉर्म से भी जुड़ते हैं। Purple 90 से अधिक देशों में 80,000+ वेन्यू में संचालित होता है और प्रति वर्ष 50 करोड़ (500 मिलियन) उपयोगकर्ताओं और लॉगिन को संभालता है। Purple 99.999% अपटाइम प्रदान करता है, इसके पास ISO 27001 प्रमाणन है और यह GDPR अनुपालन करता है।

अक्सर पूछे जाने वाले प्रश्न

क्या गेस्ट WiFi प्रदाता को Purple में स्विच करने के लिए हमें नए एक्सेस पॉइंट की आवश्यकता है?

नहीं, Purple आपके मौजूदा एक्सेस पॉइंट पर ही काम करता है। Purple हार्डवेयर-अज्ञेय (hardware-agnostic) है और यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet के साथ काम करता है। स्विच करने से आपके कंट्रोलर या डैशबोर्ड पर कैप्टिव पोर्टल, वॉल्ड गार्डन और RADIUS सेटिंग्स बदल जाती हैं। आपके एक्सेस पॉइंट, केबलिंग और स्विच अपनी जगह पर ही रहते हैं, इसलिए प्रदाता परिवर्तन केवल एक कॉन्फ़िगरेशन प्रोजेक्ट है, न कि हार्डवेयर रिफ्रेश।

क्या हम स्विच करने के बाद भी अपनी मौजूदा गेस्ट सूची को ईमेल भेजना जारी रख सकते हैं?

हाँ, बशर्ते सहमति का प्रमाण सूची के साथ ट्रांसफर हो। GDPR अनुच्छेद 7(1) के अनुसार आपको सहमति प्रदर्शित करना आवश्यक है, इसलिए प्रत्येक रिकॉर्ड में टाइमस्टैम्प, चैनल, कैप्चर साइट और आगंतुक द्वारा देखा गया शब्द-विन्यास शामिल होना चाहिए। Purple Engage उस इतिहास के साथ सहमति-प्राप्त रिकॉर्ड्स को आयात करता है। बिना प्रमाण वाले रिकॉर्ड्स को नॉन-मार्केटेबल के रूप में आयात किया जाना चाहिए। आपके ब्रांड के बजाय पुराने प्रदाता को उसके अपने नाम पर दी गई सहमति ट्रांसफर नहीं होती है।

मल्टी-साइट गेस्ट WiFi माइग्रेशन में कितना समय लगता है?

20 से 150 साइटों वाले अधिकांश एस्टेट्स के लिए छह से आठ सप्ताह की योजना बनाएं। इसमें दो सप्ताह का एक्सपोर्ट, 14 दिनों का पायलट और कटओवर के वेव शामिल हैं, जिनका आकार इस आधार पर तय किया जाता है कि आपकी टीम एक शिफ्ट में कितना सत्यापित कर सकती है। क्लाउड डैशबोर्ड साझा करने वाली साइटें अधिक तेज़ी से आगे बढ़ती हैं क्योंकि एक सिद्ध टेम्प्लेट कई साइटों पर लागू होता है। अपने पुराने अनुबंध की नोटिस तिथि से योजना शुरू करें, जिसमें समानांतर रिपोर्टिंग के लिए कम से कम 30 दिनों का ओवरलैप बचा हो।

क्या कटओवर के दौरान हमारी साइटें ऑफ़लाइन हो जाएंगी?

नहीं, यदि आप पायलट-फिर-वेव्स क्रम का पालन करते हैं तो ऐसा नहीं होगा। प्रत्येक साइट अपने सबसे शांत व्यावसायिक घंटों के दौरान बदलती है, जिसमें मिनटों में रोलबैक के लिए पुराना कॉन्फ़िगरेशन सुरक्षित रहता है। अधिकांश रुकावटें केवल उतनी ही देर तक रहती हैं जितना समय कंट्रोलर को नई सेटिंग्स लागू करने में लगता है। जिन गड़बड़ियों के कारण लंबे समय तक आउटेज होते हैं, जैसे कि वॉल्ड गार्डन डोमेन का गायब होना या ब्लॉक किए गए RADIUS पोर्ट, उन्हें पूरे एस्टेट के बजाय पायलट साइट पर ही पकड़ लिया जाता है।

क्या प्रदाताओं के बीच गेस्ट डेटा ट्रांसफर करना GDPR के अनुरूप है?

हाँ, जब आप कंट्रोलर के रूप में कार्य करते हैं और दोनों प्रदाता अनुबंध के तहत प्रोसेसर के रूप में कार्य करते हैं। GDPR आर्टिकल 28(3)(g) के तहत आपकी पसंद के आधार पर, सेवा समाप्त होने पर पुराने प्रोसेसर को व्यक्तिगत डेटा वापस करना या हटाना आवश्यक होता है। नोटिस देने से पहले लिखित रूप में "वापस करें" चुनें। सप्रेशन लिस्ट को सबसे पहले ट्रांसफर करें, ताकि जिसने भी ऑप्ट-आउट किया है वह ऑप्ट-आउट ही रहे। Purple GDPR के अनुरूप और ISO 27001 प्रमाणित है।

पुराने प्रदाता के पास बचे डेटा का क्या होता है?

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

हम यह कैसे साबित करें कि Purple की रिपोर्ट हमारे पुराने प्रदाता के आंकड़ों से मेल खाती हैं?

पायलट साइट पर दोनों प्रणालियों को 14 दिनों के लिए समानांतर रूप से चलाएं और पांच पैमानों की तुलना करें: दैनिक साइन-इन, यूनीक विज़िटर्स, नए बनाम लौटने वाले, सेशन की अवधि और ऑप्ट-इन दर। अधिकांश अंतर विज़िट की अलग-अलग परिभाषाओं के कारण आते हैं, न कि त्रुटिपूर्ण डेटा के कारण। प्रत्येक प्रदाता की परिभाषा का दस्तावेजीकरण करें, पहले से ही 5% जैसी सहनशीलता (टॉलरेंस) पर सहमति बनाएं, और पुराने अनुबंध के समाप्त होने से पहले साइन-ऑफ करें।

क्या Purple हमारे मौजूदा CRM और ईमेल प्लेटफ़ॉर्म से जुड़ सकता है?

हाँ, Purple CRM और मार्केटिंग प्लेटफ़ॉर्म के साथ एकीकृत होता है। इम्पोर्ट की गई गेस्ट प्रोफाइल, नए साइन-इन और सहमति में परिवर्तन उस सिस्टम में भेजे जा सकते हैं जिसका उपयोग आपकी मार्केटिंग टीम पहले से करती है। अपने पहले पोस्ट-माइग्रेशन अभियान से पहले इंटीग्रेशन को कनेक्ट करें, ताकि किसी भी तरफ से अनसब्सक्राइब किए जाने पर पहले सेंड से ही उसका सम्मान किया जा सके। यह WiFi साइन-इन और ईमेल दोनों में सहमति का एक ही रिकॉर्ड बनाए रखता है, जो कि ICO के सहमति मार्गदर्शन के अनुसार आपसे अपेक्षित है।