WiFi Landing Page vs. Splash Page: qual è la differenza?

Questa guida di riferimento tecnico chiarisce le differenze architetturali e funzionali tra le WiFi landing page e le splash page, due termini spesso confusi sia dai team IT che dai dipartimenti marketing. Fornisce ad architetti di rete, responsabili IT e direttori delle operazioni delle strutture strategie di implementazione pratiche per ottimizzare le prestazioni del Captive Portal, garantire la conformità a GDPR e PCI DSS e massimizzare il ROI in contesti aziendali quali hospitality, retail e settore pubblico.

📖 8 minuti di lettura📝 2,189 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Benvenuti al Purple Technical Briefing. Oggi affrontiamo una domanda che emerge in quasi tutte le chiamate conoscitive iniziali con CTO e architetti di rete: qual è esattamente la differenza tra una WiFi landing page e una splash page?

Nel mondo consumer, le persone usano questi termini in modo intercambiabile. Ma quando si progetta una rete ospiti aziendale in cinquanta punti vendita al dettaglio, o un'implementazione ad alta densità in uno stadio, confondere i due concetti può portare a problemi di conformità, percorsi utente interrotti e ROI mancato.

Quindi, nei prossimi dieci minuti, definiremo la distinzione tecnica, analizzeremo l'architettura, discuteremo gli errori di implementazione più comuni e concluderemo con una sessione di domande e risposte rapide. Cominciamo.

[SECTION: TECHNICAL DEFINITIONS]

Per prima cosa, definiamo i termini. Quando parliamo di un Captive Portal, ci riferiamo all'intero meccanismo di walled-garden che intercetta il traffico HTTP e HTTPS e costringe un dispositivo client ad autenticarsi prima di concedere l'accesso alla rete esterna.

All'interno di questo flusso, la Splash Page è il guardiano. È la primissima schermata che un utente visualizza quando si connette all'SSID. La sua funzione tecnica principale è l'autenticazione e l'autorizzazione. È qui che l'utente accetta i Termini e le Condizioni, inserisce le proprie credenziali o si autentica tramite un provider di identità, magari utilizzando OAuth o un'integrazione di fidelizzazione. Dal punto di vista della conformità, è qui che si gestiscono il consenso GDPR e le informative PCI DSS se si elaborano pagamenti.

Ora, confrontiamo tutto questo con la Landing Page. La landing page è la destinazione successiva a un'autenticazione riuscita. Una volta che il server RADIUS invia il messaggio di Access-Accept e il dispositivo client viene inserito nella VLAN attiva con instradamento internet, il walled garden cade. Il controller reindirizza quindi il browser dell'utente alla Landing Page.

Perché questa distinzione è importante? Perché la Splash Page esiste in un ambiente estremamente limitato. Il dispositivo non ha ancora un accesso completo a internet. Può raggiungere solo gli indirizzi IP o i nomi host specifici che avete inserito nella whitelist nella configurazione del vostro Walled Garden. Se provate a caricare script esterni pesanti, lettori video dinamici o tracker complessi di terze parti su una splash page senza una corretta whitelist, la pagina si bloccherà e l'utente rimarrà bloccato in un ciclo continuo di connessione.

La Landing Page, invece, si trova sull'internet aperto. L'utente è autenticato. Qui è possibile caricare esperienze di marketing complete, link dinamici per il download di app, mappe interattive della struttura e promozioni mirate basate sui dati di prima parte appena acquisiti sulla splash page.

[SECTION: IMPLEMENTATION AND PITFALLS]

Parliamo ora dell'implementazione e di dove vedo fallire i progetti.

L'errore più comune è sovraccaricare la Splash Page. Ho visto team di marketing presentare una pagina da cinque megabyte con quattro diversi pixel di tracciamento esterni e un video di sfondo, chiedendo all'IT di renderla la schermata di accesso.

Quando si fa questo, è necessario aggiungere decine di CDN e domini di terze parti alla whitelist del Walled Garden. Non solo questo è un incubo da gestire man mano che gli intervalli IP cambiano, ma rappresenta anche un rischio per la sicurezza. State creando delle falle nel vostro firewall di pre-autenticazione. Inoltre, i moderni sistemi operativi mobili, come iOS e Android, utilizzano un mini-browser specializzato per visualizzare i captive portal. Questi Captive Network Assistant, o CNA, hanno funzionalità limitate. Spesso bloccano i cookie, limitano lo storage locale e si chiudono automaticamente se rilevano una navigazione esterna prima che la connessione internet sia completamente stabilita.

La best practice? Mantenere la Splash Page snella, veloce e focalizzata esclusivamente sull'acquisizione dei dati e sul consenso legale. Utilizzare una soluzione di captive portal basata su cloud che ottimizzi il payload HTML per questi browser CNA.

Una volta che l'utente fa clic su Connetti, reindirizzatelo alla Landing Page ricca e dinamica. È qui che sfruttate la vostra piattaforma di WiFi Analytics. Poiché avete già acquisito il loro profilo, la Landing Page può essere personalizzata. Se si tratta di un ospite che ritorna nel vostro hotel, la landing page può accoglierlo per nome e offrire una prenotazione con un clic per la spa. Se si trova in un ambiente retail, può mostrare una promozione basata su mappe di calore in base alla sua zona attuale.

[SECTION: CASE STUDIES]

Permettetemi di presentarvi due casi di studio concreti che illustrano perfettamente questo aspetto.

In primo luogo, un hotel resort da cinquecento camere. Riscontravano tassi di abbandono elevati al momento dell'accesso al WiFi ospiti. Il team di marketing aveva aggiunto un video promozionale da quattro megabyte e una mappa interattiva complessa alla schermata di connessione iniziale. La soluzione è stata semplice: sostituire la schermata di connessione con una Splash Page leggera, inferiore a un megabyte, focalizzata esclusivamente sull'autenticazione tramite numero di camera e cognome, oltre all'accettazione di Termini e Condizioni. Il video e la mappa sono stati spostati sulla Landing Page post-autenticazione. I tassi di connessione sono migliorati di oltre il quaranta percento già nella prima settimana.

In secondo luogo, una catena di negozi al dettaglio con cinquanta punti vendita. Desideravano offrire un accesso WiFi fluido ai membri del programma fedeltà che ritornavano, senza costringerli ad accedere ogni volta. La soluzione è stata il MAC Authentication Bypass integrato con il database di fidelizzazione. Quando un dispositivo che ritorna si associa all'SSID, il controller interroga il server RADIUS, identifica l'indirizzo MAC e restituisce immediatamente un Access-Accept senza presentare la Splash Page. L'utente viene reindirizzato a una Landing Page personalizzata con il proprio stato di fidelizzazione e un'offerta mirata. Il risultato: un aumento del trenta percento nel coinvolgimento sull'app fedeltà in tutta la catena.

[SECTION: RAPID-FIRE Q&A]

Passiamo ora alla nostra sessione di domande e risposte rapide. Queste sono le tre domande principali che ricevo dagli ingegneri di rete.

Domanda uno: posso saltare completamente la Splash Page per gli utenti che ritornano?

Sì. Questo processo si chiama MAC Authentication Bypass, o accesso fluido. Il controller riconosce l'indirizzo MAC del dispositivo da una sessione precedente e lo autorizza automaticamente, portandolo direttamente alla Landing Page o alla sua destinazione originale. Assicuratevi solo che la vostra informativa sulla privacy copra il tracciamento persistente dei dispositivi.

Domanda due: perché la mia Splash Page mostra un errore di certificato?

Questo accade di solito quando si tenta di intercettare il traffico HTTPS senza un certificato SSL valido sul controller, o se si utilizza un certificato autofirmato. Utilizzate sempre un certificato pubblicamente attendibile per il nome host del vostro captive portal e assicuratevi che il controller supporti i moderni standard di reindirizzamento HTTPS come la specifica RFC 8908.

Domanda tre: la Landing Page deve essere ospitata localmente sul controller o nel cloud?

Sempre nel cloud. L'hosting sul controller limita la capacità di aggiornare i contenuti in modo dinamico, eseguire A/B test o integrarsi con CRM esterni. Un'architettura basata su cloud separa il piano di controllo della rete dal livello dell'esperienza utente, che è esattamente ciò che richiedono le implementazioni aziendali.

[SECTION: SUMMARY AND NEXT STEPS]

Per riassumere: la Splash Page è il guardiano sicuro e limitato per l'autenticazione e il consenso. Mantenetela leggera (sotto il megabyte, senza dipendenze esterne, ottimizzata per il Captive Network Assistant). La Landing Page è la destinazione post-autenticazione per il coinvolgimento, il marketing e la generazione di ROI. Opera sull'internet aperto con piene funzionalità del browser.

Comprendete i vincoli del Walled Garden e del Captive Network Assistant e eviterete il novanta percento dei ticket di assistenza associati alle implementazioni WiFi ospiti.

Le tre regole chiave da ricordare: Splash per la sicurezza, Landing per la fedeltà. Il Walled Garden è una sandbox, non un parco giochi. E sempre: prima l'autenticazione, poi l'animazione.

Grazie per aver partecipato a questo briefing tecnico. Se desiderate approfondire la configurazione dei captive portal basati su cloud, consultate la guida di riferimento completa sul sito web di Purple. Alla prossima, mantenete le vostre reti sicure e i vostri utenti connessi.

Punti chiave

✓La Splash Page è il guardiano pre-autenticazione che opera all'interno del Walled Garden limitato; il suo unico scopo è la verifica dell'identità e il consenso legale.
✓La WiFi Landing Page è la destinazione post-autenticazione che opera sull'internet aperto; il suo scopo è il coinvolgimento marketing, la personalizzazione e la generazione di ROI.
✓Il Captive Network Assistant (CNA) visualizza la Splash Page in un mini-browser in modalità sandbox che blocca i cookie, limita JavaScript e riduce il caricamento di risorse esterne.
✓Sovraccaricare la Splash Page con risorse di marketing è la causa principale dei fallimenti di connessione al WiFi degli ospiti e dell'aumento dei ticket di assistenza.
✓Il MAC Authentication Bypass (MAB) elimina la Splash Page per i dispositivi che ritornano, reindirizzandoli direttamente a una Landing Page personalizzata, migliorando l'esperienza per i visitatori abituali.
✓Un'architettura di captive portal basata su cloud separa il piano di controllo della rete dal livello dell'esperienza utente, consentendo una gestione centralizzata, aggiornamenti dinamici dei contenuti e l'integrazione con il CRM.
✓Il ROI misurabile del WiFi ospiti viene generato principalmente attraverso la Landing Page, tramite l'attribuzione diretta dei ricavi, il coinvolgimento nei programmi fedeltà e l'acquisizione di dati di prima parte che alimentano i WiFi Analytics.

📚 Parte della nostra serie principale: Captive Portal Guide →

Executive Summary

Per i team IT aziendali che gestiscono sedi ad alta densità — dalle strutture Hospitality ai complessi Retail — i termini "splash page" e "landing page" vengono spesso confusi. Trattarli come intercambiabili nell'architettura di rete porta a percorsi utente interrotti, vulnerabilità di sicurezza e opportunità mancate di acquisizione dati.

A livello fondamentale, la Splash Page è il guardiano pre-autenticazione. Esiste all'interno dell'ambiente limitato di un Walled Garden, responsabile della verifica dell'identità, dell'autenticazione MAC e del consenso legale ai sensi del GDPR e PCI DSS. La WiFi Landing Page è la destinazione post-autenticazione. Funziona sull'internet aperto, sfruttando i dati acquisiti durante il login per offrire esperienze personalizzate, promuovere il download di app e generare un ROI misurabile attraverso integrazioni di Guest WiFi .

Questa guida descrive in dettaglio le specifiche tecniche, le metodologie di implementazione e le modalità di errore comuni associate alla progettazione del Captive Portal, consentendo ai network architect di creare reti di accesso guest robuste, conformi e in grado di generare ricavi in qualsiasi tipo di sede.

Technical Deep-Dive

L'Architettura del Captive Portal

Un Captive Portal intercetta il traffico HTTP/HTTPS dai client non autenticati e li reindirizza a un'interfaccia web designata. Questo meccanismo si basa su una combinazione di DNS hijacking, reindirizzamento HTTP 302 e autenticazione RADIUS — con le implementazioni moderne che adottano sempre più lo standard RFC 8908 (Captive Portal Identification in DHCP and Router Advertisements) per consentire il rilevamento nativo del Captive Portal a livello di sistema operativo senza la fragilità dell'intercettazione HTTP.

All'interno di questa architettura, la Splash Page e la Landing Page svolgono ruoli fondamentalmente diversi in punti diversi del ciclo di vita dell'autenticazione.

1. La Splash Page (Stato Pre-Autenticazione)

Quando un dispositivo si associa a un SSID, il controller wireless lo inserisce in una VLAN non autenticata. Tutto il traffico in uscita viene intercettato e reindirizzato all'hostname del Captive Portal. Il Captive Network Assistant (CNA) del sistema operativo — uno pseudo-browser specializzato e in ambiente sandbox integrato in iOS, Android e Windows — rileva il Captive Portal e mostra la Splash Page.

Vincoli Tecnici dell'Ambiente CNA:

Il CNA non è un browser completo. Funziona con limitazioni significative che influiscono direttamente su ciò che può essere distribuito su una Splash Page:

I cookie e lo storage locale sono spesso bloccati o fortemente limitati
I framework JavaScript complessi potrebbero non essere eseguiti
Le risorse esterne (font, script, immagini) possono essere caricate solo se i loro domini sono inseriti nella whitelist del Walled Garden
Il CNA si chiuderà automaticamente se rileva che il dispositivo ha ottenuto l'accesso a internet prima che l'utente abbia completato l'autenticazione
La persistenza della sessione dopo la chiusura del CNA non è affidabile

Funzioni Principali della Splash Page:

Dati questi vincoli, la Splash Page deve essere progettata esclusivamente per: autenticazione (social login tramite OAuth, SMS OTP, credenziali basate su modulo o integrazione con programmi fedeltà); accettazione di Termini e Condizioni; acquisizione del consenso GDPR; e registrazione dell'indirizzo MAC per futuri login senza interruzioni.

Raccomandazione sul Payload: Mantenere la Splash Page al di sotto di 1MB. Utilizzare CSS inline, evitare librerie di font esterne e ridurre al minimo JavaScript. Ogni dipendenza esterna richiede una corrispondente voce nella whitelist del Walled Garden — ognuna delle quali rappresenta sia un carico di manutenzione che una potenziale esposizione di sicurezza.

2. La Landing Page (Stato Post-Autenticazione)

A seguito di un'autenticazione riuscita, il server RADIUS restituisce un messaggio di Access-Accept. Il controller wireless aggiorna la sessione del client, migrando il dispositivo su una VLAN autenticata con routing internet completo. Il Walled Garden viene rimosso. Il controller — o la piattaforma di Captive Portal basata su cloud — emette un reindirizzamento HTTP 302 verso la WiFi Landing Page.

A questo punto, il dispositivo funziona con un browser completo e un accesso a internet illimitato. La Landing Page può sfruttare l'insieme completo di funzionalità del moderno sviluppo web:

Contenuti dinamici e personalizzati guidati dal profilo utente acquisito sulla Splash Page
Strumentazione analitica completa (Google Analytics, pixel di tracciamento personalizzati, webhook CRM)
Rich media inclusi video, mappe interattive e dashboard di fidelizzazione
Inviti al download di app con routing deep-link
Promozioni mirate basate sui dati di WiFi Analytics , inclusi frequenza delle visite, tempo di permanenza e zona della sede

Funzioni Principali della Landing Page: Coinvolgimento marketing, visualizzazione del programma fedeltà, promozioni mirate, navigazione all'interno della sede e call to action orientate alla conversione.

Flusso di Autenticazione: End-to-End

La sequenza seguente illustra il flusso completo dall'associazione all'SSID fino alla visualizzazione della Landing Page:

Il dispositivo client si associa all'SSID guest
Il controller assegna il dispositivo a una VLAN non autenticata
Il client tenta una richiesta HTTP; il controller intercetta ed emette un reindirizzamento 302 alla Splash Page
Il CNA carica la Splash Page (risorse fornite solo da domini inseriti nella whitelist del Walled Garden)
L'utente completa l'autenticazione e accetta i Termini e le Condizioni
La piattaforma del Captive Portal invia una richiesta di Access-Request al server RADIUS
RADIUS restituisce Access-Accept; il controller riceve un messaggio di Change of Authorization (CoA)
Il controller migra il client sulla VLAN autenticata
La piattaforma del Captive Portal emette un reindirizzamento 302 alla WiFi Landing Page
Il browser del client carica la Landing Page completa sull'internet aperto

Questa netta separazione delle responsabilità — autenticazione su la Splash Page, l'interazione sulla Landing Page — è la base architetturale di ogni implementazione di guest WiFi ben progettata.

Guida all'implementazione

La distribuzione di una soluzione guest WiFi scalabile e di livello enterprise richiede la separazione del piano di controllo di rete dal livello dell'esperienza utente. I passaggi seguenti forniscono un framework di implementazione indipendente dal fornitore, applicabile alle infrastrutture Cisco Meraki, Aruba, Ruckus e Ubiquiti.

Passaggio 1: Configurazione del Walled Garden

Configura il tuo Wireless LAN Controller (WLC) per inserire in whitelist solo i domini e gli intervalli IP strettamente necessari per il funzionamento della Splash Page. Questo in genere include:

L'hostname della piattaforma Captive Portal (es. portal.purple.ai)
I domini dell'identity provider per il social login (es. accounts.google.com, graph.facebook.com)
I domini del gateway SMS se si utilizza l'autenticazione OTP
Eventuali risorse CDN utilizzate dalla Splash Page stessa

Evita di eccedere con la whitelist. Ogni voce aggiuntiva aumenta la superficie di attacco della rete di pre-autenticazione e complica la manutenzione continua al variare degli intervalli IP.

Passaggio 2: Gestione dei certificati SSL

Configura il WLC con un certificato SSL valido e pubblicamente attendibile per l'hostname di reindirizzamento del captive portal. I certificati autofirmati attiveranno avvisi di sicurezza del browser nel CNA, spingendo gli utenti ad abbandonare il processo di connessione. La scadenza del certificato è una delle cause principali di interruzione del servizio guest WiFi — implementa il rinnovo automatico tramite Let's Encrypt o la tua piattaforma di gestione dei certificati.

Passaggio 3: Ottimizzazione del CNA

Progetta la Splash Page specificamente per l'ambiente CNA. Usa CSS inline, evita framework JavaScript esterni ed effettua test su più versioni di iOS e Android. Il comportamento del CNA di iOS, in particolare, cambia tra le principali release del sistema operativo — mantieni una matrice di test di regressione che copra almeno le due versioni principali più recenti di entrambe le piattaforme.

Passaggio 4: Logica di reindirizzamento post-autenticazione

Configura il reindirizzamento post-autenticazione per supportare URL dinamici della Landing Page. Il server RADIUS può restituire attributi specifici del fornitore (VSA) oppure la piattaforma Captive Portal può utilizzare il profilo utente autenticato per creare un URL personalizzato. Ciò consente la segmentazione: un visitatore che accede per la prima volta riceve un'offerta di benvenuto, mentre un membro del programma fedeltà con stato Gold riceve una dashboard personalizzata.

Passaggio 5: Integrazione degli Analytics

Strumenta la Landing Page con il tuo stack di analytics. Poiché l'utente si trova ora su Internet aperto con un browser completo, i normali strumenti di analytics funzionano correttamente. Integrali con il tuo CRM per creare un profilo cliente unificato che combini i dati della sessione WiFi con la cronologia degli acquisti, lo stato di fedeltà e le metriche di coinvolgimento marketing.

Per un confronto dettagliato tra le architetture captive portal basate su cloud e quelle on-premise, consulta Cloud-Based vs. On-Premise Captive Portal: Which Is Right for Your Business? .

Best Practice

Disaccoppia l'autenticazione dal marketing. La decisione architetturale più d'impatto consiste nell'utilizzare la Splash Page esclusivamente per l'accesso sicuro e il consenso, spostando tutte le risorse di marketing sulla Landing Page. Ciò migliora i tassi di connessione, riduce i ticket di supporto e semplifica gli audit di conformità.

Sfrutta il MAC Authentication Bypass per gli utenti di ritorno. Per i dispositivi che ritornano, il MAC Authentication Bypass (MAB) elimina completamente la Splash Page, reindirizzando gli utenti direttamente a una Landing Page personalizzata. Questo migliora notevolmente l'esperienza utente per i visitatori ricorrenti negli ambienti Hospitality e Retail . Assicurati che la tua informativa sulla privacy copra esplicitamente il tracciamento persistente dei dispositivi.

Adotta architetture incentrate sul cloud. Proprio come il settore del networking si è spostato verso la WAN definita dal software per una gestione centralizzata — come descritto in The Core SD WAN Benefits for Modern Businesses — le piattaforme Captive Portal dovrebbero essere ospitate in cloud. Ciò consente una gestione centralizzata tra sedi distribuite, aggiornamenti rapidi dei contenuti senza modifiche al firmware del controller e un'integrazione perfetta con CRM esterni e piattaforme di marketing automation.

Implementa RFC 8908 per la compatibilità con i moderni sistemi operativi. Il rilevamento nativo del captive portal tramite RFC 8908 riduce la dipendenza dall'intercettazione HTTP, migliorando l'affidabilità sulle versioni moderne di iOS e Android che impongono sempre più la navigazione solo HTTPS.

Mantieni un programma di audit del Walled Garden. Verifica le voci del Walled Garden trimestralmente. Gli intervalli IP dei principali identity provider cambiano senza preavviso. Le voci obsolete che non si risolvono più creano errori di autenticazione; le voci mancanti bloccano i flussi di autenticazione legittimi.

Risoluzione dei problemi e mitigazione dei rischi

Il loop di connessione. Se un utente si autentica ma viene ripetutamente reindirizzato alla Splash Page, verifica che il messaggio RADIUS Access-Accept raggiunga il controller e che il client riceva correttamente un lease DHCP sulla VLAN autenticata. Verifica anche che la porta CoA (Change of Authorization) (UDP 3799) non sia bloccata da un firewall intermedio.

Chiusura prematura del CNA. Se il CNA si chiude prima che l'utente possa autenticarsi, è probabile che il dispositivo abbia rilevato l'accesso a Internet in anticipo. Ciò può accadere se il Walled Garden è troppo permissivo, consentendo inavvertitamente il routing completo di Internet prima del completamento dell'autenticazione. Verifica le voci del Walled Garden per intervalli CIDR eccessivamente ampi.

Errori di intercettazione HTTPS. I browser moderni impongono l'HTTP Strict Transport Security (HSTS). Se un utente tenta di navigare su un dominio precaricato HSTS prima di autenticarsi, il browser bloccherà il reindirizzamento al captive portal. Implementa RFC 8908 per abilitare il rilevamento nativo del captive portal, oppure invita gli utenti a navigare su un dominio non HSTS per attivare il CNA.

Errori degli script di terze parti sulla Splash Page. Se i team di marketing hanno aggiunto pixel di tracciamento o script di analisi alla Splash Page, questi falliranno silenziosamente nell'ambiente CNA se i loro domini non sono inseriti in whitelist. La risoluzione corretta consiste nel rimuovere completamente questi script dalla Splash Page e ridistribuirli sulla Landing Page, dove funzioneranno correttamente.

Lacune di conformità GDPR. Assicurarsi che il meccanismo di consenso sulla Splash Page soddisfi i requisiti dell'Articolo 7 del GDPR: il consenso deve essere libero, specifico, informato e inequivocabile. Le caselle di consenso preselezionate non sono conformi. Conservare un registro di audit del consenso per un minimo di tre anni.

ROI e impatto aziendale

Un'architettura Splash/Landing Page implementata correttamente trasforma il WiFi per gli ospiti da un centro di costo a una risorsa misurabile in grado di generare ricavi. Il caso finanziario opera su tre dimensioni.

Acquisizione dati e First-Party Intelligence. Semplificando la Splash Page, le sedi aumentano i tassi di connessione e il volume di dati di prima parte acquisiti. Negli ambienti Sanità e Trasporti , questi dati supportano l'analisi operativa (modelli di affluenza, tempo di permanenza per zona e previsione dei picchi di domanda), consentendo decisioni di allocazione delle risorse con risparmi sui costi misurabili.

Attribuzione diretta dei ricavi. La Landing Page è la superficie di conversione primaria. Un'installazione all'interno di uno stadio può utilizzare la Landing Page per promuovere l'ordinazione di cibo e bevande direttamente dal proprio posto, correlando direttamente l'accesso alla rete con i ricavi delle transazioni. Un hotel può offrire prenotazioni di spa o upgrade di camera. Un rivenditore può proporre promozioni specifiche per zona guidate dai dati di localizzazione in tempo reale di WiFi Analytics .

Fidelizzazione e retention. Le esperienze personalizzate sulla Landing Page, guidate dal profilo utente acquisito sulla Splash Page, aumentano il coinvolgimento nei programmi di fidelizzazione. Gli utenti di ritorno che ricevono un'esperienza di benvenuto personalizzata mostrano una durata della sessione e una frequenza di visite ripetute significativamente più elevate rispetto agli utenti a cui viene presentata una landing page generica.

I KPI misurabili per un'installazione WiFi per gli ospiti dovrebbero includere: tasso di connessione WiFi (target >70% dei visitatori della sede), tasso di acquisizione dati (target >85% degli utenti connessi), tasso di clic sulla Landing Page sulla CTA principale e ricavi diretti attribuiti alle promozioni guidate dal WiFi.

Ascolta il podcast completo del briefing tecnico qui sotto:

Definizioni chiave

Captive Portal

Un meccanismo di controllo dell'accesso basato sul web che intercetta il traffico di rete dei client non autenticati e li reindirizza a un'interfaccia di autenticazione prima di concedere un accesso alla rete più ampio.

Il sistema globale che i team IT implementano per gestire l'accesso degli ospiti, applicare le policy di utilizzo accettabile, acquisire il consenso dell'utente e raccogliere dati di prima parte.

Splash Page

L'interfaccia di autenticazione iniziale presentata all'interno del flusso del captive portal, che opera all'interno dell'ambiente limitato del Walled Garden prima che all'utente sia stato concesso l'accesso a internet.

La pagina in cui gli architetti di rete devono concentrarsi su un design leggero, sulla verifica dell'identità e sul consenso legale. Sovraccaricare erroneamente questa pagina con risorse di marketing è la causa principale dei fallimenti di connessione al WiFi degli ospiti.

WiFi Landing Page

La pagina di destinazione post-autenticazione caricata nel browser completo dell'utente dopo che al dispositivo è stato concesso l'accesso a internet dal server RADIUS.

La pagina in cui i team di marketing e operativi distribuiscono rich media, contenuti personalizzati, integrazioni di fidelizzazione e campagne di coinvolgimento. Opera senza i vincoli del Walled Garden.

Walled Garden

Un ambiente di rete limitato che consente agli utenti non autenticati di accedere solo a un set specifico e chiaramente inserito in whitelist di indirizzi IP o nomi host, bloccando tutto il resto del traffico internet.

Il confine tecnico entro il quale deve operare la Splash Page. Ogni risorsa esterna utilizzata dalla Splash Page deve avere il proprio dominio o intervallo IP aggiunto alla whitelist del Walled Garden.

Captive Network Assistant (CNA)

Un pseudo-browser specializzato e in modalità sandbox integrato nei sistemi operativi mobili (iOS, Android, Windows) che rileva e visualizza automaticamente le pagine di accesso del captive portal.

Il motivo principale per cui le Splash Page devono essere leggere ed evitare JavaScript complessi, cookie esterni o risorse multimediali di grandi dimensioni. Il comportamento del CNA varia a seconda delle versioni del sistema operativo e richiede continui test di regressione.

MAC Authentication Bypass (MAB)

Una tecnica di controllo dell'accesso alla rete che autentica i dispositivi in base al loro indirizzo MAC hardware senza richiedere l'interazione dell'utente, consentendo un accesso fluido per i dispositivi che ritornano.

Utilizzato per fornire esperienze di accesso fluide agli ospiti che ritornano o ai dispositivi IoT registrati. Richiede l'integrazione tra il server RADIUS e il database di fidelizzazione o di registrazione dei dispositivi della struttura.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce una gestione centralizzata di autenticazione, autorizzazione e contabilità (AAA) per l'accesso alla rete, definito nella specifica RFC 2865.

L'infrastruttura del server backend che convalida le credenziali inviate sulla Splash Page, indica al controller di concedere l'accesso e restituisce gli attributi utente utilizzati per personalizzare la Landing Page.

RFC 8908

Lo standard IETF che definisce l'API del Captive Portal, consentendo ai dispositivi di scoprire e interagire con i captive portal in modo nativo tramite opzioni DHCP e Router Advertisement anziché affidarsi all'intercettazione HTTP.

Uno standard moderno che migliora l'affidabilità del captive portal su iOS 14+ e Android 11+, riducendo i fallimenti di connessione legati al CNA causati da problemi di intercettazione HTTPS.

Change of Authorization (CoA)

Un'estensione RADIUS (RFC 5176) che consente al server RADIUS di modificare dinamicamente una sessione di rete attiva, ad esempio migrando un client da una VLAN non autenticata a una autenticata dopo un accesso riuscito.

Il meccanismo con cui la piattaforma del captive portal indica al controller wireless di concedere l'accesso a internet dopo che l'utente ha completato l'autenticazione sulla Splash Page.

Esempi pratici

Un hotel resort da 500 camere riscontra tassi di abbandono elevati al momento dell'accesso al WiFi per gli ospiti. Il team di marketing ha recentemente aggiunto un video promozionale da 4 MB e una mappa interattiva complessa della struttura alla schermata di connessione iniziale. I tassi di connessione sono scesi dal 68% al 31% dopo l'aggiornamento. In che modo l'architetto di rete dovrebbe risolvere il problema?

L'architetto deve disaccoppiare le funzioni di autenticazione e di marketing. Passaggio 1: sostituire l'attuale schermata di connessione con una Splash Page leggera, inferiore a 1 MB, contenente solo il modulo di autenticazione (numero di camera e cognome), una casella di controllo del consenso conforme al GDPR e l'accettazione di Termini e Condizioni. Passaggio 2: rimuovere tutte le dipendenze da script esterni dalla Splash Page e distribuire tutte le risorse dalla CDN della piattaforma del captive portal, che è già inserita nella whitelist del Walled Garden. Passaggio 3: configurare il reindirizzamento post-autenticazione del controller wireless per inviare l'utente a una Landing Page appena creata e ospitata sull'internet aperto. Passaggio 4: spostare il video promozionale da 4 MB e la mappa interattiva della struttura su questa Landing Page. Passaggio 5: integrare la Landing Page con il CRM dell'hotel per personalizzare il messaggio di benvenuto in base al profilo dell'utente autenticato. Passaggio 6: implementare il MAC Authentication Bypass per gli ospiti che ritornano, in modo da eliminare completamente la Splash Page nelle visite successive.

Commento dell'esaminatore: Questo approccio risolve il problema dell'abbandono riconoscendo i vincoli fondamentali del Captive Network Assistant (CNA). Le risorse pesanti causavano il timeout del CNA o la mancata visualizzazione all'interno dell'ambiente limitato del Walled Garden. Spostandole sulla Landing Page post-autenticazione si garantisce che vengano caricate correttamente utilizzando le piene funzionalità del browser del dispositivo tramite una connessione internet stabilita. L'implementazione del MAB per gli ospiti che ritornano migliora ulteriormente l'esperienza per i clienti abituali più preziosi dell'hotel, mentre l'integrazione del CRM sulla Landing Page crea un percorso misurabile di attribuzione dei ricavi.

Una catena di negozi al dettaglio desidera offrire un accesso WiFi fluido ai membri del programma fedeltà che ritornano in 50 punti vendita, saltando la schermata di accesso e visualizzando al contempo un'offerta di benvenuto personalizzata e il saldo attuale dei punti fedeltà. Qual è l'architettura tecnica consigliata?

Implementare il MAC Authentication Bypass (MAB) integrato con il database di fidelizzazione tramite RADIUS. Architettura: (1) Quando un dispositivo che ritorna si associa all'SSID, il controller invia una richiesta RADIUS Access-Request contenente l'indirizzo MAC del dispositivo. (2) Il server RADIUS interroga il database di fidelizzazione per associare l'indirizzo MAC a un profilo fedeltà. (3) Se viene trovata una corrispondenza, il server RADIUS restituisce un Access-Accept con un attributo specifico del fornitore (VSA) contenente un token utente firmato. (4) Il controller concede l'accesso immediato a internet e reindirizza all'URL della Landing Page, aggiungendo il token firmato come parametro di query. (5) La Landing Page ospitata in cloud decodifica il token, interroga l'API di fidelizzazione per ottenere il saldo punti corrente dell'utente e l'offerta personalizzata, e mostra un'esperienza di benvenuto personalizzata. Per i nuovi utenti o i dispositivi non riconosciuti, viene presentato il flusso standard della Splash Page, con l'opzione di collegare il dispositivo al proprio account fedeltà per un futuro accesso fluido.

Commento dell'esaminatore: Questa soluzione utilizza correttamente il MAB per il controllo dell'accesso alla rete, sfruttando al contempo la Landing Page per i requisiti di marketing. L'approccio con token firmato impedisce la manipolazione degli URL e garantisce che il contenuto personalizzato sia mostrato solo all'utente autenticato. Il fallback alla Splash Page standard per i dispositivi non riconosciuti garantisce che l'acquisizione di nuovi clienti non venga compromessa. Questa architettura dimostra una profonda comprensione del design disaccoppiato del captive portal ed è direttamente applicabile alle implementazioni retail aziendali in punti vendita distribuiti.

Domande di esercitazione

Q1. Un'organizzazione del settore pubblico richiede che tutti gli utenti del WiFi ospiti accettino una lunga Policy di Utilizzo Accettabile (AUP) prima di accedere a internet. Il team di comunicazione desidera inoltre mostrare un feed dinamico dei prossimi eventi della community e una bacheca social in tempo reale. Come si dovrebbe strutturare questo requisito all'interno del flusso del captive portal?

Suggerimento: Considerare i vincoli del Captive Network Assistant (CNA) e del Walled Garden quando si decide dove posizionare ciascun elemento di contenuto.

Visualizza risposta modello

Posizionare la Policy di Utilizzo Accettabile (AUP) sulla Splash Page per garantire la conformità legale prima dell'autenticazione. L'AUP deve essere presentata come testo in linea o all'interno di un div scorrevole, non caricata da un URL esterno, per evitare dipendenze dal Walled Garden. Una volta che l'utente ha accettato l'AUP ed è stato autenticato, reindirizzarlo alla Landing Page per mostrare il feed dinamico degli eventi della community e la bacheca social. La bacheca social, in particolare, richiede chiamate API esterne che non possono funzionare all'interno del Walled Garden, rendendo la Landing Page l'unica opzione praticabile.

Q2. Durante una nuova implementazione in un centro congressi, gli utenti segnalano che la schermata di accesso appare correttamente ma, quando fanno clic su 'Accedi con LinkedIn', la pagina va in timeout e restituisce un errore. La configurazione del controller e il server RADIUS funzionano entrambi correttamente per l'autenticazione tramite email/password. Qual è la causa più probabile e la relativa risoluzione?

Suggerimento: Pensare a quale accesso di rete è richiesto a un provider di identità OAuth di terze parti per completare il suo flusso di autorizzazione durante la fase di pre-autenticazione.

Visualizza risposta modello

La configurazione del Walled Garden è incompleta. Il flusso OAuth di LinkedIn richiede che il dispositivo client comunichi con i server di autorizzazione di LinkedIn (ad es. www.linkedin.com, api.linkedin.com) durante la fase di pre-autenticazione. Poiché questi domini non sono inseriti nella whitelist, il reindirizzamento OAuth non va a buon fine. La risoluzione consiste nell'identificare tutti gli intervalli IP e i nomi host utilizzati dall'API OAuth di LinkedIn e aggiungerli alla whitelist del Walled Garden sul controller wireless. Si noti che LinkedIn (e altri importanti provider di identità) potrebbero utilizzare più domini ospitati su CDN; verificare la documentazione OAuth o utilizzare un'acquisizione di pacchetti per identificare tutti gli endpoint richiesti.

Q3. Un cliente retail desidera tracciare il comportamento degli utenti sulla schermata iniziale di accesso al WiFi utilizzando Google Analytics 4 e un pixel di retargeting personalizzato della propria piattaforma pubblicitaria. Il team di marketing ha fornito uno snippet del tag manager da aggiungere alla Splash Page. Perché questo è tecnicamente problematico e qual è l'alternativa consigliata che preserva i requisiti di misurazione del team di marketing?

Suggerimento: Valutare le capacità del mini-browser CNA e le implicazioni dell'aggiunta di domini di script esterni al Walled Garden.

Visualizza risposta modello

Questo è problematico per due ragioni. In primo luogo, il CNA spesso blocca i cookie e limita l'esecuzione di JavaScript, rendendo gli script di tracciamento lato client inefficaci o inaffidabili. In secondo luogo, Google Tag Manager e i pixel pubblicitari caricano script da molteplici domini esterni; l'aggiunta di tutti questi domini al Walled Garden crea una notevole esposizione in termini di sicurezza e un continuo sovraccarico di manutenzione. L'alternativa consigliata è un approccio in due parti: (1) Acquisire l'evento di autenticazione lato server tramite l'API della piattaforma del captive portal o i log di contabilità RADIUS, e inviare questo evento a Google Analytics 4 utilizzando il Measurement Protocol (lato server), che non richiede JavaScript lato client. (2) Implementare il contenitore completo di Google Tag Manager e il pixel di retargeting sulla Landing Page post-autenticazione, dove l'ambiente completo del browser garantisce un'esecuzione affidabile degli script e il normale funzionamento del tracciamento basato sui cookie.

Continua a leggere questa serie

Captive Portal per Ruijie: come configurarlo con Purple guest WiFi

Come il cloud guest WiFi di Purple si integra con gli access point Ruijie serie RG utilizzando l'autenticazione web e RADIUS, configurati da riga di comando, e dove trovare i passaggi esatti di configurazione.

Progettazione di Captive Portal B2B: Raccolta dei Dati del Nome Registrato e dell'Azienda

Questa guida fornisce ai responsabili IT e ai gestori di sedi un framework tecnico indipendente dal fornitore per la progettazione di Captive Portal B2B. Dettaglia come strutturare i campi di registrazione per acquisire il nome registrato e i dati aziendali, garantendo tassi di completamento elevati pur mantenendo la conformità al GDPR e creando un'intelligence a livello di account.

Architettura Captive Portal: sicurezza, reindirizzamento e best practice

Un riferimento tecnico definitivo sull'architettura enterprise del captive portal. Questa guida analizza l'isolamento della rete, il reindirizzamento DNS, l'autenticazione RADIUS e la conformità della sicurezza per i responsabili IT che implementano reti WiFi ospiti sicure e ricche di dati.