Cambio di fornitore di WiFi per ospiti: lista di controllo per la migrazione di strutture multi-sede

Il passaggio a un nuovo fornitore di WiFi per ospiti in sedi distribuite richiede l'esportazione dei dati degli ospiti, la configurazione di RADIUS sul cloud in conformità con gli standard RFC 2865 e RFC 2866 e l'esecuzione di un progetto pilota di 14 giorni prima dell'implementazione a scaglioni. L'hardware esistente di fornitori quali Cisco Meraki o HPE Aruba si integra senza dover sostituire i dispositivi, mentre il mantenimento di report paralleli durante un periodo di sovrapposizione di 30 giorni garantisce la continuità del servizio.

Cosa comporta concretamente il passaggio a un altro fornitore di WiFi per ospiti?

Il passaggio a un altro fornitore di WiFi per ospiti trasferisce tre elementi: i dati degli ospiti, le impostazioni di rete e la reportistica. I punti di accesso rimangono dove sono. Con una soluzione overlay basata su cloud come Guest WiFi di Purple, il nuovo fornitore opera sull'hardware già in vostro possesso. Tale hardware include Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La spiegazione dettagliata è disponibile in Perché il vostro prossimo aggiornamento WiFi non necessita di nuovo hardware.

Tre concetti rappresentano la maggior parte del lavoro durante la migrazione del WiFi per ospiti:

• Portale captive: la pagina di accesso visualizzata da un visitatore prima di potersi connettere a Internet.
• Walled garden: l'elenco dei domini raggiungibili da un dispositivo prima dell'accesso, necessario per consentire il caricamento del portale e delle pagine di autenticazione social.
• RADIUS: il protocollo definito da RFC 2865 utilizzato dai punti di accesso per verificare con un server l'autorizzazione all'accesso di un dispositivo. La relativa estensione contabile, RFC 2866, comunica al server l'inizio, la fine e la durata della sessione.

I due rischi critici da evitare sono una giornata di blocco totale ("dark day") e la perdita dell'elenco dei contatti ("lost list"). Una giornata di blocco si verifica quando gli ospiti di una sede non possono connettersi a causa di un'impostazione non configurata. La perdita dell'elenco riguarda un database di marketing a cui non è più possibile inviare e-mail perché le prove del consenso sono rimaste con il fornitore precedente. L'ordine delle operazioni descritto di seguito ha lo scopo di prevenire entrambi i problemi.

Cosa occorre verificare prima di cambiare il fornitore di WiFi per ospiti?

Scadenze contrattuali e clausole relative ai dati

Iniziate dal contratto esistente, non dalla rete. Individuate tre date: il termine per il preavviso, la fine del servizio e l'eventuale termine per la restituzione dei dati. Ai sensi dell'articolo 28, paragrafo 3, lettera g), del GDPR, al termine del servizio il responsabile del trattamento deve cancellare o restituire i dati personali, a scelta del titolare del trattamento. Contattate per iscritto il fornitore uscente richiedendo la "restituzione" prima di notificare la disdetta.

Pianificate una sovrapposizione di almeno 30 giorni tra l'attivazione del nuovo servizio e la disattivazione del precedente. Questa finestra temporale è necessaria per la generazione parallela dei report descritta in seguito. Se il periodo di preavviso è di 90 giorni, procedete a ritroso: esportate i dati nelle prime due settimane, avviate il pilota entro il 45° giorno e completate l'ultimo scaglione entro il 75° giorno.

Un inventario dettagliato di ciascuna sede

Non è possibile pianificare una transizione senza una visione d'insieme. Create un foglio di calcolo con una riga per ogni sede e le seguenti colonne:

• Fornitore dei punti di accesso e controller o dashboard (ad esempio, dashboard Cisco Meraki, HPE Aruba Central, Ruckus SmartZone).
• Nomi del SSID per ospiti ed eventuali VLAN (LAN virtuale, un segmento di rete separato) su cui risiede il traffico degli ospiti.
• Chi gestisce il firewall e la linea a banda larga in quella sede.
• Un referente locale indicato che possa confermare il caricamento del portale su un telefono.
• Picchi di affluenza e date con blocco delle modifiche.

Un'esportazione pulita dal vecchio provider

Richieda l'esportazione per iscritto e ne specifichi il formato. Una richiesta vaga produrrà un file vago. Questa tabella illustra cosa richiedere.

Campo	Perché serve	Formato da richiedere
Indirizzo email	Chiave primaria per il marketing e la deduplicazione	CSV UTF-8, un record per riga
Numero di cellulare	Marketing via SMS e associazione	Formato internazionale ITU-T E.164
Flag di consenso per canale	Il consenso via email e SMS è separato ai sensi del PECR	Una colonna vero/falso per canale
Timestamp del consenso	Dimostra quando è stato prestato il consenso (GDPR Articolo 7(1))	ISO 8601 con offset UTC
Formulazione o versione del consenso	Dimostra cosa è stato comunicato al visitatore	ID versione mappato al testo archiviato del portale
Sede di acquisizione	Collega il consenso alla sede che lo ha raccolto	ID sede corrispondente al Suo inventario
Revoche e disiscrizioni	Evita di inviare email a persone che hanno revocato il consenso	File di soppressione separato con date
Cronologia delle visite	Base di riferimento per la riconciliazione dei report	Totali mensili per sede, ultimi 13 mesi

All'arrivo, verifichi il conteggio delle righe. Se la vecchia dashboard mostra 200.000 profili e il file ne contiene 160.000, chieda chiarimenti prima di approvare qualsiasi cosa.

Prove del consenso valide anche dopo la migrazione

L'Articolo 7(1) del GDPR stabilisce che, qualora il trattamento sia basato sul consenso, il titolare del trattamento deve essere in grado di dimostrarlo. Le linee guida sul consenso dell'ICO specificano cosa deve contenere tale record: chi ha prestato il consenso, quando, come, cosa gli è stato comunicato e se ha revocato il consenso. Un foglio di calcolo di indirizzi email con una colonna "marketing = sì" non soddisfa alcuno di questi requisiti.

Tre passaggi consentono di trasferire il consenso intatto:

1. Archiviare la precedente formulazione del portale. Catturi screenshot con data di ogni versione della pagina di accesso e dell'informativa sulla privacy, mappando ciascuna al campo della versione del consenso.
2. Verificare a nome di chi è stato rilasciato il consenso. Il Considerando 42 del GDPR afferma che l'interessato dovrebbe conoscere almeno l'identità del titolare del trattamento. Il consenso rilasciato al marchio della Sua sede viene trasferito. Il consenso rilasciato per le attività di marketing del vecchio provider non viene trasferito.
3. Importare prima la lista di soppressione. Chiunque abbia annullato l'iscrizione deve rimanere disiscritto nel nuovo sistema fin dal primo giorno.

I record privi di timestamp o di versione del testo non sono utilizzabili per finalità di marketing. È opportuno importarli come contatti senza consenso al marketing anziché eliminarli, in modo che la cronologia delle visite rimanga intatta.

Come eseguire una migrazione del WiFi per ospiti sede per sede?

Passaggio 1: importare l'elenco prima di intervenire su un access point

Importare innanzitutto in Purple Engage. Purple Engage acquisisce i record degli ospiti che hanno espresso il consenso insieme alla relativa cronologia, in modo che ogni profilo mantenga il proprio timestamp, il canale e la versione del testo dell'informativa. Eseguire questa operazione prima di qualsiasi migrazione garantisce che nessun invio di marketing parta senza che sia stata caricata la lista di soppressione. Inoltre, consente ai visitatori di ritorno di trovare un database che contiene già il loro profilo.

Purple Engage si integra con le piattaforme CRM e di marketing. Se la piattaforma e-mail utilizzata rappresenta il sistema di riferimento (system of record) per le disiscrizioni, è opportuno collegarla prima della prima campagna, non dopo.

Passaggio 2: creare il portale captive, il walled garden e configurare le impostazioni RADIUS

Purple Access gestisce il portale captive e il cloud RADIUS sugli access point già disponibili. Creare un modello di portale per ciascun brand, quindi clonarlo per ogni sede in modo che l'ID sede risulti corretto fin dall'inizio. Redigere il nuovo testo di consenso con opzioni di adesione esplicite e consapevoli, una per ciascun canale, e registrare la versione prima del go-live.

Per la parte relativa agli access point, seguire l'articolo di supporto di Purple specifico per il fornitore in uso, anziché copiare i valori dal vecchio provider. Indirizzi server, shared secret e domini del walled garden variano da un provider all'altro. Un'impostazione ereditata dalla vecchia configurazione rappresenta la causa più comune di fallimento della migrazione.

Passaggio 3: eseguire la migrazione su una sede pilota

Scegliere una sede pilota che sia rappresentativa, non semplice. Dovrebbe utilizzare l'hardware più diffuso nella propria infrastruttura, registrare un afflusso normale di visitatori ed essere facilmente raggiungibile dal team IT. Effettuare la migrazione durante le ore di minore attività, salvando la vecchia configurazione SSID in modo da poter eseguire il rollback in pochi minuti.

Eseguire il test su almeno quattro dispositivi: un iPhone recente, un telefono Android recente, un portatile Windows e un portatile macOS. Testare ogni metodo di accesso offerto. Lasciare quindi la sede pilota operativa per 14 giorni prima della fase 1, poiché alcuni problemi emergono solo in presenza di un carico di lavoro reale.

Passaggio 4: migrare a scaglioni

Raggruppare le sedi in modo che ogni scaglione riutilizzi una configurazione già collaudata. Questa matrice decisionale ne definisce l'ordine.

Profilo della sede	Scaglione	Motivazione
Sede rappresentativa, hardware diffuso, vicina all'IT	Pilota	Rileva gli errori di configurazione in una sola sede, non in 30
Stesso controller o dashboard del pilota	Scaglione 1	Modello collaudato, rischio minimo
Fornitore hardware differente	Pilota dedicato, poi scaglione successivo	La sintassi del walled garden e di RADIUS varia in base al fornitore
Sedi stagionali o a bassa affluenza	Scaglione 1 o 2	Minore impatto sui visitatori in caso di problemi imprevisti
Sedi di punta o a più alto fatturato	Scaglione finale	Beneficiano della configurazione più collaudata
Sedi con eventi o picchi di affluenza previsti nel piano	Al di fuori di una finestra di 7 giorni prima e dopo il picco	Evita di violare il blocco delle modifiche (change freeze) nel momento di massima attività

Mantenere ogni scaglione entro un numero di sedi che il team possa verificare in un unico turno lavorativo. Un referente locale dovrebbe confermare il corretto caricamento del portale in ogni sede prima di considerare chiuso lo scaglione.

Scenario pratico: un gruppo di 30 hotel

Le cifre riportate di seguito rappresentano un esempio pratico e non un'implementazione specifica. Un gruppo di 30 hotel gestisce il WiFi per ospiti su Cisco Meraki in 22 strutture e su HPE Aruba in otto. Il relativo contratto prevede un preavviso di 90 giorni. È possibile ottenere maggiori informazioni sul settore consultando la nostra pagina dedicata agli Hotel.

Interventi eseguiti. Il gruppo ha scelto la clausola di "restituzione" ai sensi dell'Articolo 28 e ha inviato la disdetta il primo giorno. L'esportazione è pervenuta nella seconda settimana con 210.000 record. Di questi, 31.000 non presentavano un timestamp relativo al consenso e sono stati importati in Purple Engage come non idonei al marketing. Il progetto pilota è stato condotto presso un hotel Meraki di 120 camere per 14 giorni. I restanti hotel Meraki sono stati migrati in due fasi da 10 e 11 strutture utilizzando i modelli della dashboard. Il parco strutture Aruba ha avuto un proprio progetto pilota, per poi essere migrato in un'unica fase di sette strutture.

Risultato. Entro la settima settimana, tutti i 30 hotel erano operativi sul nuovo portale. L'interruzione più lunga riscontrata in una singola sede è stata di 12 minuti, all'interno di una finestra di manutenzione notturna. Gli accessi giornalieri registrati durante il progetto pilota sono risultati allineati entro il 3% rispetto ai dati del fornitore precedente. Il vecchio contratto è terminato con 40 giorni di sovrapposizione residui.

Come verificare che i nuovi report corrispondano a quelli precedenti?

Eseguire entrambi i sistemi in parallelo durante il progetto pilota

Non è possibile confrontare i report di due sistemi che non hanno mai monitorato gli stessi visitatori. Nelle due settimane del progetto pilota, è opportuno mantenere attiva la dashboard del vecchio fornitore con le esportazioni abilitate. Si consiglia di estrarre le stesse cinque metriche da entrambi i sistemi per le medesime date e per la stessa sede:

• Accessi giornalieri.
• Visitatori unici.
• Visitatori nuovi rispetto a quelli di ritorno.
• Durata media della sessione.
• Tasso di adesione al marketing (opt-in).

Lo strumento WiFi Analytics di Purple rileva questi parametri sia per singola sede che per l'intero parco strutture. Poiché la durata della sessione dipende dal monitoraggio (accounting) RADIUS, verificare che i record di accounting vengano registrati correttamente prima di considerare affidabile tale valore.

Riconciliare i dati in base alle definizioni, non ai totali

I totali raramente coincidono dal primo giorno, e ciò non costituisce di per sé un'anomalia. La maggior parte delle discrepanze è riconducibile a definizioni differenti. Un fornitore potrebbe conteggiare ogni associazione di un dispositivo come una visita. Un altro potrebbe calcolare esclusivamente le sessioni autenticate. Uno potrebbe unificare le sessioni che avvengono entro 30 minuti, mentre un altro potrebbe non farlo.

È consigliabile annotare la definizione applicata da ciascun fornitore, per poi confrontare elementi omogenei. Anche le funzioni di privacy dei dispositivi influenzano il calcolo dei visitatori di ritorno. Apple ha introdotto gli indirizzi privati a partire da iOS 14, mentre Android randomizza gli indirizzi per impostazione predefinita a partire da Android 10. Un fornitore che identifica i visitatori di ritorno basandosi unicamente sull'indirizzo MAC riporterà un numero inferiore di ritorni rispetto a chi esegue la corrispondenza sull'identità di accesso.

È opportuno concordare una tolleranza preliminare, ad esempio il 5% sugli accessi giornalieri. Senza una soglia definita in anticipo, ogni divergenza rischia di generare discussioni.

Formalizzare l'approvazione prima del termine del periodo di preavviso

Si raccomanda di predisporre un documento di approvazione sintetico di una pagina contenente: le metriche a confronto, le definizioni adottate da ciascun fornitore, le discrepanze riscontrate e le relative motivazioni. Tale documento dovrà essere sottoscritto dai reparti IT, marketing e procurement. Successivamente, sarà necessario effettuare un'esportazione finale dei report storici dal fornitore precedente, consentendo così la continuità dei confronti su base annua anche dopo la migrazione.

Esempio pratico: una catena retail di 120 punti vendita

Le cifre riportate di seguito sono un esempio pratico, non una distribuzione reale. Una catena di negozi di moda con 120 punti vendita gestisce access point Ruckus tramite un controller centrale. Il marketing di gruppo deve mantenere i trend delle visite degli acquirenti su base annua anche dopo il passaggio. La nostra pagina Retail approfondisce il settore in maggior dettaglio.

Intervento effettuato. Nel negozio pilota è emerso che il login social non funzionava sui dispositivi Android. Il walled garden includeva i domini del portale ma non i domini di accesso dell'identity provider. Il team IT ha risolto il problema prima della fase 1. Nei report paralleli, il precedente provider mostrava il 18% di visite giornaliere in più rispetto a Purple. Il vecchio provider conteggiava ogni associazione, mentre Purple conteggiava le sessioni autenticate. Eseguendo nuovamente la vecchia esportazione solo sulle sessioni autenticate, il divario si è ridotto al 2%.

Risultato. Tutti i 120 negozi sono stati migrati in quattro fasi settimanali. Nessun punto vendita ha registrato interruzioni del WiFi per ospiti durante gli orari di apertura. La riconciliazione è stata approvata con uno scarto del 2% a fronte di una tolleranza concordata del 5%, tre settimane prima della scadenza del vecchio contratto.

Quali impostazioni degli access point creano più problemi durante la migrazione di un portale captive?

La maggior parte degli errori è riconducibile a poche impostazioni. Questa tabella elenca ciascuna di esse, il relativo sintomo e la soluzione.

Impostazione	Sintomo in caso di errore	Soluzione
Domini del nuovo portale mancanti nel walled garden	Il telefono si connette, ma il portale non si carica	Aggiungere tutti i domini indicati nella guida del vendor di Purple, quindi rimuovere quelli del vecchio provider
Domini del login social mancanti nel walled garden	L'accesso via e-mail funziona, il login social non funziona	Aggiungere i domini dell'identity provider elencati nella guida del vendor
Mancata corrispondenza del segreto condiviso RADIUS	Accesso accettato, ma il dispositivo non si connette mai a Internet	Reinserire il segreto sia sul controller che sul nuovo server
Accounting RADIUS disabilitato	Gli accessi vengono registrati, ma la durata della sessione è pari a zero	Abilitare l'accounting (RFC 2866) con aggiornamenti provvisori (interim updates)
Firewall che blocca le porte RADIUS	Timeout dell'accesso solo in una sede	Consentire le porte UDP in uscita 1812 e 1813, assegnate negli standard RFC 2865 e RFC 2866
Mappatura errata dell'identificatore della sede	Le sessioni vengono associate alla sede sbagliata	Far corrispondere l'identificatore della sede del controller all'ID sede di Purple
Vecchio reindirizzamento mantenuto su un gruppo di access point	Metà sede mostra il vecchio portale	Verificare ogni SSID e gruppo di access point, non solo quello predefinito
Timeout di sessione copiato dal vecchio provider	Agli ospiti viene richiesta nuovamente l'autenticazione a metà visita	Impostare il timeout in base alla durata della visita; consultare Come implementare restrizioni di tempo e larghezza di banda sul WiFi per ospiti

Policy gestite all'interno del vecchio provider

Alcuni provider applicano il filtraggio dei contenuti o i limiti di larghezza di banda all'interno del proprio cloud, anziché sul vostro hardware. Quando si cambia provider, queste policy scompaiono silenziosamente. È opportuno elencare tutte le policy applicate dal vecchio provider e reimpostarle prima del passaggio definitivo. I locali serali e notturni sono quelli che affrontano più spesso questa situazione, come illustrato in Provider di WiFi per locali notturni e discoteche: filtraggio dei contenuti, capacità massima e accesso del personale.

Problemi relativi a orologio e certificati

L'accounting RADIUS e i certificati del portale dipendono entrambi dalla correttezza dell'orario. Un controller con un orologio non sincronizzato genera record di sessione attribuiti al giorno sbagliato. Prima del pilot, indirizzi ogni controller verso una sorgente NTP (Network Time Protocol) affidabile.

Quanto costa un passaggio e cosa si ottiene in cambio?

Le voci di costo da preventivare

Un passaggio sull'hardware esistente prevede quattro voci di costo, nessuna delle quali legata all'hardware:

• Licenza di sovrapposizione. Preveda di pagare entrambi i provider per almeno 30 giorni.
• Tempo IT per sede. I dashboard basati su template riducono drasticamente questi tempi dopo il pilot. Le sedi con controller autonomi richiedono più tempo.
• Pulizia dei dati. Qualcuno deve mappare le versioni del consenso, deduplicare i record e caricare la lista di soppressione.
• Verifica locale. Il giorno del passaggio, una persona designata in ciascuna sede verifica che il portale si carichi correttamente.

Purple offre licenze attraverso tre piani: Connect, Capture ed Engage. L'ufficio acquisti dovrebbe calcolare il prezzo del piano necessario rispetto al periodo di sovrapposizione, non rispetto a un anno intero a partire dal cutover.

Cosa si ottiene in cambio

Conserva gli access point già in Suo possesso, evitando così spese di capitale per l'hardware. Mantiene una lista di marketing a cui può inviare email legittimamente, poiché la prova del consenso accompagna ogni record. Ottiene un unico modello di reportistica per tutte le sedi, così i confronti a livello di intero patrimonio aziendale non dipendono più da quale provider gestiva la specifica sede.

Inoltre, entra a far parte di una piattaforma collaudata su larga scala. Purple è attiva in oltre 80.000 sedi in più di 90 Paesi e gestisce 500 milioni di utenti e accessi all'anno. Purple garantisce un uptime del 99,999%, possiede la certificazione ISO 27001 ed è conforme a GDPR.

Domande frequenti

Sono necessari nuovi access point per passare il provider di WiFi per ospiti a Purple?

No, Purple funziona sugli access point già in Suo possesso. Purple è indipendente dall'hardware e funziona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Il passaggio modifica il portale captive, il walled garden e le impostazioni RADIUS sul Suo controller o dashboard. I Suoi access point, il cablaggio e gli switch restano al loro posto, quindi un cambio di provider è un progetto di configurazione, non un rinnovamento dell'hardware.

È possibile continuare a inviare email alla lista di ospiti esistente dopo il passaggio?

Sì, a condizione che la prova del consenso venga trasferita insieme alla lista. L'articolo 7(1) del GDPR richiede di dimostrare il consenso, quindi ogni record necessita di data/ora, canale, sede di acquisizione e testo esatto visualizzato dal visitatore. Purple Engage importa i record con consenso allegando tale storico. I record privi di prova dovrebbero essere importati come non commercializzabili. Il consenso fornito al vecchio provider a proprio nome, anziché al Suo brand, non si trasferisce.

Quanto tempo richiede la migrazione di una rete WiFi per ospiti multi-sede?

Preveda dalle sei alle otto settimane per la maggior parte delle reti da 20 a 150 sedi. Questo lasso di tempo comprende due settimane per l'esportazione, un progetto pilota di 14 giorni e scaglioni di transizione dimensionati in base a quanto il Suo team può verificare in un singolo turno lavorativo. Le sedi che condividono una dashboard cloud procedono più rapidamente, poiché un modello collaudato può essere applicato a molti casi. Avvii la pianificazione a partire dalla data di disdetta del vecchio contratto, lasciando almeno 30 giorni di sovrapposizione per la reportistica parallela.

Le nostre sedi saranno offline durante la transizione?

No, non se segue l'ordine pilota-poi-scaglioni. Ogni sede effettua il passaggio durante le ore di minore attività, con la vecchia configurazione salvata per un eventuale ripristino in pochi minuti. La maggior parte delle interruzioni dura solo il tempo necessario al controller per distribuire le nuove impostazioni. I problemi che causano interruzioni più lunghe, come domini walled garden mancanti o porte RADIUS bloccate, vengono individuati nella sede pilota anziché nell'intera rete.

Il trasferimento dei dati degli ospiti tra provider è conforme a GDPR?

Sì, nel caso in cui Lei agisca come titolare del trattamento ed entrambi i provider agiscano come responsabili del trattamento contrattualizzati. L'articolo 28(3)(g) di GDPR stabilisce che il vecchio responsabile del trattamento deve restituire o cancellare i dati personali al termine del servizio, a Sua discrezione. Scelga "restituzione" per iscritto prima di comunicare la disdetta. Trasferisca prima di tutto la lista di soppressione (suppression list), affinché chiunque abbia scelto di non partecipare (opt-out) mantenga tale scelta. Purple è conforme a GDPR e certificato ISO 27001.

Cosa succede ai dati ancora in possesso del vecchio provider?

Il vecchio provider è tenuto a cancellarli una volta terminato il servizio, se il Suo contratto rispetta l'articolo 28 di GDPR. Richieda una conferma scritta dell'avvenuta cancellazione dopo aver verificato l'esportazione e finalizzato l'approvazione della reportistica. Effettui prima un'esportazione finale dei report storici, poiché i confronti su base annua dipendono da tale storico. Conservi la conferma di cancellazione insieme al registro delle attività di trattamento, nel caso in cui un'autorità di regolamentazione o un visitatore ne facciano richiesta.

Come possiamo verificare che i report di Purple corrispondano ai dati del nostro vecchio provider?

Esegua entrambi i sistemi in parallelo nella sede pilota per 14 giorni e confronti cinque parametri: accessi giornalieri, visitatori unici, nuovi rispetto a quelli di ritorno, durata della sessione e tasso di consenso (opt-in). La maggior parte delle discrepanze deriva da diverse definizioni di visita, non da dati errati. Documenti la definizione di ciascun provider, concordi preventivamente una tolleranza (ad esempio il 5%) e approvi i risultati prima della scadenza del vecchio contratto.

Purple può collegarsi alla nostra piattaforma CRM e di posta elettronica esistente?

Sì, Purple si integra con le piattaforme CRM e di marketing. I profili degli ospiti importati, i nuovi accessi e le modifiche al consenso possono essere trasferiti al sistema già utilizzato dal Suo team di marketing. Attivi l'integrazione prima della Sua prima campagna post-migrazione, in modo tale che le disiscrizioni da entrambe le parti vengano rispettate fin dal primo invio. Questo approccio consente di mantenere un unico registro dei consensi tra accesso WiFi ed e-mail, proprio come richiesto dalle linee guida sul consenso dell'ICO.