HPE Aruba Central प्रेझेन्स ॲनालिटिक्स: सेटअप, एक्स्पोर्ट्स आणि मर्यादा

Aruba Central presence analytics तुमच्या HPE Aruba ॲक्सेस पॉईंट्सच्या कक्षेत येणाऱ्या उपकरणांची संख्या मोजते. त्यानंतर ते तुम्ही प्रत्येक साइटसाठी सेट केलेल्या RSSI थ्रेशोल्ड आणि ड्वेल-टाइम मर्यादांच्या आधारे त्यांचे वर्गीकरण येणारे-जाणारे (passers-by) आणि अभ्यागत (visitors) यामध्ये करते. तुम्ही ते प्रति साइट सुरू करता, फ्लोअरवर थ्रेशोल्ड कॅलिब्रेट करता आणि Central REST API द्वारे एकूण डेटा एक्सपोर्ट करता. हे फक्त उपकरणांची संख्या मोजते आणि कधीही लोकांची ओळख पटवत नाही.

Aruba Central presence analytics नक्की काय मोजते?

WiFi सुरू असलेला प्रत्येक फोन प्रोब रिक्वेस्ट पाठवतो, ज्या जवळ कोणते नेटवर्क उपलब्ध आहे हे विचारणाऱ्या लहान फ्रेम्स असतात. तो तुमचे नेटवर्क जॉइन करो किंवा न करो, तो या फ्रेम्स पाठवतोच. तुमचे Aruba ॲक्सेस पॉईंट्स त्या फ्रेम्स शोधतात आणि प्रत्येक उपकरणाचा MAC ॲड्रेस आणि सिग्नल स्ट्रेंथ Central ला रिपोर्ट करतात. Central नंतर तुम्ही नियंत्रित करता ते दोन नियम लागू करते.

पहिला नियम म्हणजे सिग्नल स्ट्रेंथ. RSSI (रिसीव्हड सिग्नल स्ट्रेंथ इंडिकेटर) dBm मध्ये मोजला जातो आणि शून्याच्या जवळ असलेली मूल्ये दर्शवतात की उपकरण ॲक्सेस पॉईंटच्या जवळ आहे. तुमच्या RSSI थ्रेशोल्डच्या वर असणारे उपकरण आवारात उपस्थित असल्याचे मानले जाते. त्याखाली नोंदणी झालेले उपकरण येणारे-जाणारे म्हणून मोजले जाते.

दुसरा नियम म्हणजे ड्वेल टाइम (थांबण्याचा वेळ). थ्रेशोल्डच्या वर असणाऱ्या उपकरणांमध्ये, Central थोड्या वेळासाठी उपस्थित राहिलेली उपकरणे आणि प्रत्यक्ष भेट देणारे अभ्यागत वेगळे करण्यासाठी ड्वेल-टाइम मर्यादांचा वापर करते. त्यानंतर ते अभ्यागतांचे त्यांच्या थांबण्याच्या वेळेनुसार वेगवेगळ्या बँड्समध्ये वर्गीकरण करते.

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

Purple चे स्वतःचे प्रेझेन्स मॉडेल याच भौतिकशास्त्रावर काम करते. Presence (Legacy) documentation मध्ये अशा अनऑथेंटिकेटेड उपकरणांची गणना करण्याचे वर्णन आहे जे ॲक्सेस पॉईंटच्या इतके जवळ "पिंग" करतात की त्यांचा MAC ॲड्रेस रेकॉर्ड केला जाऊ शकतो. RSSI हा जवळीक दर्शवणारा सिग्नल म्हणून काम करतो. आवारातील कोणत्याही ॲक्सेस पॉईंटने त्या उपकरणाला किती वेळ पाहिले यावरून ड्युरेशन मोजले जाते. जर तुम्हाला एक मॉडेल समजले, तर तुम्हाला दोन्ही समजतील.

Aruba Central मध्ये presence analytics सुरू करण्यापूर्वी तुम्हाला कशाची गरज आहे?

पाच गोष्टी, आणि शेवटची गोष्ट अशी आहे जी सहसा टीम्स वगळतात.

1. presence analytics समाविष्ट असलेले Central सबस्क्रिप्शन. presence analytics प्रत्येक Central लायसन्स टियरचा भाग नाही. प्रत्येक साइटवरील APs ला दिलेल्या सबस्क्रिप्शननुसार HPE चे सध्याचे लायसन्सिंग डॉक्युमेंटेशन तपासा.
2. फक्त ग्रुपला नाही, तर साइटला नियुक्त केलेले APs. Central कॉन्फिगरेशनसाठी ग्रुप्सचा आणि लोकेशन व रिपोर्टिंगसाठी साइट्सचा वापर करते. प्रेझेन्स डेटा प्रति साइट एकत्रित केला जातो, त्यामुळे साइट नियुक्त न केलेला AP कोणताही उपयुक्त डेटा देत नाही.
3. भौतिक मर्यादा दर्शवलेला फ्लोअर प्लॅन. दरवाजे, दुकानाची दर्शनी काच, टेरेस, कार पार्क आणि शेजारील युनिट्स सामायिक असणाऱ्या भिंती चिन्हांकित करा. या अशा जागा आहेत जिथे तुमचा थ्रेशोल्ड सर्वात आधी चुकू शकतो.
4. तुम्ही ओळखू शकाल असे चाचणी उपकरण. आधुनिक iOS आणि Android रिलीज उपकरण प्रदर्शित करत असलेला MAC ॲड्रेस रँडमाइज करतात, त्यामुळे एकतर तुमच्या चाचणी हँडसेटवरील प्रायव्हेट ॲड्रेस सेटिंग बंद करा किंवा तो वापरत असलेला ॲड्रेस नोंदवून ठेवा.
5. एक गोपनीयता भूमिका. MAC Addresses हे डिव्हाइस आयडेंटिफायर्स आहेत. GDPR च्या Recital 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: जवळून जाणाऱ्यांना भेट देणाऱ्यांपासून वेगळे करणाऱ्या ड्वेल बाउंड्रीज सेट करा

केवळ RSSI मुळे काचेच्या जवळून चालत जाणाऱ्या कोणाचेही चुकीचे वर्गीकरण होऊ शकते. किमान व्हिजिटर ड्वेल त्यांना काढून टाकते. ते तुमच्या ठिकाणच्या सर्वात लहान अस्सल भेटीवर सेट करा, उद्योगाच्या सरासरीवर नाही. त्यानंतरचे मोठे बँड्स तुमचे व्हिजिटर्स किती व्यस्त आहेत याचे वर्णन करतात.

ठिकाणाचा प्रकार	जवळून जाणारी व्यक्ती कशी दिसते	किमान व्हिजिटर ड्वेलसाठी अँकर	वैधतेची पडताळणी करण्यासाठी ग्राउंड ट्रुथ
हाय स्ट्रीट रिटेल	दुकानाच्या दर्शनी भागावरून चालत जाणारा पादचारी	सर्वात जलद प्रत्यक्ष खरेदी, जसे की ग्रॅब-अँड-गो वस्तू	कॅश रजिस्टर ट्रान्झॅक्शन काउंट
हॉटेल लॉबी	लिफ्ट किंवा रेस्टॉरंटकडे जाणारा पाहुणा	सर्वात लहान चेक-इन किंवा कॉन्शियर सेवा संवाद	फ्रंट डेस्क चेक-इन लॉग
Stadium concourse	स्टँड आणि किओस्क दरम्यान चाहत्यांचे फिरणे	सर्वात कमी वेळात किओस्कवर झालेली खरेदी	किओस्क व्यवहार गणना
Library or council service point	लगतच्या रस्त्यावरील पादचारी	डेस्कवर विचारलेली सर्वात कमी वेळाची चौकशी	डेस्क चौकशी लॉग किंवा दरवाजा काउंटर

एका वेळी एकच सेटिंग बदला. जर तुम्ही RSSI threshold आणि dwell boundary एकत्र बदलले, तर कोणत्या बदलामुळे गणना बदलली हे तुम्हाला सांगता येणार नाही.

पायरी ४: Central API द्वारे प्रेझेन्स डेटा एक्सपोर्ट करा

Central डॅशबोर्ड्स एका नजरेत पाहण्यासाठी चांगले आहेत, परंतु पुढील रिपोर्टिंगसाठी डेटा बाहेर काढणे आवश्यक आहे. Aruba Central API एक्सपोर्ट चार पायऱ्यांचे अनुसरण करतो.

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

पायरी ३ दिसते त्यापेक्षा जास्त महत्त्वाची आहे. जेव्हा कोणी सहा महिन्यांनंतर threshold बदलेल, तेव्हा स्टोअर केलेल्या सेटिंग्ज विश्लेषकांना व्हिजिटर्समध्ये झालेली काल्पनिक घट रिपोर्ट करण्याऐवजी डेटा सिरीज विभागण्यास मदत करतात.

गणना बरोबर आहे हे तुम्ही कसे तपासता?

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

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

डेटावर विश्वास ठेवण्यापूर्वी चार सॅनिटरी तपासण्या करा:

• रात्रभरची गणना. बंद झाल्यानंतर रेकॉर्ड केलेले व्हिजिटर्स सहसा कर्मचाऱ्यांची डिव्हाइसेस, निश्चित डिव्हाइसेस किंवा तुमच्या threshold च्या वरील शेजाऱ्यांच्या उपकरणांकडे निर्देश करतात.
• क्षमता. एकाच वेळी उपस्थित असलेले व्हिजिटर्स कधीही ठिकाणाच्या परवानाकृत क्षमतेपेक्षा जास्त नसावेत.
• डॅशबोर्ड विरुद्ध API. तुमच्या API पुलमधील दैनिक एकूण संख्या समान साइट आणि विंडोसाठीच्या Central डॅशबोर्डशी जुळली पाहिजे. तफावत असल्यास सहसा टाइम झोनची चूक असते.
• साइट विरुद्ध साइट. समान व्यवसाय असलेल्या साइट्सची तुलना करा. ज्या साइटवर दुप्पट व्हिजिटर्स आहेत आणि निम्मे व्यवहार आहेत, तिथे सेल्सची समस्या नसून कॅलिब्रेशनची समस्या आहे.

खऱ्या वेन्यूमध्ये ट्यूनिंग कसे दिसते?

खालील दोन परिस्थिती पद्धत दर्शवण्यासाठी उदाहरणात्मक आकडेवारी वापरतात. तुमचे स्वतःचे आकडे वेगळे असतील, परंतु गणित तेच आहे.

Scenario 1: काचेचे दर्शनी भाग असलेले हाय स्ट्रीट फॅशन स्टोअर

परिस्थिती. एका मजल्याच्या दुकानात व्यस्त पदपथावर पूर्ण उंचीच्या काचेच्या दर्शनी भागाच्या काही मीटरच्या आत दोन AP आहेत. एका विशिष्ट शनिवारी, Central ने ४१० कॅश काउंटर व्यवहारांच्या तुलनेत ३,२९०० अभ्यागत नोंदवले. अंदाजे १३% चा हा कॅप्चर दर ट्रेडिंग टीमच्या अनुभवाच्या तुलनेत अशक्य वाटण्याइतका कमकुवत दिसत आहे.

काय केले गेले. नेटवर्क इंजिनिअरने शनिवारच्या दुपारच्या जेवणाच्या वेळी बाहेरील सीमेवर पाहणी केली. त्याला असे आढळले की थेट काचेच्या बाहेर पदपथावरील उपकरणांचे रीडिंग दरवाजाच्या अगदी आत असलेल्या उपकरणांइतकेच मजबूत होते. त्याने त्या दोन रीडिंगच्या दरम्यान राहण्यासाठी RSSI थ्रेशोल्ड वाढवला. त्यानंतर त्याने किमान अभ्यागत निवास वेळ (dwell time) काउंटरवर एकच वस्तू खरेदी करण्यासाठी लागणाऱ्या वेळेइतकी सेट केली.

परिणाम. पुढील शनिवारी, Central ने ४२५ व्यवहारांच्या तुलनेत १,१५० अभ्यागत नोंदवले, जे प्रति विक्री अंदाजे २.७ अभ्यागतांचे गुणोत्तर आहे. पुढील चार शनिवार व रविवार दरम्यान हे गुणोत्तर एका मर्यादित श्रेणीत राहिले. इनसाइट्स अ‍ॅनालिस्ट आता स्टोअरच्या retail ट्रेडिंग पुनरावलोकनासाठी रूपांतरण निर्देशक (conversion indicator) म्हणून दर आठवड्याला याचा अहवाल देतो.

Scenario 2: शेजारी हॉटेल असलेले कॉन्फरन्स सेंटरचे फॉयर

परिस्थिती. एका कॉन्फरन्स सेंटरचा २०० खोल्यांच्या हॉटेलशी काचेचा कॉरिडॉर जोडलेला आहे. इव्हेंट आयोजकांना फॉयरमधील प्रायोजक स्टँडची किंमत ठरवण्यासाठी दररोजच्या निवास वेळेचा (dwell data) डेटा हवा आहे. इव्हेंट सुरू असो किंवा नसो, Central चे निवास वितरण सर्वात कमी श्रेणीत मोठी वाढ दर्शवते.

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

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

Scenario 3: बाहेर बस स्टॉप असलेली कौन्सिल लायब्ररी

परिस्थिती. एक सार्वजनिक लायब्ररी बस स्टॉपच्या शेजारी आहे जिथे लोक काही मिनिटे थांबतात, जे प्रवेशद्वाराच्या AP च्या कव्हरेज रेंजमध्ये येते. कौन्सिलला त्यांच्या वार्षिक सेवा अहवालासाठी भेट देणाऱ्यांची संख्या हवी आहे.

काय केले गेले. केवळ RSSI किंवा केवळ निवास वेळेने बसची वाट पाहणाऱ्या प्रवाशाला लायब्ररीच्या अभ्यागतापासून वेगळे केले नाही. टीमने बस स्टॉपवरच घेतलेल्या रीडिंगचा वापर करून थ्रेशोल्ड सेट केला. त्यानंतर त्यांनी एका महिन्यासाठी सध्याच्या डोअर काउंटरच्या तुलनेत या संख्येची उलट तपासणी केली.

परिणाम. Presence संख्या आणि डोअर संख्या सुसंगत फरकासह एकत्रितपणे बदलल्या. कौन्सिलने डोअर काउंटरची संख्या अधिकृत आकडा म्हणून कायम ठेवली आणि तासानुसार पॅटर्न समजून घेण्यासाठी presence डेटाचा वापर केला, जो डोअर काउंटर पुरवू शकत नव्हता. या पॅटर्ननुसार चौकशी कक्षावरील कर्मचारी नियोजनात बदल करण्यात आले.

काय चुकते आणि तुम्ही ते कसे दुरुस्त करता?

व्हिजिटर्सची संख्या प्रत्यक्ष संख्येपेक्षा खूप जास्त दिसते

RSSI मर्यादा खूप सैल आहे, साधारणपणे काच, पातळ भिंत किंवा प्रवेशद्वाराजवळ लावलेल्या AP मुळे असे होते. गर्दीच्या वेळी सीमारेषेवर पुन्हा फिरून पाहा आणि मर्यादा वाढवा. जर AP च्या रचनेमुळे स्पष्ट फरक करणे अशक्य असेल, तर ते सीमेपासून थोडे दूर हलवण्याचा विचार करा.

मोबाईल OS अपडेटनंतर संख्येत बदल होतो

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

रात्रीचे किंवा पहाटेचे व्हिजिटर्स

कर्मचाऱ्यांचे फोन्स, हँडहेल्ड स्कॅनर, प्रिंटर आणि स्मार्ट डिव्हाइसेस दिवसभर मर्यादेपेक्षा जास्त ॲक्टिव्ह असतात. Central जिथे परवानगी देते तिथे ओळखीच्या डिव्हाइसचे ॲड्रेस वगळा किंवा तुमच्या डाउनस्ट्रीम रिपोर्टिंगमधून कामकाजाच्या वेळेव्यतिरिक्त इतर तास वगळा.

API कॉल्स ऑथरायझेशन एरर दाखवतात

ॲक्सेस टोकनची मुदत संपली आहे आणि रिफ्रेश स्टेप अयशस्वी झाली आहे किंवा कधी रनच झाली नाही. तुमचे जॉब रिफ्रेश टोकन वापरत असल्याची, मिळालेली नवीन टोकन जोडी स्टोअर करत असल्याची आणि कोणताही एरर आल्यास शांतपणे रिकामे दिवस नोंदवण्याऐवजी अलर्ट देत असल्याची खात्री करा.

ऐतिहासिक तुलनेत अचानक झालेला मोठा बदल

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

Captive portal च्या समस्यांमुळे ऑथेंटिकेट केलेल्या मेट्रिक्समध्ये बिघाड होतो

जर तुम्ही captive portal देखील चालवत असाल (जी एखादे डिव्हाइस नेटवर्क ॲक्सेस मिळण्यापूर्वी पाहते ते वेब पेज असते), तर रिडायरेक्ट अयशस्वी झाल्यामुळे ऑथेंटिकेट केलेल्या व्हिजिट्स कमी होतात. यामुळे presence संख्येवर परिणाम होत नाही. presence कॅलिब्रेशनपेक्षा वेगळी समस्या म्हणून पोर्टल रिडायरेक्ट्सची चौकशी करा.

Aruba Central ॲनालिटिक्सच्या मर्यादा काय आहेत?

नेटिव्ह presence ॲनालिटिक्स उपयुक्त आहे आणि तुमच्या Aruba मालमत्तेसोबत येते. याच्या काही ठराविक मर्यादा देखील आहेत ज्या तुम्ही भागधारकांना त्यावर आधारित रिपोर्टिंग प्रोग्राम तयार करण्यापूर्वी स्पष्टपणे सांगितल्या पाहिजेत.

• साईट-स्तरीय एकत्रीकरण (Site-level aggregation). Central प्रत्येक साईटनुसार रिपोर्ट तयार करते. जर तुम्हाला एखाद्या साईटमधील वेगवेगळ्या झोनची तुलना करायची असेल किंवा सुसंगत नियमांसह मोठ्या मालमत्तेमध्ये रँकिंग करायचे असेल, तर तुम्हाला ते डाउनस्ट्रीम स्वतः तयार करावे लागेल.
• रिटेंशन (माहिती साठवून ठेवणे). Central प्लॅटफॉर्म आणि तुमच्या सबस्क्रिप्शनद्वारे सेट केलेल्या मर्यादित कालावधीसाठी presence डेटा ठेवते. वर्षानुवर्षाची तुलना तुमच्या स्वतःच्या एक्स्पोर्टवर अवलंबून असते, त्यामुळे पहिल्या दिवसापासूनच API पाइपलाइन सुरू करा.- कोणताही ओळखलेला स्तर नाही. प्रेझेन्स डेटा हा केवळ अनामित डिव्हाइसेसची संख्या दर्शवतो. तुम्ही एखाद्या भेटीला संमती मिळालेला संपर्क, लॉयल्टी अकाउंट किंवा CRM रेकॉर्डशी जोडू शकत नाही. यादृच्छिक (Randomised) MAC Addresses मुळे दीर्घ कालावधीत अनामित वारंवार येणाऱ्या भेटींची संख्या देखील अविश्वसनीय बनते.
• सिंगल-व्हेंडर व्ह्यू. Central ला फक्त Aruba ॲक्सेस पॉइंट्स दिसतात. ज्या मालमत्तांमध्ये अधिग्रहित केलेल्या ठिकाणी Cisco Meraki, Ruckus किंवा Juniper Mist सोबत Aruba चे मिश्रण आहे, तिथे केवळ अर्धवट चित्र दिसते.
• कॅलिब्रेशनची उणीव. प्रत्येक नवीन बदल, AP ची जागा बदलणे किंवा नवीन काचेचे काम यांमुळे रेडिओ वातावरण बदलते. इन्स्टॉलेशनच्या वेळी योग्य असलेले थ्रेशोल्ड्स (मर्यादा), जोपर्यंत कोणी पुन्हा येऊन त्या जागेची प्रत्यक्ष तपासणी करत नाही, तोपर्यंत बदलत राहतात.

यापैकी कोणतीही त्रुटी नाही. ही एका नेटवर्क व्हेंडरच्या ॲनालिटिक्स वैशिष्ट्याची व्याप्ती आहे, आणि यावरूनच हे स्पष्ट होते की प्लॅटफॉर्म स्तर कुठे आपले स्थान निर्माण करतो.

याचा खर्च किती आहे, आणि यावरील प्लॅटफॉर्म स्तर कधी फायदेशीर ठरतो?

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

Purple चे WiFi Analytics Central ची नक्कल न करता एक वेगळा स्तर जोडते. हे तुमच्याकडे आधीपासूनच असलेल्या Aruba ॲक्सेस पॉइंट्सवर कोणतेही हार्डवेअर न बदलता क्लाउड ओव्हरले म्हणून चालते. Purple चे Guest WiFi Captive Portal जाणीवपूर्वक घेतलेल्या संमतीद्वारे एक अधिकृत स्तर जोडते, ज्यामुळे तुम्हाला फर्स्ट-पार्टी डेटा मिळतो जो अनामित प्रेझेन्स डेटा देऊ शकत नाही.

क्षमता	Aruba Central प्रेझेन्स ॲनालिटिक्स	तुमच्या Aruba APs वरील Purple WiFi Analytics
हे काय मोजते	RSSI थ्रेशोल्डच्या वरील अनामित डिव्हाइसेस	अशा भेटी जिथे सिग्नलच्या क्षमतेमुळे डिव्हाइस जागेच्या आत असल्याचे निश्चित होते, तसेच अधिकृत व्हिजिटर्स
ओळख	काहीही नाही, केवळ MAC address	संमती दिलेल्या फर्स्ट-पार्टी डेटासह अधिकृत व्हिजिटर्स
ड्वेल (थांबण्याचा काळ) रिपोर्टिंग	प्रति साइट कालावधीचे टप्पे	अधिकृत व्हिजिटर्ससाठी प्रति भेट सरासरी थांबण्याचा काळ
वेळेचे नमुने	निवडलेल्या कालावधीत साइट डॅशबोर्ड्स	आठवड्याचा दिवस आणि दिवसाच्या तासानुसार भेटींचा हीटमॅप
क्रॉस-व्हेन्यू व्ह्यू	प्रति-साइट, मालमत्तेसाठी डाउनस्ट्रिम तयार केलेले	भेटींनुसार टॉप 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) अभ्यागतांच्या डेटावर प्रक्रिया करण्यासाठी अधिकृत (authenticated) अभ्यागतांच्या डेटापेक्षा जास्त वेळ लागू शकतो.

जर तुम्ही एकल Aruba इस्टेट चालवत असाल, तुम्हाला निनावी ऑक्युपन्सी आणि ड्वेल पॅटर्न हवे असतील, आणि तुमच्याकडे कॅलिब्रेशन आणि API पाइपलाइन हाताळू शकणारा इंजिनिअर असेल तर नेटिव्ह राहा.

प्लॅटफॉर्म लेयर जोडा जेव्हा यांपैकी कोणतीही गोष्ट लागू होते: तुम्ही मिश्र हार्डवेअर चालवता; तुम्ही अनेक ठिकाणांची एकमेकांशी तुलना करता; किंवा तुम्हाला मार्केटिंग किंवा सर्व्हिस डिझाइनसाठी संमती असलेला, ओळखता येणारा अभ्यागत डेटा हवा असतो. हे अतिथी प्रोफाइल तयार करणाऱ्या हॉटेल्स आणि भेटींना मोहिमांशी जोडणाऱ्या रिटेल चेन्सना लागू होते. Purple ८०,०००+ हून अधिक लाइव्ह ठिकाणी कार्यरत आहे आणि २०२४ मध्ये ४४० दशलक्ष लॉगइन हाताळले आहेत (हा Purple चा स्वतःचा डेटा आहे). त्यापैकी बहुतांश ठिकाणी आधीपासूनच स्थापित असलेल्या हार्डवेअरवर हे काम चालते.

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

माझ्या Aruba Central परवान्यामध्ये प्रेझेन्स ॲनालिटिक्स समाविष्ट आहे का?

प्रत्येक बाबतीत नाही. प्रेझेन्स ॲनालिटिक्स विशिष्ट Aruba Central सबस्क्रिप्शन टियर्समध्ये समाविष्ट असते, त्यामुळे प्रत्येक साइटवरील APs कडे ते समाविष्ट करणारा टियर असल्याची खात्री करा. रोलआउटचे नियोजन करण्यापूर्वी तुमच्या Central खात्यामध्ये नियुक्त केलेल्या सबस्क्रिप्शन्ससह HPE चे सध्याचे परवाना दस्तऐवज तपासा. जर काही साइट्सवर लोअर टियर असेल, तर तुम्हाला इस्टेट-व्यापी रिपोर्टिंगमध्ये त्रुटी आढळतील. आधी परवाना दुरुस्त करा, नंतर कॅलिब्रेट करा.

Purple माझ्या अस्तित्वात असलेल्या HPE Aruba ॲक्सेस पॉइंट्ससह काम करते का?

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

मी Aruba Central प्रेझेन्स डेटा डेटा वेअरहाउस किंवा BI टूलमध्ये एक्सपोर्ट करू शकतो का?

होय, Central REST API च्या माध्यमातून. API Gateway मध्ये एक API क्लायंट तयार करा, OAuth 2.0 टोकन्ससह ऑथेंटिकेट करा, आणि साइट-लेव्हल ॲग्रीगेट्ससाठी प्रेझेन्स ॲनालिटिक्स एंडपॉइंट्स कॉल करा. प्रत्येक साइटसाठी दररोज डेटा खेचण्याचे शेड्युल करा, टाइमस्टॅम्प्स UTC मध्ये स्टोअर करा, आणि लागू असलेल्या थ्रेशोल्ड सेटिंग्ज रेकॉर्ड करा. Central रिटेंशन मर्यादित असल्याने, तुमचे एक्सपोर्ट हे वर्ष-दर-वर्ष तुलनेसाठी दीर्घकालीन रेकॉर्ड बनते.

WiFi प्रेझेन्स डेटा GDPR अंतर्गत वैयक्तिक डेटा आहे का?

याला वैयक्तिक डेटा म्हणून हाताळा. GDPR च्या Recital 30 मध्ये उपकरणाद्वारे प्रदान केलेल्या ऑनलाइन आयडेंटिफायर्सचा असा उल्लेख आहे ज्यामुळे व्यक्तीची ओळख पटू शकते, आणि प्रेझेन्स ॲनालिटिक्स MAC ॲड्रेसेसवर प्रक्रिया करते. डेटा प्रोटेक्शन इम्पॅक्ट असेसमेंट पूर्ण करा, प्रवेशद्वारांवर स्पष्ट फलक लावा, आणि रिटेंशन प्रमाणात ठेवा. संकलित केलेल्या एकत्रित संख्येमध्ये कच्च्या आयडेंटिफायर्सपेक्षा कमी धोका असतो, परंतु संकलन टप्पा अजूनही कक्षेमध्ये येतो.

Aruba presence analytics सेट अप आणि कॅलिब्रेट करण्यासाठी किती वेळ लागतो?

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

MAC ॲड्रेस रँडमायझेशनमुळे Aruba presence counts निरुपयोगी होतील का?

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

मी Aruba Central presence analytics निवडावे की Purple WiFi Analytics?

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

आयडेंटिफाय केलेली ॲनालिटिक्स लेयर जोडण्यासाठी मला नवीन हार्डवेअरची गरज आहे का?

नाही. Purple तुम्ही आधीपासूनच चालवत असलेल्या HPE Aruba ॲक्सेस पॉइंट्सवर काम करते, त्यामुळे जुने काढून नवीन बसवण्याची गरज नाही. आयडेंटिफाय केलेली लेयर नवीन रेडिओमधून नाही, तर जाणीवपूर्वक घेतलेल्या संमतीसह captive portal कडून येते. तुमचे सध्याचे Central कॉन्फिगरेशन, presence analytics आणि API एक्सपोर्ट्स यासोबत काम करत राहतील.