HPE Aruba Central presence analytics: सेटअप, एक्सपोर्ट और सीमाएं

Aruba Central प्रेजेंस एनालिटिक्स उन डिवाइसेज को काउंट करता है जिन्हें आपके HPE Aruba एक्सेस पॉइंट्स डिटेक्ट करते हैं। इसके बाद यह आपके द्वारा प्रत्येक साइट के लिए सेट की गई RSSI थ्रेशोल्ड और ड्वेल-टाइम लिमिट्स का उपयोग करके उन्हें राहगीरों (passers-by) और विज़िटर्स में वर्गीकृत करता है। आप इसे प्रति साइट इनेबल करते हैं, फ्लोर पर थ्रेशोल्ड को कैलिब्रेट करते हैं, और Central REST API के माध्यम से एग्रीगेट डेटा एक्सपोर्ट करते हैं। यह केवल डिवाइसेज को काउंट करता है और कभी भी लोगों की पहचान नहीं करता है।

Aruba Central प्रेजेंस एनालिटिक्स वास्तव में क्या मापता है?

प्रत्येक फोन जिसका WiFi ऑन होता है, वह प्रोब रिक्वेस्ट भेजता है, जो कि शॉर्ट फ्रेम्स होते हैं और यह पूछते हैं कि पास में कौन से नेटवर्क उपलब्ध हैं। फोन इन्हें भेजता है, भले ही वह कभी आपके नेटवर्क से जुड़े या न जुड़े। आपके Aruba एक्सेस पॉइंट्स उन फ्रेम्स को सुनते हैं और प्रत्येक डिवाइस का MAC एड्रेस और सिग्नल स्ट्रेंथ Central को रिपोर्ट करते हैं। इसके बाद Central दो नियमों को लागू करता है जिन्हें आप कंट्रोल कर सकते हैं।

पहला नियम सिग्नल स्ट्रेंथ है। RSSI (रिसीव्ड सिग्नल स्ट्रेंथ इंडिकेटर) को dBm में मापा जाता है, और शून्य के करीब की वैल्यूज का मतलब है कि डिवाइस एक्सेस पॉइंट के अधिक करीब है। आपके RSSI थ्रेशोल्ड से ऊपर का डिवाइस वेन्यू के अंदर माना जाता है। इससे नीचे डिटेक्ट होने वाला डिवाइस राहगीर (passers-by) माना जाता है।

दूसरा नियम ड्वेल टाइम है। थ्रेशोल्ड से ऊपर के डिवाइसेज में से, Central संक्षिप्त डिटैक्शन्स को वास्तविक विज़िट्स से अलग करने के लिए ड्वेल-टाइम लिमिट्स का उपयोग करता है। फिर यह विज़िटर्स को ड्यूरेशन बैंड्स में ग्रुप करता है।

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

Purple का अपना प्रेजेंस मॉडल भी इसी फिजिक्स पर काम करता है। Presence (Legacy) documentation उन अनऑथेंटिकेटेड डिवाइसेज को काउंट करने का वर्णन करता है जो एक एक्सेस पॉइंट को इतनी करीब से "पिंग" करते हैं कि उनका MAC एड्रेस रिकॉर्ड हो सके। RSSI प्रॉक्सिमिटी सिग्नल के रूप में कार्य करता है। ड्यूरेशन यह मापता है कि वेन्यू में किसी भी एक्सेस पॉइंट ने डिवाइस को कितने समय तक देखा। यदि आप एक मॉडल को समझते हैं, तो आप दोनों को समझते हैं।

Aruba Central में प्रेजेंस एनालिटिक्स इनेबल करने से पहले आपको क्या चाहिए?

पाँच चीजें, और आखिरी वाली वह है जिसे टीमें अक्सर छोड़ देती हैं।

1. एक Central सब्सक्रिप्शन जिसमें प्रेजेंस एनालिटिक्स शामिल हो। प्रेजेंस एनालिटिक्स प्रत्येक Central लाइसेंस टियर का हिस्सा नहीं है। प्रत्येक साइट पर APs को असाइन किए गए सब्सक्रिप्शन के साथ HPE के वर्तमान लाइसेंसिंग डॉक्यूमेंटेशन की जांच करें।
2. साइट पर असाइन किए गए APs, न कि केवल एक ग्रुप में। Central कॉन्फ़िगरेशन के लिए ग्रुप्स का और लोकेशन तथा रिपोर्टिंग के लिए साइट्स का उपयोग करता है। प्रेजेंस प्रति साइट एग्रीगेट होता है, इसलिए बिना साइट असाइनमेंट वाला AP कोई उपयोगी योगदान नहीं देता है।
3. भौतिक सीमा (physical boundary) के साथ मार्क किया गया एक फ्लोर प्लान। दरवाजे, शॉपफ्रंट ग्लास, छतों, कार पार्कों और पड़ोसी यूनिट्स के साथ साझा की जाने वाली दीवारों को मार्क करें। ये वे स्थान हैं जहाँ आपकी थ्रेशोल्ड सबसे पहले गलत साबित होगी।
4. एक टेस्ट डिवाइस जिसकी आप पहचान कर सकें। आधुनिक iOS और Android रिलीज उस MAC एड्रेस को रैंडमाइज करते हैं जिसे एक डिवाइस प्रस्तुत करता है, इसलिए या तो अपने टेस्ट हैंडसेट पर प्राइवेट एड्रेस सेटिंग को डिसेबल करें या इसके द्वारा उपयोग किए जाने वाले एड्रेस को नोट करें।5. एक गोपनीयता स्थिति। MAC एड्रेस डिवाइस आइडेंटिफायर होते हैं। GDPR का रीसाइटल 30 डिवाइस द्वारा प्रदान किए गए ऑनलाइन आइडेंटिफायर को ऐसी जानकारी के रूप में नामित करता है जो किसी व्यक्ति की पहचान कर सकती है। डेटा प्रोटेक्शन इम्पैक्ट असेसमेंट पूरा करें और डेटा कलेक्शन शुरू होने से पहले प्रवेश द्वारों पर साइनेज लगाएं। UK ICO ने डिवाइस सिग्नल्स के आधार पर लोकेशन एनालिटिक्स पर गाइडेंस पब्लिश की है, और यह दोनों बिंदुओं को कवर करती है।

API वर्क के लिए, आपको Central में एक एडमिन रोल की भी आवश्यकता होगी जो API Gateway क्लाइंट बना सके, और डेटा के लिए एक डेस्टिनेशन: एक वेयरहाउस, एक डेटाबेस या एक BI टूल।

आप Aruba Central प्रेजेंस एनालिटिक्स को कैसे सेटअप करते हैं?

स्टेप 1: प्रत्येक साइट के लिए सर्विस सक्षम करें

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

स्टेप 2: RSSI थ्रेशोल्ड को कैलिब्रेट करें

विज़िटर काउंटिंग के लिए कोई यूनिवर्सल Aruba RSSI थ्रेशोल्ड नहीं है। सही वैल्यू AP माउंटिंग हाइट, एंटीना पैटर्न, वॉल मटेरियल, ग्लेजिंग और APs बाउंड्री के कितने करीब हैं, इस पर निर्भर करती है। किसी अन्य वेन्यू से कॉपी किया गया नंबर आपके वेन्यू पर डिवाइसेस को गलत तरीके से वर्गीकृत करेगा। इसके बजाय इसे कैलिब्रेट करें:

1. बाउंड्री पर चलें। टेस्ट डिवाइस को तीन बिंदुओं पर ले जाएं: प्रवेश द्वार के ठीक अंदर, थ्रेशोल्ड पर, और बाहर फुटपाथ या कॉनकोर्स पर। प्रत्येक बिंदु पर कुछ मिनटों के लिए रुकें और Central द्वारा रिपोर्ट किए जाने वाले RSSI को नोट करें।
2. व्यस्त समय में दोहराएं। लोग रेडियो एनर्जी को एब्जॉर्ब करते हैं, इसलिए पीक टाइम की रीडिंग खाली बिल्डिंग की रीडिंग की तुलना में कम होती है। पीक कंडीशंस के अनुसार कैलिब्रेट करें, क्योंकि नंबर्स तभी मायने रखते हैं।
3. थ्रेशोल्ड को "ठीक अंदर" और "बाहर" के बीच रखें। यदि सड़क का ट्रैफ़िक ग्लास के करीब से गुजरता है, तो इसे अंदर की रीडिंग की ओर झुकाएं। यदि प्रवेश द्वार अंदर की ओर धंसा हुआ है और आसपास कोई नहीं रुकता है, तो इसे बाहर की रीडिंग की ओर झुकाएं।
4. वैल्यू और तारीख रिकॉर्ड करें। बाद की हर तुलना यह जानने पर निर्भर करती है कि किस थ्रेशोल्ड ने कौन से नंबर्स जनरेट किए।

स्टेप 3: ड्वेल बाउंड्रीज सेट करें जो आने-जाने वालों (passers-by) को विज़िटर्स से अलग करती हैं

अकेले RSSI ग्लास के करीब से गुजरने वाले किसी भी व्यक्ति को गलत तरीके से वर्गीकृत कर देता है। न्यूनतम विज़िटर ड्वेल उन्हें हटा देता है। इसे इंडस्ट्री एवरेज के बजाय अपने वेन्यू पर सबसे छोटी वास्तविक विज़िट पर सेट करें। लंबे बैंड फिर यह दर्शाते हैं कि आपके विज़िटर्स कितने जुड़े हुए हैं।

वेन्यू का प्रकार	एक आने-जाने वाला (passer-by) कैसा दिखता है	न्यूनतम विज़िटर ड्वेल के लिए एंकर	वैलिडेट करने के लिए ग्राउंड ट्रुथ
हाई स्ट्रीट रिटेल	दुकान के सामने से गुजरता हुआ पैदल यात्री	सबसे तेज़ वास्तविक खरीदारी, जैसे कि ग्रैब-एंड-गो आइटम	टिल ट्रांजैक्शन काउंट
होटल लॉबी	लिफ्ट या रेस्टोरेंट की ओर जाता हुआ गेस्ट	सबसे छोटा चेक-इन या कंसीयज इंटरैक्शन	फ्रंट डेस्क चेक-इन लॉग
कॉन्फ्रेंस सेंटर फ़ोयर	हॉलों के बीच से गुजरने वाले प्रतिनिधि	लघुतम सत्र उपस्थिति	प्रति सत्र बैज स्कैन
स्टेडियम कॉन्कोर्स	स्टैंड और कियोस्क के बीच आने-जाने वाले प्रशंसक	लघुतम कियोस्क खरीदारी	कियोस्क लेनदेन संख्या
पुस्तकालय या परिषद सेवा बिंदु	बगल की सड़क पर चलने वाले पैदल यात्री	डेस्क पर लघुतम पूछताछ	डेस्क पूछताछ लॉग या दरवाजा काउंटर

एक बार में केवल एक ही सेटिंग बदलें। यदि आप RSSI थ्रेसहोल्ड और ड्वेल बाउंड्री दोनों को एक साथ बदलते हैं, तो आप यह नहीं जान पाएंगे कि किस बदलाव के कारण संख्या में बदलाव आया है।

चरण 4: Central API के माध्यम से उपस्थिति डेटा एक्सपोर्ट करें

Central डैशबोर्ड केवल एक नज़र में देखने के लिए अच्छे हैं, लेकिन आगे की रिपोर्टिंग के लिए डेटा को बाहर निकालना आवश्यक है। Aruba Central API एक्सपोर्ट चार चरणों का पालन करता है।

1. API गेटवे में एक API क्लाइंट बनाएं। Central, REST कॉल्स को OAuth 2.0 एक्सेस टोकन के साथ प्रमाणित करता है। एक्सेस टोकन कम समय के लिए वैध होते हैं, इसलिए रिफ्रेश टोकन को सीक्रेट्स मैनेजर में स्टोर करें और रिन्यूअल को ऑटोमेट करें।
2. उपस्थिति एनालिटिक्स एंडपॉइंट्स को कॉल करें। वे आपके द्वारा निर्दिष्ट समय सीमा के लिए साइट-स्तरीय समग्र डेटा प्रदान करते हैं। वर्तमान एंडपॉइंट पाथ और मापदंडों के लिए HPE के डेवलपर संदर्भ का उपयोग करें, क्योंकि वे API वर्ज़न के बीच बदलते रहते हैं।
3. पुल को शेड्यूल करें। एक दैनिक जॉब जो प्रति साइट पिछले दिन के डेटा का अनुरोध करती है, उसका ऑडिट करना आसान है। साइट ID, UTC में समय सीमा, और उस समय प्रभावी थ्रेसहोल्ड और ड्वेल सेटिंग्स को स्टोर करें।
4. रेट लिमिट का सम्मान करें। Central प्रति अकाउंट API रेट लिमिट लागू करता है। बड़ी संपत्तियों को एक ही मिनट में हर साइट का डेटा पुल करने के बजाय साइट अनुरोधों को अलग-अलग समय पर शेड्यूल करना चाहिए।

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

आप यह कैसे जांचते हैं कि संख्या सही है?

उस चीज़ के साथ प्रमाणित करें जिसे आप पहले से गिनते हैं। ऊपर दी गई तालिका से प्रति साइट एक वास्तविक स्रोत (ग्राउंड-ट्रुथ सोर्स) चुनें और कम से कम एक सप्ताह के लिए हर दिन Central की विज़िटर संख्या के साथ इसकी तुलना करें।

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

डेटा पर भरोसा करने से पहले चार सैनिटी चेक चलाएं:

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

एक वास्तविक वेन्यू में ट्यूनिंग कैसी दिखती है?

नीचे दिए गए दो उदाहरण इस पद्धति को स्पष्ट करने के लिए काल्पनिक आंकड़ों का उपयोग करते हैं। आपके अपने आंकड़े भिन्न हो सकते हैं, लेकिन गणना की विधि यही रहेगी।

परिदृश्य 1: कांच के मुख्य द्वार वाली एक हाई स्ट्रीट फैशन रिटेल दुकान

स्थिति: एक एकल-मंजिला दुकान के व्यस्त फुटपाथ पर स्थित कांच के मुख्य द्वार से कुछ ही मीटर की दूरी पर दो AP लगे हैं। एक सामान्य शनिवार को, Central द्वारा 410 बिलिंग लेनदेन के मुकाबले 3,200 विजिटर्स की रिपोर्ट दी जाती है। लगभग 13% की यह अनुमानित कैप्चर दर व्यापारिक टीम के व्यावहारिक अनुभव के मुकाबले अवास्तविक रूप से कमजोर लगती है।

क्या किया गया: नेटवर्क इंजीनियर ने शनिवार को दोपहर के भोजन के समय बाहरी सीमा का निरीक्षण किया। उन्होंने पाया कि कांच के ठीक बाहर फुटपाथ पर मौजूद डिवाइसेस की सिग्नल क्षमता लगभग उतनी ही मजबूत थी जितनी कि दरवाजे के ठीक अंदर मौजूद डिवाइसेस की। उन्होंने RSSI थ्रेशोल्ड को इन दोनों रीडिंग्स के बीच सेट किया। इसके बाद उन्होंने न्यूनतम विजिटर ड्वेल टाइम (रुकने की अवधि) को उस समय पर सेट किया जो बिलिंग काउंटर पर एक वस्तु खरीदने में लगता है।

परिणाम: अगले शनिवार को, Central ने 425 लेनदेन के मुकाबले 1,150 विजिटर्स की रिपोर्ट दी, जो प्रति बिक्री लगभग 2.7 विजिटर्स का अनुपात है। यह अनुपात अगले चार सप्ताहांतों में एक संकीर्ण सीमा के भीतर बना रहा। इनसाइट एनालिस्ट अब स्टोर की retail ट्रेडिंग समीक्षा के लिए कन्वर्जन इंडिकेटर के रूप में साप्ताहिक रूप से इसकी रिपोर्ट करता है।

परिदृश्य 2: एक होटल के बगल में स्थित कॉन्फ्रेंस सेंटर का फ़ोयर (लॉबी)

स्थिति: एक कॉन्फ्रेंस सेंटर कांच की दीवारों वाले लिंक कॉरिडोर के जरिए 200 कमरों वाले होटल से जुड़ा है। इवेंट आयोजक फ़ोयर में स्पॉन्सर स्टॉल की कीमत तय करने के लिए प्रतिदिन के ड्वेल डेटा की मांग करते हैं। Central का ड्वेल वितरण सबसे कम समय वाली श्रेणी में एक बड़ा उछाल दिखाता है, चाहे कोई इवेंट चल रहा हो या नहीं।

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

परिणाम: जिन दिनों इवेंट नहीं थे, फ़ोयर विजिटर्स की संख्या घटकर स्टाफ और ठेकेदारों के अनुकूल स्तर पर आ गई। इवेंट के दिनों में, विजिटर संख्या एक स्थिर अनुपात में बैज स्कैन के समान रही। इसके बाद आयोजक स्पॉन्सर्स को उन प्रतिनिधियों का एक विश्वसनीय आंकड़ा देने में सक्षम हुए जिन्होंने फ़ोयर में निर्धारित समय से अधिक वक्त बिताया था। होटल के guest ट्रैफिक ने इवेंट डेटा को प्रभावित करना बंद कर दिया।

परिदृश्य 3: बाहर बस स्टॉप वाला एक काउंसिल पुस्तकालय

स्थिति: एक सार्वजनिक पुस्तकालय एक ऐसे बस स्टॉप के बगल में स्थित है जहाँ लोग कई मिनटों तक प्रतीक्षा करते हैं, जो प्रवेश द्वार के AP की पूरी रेंज के भीतर आता है। काउंसिल अपनी वार्षिक सेवा रिपोर्ट के लिए विजिटर संख्या चाहती है।

क्या किया गया: केवल RSSI या केवल ड्वेल टाइम के आधार पर बस का इंतजार करने वाले यात्री को पुस्तकालय के विजिटर से अलग करना संभव नहीं था। टीम ने बस स्टॉप पर ली गई रीडिंग्स का उपयोग करके थ्रेशोल्ड सेट किया। इसके बाद उन्होंने एक महीने के लिए मौजूदा डोर काउंटर के आंकड़ों के साथ इन नंबरों का मिलान किया।

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

क्या गलतियाँ होती हैं, और आप उन्हें कैसे सुधारते हैं?

विज़िटर काउंट वास्तविक संख्या से बहुत अधिक हैं

RSSI थ्रेशोल्ड बहुत अधिक उदार है, आमतौर पर कांच, एक पतले विभाजन या प्रवेश द्वार के पास लगे AP के कारण ऐसा होता है। व्यस्त समय में सीमा पर फिर से टहलें और थ्रेशोल्ड को बढ़ाएं। यदि AP प्लेसमेंट के कारण साफ अंतर करना असंभव है, तो इसे सीमा से आगे ले जाने पर विचार करें।

मोबाइल OS अपडेट के बाद काउंट बदल जाते हैं

MAC एड्रेस रैंडमाइजेशन का मतलब है कि एक भौतिक डिवाइस समय के साथ कई एड्रेस के रूप में दिखाई दे सकती है। iOS या Android में रैंडमाइजेशन व्यवहार में प्रत्येक परिवर्तन आपके काउंट को बदल सकता है और रिपीट-विज़िट के आंकड़ों को कम कर सकता है। अपनी रिपोर्टिंग सीरीज़ में प्रमुख OS रिलीज़ तिथियों को चिह्नित करें। बिना प्रमाणीकृत डिवाइसों से मिलने वाले रिपीट-विज़िट मेट्रिक्स को सावधानी से संभालें।

रात भर या सुबह-सुबह आने वाले विज़िटर

कर्मचारियों के फोन, हैंडहेल्ड स्कैनर, प्रिंटर और स्मार्ट डिवाइस पूरे दिन थ्रेशोल्ड से ऊपर रहते हैं। जहां Central इसकी अनुमति देता है, वहां ज्ञात डिवाइस एड्रेस को हटा दें, या अपनी डाउनस्ट्रीम रिपोर्टिंग में व्यावसायिक घंटों के अलावा अन्य समय को हटा दें।

API कॉल ऑथराइजेशन एरर देती हैं

एक्सेस टोकन समाप्त हो गया है और रीफ्रेश स्टेप विफल हो गया या कभी नहीं चला। जांचें कि आपका जॉब रीफ्रेश टोकन का उपयोग करता है, प्राप्त होने वाले नए टोकन पेयर को स्टोर करता है, और चुपचाप खाली दिन दर्ज करने के बजाय विफलता पर अलर्ट भेजता है।

ऐतिहासिक तुलनाओं में अचानक बड़ा बदलाव

किसी ने थ्रेशोल्ड या ड्वेल सीमा को बदल दिया है। यही कारण है कि स्टेप 4 हर पुल के साथ सेटिंग्स को स्टोर करता है। परिवर्तन की तिथि पर सीरीज़ को विभाजित करें और दोनों अवधियों की अलग-अलग रिपोर्ट करें।

Captive Portal की समस्याएं प्रमाणीकृत मेट्रिक्स को बिगाड़ देती हैं

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

Aruba Central एनालिटिक्स की सीमाएं क्या हैं?

नेटिव प्रेजेंस एनालिटिक्स उपयोगी है और आपके Aruba एस्टेट के साथ आता है। इसकी कुछ सख्त सीमाएं भी हैं जिन्हें आपको हितधारकों को इस पर रिपोर्टिंग प्रोग्राम बनाने से पहले स्पष्ट रूप से बता देना चाहिए।

• साइट-स्तरीय एकत्रीकरण (Site-level aggregation)। Central प्रति साइट रिपोर्ट करता है। यदि आपको किसी साइट के भीतर ज़ोन की आपस में तुलना करनी है, या सुसंगत नियमों के साथ एक बड़े एस्टेट में रैंकिंग करनी है, तो आपको इसे खुद डाउनस्ट्रीम में बनाना होगा।
• रिटेंशन (Retention)। Central प्लेटफॉर्म और आपकी सदस्यता द्वारा निर्धारित एक सीमित अवधि के लिए प्रेजेंस डेटा रखता है। साल-दर-साल की तुलना आपके खुद के एक्सपोर्ट पर निर्भर करती है, इसलिए पहले दिन से ही API पाइपलाइन शुरू कर दें।- कोई पहचान परत नहीं। Presence डेटा अनाम डिवाइस गणना है। आप किसी विज़िट को किसी सहमति प्राप्त संपर्क, लॉयल्टी अकाउंट या CRM रिकॉर्ड से नहीं जोड़ सकते। रैंडमाइज्ड MAC पते लंबी अवधि में अनाम रिपीट-विज़िट काउंट को भी अविश्वसनीय बना देते हैं।
• सिंगल-वेंडर व्यू। Central केवल Aruba एक्सेस पॉइंट्स देखता है। जिन एस्टेट्स में एक्वायर्ड साइटों पर Aruba के साथ Cisco Meraki, Ruckus या Juniper Mist का मिश्रण है, उन्हें केवल एक आंशिक तस्वीर मिलती है।
• कैलिब्रेशन डेब्ट। हर रीफ़िट, AP मूव या नया ग्लेज़िंग रेडियो वातावरण को बदल देता है। इंस्टॉलेशन के समय सही रहने वाली सीमाएं तब तक बदलती रहती हैं जब तक कि कोई व्यक्ति फिर से बाउंड्री वॉक न करे।

इनमें से कोई भी कोई ख़ामी नहीं है। वे एक नेटवर्क वेंडर के एनालिटिक्स फ़ीचर का दायरा हैं, और वे यह तय करते हैं कि प्लेटफ़ॉर्म लेयर को अपनी जगह कहाँ बनानी है।

इसकी लागत क्या है, और इसके ऊपर एक प्लेटफ़ॉर्म लेयर कब काम आती है?

नेटिव रूट के लिए अतिरिक्त लाइसेंस खर्च के बजाय इंजीनियरिंग और एनालिस्ट के समय की लागत आती है, बशर्ते आपका Central सब्सक्रिप्शन पहले से ही प्रेजेंस एनालिटिक्स को कवर करता हो। प्रति साइट एक बाउंड्री वॉक, एक सप्ताह का वैलिडेशन, बनाने और बनाए रखने के लिए एक API पाइपलाइन, और भौतिक परिवर्तनों के बाद रीकैलिब्रेशन का बजट तय करें।

Purple का WiFi Analytics Central को डुप्लिकेट करने के बजाय एक अलग लेयर जोड़ता है। यह आपके पहले से मौजूद Aruba एक्सेस पॉइंट्स पर हार्डवेयर-एग्नोस्टिक क्लाउड ओवरले के रूप में चलता है, जिसमें किसी रिप और रिप्लेस की आवश्यकता नहीं होती है। Purple का Guest WiFi Captive Portal सचेत-विकल्प ऑप्ट-इन्स के माध्यम से एक प्रमाणित लेयर जोड़ता है, जो आपको फ़र्स्ट-पार्टी डेटा देता है जो अनाम प्रेजेंस नहीं दे सकता।

क्षमता	Aruba Central प्रेजेंस एनालिटिक्स	आपके Aruba APs पर Purple WiFi Analytics
यह क्या गिनता है	RSSI थ्रेशोल्ड से ऊपर के अनाम डिवाइस	वे विज़िट जहाँ सिग्नल स्ट्रेंथ ने डिवाइस को वेन्यू के अंदर रखा, साथ ही प्रमाणित विज़िटर
पहचान	कोई नहीं, केवल MAC पता	सहमति प्राप्त फ़र्स्ट-पार्टी डेटा वाले प्रमाणित विज़िटर
ड्वेल रिपोर्टिंग	प्रति साइट अवधि बैंड	प्रमाणित विज़िटर्स के लिए प्रति विज़िट औसत ड्वेल
समय पैटर्न	चुने हुए विंडो पर साइट डैशबोर्ड	सप्ताह के दिन और दिन के घंटे के हिसाब से विज़िट का हीटमैप
क्रॉस-वेन्यू व्यू	प्रति-साइट, एस्टेट के लिए डाउनस्ट्रीम बनाया गया	विज़िट के आधार पर टॉप 10 और बॉटम 10 वेन्यू, प्लेटफ़ॉर्म में रैंक किए गए
हार्डवेयर	केवल HPE Aruba	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet
रीयल-टाइम व्यू	Central डैशबोर्ड	एक मिनट के अंतराल में पिछले 25 मिनट, हर मिनट रिफ्रेश (Presence Legacy)
यह किसके लिए उपयुक्त है	सिंगल-वेंडर एस्टेट्स जिन्हें अनाम ऑक्यूपेंसी पैटर्न की आवश्यकता है	मल्टी-वेन्यू या मिक्स्ड-वेंडर एस्टेट्स जिन्हें पहचानी गई, सहमति प्राप्त विज़िटर डेटा की आवश्यकता है

इस तालिका में दी गई Purple क्षमताएं Purple के WiFi Analytics - Presence और Presence (Legacy) दस्तावेज़ों से ली गई हैं। उन दस्तावेज़ों की एक महत्वपूर्ण बात: गैर-प्रमाणित (unauthenticated) आगंतुकों के डेटा को संसाधित करने में प्रमाणित आगंतुकों के डेटा की तुलना में अधिक समय लग सकता है।

यदि आप एक ही Aruba संपत्ति का संचालन करते हैं, आपको अज्ञात उपस्थिति और रुकने के पैटर्न की आवश्यकता है, और आपके पास एक ऐसा इंजीनियर है जो कैलिब्रेशन और API पाइपलाइन को संभाल सकता है, तो नेटिव (native) पर ही बने रहें।

यदि इनमें से कोई भी स्थिति लागू होती है, तो प्लेटफ़ॉर्म लेयर जोड़ें: आप मिश्रित हार्डवेयर संचालित करते हैं; आप एक दूसरे के विपरीत कई स्थानों की तुलना करते हैं; या आपको मार्केटिंग या सर्विस डिज़ाइन के लिए सहमति-प्राप्त, पहचाने गए आगंतुकों के डेटा की आवश्यकता है। यह अतिथि प्रोफ़ाइल बनाने वाले होटलों और विज़िट को अभियानों से जोड़ने वाली रिटेल श्रृंखलाओं पर लागू होता है। Purple 80,000+ सक्रिय स्थानों पर चलता है और इसने 2024 में 440 मिलियन लॉगिन को संभाला (Purple का अपना डेटा)। इनमें से अधिकांश स्थान उस हार्डवेयर पर काम करते हैं जो पहले से ही स्थापित था।

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

क्या उपस्थिति एनालिटिक्स मेरे Aruba Central लाइसेंस में शामिल है?

हर मामले में नहीं। उपस्थिति एनालिटिक्स विशिष्ट Aruba Central सब्सक्रिप्शन स्तरों में आता है, इसलिए पुष्टि करें कि प्रत्येक साइट पर APs में ऐसा स्तर मौजूद है जिसमें यह शामिल है। रोलआउट की योजना बनाने से पहले अपने Central खाते में असाइन की गई सब्सक्रिप्शन के साथ HPE के वर्तमान लाइसेंसिंग दस्तावेज़ों की जांच करें। यदि कुछ साइटों पर कम स्तर का लाइसेंस है, तो आपको संपत्ति-व्यापी रिपोर्टिंग में अंतर दिखाई देगा। पहले लाइसेंसिंग को ठीक करें, फिर कैलिब्रेट करें।

क्या Purple मेरे मौजूदा HPE Aruba एक्सेस पॉइंट्स के साथ काम करता है?

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

क्या मैं Aruba Central उपस्थिति डेटा को डेटा वेयरहाउस या BI टूल में एक्सपोर्ट कर सकता हूँ?

हाँ, Central REST API के माध्यम से। API Gateway में एक API क्लाइंट बनाएं, OAuth 2.0 टोकन के साथ प्रमाणित करें, और साइट-स्तरीय योगों के लिए उपस्थिति एनालिटिक्स एंडपॉइंट्स को कॉल करें। प्रति साइट एक दैनिक पुल शेड्यूल करें, UTC में टाइमस्टैम्प संग्रहीत करें, और लागू थ्रेशोल्ड सेटिंग्स को रिकॉर्ड करें। चूंकि Central रिटेंशन सीमित है, इसलिए आपका एक्सपोर्ट साल-दर-साल तुलना के लिए दीर्घकालिक रिकॉर्ड बन जाता है।

क्या WiFi उपस्थिति डेटा GDPR के तहत व्यक्तिगत डेटा है?

इसे व्यक्तिगत डेटा के रूप में ही मानें। GDPR का नियम 30 डिवाइस-प्रदान किए गए ऑनलाइन पहचानकर्ताओं को ऐसी जानकारी के रूप में नामित करता है जो किसी व्यक्ति की पहचान कर सकती है, और उपस्थिति एनालिटिक्स MAC एड्रेस को संसाधित करता है। एक डेटा सुरक्षा प्रभाव मूल्यांकन पूरा करें, प्रवेश द्वारों पर स्पष्ट संकेत लगाएं, और डेटा रिटेंशन को आनुपातिक रखें। एकत्रित गणनाओं में कच्चे पहचानकर्ताओं की तुलना में कम जोखिम होता है, लेकिन संग्रह का चरण अभी भी इसके दायरे में आता है।### Aruba उपस्थिति एनालिटिक्स (presence analytics) को सेट अप और कैलिब्रेट करने में कितना समय लगता है?

प्रत्येक साइट के लिए एक बाउंड्री वॉक और कम से कम एक सप्ताह के वैलिडेशन की योजना बनाएं। सर्विस को सक्षम करने में केवल कुछ मिनट लगते हैं। कैलिब्रेशन का अर्थ है पीक समय पर प्रवेश द्वार पर चलना, RSSI थ्रेशोल्ड और ड्वेल बाउंड्री सेट करना, फिर टिल (tills), चेक-इन या डोर काउंटर्स के साथ काउंट की तुलना करना। API पाइपलाइन इंजीनियरिंग का एक अलग काम है। किसी भी रिफिट, AP को हटाने या ग्लेज़िंग में बदलाव के बाद फिर से कैलिब्रेट करें।

क्या MAC एड्रेस रैंडमाइजेशन Aruba उपस्थिति काउंट को बेकार कर देगा?

नहीं, लेकिन यह सीमित करता है कि इन काउंट का क्या अर्थ है। कुल विज़िटर्स और ड्वेल पैटर्न तब भी उपयोगी रहते हैं जब उन्हें टिल (till) ट्रांजेक्शन जैसे जमीनी सच्चाई के स्रोत के खिलाफ वैलिडेट किया जाता है। बिना ऑथेंटिकेशन वाले डिवाइसेस से मिलने वाले रिपीट-विज़िट और लॉयल्टी के आंकड़े अविश्वसनीय होते हैं, क्योंकि एक फोन समय के साथ कई एड्रेस प्रदर्शित कर सकता है। विश्वसनीय रिपीट-विज़िट डेटा के लिए, आपको ऑथेंटिकेटेड विज़िटर्स की आवश्यकता होती है जो सहमति के साथ captive portal के माध्यम से साइन इन करते हैं।

क्या मुझे Aruba Central उपस्थिति एनालिटिक्स चुनना चाहिए या Purple WiFi Analytics?

अधिकांश Aruba एस्टेट दोनों चलाते हैं, क्योंकि वे अलग-अलग सवालों के जवाब देते हैं। Central बिना किसी अतिरिक्त लाइसेंस लागत के प्रति साइट अनाम ऑक्यूपेंसी और ड्वेल पैटर्न प्रदान करता है यदि आपका टियर इसमें शामिल है। Purple ऑथेंटिकेटेड, सहमति प्राप्त विज़िटर डेटा, क्रॉस-वेन्यू रैंकिंग और मिश्रित हार्डवेयर के लिए सपोर्ट जोड़ता है। सिंगल-वेंडर एस्टेट पर अनाम काउंट के लिए नेटिव का उपयोग करें। जब आपको पहचाने गए फर्स्ट-पार्टी डेटा की आवश्यकता हो तो Purple जोड़ें।

क्या मुझे एक पहचाने गए एनालिटिक्स लेयर को जोड़ने के लिए नए हार्डवेयर की आवश्यकता है?

नहीं। Purple आपके द्वारा पहले से चलाए जा रहे HPE Aruba एक्सेस पॉइंट्स के शीर्ष पर काम करता है, इसलिए किसी भी प्रकार के रिप और रिप्लेस की आवश्यकता नहीं है। पहचानी गई लेयर नए रेडियो से नहीं, बल्कि सचेत-विकल्प ऑप्ट-इन्स वाले captive portal से आती है। आपका मौजूदा Central कॉन्फ़िगरेशन, उपस्थिति एनालिटिक्स और API एक्सपोर्ट इसके साथ काम करना जारी रखते हैं।