Analisi delle presenze con HPE Aruba Central: configurazione, esportazioni e limiti

I dati di presence analytics di Aruba Central contano i dispositivi rilevati dai tuoi access point HPE Aruba. Vengono quindi suddivisi in passanti e visitatori utilizzando una soglia RSSI e limiti di tempo di sosta definiti per ciascun sito. È possibile abilitare questa funzione per ogni singolo sito, calibrare la soglia sul campo ed esportare i dati aggregati tramite le REST API di Central. Il sistema si limita a contare i dispositivi e non identifica mai le persone.

Cosa misurano effettivamente i dati di presence analytics di Aruba Central?

Ogni telefono con il WiFi attivato invia richieste di probe, ovvero brevi pacchetti che interrogano le reti vicine. L'invio avviene indipendentemente dal fatto che il telefono si connetta o meno alla tua rete. I tuoi access point Aruba rilevano questi pacchetti e inviano a Central l'indirizzo MAC e la potenza del segnale di ciascun dispositivo. Central applica quindi due regole che puoi configurare.

La prima regola riguarda la potenza del segnale. L'RSSI (received signal strength indicator) è misurato in dBm; i valori più vicini allo zero indicano che il dispositivo è più vicino all'access point. Un dispositivo che supera la soglia RSSI impostata viene conteggiato all'interno della struttura. Un dispositivo rilevato al di sotto di tale soglia viene conteggiato come passante.

La seconda regola riguarda il tempo di sosta. Tra i dispositivi che superano la soglia, Central utilizza i limiti di tempo di sosta per distinguere i rilevamenti rapidi dalle visite effettive. Suddivide poi i visitatori in fasce di durata della sosta.

Il risultato è un dato aggregato sul flusso di persone di Aruba per ogni sito: passanti, visitatori e distribuzione del tempo di sosta. Risponde alla domanda "quanti dispositivi erano presenti e per quanto tempo", ma non può rispondere a "chi erano", e questo limite condiziona ogni aspetto descritto alla fine di questa guida.

Il modello di presence di Purple si basa sugli stessi principi fisici. La documentazione Presence (Legacy) descrive il conteggio dei dispositivi non autenticati che inviano un "ping" a un access point a una distanza sufficiente per registrarne l'indirizzo MAC. L'RSSI funge da segnale di prossimità. La durata misura per quanto tempo un qualsiasi access point della struttura ha rilevato il dispositivo. Se comprendi un modello, li comprendi entrambi.

Cosa ti serve prima di abilitare i dati di presence analytics in Aruba Central?

Cinque cose, e l'ultima è quella che i team tendono a saltare.

1. Un abbonamento a Central che includa i dati di presence analytics. La funzionalità di presence analytics non è inclusa in tutti i livelli di licenza di Central. Verifica la documentazione di licenza HPE attuale rispetto all'abbonamento assegnato agli AP di ciascun sito.
2. AP assegnati a un sito, non solo a un gruppo. Central utilizza i gruppi per la configurazione e i siti per la posizione e la reportistica. I dati di presence vengono aggregati per sito, quindi un AP non assegnato a un sito non fornirà dati utili.
3. Una planimetria con i confini fisici tracciati. Indica porte, vetrate dei negozi, terrazze, parcheggi e pareti condivise con unità adiacenti. Questi sono i punti in cui la tua soglia rischia di risultare inizialmente errata.
4. Un dispositivo di test identificabile. Le versioni recenti di iOS e Android rendono casuale l'indirizzo MAC presentato da un dispositivo; pertanto, disabilita l'impostazione dell'indirizzo privato sul telefono di test o annota l'indirizzo utilizzato.
5. Una posizione sulla privacy. Gli indirizzi MAC sono identificatori di dispositivo. Il considerando 30 del GDPR definisce gli identificatori online forniti dai dispositivi come informazioni che possono identificare una persona. Completa una valutazione dell'impatto sulla protezione dei dati e posiziona cartelli informativi agli ingressi prima di iniziare la raccolta dei dati. L'ICO del Regno Unito ha pubblicato linee guida sull'analisi della posizione basata sui segnali dei dispositivi, che coprono entrambi questi punti.

Per il lavoro sulle API, avrai anche bisogno di un ruolo di amministratore in Central che possa creare client API Gateway e di una destinazione per i dati: un data warehouse, un database o uno strumento di BI.

Come si configura l'analisi di presenza di Aruba Central?

Passaggio 1: abilitare il servizio per ciascun sito

Attiva l'analisi di presenza a livello di sito in Central. Il percorso esatto del menu varia tra il classico Aruba Central e la più recente interfaccia HPE Aruba Networking Central. Segui la documentazione attuale di HPE per la tua versione specifica anziché uno screenshot di una versione precedente. Attendi che i primi dati vengano popolati prima di trarre conclusioni, e aspettati che i numeri del primo giorno sembrino errati finché non avrai effettuato la calibrazione.

Passaggio 2: calibrare la soglia RSSI

Non esiste una soglia RSSI Aruba universale per il conteggio dei visitatori. Il valore corretto dipende dall'altezza di montaggio degli AP, dal diagramma dell'antenna, dal materiale delle pareti, dalle vetrate e dalla vicinanza degli AP al confine esterno. Un numero copiato da un'altra sede classificherà erroneamente i dispositivi nella tua. Esegui invece la calibrazione in questo modo:

1. Percorri il confine esterno. Porta il dispositivo di test in tre punti: appena dentro l'ingresso, sulla soglia stessa e sul marciapiede o piazzale esterno. Sosta in ciascun punto per alcuni minuti e annota l'RSSI segnalato da Central.
2. Ripeti in un'ora di punta. Le persone assorbono l'energia radio, quindi le letture nelle ore di punta sono inferiori a quelle in un edificio vuoto. Calibra in base alle condizioni di picco, perché è in quel momento che i conteggi contano davvero.
3. Posiziona la soglia tra "appena dentro" e "all'esterno". Spostala verso la lettura interna se il traffico stradale passa vicino ai vetri. Spostala verso la lettura esterna se l'ingresso è rientrato e nessuno si sofferma nelle vicinanze.
4. Registra il valore e la data. Qualsiasi confronto successivo dipenderà dal sapere quale soglia ha prodotto quali numeri.

Passaggio 3: impostare i limiti del tempo di sosta che separano i passanti dai visitatori

L'RSSI da solo classifica erroneamente chiunque passi vicino alle vetrate. Il tempo di sosta minimo del visitatore consente di escluderli. Impostalo sulla visita reale più breve presso la tua sede, non su una media del settore. Le fasce temporali più lunghe descriveranno quindi il livello di coinvolgimento dei tuoi visitatori.

Tipo di sede	Profilo del passante	Riferimento per il tempo di sosta minimo del visitatore	Dati reali per la convalida
Negozio su strada	Pedone che cammina davanti alla vetrina	Acquisto reale più rapido, come un articolo da asporto	Conteggio delle transazioni di cassa
Hall di hotel	Ospite che si dirige verso gli ascensori o il ristorante	Interazione più breve per il check-in o con la reception	Registro dei check-in della reception
Atrio del centro congressi	Delegato che passa tra i padiglioni	Frequenza alla sessione più breve	Scansioni dei badge per sessione
Atrio dello stadio	Tifoso che si sposta tra la tribuna e il chiosco	Acquisto al chiosco più rapido	Conteggio delle transazioni del chiosco
Biblioteca o punto di servizio comunale	Pedone sulla strada adiacente	Richiesta più breve allo sportello	Registro delle richieste allo sportello o contatore ingressi

Modifica un'impostazione alla volta. Se sposti contemporaneamente la soglia RSSI e il limite del tempo di permanenza, non potrai capire quale modifica ha influito sul conteggio.

Passaggio 4: esportare i dati di presenza tramite la Central API

I cruscotti di Central sono ottimi per una rapida consultazione, ma i report a valle richiedono l'estrazione dei dati. Un'esportazione tramite Aruba Central API segue quattro passaggi.

1. Crea un client API in API Gateway. Central autentica le chiamate REST con token di accesso OAuth 2.0. I token di accesso hanno una durata breve, pertanto memorizza il token di aggiornamento in un gestore di segreti e automatizza il rinnovo.
2. Chiama gli endpoint di presenza analitica. Restituiscono aggregati a livello di sito per una finestra temporale specificata. Utilizza il riferimento per sviluppatori di HPE per i percorsi e i parametri correnti degli endpoint, poiché variano tra le versioni dell'API.
3. Pianifica l'estrazione. Un'attività giornaliera che richiede il giorno precedente per ciascun sito è facile da verificare. Memorizza l'ID del sito, la finestra temporale in UTC e le impostazioni di soglia e permanenza in vigore in quel momento.
4. Rispetta i limiti di frequenza. Central applica limiti di frequenza API per account. Le grandi strutture dovrebbero scaglionare le richieste dei siti anziché estrarre tutti i siti nello stesso minuto.

Il passaggio 3 è più importante di quanto sembri. Quando qualcuno cambierà una soglia tra sei mesi, le impostazioni memorizzate consentiranno agli analisti di suddividere la serie storica anziché segnalare un calo fantasma dei visitatori.

Come verificare che i conteggi siano corretti?

Effettua una convalida rispetto a qualcosa che già misuri. Scegli una fonte di verità sul campo per ciascun sito dalla tabella sopra e confrontala con il conteggio dei visitatori di Central ogni giorno per almeno una settimana.

Non stai cercando numeri identici. Diversi acquirenti arrivano insieme, il personale porta con sé telefoni e alcuni visitatori non hanno alcun dispositivo. Quello che cerchi è un rapporto stabile. Se i visitatori si attestano su un multiplo coerente delle transazioni, la configurazione è solida e il rapporto diventa una metrica del tasso di cattura che puoi includere nei report.

Esegui quattro controlli di coerenza prima di considerare attendibili i dati:

• Conteggi notturni. I visitatori registrati dopo l'orario di chiusura di solito indicano dispositivi del personale, dispositivi fissi o apparecchiature di un vicino che superano la soglia impostata.
• Capacità. I visitatori presenti contemporaneamente non dovrebbero mai superare la capienza consentita della struttura.
• Dashboard rispetto alle API. I totali giornalieri estratti dalle tue API dovrebbero corrispondere alla dashboard di Central per lo stesso sito e la stessa finestra temporale. Una discrepanza di solito indica un errore di fuso orario.
• Sito rispetto a sito. Confronta siti con flussi commerciali simili. Un sito con il doppio dei visitatori e la metà delle transazioni presenta un problema di calibrazione, non di vendite.

Come si presenta l'ottimizzazione in una struttura reale?

I due scenari seguenti utilizzano cifre illustrative per mostrare il metodo. I vostri numeri differiranno, ma il calcolo aritmetico rimane lo stesso.

Scenario 1: un negozio di moda su una strada principale con una facciata in vetro

Situazione. Un negozio a piano unico ha due AP posizionati a pochi metri da una facciata in vetro a tutta altezza su un marciapiede trafficato. In un tipico sabato, Central segnala 3.200 visitatori a fronte di 410 transazioni di cassa. Il tasso di cattura implicito di circa il 13% appare improbabilmente debole rispetto all'esperienza del team di vendita.

Cosa è stato fatto. L'ingegnere di rete ha percorso il perimetro all'ora di pranzo del sabato. Ha scoperto che i dispositivi sul marciapiede direttamente fuori dal vetro venivano rilevati con un'intensità quasi pari a quella dei dispositivi appena dentro la porta. Ha quindi innalzato la soglia RSSI per posizionarla tra queste due letture. Successivamente, ha impostato la permanenza minima del visitatore sul tempo necessario per acquistare un singolo articolo alla cassa.

Risultato. Il sabato successivo, Central ha segnalato 1.150 visitatori a fronte di 425 transazioni, un rapporto di circa 2,7 visitatori per vendita. Tale rapporto si è mantenuto entro un intervallo ristretto nei quattro fine settimana successivi. L'analista dei dati ora lo segnala settimanalmente come indicatore di conversione per la revisione commerciale retail del negozio.

Scenario 2: il foyer di un centro congressi adiacente a un hotel

Situazione. Un centro congressi condivide un corridoio di collegamento vetrato con un hotel da 200 camere. Gli organizzatori di eventi desiderano dati sulla permanenza giornaliera per tariffare gli stand degli sponsor nel foyer. La distribuzione della permanenza di Central mostra un forte picco nella fascia più breve, indipendentemente dal fatto che sia in corso un evento.

Cosa è stato fatto. L'ingegnere ha scoperto che gli ospiti dell'hotel che percorrevano il corridoio di collegamento superavano la soglia RSSI degli AP del foyer. Spostare solo la soglia avrebbe escluso i delegati effettivi che sostavano vicino al corridoio. Invece, il team ha aumentato la permanenza minima del visitatore al di sopra del tempo necessario per percorrere il corridoio da un'estremità all'altra. Hanno poi validato i conteggi confrontandoli con le scansioni dei badge durante tre giorni di eventi.

Risultato. Nei giorni senza eventi, i visitatori del foyer sono scesi a un livello coerente con il personale e i collaboratori esterni. Nei giorni di evento, il conteggio dei visitatori ha seguito le scansioni dei badge con un rapporto costante. Gli organizzatori hanno così potuto quotare agli sponsor una cifra difendibile di delegati che hanno trascorso più di un tempo stabilito nel foyer. Il traffico guest dell'hotel ha smesso di inquinare i dati dell'evento.

Scenario 3: una biblioteca comunale con una fermata dell'autobus all'esterno

Situazione. Una biblioteca pubblica si trova accanto a una fermata dell'autobus dove le persone attendono per diversi minuti, ampiamente nel raggio d'azione dell'AP d'ingresso. Il comune desidera conoscere il numero di visite per il suo rapporto annuale sul servizio.

Cosa è stato fatto. Né l'RSSI né la permanenza da soli consentivano di distinguere un passeggero dell'autobus in attesa da un visitatore della biblioteca. Il team ha posizionato la soglia utilizzando le letture effettuate alla fermata dell'autobus stessa. Hanno poi verificato i conteggi incrociandoli con il contapersone esistente all'ingresso per un mese. Risultato. I conteggi delle presenze e i conteggi dei varchi si sono mossi di pari passo entro un margine costante. Il consiglio ha mantenuto il contatore dei varchi come dato ufficiale e ha utilizzato i dati di presenza per l'andamento orario, che il contatore dei varchi non era in grado di fornire. Questo andamento ha orientato le modifiche al personale dello sportello informazioni.

Cosa può andare storto e come rimediare?

I conteggi dei visitatori sono molto più alti rispetto alla realtà sul campo

La soglia RSSI è troppo permissiva, solitamente a causa di vetri, di una parete sottile o di un AP montato vicino all'ingresso. Ripercorri il perimetro nelle ore di punta e alza la soglia. Se il posizionamento dell'AP rende impossibile una netta separazione, valuta la possibilità di spostarlo più lontano dal perimetro.

I conteggi variano dopo un aggiornamento del sistema operativo mobile

La randomizzazione degli indirizzi MAC fa sì che un dispositivo fisico possa apparire come più indirizzi diversi nel tempo. Ogni modifica al comportamento di randomizzazione in iOS o Android può alterare i tuoi conteggi e abbassare le cifre relative alle visite ripetute. Annota nelle tue serie di report le date di rilascio delle principali versioni dei sistemi operativi. Tratta con cautela le metriche delle visite ripetute da dispositivi non autenticati.

Visitatori notturni o al mattino presto

I telefoni del personale, gli scanner palmari, le stampanti e i dispositivi smart rimangono sopra la soglia per tutto il giorno. Escludi gli indirizzi dei dispositivi noti dove Aruba Central lo consente, oppure escludi le ore non commerciali nei tuoi report a valle.

Le chiamate API restituiscono errori di autorizzazione

Il token di accesso è scaduto e la fase di aggiornamento è fallita o non è mai stata eseguita. Verifica che il tuo processo utilizzi il token di aggiornamento, memorizzi la nuova coppia di token ricevuta e segnali l'errore anziché scrivere silenziosamente giornate vuote.

Un improvviso cambiamento repentino nei confronti storici

Qualcuno ha modificato una soglia o un limite di permanenza. Per questo motivo il Passaggio 4 memorizza le impostazioni a ogni estrazione. Dividi la serie in corrispondenza della data di modifica e riporta i due periodi separatamente.

I problemi del captive portal distorcono le metriche di autenticazione

Se utilizzi anche un captive portal, ovvero la pagina web che un dispositivo visualizza prima di ottenere l'accesso alla rete, i guasti di reindirizzamento riducono le visite autenticate. Non influiscono sui conteggi delle presenze. Esamina i reindirizzamenti del portale come un problema separato dalla calibrazione delle presenze.

Quali sono i limiti della analytics di Aruba Central?

L'analitica nativa delle presenze è utile ed è inclusa nel tuo pacchetto Aruba. Tuttavia presenta dei limiti evidenti che dovresti esporre chiaramente agli stakeholder prima che sviluppino un programma di reportistica su di essa.

• Aggregazione a livello di sito. Aruba Central genera report per ciascun sito. Se hai bisogno di fare confronti tra zone all'interno di un sito, o classifiche su un vasto patrimonio immobiliare con regole coerenti, dovrai svilupparli autonomamente a valle.
• Conservazione dei dati. Aruba Central conserva i dati di presenza per un periodo limitato stabilito dalla piattaforma e dal tuo abbonamento. Il confronto anno su anno dipende dalla tua esportazione, quindi avvia la pipeline API fin dal primo giorno.
• Nessun livello identificato. I dati di presenza sono conteggi di dispositivi anonimi. Non è possibile collegare una visita a un contatto consenziente, a un account fedeltà o a un record CRM. Gli indirizzi MAC casuali rendono inaffidabili persino i conteggi anonimi delle visite ripetute su lunghi periodi.
• Vista a fornitore unico. Central rileva gli access point Aruba. Gli immobili che combinano Aruba con Cisco Meraki, Ruckus o Juniper Mist nei siti acquisiti ottengono una panoramica parziale.
• Debito di calibrazione. Ogni ristrutturazione, spostamento di AP o nuova vetratura modifica l'ambiente radio. Le soglie corrette al momento dell'installazione tendono a deviare a meno che qualcuno non esegua nuovamente un sopralluogo sul campo.

Nessuno di questi è un difetto. Rappresentano semplicemente l'ambito della funzionalità di analytics di un fornitore di rete e definiscono il punto in cui un livello di piattaforma si guadagna il suo posto.

Quanto costa e quando conviene aggiungere un livello di piattaforma superiore?

La via nativa costa tempo di progettazione e analisi piuttosto che spese di licenza aggiuntive, a condizione che l'abbonamento Central copra già la presenza analytics. È necessario prevedere un budget per un sopralluogo per ogni sito, una settimana di convalida, una pipeline API da creare e mantenere, e la ricalibrazione dopo modifiche fisiche.

WiFi Analytics di Purple aggiunge un livello diverso anziché duplicare Central. Funziona come un overlay cloud agnostico rispetto all'hardware sugli access point Aruba già posseduti, senza necessità di sostituzioni radicali. Il Captive Portal Guest WiFi di Purple aggiunge un livello autenticato tramite opt-in consapevoli, che fornisce dati di prima parte che la presenza anonima non può offrire.

Funzionalità	Aruba Central presenza analytics	Purple WiFi Analytics sui tuoi AP Aruba
Cosa conta	Dispositivi anonimi al di sopra di una soglia RSSI	Visite in cui l'intensità del segnale ha posizionato il dispositivo all'interno della sede, oltre ai visitatori autenticati
Identità	Nessuna, solo indirizzo MAC	Visitatori autenticati con dati di prima parte consenzienti
Report sulla permanenza	Fasce di durata per sito	Permanenza media per visita per i visitatori autenticati
Modelli temporali	Dashboard del sito su una finestra temporale scelta	Mappa termica delle visite per giorno della settimana e ora del giorno
Vista cross-venue	Per sito, creata a valle per i vari immobili	Le 10 sedi migliori e le 10 peggiori per visite, classificate all'interno della piattaforma
Hardware	Solo HPE Aruba	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet
Vista in tempo reale	Dashboard di Central	Ultimi 25 minuti in intervalli di un minuto, aggiornati ogni minuto (Presence Legacy)
A chi si adatta	Immobili con un unico fornitore che necessitano di modelli di occupazione anonimi	Immobili multi-sede o con fornitori misti che necessitano di dati dei visitatori identificati e consenzienti

Le funzionalità Purple presenti in questa tabella provengono dalla documentazione di Purple su WiFi Analytics - Presence e Presence (Legacy). Un'avvertenza importante da considerare: l'elaborazione dei dati per i visitatori non autenticati può richiedere più tempo rispetto a quella per i visitatori autenticati.

Scegli la soluzione nativa se gestisci un'unica infrastruttura Aruba, hai bisogno di analizzare i modelli di presenza e di occupazione in modalità anonima e disponi di un tecnico in grado di gestire la calibrazione e la pipeline delle API.

Aggiungi una piattaforma di terze parti se si verifica una di queste condizioni: gestisci un parco hardware misto; devi confrontare e classificare numerosi punti vendita o sedi tra loro; oppure hai bisogno di dati dei visitatori identificati e provvisti di consenso per finalità di marketing o progettazione dei servizi. Questo scenario si applica agli hotel che creano profili degli ospiti e alle catene retail che collegano le visite alle campagne pubblicitarie. Purple è attivo in oltre 80.000 sedi live e ha gestito 440 milioni di accessi nel 2024 (dati interni di Purple). La maggior parte di queste sedi utilizza hardware che era già preinstallato.

Domande frequenti

L'analisi delle presenze è inclusa nella mia licenza Aruba Central?

Non in tutti i casi. L'analisi della presenza è disponibile solo in specifici livelli di abbonamento Aruba Central, pertanto ti invitiamo a verificare che gli AP di ciascun sito dispongano di un livello di licenza che la includa. Confronta la documentazione di licenza corrente di HPE con gli abbonamenti assegnati nel tuo account Central prima di pianificare l'attivazione. Se alcuni siti hanno un livello inferiore, si verificheranno delle lacune nei report sull'intera infrastruttura. Risolvi prima il problema delle licenze, poi procedi alla calibrazione.

Purple funziona con i miei access point HPE Aruba esistenti?

Sì. Purple è indipendente dall'hardware e funziona come overlay cloud sugli access point HPE Aruba, oltre che con Cisco Meraki, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Mantieni la configurazione di Aruba Central e gli AP esistenti. Purple aggiunge sopra il Captive Portal, i dati dei visitatori autenticati e il livello di analisi, eliminando la necessità di sostituire l'hardware.

Posso esportare i dati di presenza di Aruba Central in un data warehouse o in uno strumento di BI?

Sì, tramite l'API REST di Central. Crea un client API in API Gateway, autenticati con token OAuth 2.0 e chiama gli endpoint di analisi della presenza per i dati aggregati a livello di sito. Pianifica un'estrazione giornaliera per sito, memorizza i timestamp in UTC e registra le impostazioni di soglia applicate. Poiché la conservazione dei dati in Central è limitata, l'esportazione diventa l'archivio storico per i confronti anno su anno.

I dati di presenza WiFi sono considerati dati personali ai sensi del GDPR?

Sì, devono essere trattati come dati personali. Il Considerando 30 del GDPR menziona gli identificativi online forniti dai dispositivi come informazioni in grado di identificare una persona, e l'analisi della presenza elabora gli indirizzi MAC. Completa una valutazione d'impatto sulla protezione dei dati, inserisci un'informativa chiara e visibile agli ingressi e mantieni tempi di conservazione proporzionati. I conteggi aggregati presentano rischi inferiori rispetto agli identificativi grezzi, ma la fase di raccolta rientra comunque nell'ambito di applicazione della norma.

Quanto tempo è necessario per configurare e calibrare l'analisi delle presenze Aruba?

Prevedi un test di copertura per sede e almeno una settimana di validazione. L'attivazione del servizio richiede pochi minuti. La calibrazione consiste nel percorrere l'ingresso nelle ore di punta, impostare la soglia RSSI e i limiti del tempo di sosta, per poi confrontare i conteggi con le casse, i check-in o i contapersone all'ingresso. L'integrazione delle API è un'attività tecnica separata. Ricalibra dopo ogni ristrutturazione, spostamento di AP o modifica delle vetrate.

La randomizzazione degli indirizzi MAC renderà inutili i conteggi delle presenze Aruba?

No, ma limita il significato dei conteggi. I visitatori totali e i modelli di sosta rimangono utilizzabili se validati rispetto a una fonte di dati reali, come le transazioni di cassa. I dati sulle visite ripetute e sulla fidelizzazione provenienti da dispositivi non autenticati non sono affidabili, poiché un singolo telefono può presentare diversi indirizzi nel tempo. Per ottenere dati affidabili sulle visite ripetute, sono necessari visitatori autenticati che effettuano l'accesso tramite un Captive Portal con il dovuto consenso.

Dovrei scegliere l'analisi delle presenze Aruba Central o Purple WiFi Analytics?

La maggior parte delle infrastrutture Aruba utilizza entrambe le soluzioni, poiché rispondono a domande diverse. Central fornisce dati anonimi sull'occupazione e sui modelli di sosta per sede senza costi di licenza aggiuntivi, se inclusi nel tuo piano. Purple aggiunge dati sui visitatori autenticati e consenzienti, classifiche tra diverse sedi e supporto per hardware misto. Rimani sulla soluzione nativa per i conteggi anonimi su un'infrastruttura monomarca. Aggiungi Purple quando hai bisogno di dati identificati di prima parte.

Ho bisogno di nuovo hardware per aggiungere un livello di analisi identificata?

No. Purple si integra sopra gli access point HPE Aruba già in uso, quindi non è necessaria alcuna sostituzione hardware. Il livello identificato proviene da un Captive Portal con opzioni di consenso esplicito, non da nuovi apparati radio. La tua configurazione esistente di Central, l'analisi delle presenze e le esportazioni API continueranno a funzionare in parallelo.