Cisco Meraki स्थान विश्लेषण: आपल्याला इन-बिल्ट काय मिळते आणि ते कुठे थांबते

Cisco Meraki ॲक्सेस पॉइंट्समध्ये कोणत्याही स्वतंत्र परवान्याशिवाय स्थान विश्लेषण (location analytics) समाविष्ट असते. तुम्हाला प्रोक्सिमिटी, एंगेजमेंट आणि लॉयल्टी व्ह्यूज, फ्लोअर-प्लान हीटमॅप आणि कच्च्या निरीक्षणांसाठी स्कॅनिंग API मिळते. हे अनामित उपकरणांची संख्या मोजते, लोकांची नाही. MAC रँडमायझेशनमुळे पुन्हा भेट देणाऱ्यांची आकडेवारी कमकुवत होते, व्ह्यूज प्रति नेटवर्क मर्यादित असतात आणि कॅप्टिव्ह पोर्टलशिवाय तुम्हाला ओळख असलेला व्हिजिटर मिळत नाही.

Cisco Meraki स्थान विश्लेषण (location analytics) म्हणजे काय?

Cisco Meraki स्थान विश्लेषण ही Meraki MR ॲक्सेस पॉइंट्स आणि Meraki डॅशबोर्डमध्ये तयार केलेली उपस्थिती अहवाल (presence reporting) प्रणाली आहे. तुमचे ॲक्सेस पॉइंट्स जवळच्या उपकरणांचे प्रोब रिक्वेस्ट आणि ट्रॅफिक ऐकतात. डॅशबोर्ड त्या शोधलेल्या उपकरणांचे प्रत्येक नेटवर्कसाठी मोजणी, कालावधी आणि पुन्हा भेट देण्याच्या पॅटर्नमध्ये रूपांतर करतो.

Cisco ही सुविधा Meraki वायरलेससोबत समाविष्ट करते. त्यामुळे बहुतांश Meraki वापरकर्ते फूटफॉलबद्दलची माहिती शोधण्यासाठी प्रथम याचाच वापर करतात. यात तुम्हाला सुरुवातीलाच चार गोष्टी मिळतात.

प्रोक्सिमिटी, एंगेजमेंट आणि लॉयल्टी व्ह्यूज

डॅशबोर्ड उपस्थितांच्या डेटाची तीन व्ह्यूजमध्ये विभागणी करतो:

• प्रोक्सिमिटी शोधलेल्या उपकरणांना वाटसरू (passersby), व्हिजिटर्स (visitors) आणि कनेक्ट केलेले (connected) अशा भागात विभागते. वाटसरू कमी कालावधीसाठी किंवा कमी सिग्नल क्षमतेवर ऐकू येतात. व्हिजिटर्स पुरेशा जवळ आणि पुरेशा वेळेसाठी दिसतात, ज्यामुळे त्यांची गणना परिसराच्या आत मानली जाते. कनेक्ट केलेल्या उपकरणांनी तुमच्या WiFi मध्ये प्रवेश केला आहे.
• एंगेजमेंट व्हिजिटर्सची त्यांच्या थांबण्याच्या वेळेनुसार (dwell time) वर्गवारी करते: 5 - 20 मिनिटे, 20 - 60 मिनिटे, 1 - 6 तास आणि 6+ तास.
• लॉयल्टी व्हिजिटर्सची त्यांच्या परत येण्याच्या वारंवारतेनुसार वर्गवारी करते: पहिल्यांदा आलेले, दैनंदिन, साप्ताहिक आणि कधीतरी येणारे.

Cisco चे स्थान विश्लेषण दस्तऐवजीकरण (location analytics documentation) प्रत्येक श्रेणीमागील सिग्नल आणि वेळेच्या मर्यादा परिभाषित करते. तुमच्या बोर्डसमोर कोणतीही आकडेवारी मांडण्यापूर्वी या व्याख्या नक्की वाचा.

Meraki लोकेशन हीटमॅप

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

Meraki स्कॅनिंग API

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

तुमच्या ठिकाणासाठी Meraki उपस्थितांचा डेटा का महत्त्वाचा आहे?

उपस्थितांचा डेटा अशा प्रश्नांची उत्तरे देतो जी बिलिंग काउंटर आणि तिकीट स्कॅनर्स देऊ शकत नाहीत. आत न येता किती लोक प्रवेशद्वारावरून पुढे गेले? ते किती वेळ थांबले? मंगळवारी दुपारी 3 वाजता कोणते झोन रिकामे होते?

रिटेल टीम्स दुकानाच्या दर्शनी भागाचे रूपांतरण (frontage conversion) समजण्यासाठी वाटसरू आणि व्हिजिटर यांच्या प्रमाणाचा अभ्यास करतात. हॉटेल्स लॉबी बार किंवा स्पा मधील थांबण्याचा वेळ पाहून पाहुणे त्यांच्या संध्याकाळ कोठे घालवतात हे पाहतात. हेल्थकेअर इस्टेट्स टीम्स अपॉइंटमेंट लिस्टऐवजी प्रत्यक्षात पाहिलेल्या व्हिजिटर्सच्या संख्येनुसार प्रतीक्षालयाचा आकार ठरवू शकतात.

आकर्षण स्पष्ट आहे. तुम्ही मालकी असलेल्या हार्डवेअरवर डेटा आधीच गोळा केला जात आहे. उपयुक्त प्रश्न हा आहे की तुम्हाला अधिक डेटाची आवश्यकता भासण्यापूर्वी तो तुम्हाला किती दूर घेऊन जातो.

Meraki लोकेशन ॲनालिटिक्स कसे काम करते?

ते चालू करणे

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

कोणत्याही आकड्यावर विश्वास ठेवण्यापूर्वी दोन तपासण्या:

1. प्रत्येक ॲक्सेस पॉइंट योग्य मजल्यावर आणि योग्य स्थानावर पिन केला असल्याची पुष्टी करा.
2. तुम्ही कालावधी किंवा साइट्सची तुलना करण्यापूर्वी काही आठवड्यांचा बेसलाइन डेटा गोळा करा.

स्थान निश्चितीसाठी ॲक्सेस पॉइंट डेंसिटी हा एक डिझाइन निर्णय आहे, तो एक साधा टॉगल नाही. केवळ कव्हरेजसाठी डिझाइन केलेले नेटवर्क केवळ एकाच ॲक्सेस पॉइंटद्वारे ऐकल्या जाणाऱ्या उपकरणांना सोडू शकते. ते संख्या दर्शवते परंतु स्थान अचूक दाखवत नाही. आमचे Network Best Practices for Venues and Enterprises in 2026 प्लेसमेंट आणि डेंसिटी समाविष्ट करते.

तीन व्ह्यूज वाचणे

Proximity. केवळ येणाऱ्या-जाणाऱ्यांची संख्या पाहण्याऐवजी गुणोत्तरावर लक्ष ठेवा. येणाऱ्या-जाणाऱ्यांमध्ये भिंती आणि खिडक्यांमधून ऐकल्या जाणाऱ्या उपकरणांचा समावेश होतो, आणि MAC रँडमायझेशनमुळे हा आकडा वाढतो, जसे की खाली स्पष्ट केले आहे. अभ्यागत आणि कनेक्ट केलेल्यांची संख्या अधिक स्थिर असते.

Engagement. ऑपरेशनल निर्णयांसाठी हा सर्वात विश्वासार्ह व्ह्यू आहे, विशेषतः कनेक्ट केलेल्या उपकरणांसाठी. कनेक्ट केलेले उपकरण सामान्यतः संपूर्ण भेटीदरम्यान तुमच्या नेटवर्कवर एकच खाजगी पत्ता ठेवते. कधीही कनेक्ट न होणारी उपकरणे त्यांचे प्रोब पत्ते फिरवत राहतात, ज्यामुळे एक लांब भेट अनेक लहान भेटींमध्ये विभागली जाऊ शकते. लेआउट बदलामुळे लोक जास्त वेळ थांबले का हे ठरवण्यासाठी दर आठवड्याला त्याच श्रेणीची तुलना करा.

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

Meraki स्कॅनिंग API वापरणे

Meraki स्कॅनिंग API द्वारे तुमची डेटा टीम थेट निरीक्षणे तिच्या स्वतःच्या पाइपलाइनमध्ये मिळवते. Cisco चे स्कॅनिंग API दस्तऐवजीकरण सध्याची आवृत्ती आणि पेलोड स्कीमा निर्धारित करते. थोडक्यात:

• तुम्ही डॅशबोर्डमध्ये एक रिसीव्हर URL नोंदवता. Meraki व्हॅलिडेशन विनंती पाठवते, आणि तुमच्या सर्व्हरने डॅशबोर्ड प्रदर्शित करणारी व्हॅलिडेटर स्ट्रिंग परत केली पाहिजे.
• Meraki नंतर Cisco च्या दस्तऐवजीकरणानुसार साधारणपणे मिनिटातून एकदा बॅचमध्ये निरीक्षणांचे JSON पेलोड पोस्ट करते.
• प्रत्येक पेलोड तुम्ही सेट केलेले सामायिक केलेले सिक्रेट वाहून नेते, त्यामुळे तुमचा रिसीव्हर तुमच्या नेटवर्कवरून न आलेली कोणतीही गोष्ट नाकारू शकतो.
• WiFi आणि Bluetooth Low Energy (BLE) निरीक्षणे स्वतंत्र स्ट्रीम म्हणून येतात.
• प्रत्येक निरीक्षणामध्ये क्लायंट MAC पत्ता, निर्माता आणि RSSI सह जवळचा ॲक्सेस पॉइंट समाविष्ट असतो. कनेक्ट केलेली उपकरणे SSID ची माहिती देखील देतात.
• लोकेशनचे अंदाज x/y कोऑर्डिनेट्स आणि लॅटिट्यूड/लॉन्गिट्यूड म्हणून येतात, ज्यामध्ये अंदाज किती विश्वासार्ह आहे हे दर्शवणारा व्हेरियन्स आकडा असतो.

API तुम्हाला पूर्ण नियंत्रण देते. तुम्ही तुमच्या इमारतीला अनुकूल असे RSSI थ्रेशोल्ड आणि किमान ड्वेल टाइम वापरून स्वतःची व्हिजिटर व्याख्या सेट करू शकता. उपयुक्त ठरण्यासाठी ज्यांची व्हॅरिएंस खूप जास्त आहे अशी पोझिशन्स तुम्ही काढून टाकू शकता. तुम्ही आगमनावरच MAC ॲड्रेस हॅश करू शकता जेणेकरून राॉ आयडेंटिफायर्स तुमच्या डेटा वेअरहाऊसपर्यंत कधीही पोहोचणार नाहीत.

हे तुम्हाला मालकी हक्कदेखील देते. तुम्ही रिसीव्हर होस्ट करता, तो उपलब्ध ठेवता, API व्हर्जनमधील स्कीमा बदल सामावून घेता आणि डिव्हाइस आयडेंटिफायर्ससाठी GDPR च्या जबाबदाऱ्या पार पाडता. यासाठी केवळ सुरुवातीच्या निर्मितीचाच नाही, तर इंजिनिअरिंग वेळेच्या बजेटचाही विचार करा.

तुम्ही आधीपासून चालवत असलेल्या सिस्टीमसोबत हे कुठे बसते?

Meraki चे नेव्हिट व्ह्यूज आणि स्कॅनिंग API दोन्ही डिव्हाइसेसचे मोजमाप करतात. Captive Portal अशा लोकांचे मोजमाप करते ज्यांनी स्वतःची ओळख पटवणे निवडले आहे. Captive Portal हे एक वेब पेज आहे जे इंटरनेट ॲक्सेस मिळण्यापूर्वी डिव्हाइसला दिसते, जिथे भेट देणारा साइन इन करतो किंवा अटी स्वीकारतो. हे दोन्ही वेगवेगळ्या प्रश्नांची उत्तरे देतात, त्यामुळे बहुतांश प्रगल्भ नेटवर्क दोन्ही प्रणाली वापरतात.

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

क्षमता	Meraki डॅशबोर्ड व्ह्यूज	Meraki स्कॅनिंग API	Meraki वर Purple
हे कशाचे मोजमाप करते	अनामित डिव्हाइस संख्या, ड्वेल टाइम आणि पुन्हा येण्याची वारंवारता	अंदाजे दर मिनिटाला बॅचमध्ये प्रत्येक डिव्हाइसचे रॉ निरीक्षण	प्रोफाइल आणि संमती रेकॉर्ड असलेले लॉग-इन केलेले भेट देणारे
व्याप्ती	एका वेळी एक नेटवर्क	तुम्ही तुमच्या रिसीव्हरकडे निर्देशित केलेले प्रत्येक नेटवर्क	एकाच डॅशबोर्डवर प्रत्येक ठिकाण
इतिहास	लोकेशन डेटासाठी Cisco ची प्रकाशित रिटेंशन विंडो	तुमच्या स्वतःच्या स्टोअरमध्ये जे काही राखून ठेवले जाते	Purple प्लॅटफॉर्मवर ठेवलेले (ISO 27001 प्रमाणित)
MAC रँडमायझेशनचा प्रभाव	लॉयल्टी आणि येणाऱ्या-जाणाऱ्यांची संख्या विस्कळीत होते	तोच विस्कळीतपणा, परंतु तुम्ही त्याचे मॉडेल तयार करू शकता	पुन्हा येणाऱ्या भेटींना लॉगिन प्रोफाइलशी जुळवले जाते
भेट देणाऱ्याची ओळख पटवते	नाही	नाही	होय, स्पष्ट इच्छेने दिलेल्या ऑप्ट-इनद्वारे
मार्केटिंग संमती	मिळवली जात नाही	मिळवली जात नाही	लॉगिनच्या वेळी मिळवली जाते
चालवण्यासाठीचे प्रयत्न	प्रति नेटवर्क सक्षम करा, फ्लोअर प्लॅनवर ॲक्सेस पॉइंट्स ठेवा	रिसीव्हर, स्टोअर आणि डेटा मॉडेल तयार करा, होस्ट करा आणि ते व्यवस्थापित करा	Meraki वर Captive Portal कॉन्फिगर करा, कोणत्याही नवीन हार्डवेअरची गरज नाही
खर्च	Meraki वायरलेस सोबत समाविष्ट	समाविष्ट, अधिक तुमचा होस्टिंग आणि इंजिनिअरिंग वेळ	तुमच्या Meraki लायसन्ससोबत Purple सबस्क्रिप्शन

Meraki लोकेशन ॲनालिटिक्सच्या मर्यादा काय आहेत?

रिटेंशन विंडो

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

तुम्हाला मोठा इतिहास हवा असल्यास, पहिल्या दिवसापासून स्कॅनिंग API द्वारे तुमच्या स्वतःच्या स्टोअरमध्ये डेटा स्ट्रीम करा. API रिअल टाइमच्या जवळपास निरीक्षणे पाठवते. हे इतिहासाची पुनरावृत्ती करत नाही, त्यामुळे तुमच्या रिसीव्हरकडून जे काही सुटले ते निघून जाते.

तुम्हाला तुमच्या स्वतःच्या स्टोअरच्या जबाबदाऱ्या पार पाडाव्या लागतील. GDPR चे डेटा स्टोरेज मर्यादा तत्त्व, आर्टिकल 5(1)(e), तुम्हाला वैयक्तिक डेटा आवश्यकतेपेक्षा जास्त काळ न ठेवण्याची सक्ती करते. डेटा जतन करण्याचा कालावधी निश्चित करा, त्याची नोंद ठेवा आणि वेळेवर तो हटवा.

साइट-स्तरीय एकत्रीकरण (Aggregation)

मूळ दृश्ये एकाच नेटवर्कभोवती तयार केली जातात, ज्याचा अर्थ सहसा एकच साइट असा होतो. 60 स्टोअरची मालमत्ता म्हणजे चार्टचे 60 संच. क्रॉस-साइट मूल्यांकनासाठी प्रत्येक नेटवर्कनुसार डेटा एक्सपोर्ट करावा लागतो किंवा स्कॅनिंग API वर तुमची स्वतःची पाइपलाइन तयार करावी लागते.

मूळ दृश्ये तुम्हाला हे देखील सांगू शकत नाहीत की एका खरेदीदाराने एकाच आठवड्यात तुमच्या लीड्स आणि मँचेस्टर स्टोअरला भेट दिली आहे. प्रत्येक नेटवर्क केवळ स्वतःची डिव्हाइसेस पाहते आणि रँडम करण्यात आलेले ॲड्रेसेस वेगवेगळ्या साइट्समधील कोणत्याही मॅचिंग प्रयत्नांना अपयशी ठरवतात.

MAC रँडोमायझेशन आणि लॉयल्टी कॅटेगिरी

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

Meraki च्या उपस्थिती डेटावरील परिणाम स्पष्ट आहेत:

• पासर्सबाय (रस्त्याने जाणारे) वाढून दिसतात. कनेक्ट न होणारा एकच फोन त्याचा प्रोब ॲड्रेस बदलत राहिल्याने अनेक डिव्हाइसेस म्हणून दिसू शकतो.
• पहिल्यांदा भेट देणारे ग्राहक वाढून दिसतात. पुन्हा भेट देणारा फोन जर कनेक्ट झाला नाही तर तो नवीन ॲड्रेस दाखवतो, ज्यामुळे डॅशबोर्ड नवीन व्यक्तीची नोंद करतो.
• दैनिक आणि साप्ताहिक लॉयल्टी कमी दिसते. याच कारणामुळे वारंवार येणाऱ्या भेटींची नोंद होत नाही.

कनेक्ट केलेली डिव्हाइसेस अधिक चांगली कामगिरी करतात, कारण प्रति-नेटवर्क खाजगी ॲड्रेस सहसा तुमच्या SSID वर तसाच राहतो. अलीकडील Apple रिलीजमध्ये रँडोमायझेशन पर्याय जोडला गेला आहे जो कालावधीनुसार तो ॲड्रेस देखील बदलतो. त्यामुळे वापरकर्ते वाढतील तसतशी कनेक्ट केलेल्या डिव्हाइसची लॉयल्टी कमी होण्याची अपेक्षा ठेवा.

व्यवहारिक नियम: लॉयल्टी ही कनेक्ट केलेल्या डिव्हाइसेससाठी केवळ एक ट्रेंड म्हणून रिपोर्ट करा, पुन्हा भेट देणाऱ्या ग्राहकांचा अंतिम आकडा म्हणून कधीही नाही. व्यवसायासमोर ते "पुन्हा येणारे ग्राहक" म्हणून कधीही सादर करू नका.

कोणतीही ओळख पटलेली व्हिजिटर लेयर नाही

नेटिव्ह ॲनालिटिक्सला कोण व्यक्ती कोण आहे हे कधीही माहित नसते. त्यामध्ये कोणतेही नाव, ईमेल ॲड्रेस, संमतीची नोंद आणि तुमच्या CRM किंवा मालमत्ता व्यवस्थापन प्रणालीची लिंक नसते. तुम्ही पाहू शकता की एका झोनमध्ये थांबण्याचा वेळ (dwell) 12% ने वाढला आहे. परंतु तुम्ही त्या भेट देणाऱ्यांना काहीही पाठवू शकत नाही किंवा त्यांनी किती खर्च केला याचे मोजमाप करू शकत नाही.

त्या लेयरसाठी Captive Portal ची आवश्यकता असते जिथे भेट देणारे स्वतःची ओळख पटवणे निवडतात. Purple चे Guest WiFi स्पष्ट इच्छेने केलेल्या ऑप्ट-इन्सद्वारे फर्स्ट-पार्टी डेटा गोळा करते आणि CRM व मार्केटिंग प्लॅटफॉर्मसह समाकलित होते. त्यामुळे वारंवार होणाऱ्या भेटी केवळ डिव्हाइस ॲड्रेसवरून न मोजता, भेट देणाऱ्याने ज्या प्रोफाईलने लॉग इन केले आहे त्यावरून मोजल्या जातात. Purple ने 2024 मध्ये 80,000+ हून अधिक सक्रिय ठिकाणी 440 दशलक्ष लॉग इन प्रक्रिया पूर्ण केल्या आहेत (Purple डेटा).

वास्तविक ठिकाणांवर Meraki लोकेशन ॲनालिटिक्स कसे कार्य करते

खालील दोन परिस्थिती प्रातिनिधिक उदाहरणे आहेत. आकडेवारी केवळ पद्धत स्पष्ट करते, कोणत्याही विशिष्ट ठिकाणाचा निकाल नाही.

परिस्थिती 1: 60 स्टोअर असलेला फॅशन रिटेलर स्टोअर्सची तुलना करतो

परिस्थिती. इनसाइट्स टीमला ग्राहकांच्या थांबण्याच्या वेळेनुसार (dwell) दुकानांची साप्ताहिक रँकिंग हवी होती. प्रत्येक दुकान स्वतःचे Meraki नेटवर्क चालवत होते. हा अहवाल तयार करण्यासाठी 60 डॅशबोर्ड उघडावे लागत होते आणि एका स्प्रेडशीटमध्ये एंगेजमेंटचे आकडे कॉपी करावे लागत होते, ज्यासाठी दर आठवड्याला साधारणपणे एक दिवस लागायचा.

काय केले गेले. IT टीमने एक स्कॅनिंग API रिसिव्हर उभा केला आणि सर्व 60 नेटवर्क त्याच्याशी जोडले. त्यांनी येणाऱ्या MAC ॲड्रेस हॅश केले, संपूर्ण प्रॉपर्टीवर एक RSSI थ्रेशोल्ड लागू केला आणि जास्त फरक असलेल्या निरीक्षणांना काढून टाकले. त्यांनी 13 महिन्यांचा रिटेंशन कालावधी निश्चित केला, जो त्यांच्या GDPR रेकॉर्ड अंतर्गत डॉक्युमेंट केला गेला.

निकाल. साप्ताहिक अहवाल हा सर्व 60 दुकानांचा समावेश करणारी एक स्वयंचलित क्वेरी बनली. लॉयल्टी बकेट काय लपवत होते याचीही टीमने पुष्टी केली. कमी WiFi वापर असलेल्या दुकानांमध्ये, 80% पेक्षा जास्त अभ्यागत पहिल्यांदा आलेले म्हणून नोंदवले गेले, जे रिटेलरच्या स्वतःच्या ॲप डेटातील खूपच कमी आकड्याच्या विरुद्ध होते. बोर्ड पॅकमधून लॉयल्टी हटवण्यात आली आणि त्याऐवजी थांबण्याची वेळ आणि अभ्यागत-ते-जाणारे यांचे प्रमाण जोडले गेले.

सिनॅरिओ 2: पुन्हा येणाऱ्या ग्राहकांचा शोध घेणारे 200 खोल्यांचे हॉटेल

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

काय केले गेले. लॉयल्टी बकेट्स डिव्हाइस ॲड्रेस मोजतात, ग्राहक नाही, हे टीमने मान्य केले. त्यांनी विद्यमान Meraki ॲक्सेस पॉइंट्सवर लॉगिनच्या वेळी ऐच्छिक मार्केटिंग ऑप्ट-इनसह Purple Captive Portal जोडले. त्यांनी बार, रेस्टॉरंट आणि स्पा मधील झोन ड्वेलसाठी Meraki एंगेजमेंट व्ह्यू चालू ठेवला.

निकाल. पुन्हा येणारे ग्राहक आता ॲड्रेसवरून अंदाज लावण्याऐवजी लॉगिनच्या वेळी ओळखले गेले. ऑप्ट-इन केलेल्या ग्राहकांची माहिती पूर्व-आगमन ऑफरसाठी CRM मध्ये पाठवली गेली. एंगेजमेंट डेटाने बारमधील कर्मचारी व्यवस्थापनास मदत केली. जर तुम्ही नवीन करारासाठी हे निश्चित करत असाल, तर आमचे Hotel WiFi RFP checklist: authentication, content filtering and guest marketing विचारले जाणारे प्रश्न सूचीबद्ध करते.

तुम्ही पुढे काय करावे?

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

तुमची परिस्थिती	काय वापरावे
एक साइट, व्यस्त झोन आणि वेळेबद्दलचे ऑपरेशन्सचे प्रश्न	Meraki डॅशबोर्ड व्ह्यूज आणि लोकेशन हीटमॅप
अनेक साइट्स, डेटा टीम, दीर्घ इतिहासाची गरज	तुमच्या स्वतःच्या वेअरहाऊसमध्ये Meraki स्कॅनिंग API
तुम्ही समर्थन करू शकाल अशा पुनरावृत्ती भेटींचा अहवाल देण्याची गरज	लॉगिनसह Captive Portal, डिव्हाइस लॉयल्टी बकेट्स नाही
अभ्यागतांशी संपर्क साधण्याची किंवा खर्चाशी भेटी जोडण्याची गरज	Meraki वर Purple Guest WiFi आणि WiFi Analytics
मर्यादित इंजिनिअरिंग क्षमता, अनेक साइट्स	स्वतः तयार केलेल्या पाइपलाइनऐवजी Purple WiFi Analytics
नंतर चार टप्प्यांवर काम करा:

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

यापैकी कशासाठीही नवीन एक्सेस पॉईंट्सची गरज नाही. आमचा ब्लॉग Why your next WiFi upgrade doesn't need new hardware Meraki वरील ओव्हरले दृष्टिकोन स्पष्ट करतो.

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

Cisco Meraki लोकेशन ॲनालिटिक्स Meraki परवान्यामध्ये समाविष्ट आहे का?

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

Meraki लोकेशन ॲनालिटिक्स मला माझे अभ्यागत कोण आहेत हे सांगू शकते का?

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

Meraki लोकेशन ॲनालिटिक्स डेटा किती काळ ठेवते?

Cisco च्या प्रकाशित Meraki डेटा रिटेंशन दस्तऐवजीकरणामध्ये नमूद केलेल्या कालावधीसाठी Meraki लोकेशन डेटा ठेवते. वर्ष-दर-वर्ष रिपोर्टिंगचे नियोजन करण्यापूर्वी तेथील सध्याचे आकडे तपासा. तुम्हाला अधिक काळाचा इतिहास हवा असल्यास, पहिल्या दिवसापासूनच स्कॅनिंग API द्वारे तुमच्या स्वतःच्या स्टोअरमध्ये निरीक्षणे स्ट्रीम करा. API मागील डेटा पुन्हा प्ले करत नाही. तुमच्या स्वतःच्या स्टोअरने त्यानंतर GDPR च्या स्टोरेज लिमिटेशन तत्त्वाचे पालन केले पाहिजे.

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

होय, MAC पत्ते GDPR अंतर्गत वैयक्तिक डेटा म्हणून गणले जाऊ शकतात, कारण ते ओळखता येण्याजोग्या व्यक्तीद्वारे नेल्या जाणाऱ्या उपकरणाशी संबंधित असतात. UK ICO ने WiFi लोकेशन ॲनालिटिक्सवरील आपल्या मार्गदर्शनामध्ये असे म्हटले आहे. आल्यावर पत्ते हॅश करा किंवा ट्रंकेट करा, तुमचा कायदेशीर आधार दस्तऐवजीकृत करा, रिटेंशन कालावधी सेट करा आणि स्पष्ट फलक लावा. कॅप्टिव्ह पोर्टल मार्केटींग वापरासाठी स्पष्ट संमती जोडते.

Meraki अभ्यागत लॉयल्टी डेटा किती अचूक आहे?

MAC रँडमायझेशनमुळे Meraki लॉयल्टी डेटा परिपूर्ण माप म्हणून अविश्वसनीय आहे. iOS 14 आणि Android 10 पासून, फोन रँडमाइज्ड पत्ते वापरतात ज्यामुळे परत येणारी उपकरणे नवीन दिसतात. पहिल्यांदा येणाऱ्यांची संख्या जास्त दिसते आणि पुन्हा भेट देणाऱ्यांची संख्या कमी दिसते. कनेक्ट केलेली उपकरणे अधिक स्थिर असतात, कारण त्यांचा प्रति-नेटवर्क पत्ता सहसा कायम राहतो. लॉयल्टीचा वापर केवळ कनेक्ट केलेल्या उपकरणाचा ट्रेंड म्हणून करा आणि लॉगीनवरून पुन्हा भेट देणाऱ्यांची गणना करा.

Purple माझ्या विद्यमान Cisco Meraki एक्सेस पॉईंट्ससोबत काम करते का?

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

मी Meraki स्कॅनिंग API वर बिल्ड करावे की ॲनालिटिक्स प्लॅटफॉर्म वापरावे?

तुमच्याकडे डेटा टीम असल्यास आणि तुम्हाला व्याख्या व स्टोरेजवर पूर्ण नियंत्रण हवे असल्यास स्कॅनिंग API वर बिल्ड करा. तुमच्याकडे इंजिनिअरिंग क्षमता नसल्यास किंवा ओळख पटलेले अभ्यागत हवे असल्यास प्लॅटफॉर्म निवडा. API फक्त रॉ डिव्हाइस निरीक्षक पुरवते, त्यामुळे तुम्हाला अजूनही MAC ॲनोनिमायझेशनचा सामना करावा लागतो आणि सहमतीचा कोणताही रेकॉर्ड राहत नाही. अनेक इस्टेट्स दोन्ही वापरतात: डिव्हाइस ड्वेलसाठी API आणि लॉग-इन केलेल्या अभ्यागतांसाठी Purple.