Mudar de fornecedor de WiFi para visitantes: uma lista de verificação de migração para locais com vários espaços

Mudar de fornecedor de WiFi para visitantes em locais com vários espaços exige exportar dados de visitantes, configurar o RADIUS na cloud ao abrigo das normas RFC 2865 e RFC 2866 e executar um piloto de 14 dias antes da implementação por fases. O hardware existente de fornecedores como a Cisco Meraki ou a HPE Aruba integra-se sem necessidade de substituir equipamentos, enquanto a manutenção de relatórios paralelos durante um período de sobreposição de 30 dias protege a continuidade do serviço.

O que envolve concretamente a mudança de fornecedor de WiFi para visitantes?

A mudança de fornecedor de WiFi para visitantes transfere três elementos: os seus dados de visitantes, as suas configurações de rede e os seus relatórios. Os seus pontos de acesso permanecem onde estão. Com uma camada cloud como o WiFi para visitantes da Purple, o novo fornecedor funciona sobre o hardware que já possui. Esse hardware inclui Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. O fundamento é explicado em Por que razão a sua próxima atualização de WiFi não precisa de hardware novo.

Três termos concentram a maior parte do trabalho numa migração de WiFi para visitantes:

• Portal cativo: a página de início de sessão que o visitante vê antes de aceder à Internet.
• Walled garden: a lista de domínios a que um dispositivo pode aceder antes do início de sessão, para que o portal e eventuais páginas de início de sessão social possam carregar.
• RADIUS: o protocolo definido na norma RFC 2865 que os pontos de acesso utilizam para perguntar a um servidor se devem autorizar um dispositivo. A sua extensão de faturação/contabilização, a RFC 2866, comunica o início, o fim e a duração da sessão ao servidor.

As duas falhas verdadeiramente críticas são um dia sem serviço e a perda de listas. Um dia sem serviço é um local onde os visitantes não conseguem aceder à Internet devido a uma configuração em falta. Uma perda de lista corresponde a uma base de dados de marketing à qual já não pode enviar e-mails porque os registos comprovativos de consentimento ficaram no fornecedor anterior. A ordem de trabalhos apresentada abaixo destina-se a evitar ambas as situações.

Do que necessita antes de mudar de fornecedor de WiFi para visitantes?

As datas contratuais e cláusulas de dados

Comece pelo contrato antigo e não pela rede. Identifique três datas: o prazo de pré-aviso, a data de cessação do serviço e qualquer prazo para devolução de dados. Nos termos do Artigo 28.º, n.º 3, alínea g) do GDPR, o subcontratante deve apagar ou devolver os dados pessoais no final da prestação de serviços, consoante a escolha efetuada por si, enquanto responsável pelo tratamento. Contacte o fornecedor anterior e opte pela "devolução", por escrito, antes de apresentar o pré-aviso.

Preveja uma sobreposição mínima de 30 dias entre o arranque do novo serviço e o término do antigo. Irá necessitar dessa sobreposição para o período de execução de relatórios paralelos descrito mais adiante. Se o período de pré-aviso for de 90 dias, faça a contagem decrescente: exportação na primeira quinzena, piloto por volta do 45.º dia e fase final até ao 75.º dia.

Um inventário de todos os locais

Não é possível calendarizar uma transição que não se consegue visualizar. Crie uma folha de cálculo com uma linha por local e as seguintes colunas:

• Fabricante do ponto de acesso e controlador ou dashboard (por exemplo, dashboard da Cisco Meraki, HPE Aruba Central, Ruckus SmartZone).
• Nomes do SSID para visitantes e qualquer VLAN (LAN virtual, um segmento de rede separado) onde o tráfego de visitantes reside.
• Quem é o proprietário da firewall e da linha de banda larga nesse local.
• Um contacto local designado que possa confirmar que o portal carrega num telemóvel.
• Picos de atividade comercial e períodos de indisponibilidade/bloqueio.

Uma exportação limpa do fornecedor anterior

Solicite a exportação por escrito e especifique o formato. Um pedido vago resulta num ficheiro vago. Esta tabela define o que deve solicitar.

Campo	Porque precisa dele	Formato a solicitar
Endereço de e-mail	Chave primária para marketing e eliminação de duplicados	CSV em UTF-8, um registo por linha
Número de telemóvel	Marketing por SMS e correspondência	Formato internacional ITU-T E.164
Indicador de consentimento por canal	O consentimento para e-mail e SMS é separado ao abrigo dos PECR	Uma coluna de verdadeiro/falso por canal
Carimbo de data/hora do consentimento	Comprova quando o consentimento foi dado (GDPR Artigo 7.º, n.º 1)	ISO 8601 com desvio UTC
Redação ou versão do consentimento	Comprova o que foi transmitido ao visitante	ID da versão mapeado para o texto arquivado do portal
Local de captura	Associa o consentimento ao espaço que o recolheu	ID do local correspondente ao seu inventário
Revogações e cancelamentos de subscrição	Impede o envio de e-mails para pessoas que optaram por não receber comunicações	Ficheiro de supressão separado com datas
Histórico de visitas	Referência para a reconciliação de relatórios	Totais mensais por local, últimos 13 meses

Verifique a contagem de linhas aquando da receção. Se o painel antigo mostrar 200 000 perfis e o ficheiro contiver 160 000, pergunte o motivo antes de aprovar qualquer documento.

Prova de consentimento que se mantém válida após a migração

O Artigo 7.º, n.º 1, do GDPR estabelece que, sempre que o tratamento se basear no consentimento, o responsável pelo tratamento deve ser capaz de o demonstrar. As orientações sobre consentimento do ICO indicam o que esse registo deve conter: quem consentiu, quando, como, o que lhe foi dito e se revogou o consentimento. Uma folha de cálculo de endereços de e-mail com uma coluna "marketing = sim" não cumpre nenhum desses requisitos.

Três passos para manter o consentimento intacto:

1. Arquive o texto do portal antigo. Guarde capturas de ecrã de todas as versões da página de início de sessão e do aviso de privacidade, com data, e associe cada uma ao campo da versão de consentimento.
2. Verifique em nome de quem está o consentimento. O Considerando 42 do GDPR estabelece que o titular dos dados deve conhecer, pelo menos, a identidade do responsável pelo tratamento. O consentimento dado à marca do seu espaço mantém-se válido. O consentimento concedido para o marketing do próprio fornecedor anterior não transita.
3. Importe a lista de supressão primeiro. Qualquer pessoa que tenha cancelado a subscrição tem de permanecer com a subscrição cancelada no novo sistema desde o primeiro dia.

Os registos sem carimbo de data/hora ou sem versão de redação não podem ser utilizados para fins de marketing. Importe-os como contactos sem consentimento de marketing em vez de os eliminar, para que o histórico de visitas permaneça intacto.

Como executar uma migração de WiFi para visitantes local a local?

Passo 1: importar a lista antes de intervir num ponto de acesso

Importe primeiro para a Purple Engage. A Purple Engage recebe registos de visitantes com consentimento juntamente com o respetivo histórico de consentimento, para que cada perfil mantenha o seu carimbo de data/hora, canal e versão do texto. Fazer isto antes de qualquer transição garante que nenhum envio de marketing seja realizado sem a lista de supressão carregada. Significa também que os visitantes habituais encontram uma base de dados que já contém o seu registo.

A Purple Engage integra-se com plataformas de CRM e de marketing. Se a sua plataforma de e-mail for o sistema de registo para cancelamentos de subscrição, ligue-a antes da primeira campanha, e não depois.

Passo 2: criar o portal cativo, o walled garden e as definições de RADIUS

O Purple Access gere o portal cativo e o RADIUS na cloud nos pontos de acesso que já possui. Crie um modelo de portal por marca e, em seguida, clone-o por localização para que o ID da localização esteja correto desde o início. Redija o novo texto de consentimento com opções de adesão consciente (opt-in), uma por canal, e registe a sua versão antes do lançamento.

Do lado dos pontos de acesso, siga o artigo de suporte da Purple específico para o seu fornecedor em vez de copiar valores do fornecedor antigo. Os endereços de servidor, os segredos partilhados e os domínios de walled garden variam consoante o fornecedor. Uma definição herdada da configuração antiga é a causa mais comum de uma transição com falhas.

Passo 3: fazer a transição de um local piloto

Escolha um piloto que seja representativo, não simples. Deve utilizar o seu hardware mais comum, ter um volume normal de visitantes e estar ao alcance da sua equipa de TI. Efetue a transição durante as horas de menor atividade, mantendo a configuração antiga de SSID guardada para que possa reverter em poucos minutos.

Teste em, pelo menos, quatro dispositivos: um iPhone recente, um telemóvel Android recente, um computador portátil Windows e um computador portátil macOS. Teste todos os métodos de início de sessão que disponibiliza. Depois, mantenha o piloto em funcionamento durante 14 dias antes da vaga 1, uma vez que algumas falhas só surgem sob carga real.

Passo 4: fazer a transição por vagas

Agrupe as localizações para que cada vaga reutilize uma configuração que já tenha validado. Esta matriz de decisão define a ordem.

Perfil da localização	Vaga	Motivo
Localização típica, hardware comum, próxima do suporte de TI	Piloto	Deteta falhas de configuração numa localização, e não em 30
Mesmo controlador ou dashboard que o piloto	Vaga 1	Modelo comprovado, risco mínimo
Fornecedor de hardware diferente	Piloto próprio, depois vaga seguinte	A sintaxe do walled garden e de RADIUS varia consoante o fornecedor
Localizações sazonais ou de menor movimento	Vaga 1 ou 2	Menos visitantes afetados se surgir alguma falha
Localizações emblemáticas ou de maior receita	Vaga final	Recebe a configuração mais testada
Localizações com eventos ou picos de tráfego durante o plano	Fora de uma margem de segurança de 7 dias antes e depois do pico	Sem quebra de congelamento de alterações no período de maior atividade

Mantenha cada vaga num número que a sua equipa consiga verificar num único turno. Um contacto local deve confirmar que o portal carrega em todas as localizações antes de a vaga ser dada como concluída.

Cenário prático: um grupo de 30 hotéis

Os valores abaixo constituem um exemplo prático, não uma implementação com nomes reais. Um grupo de 30 hotéis opera o WiFi para visitantes em Cisco Meraki em 22 propriedades e HPE Aruba em oito. O respetivo contrato prevê um aviso prévio de 90 dias. Pode ler mais sobre o setor na nossa página de Hotéis.

O que foi feito. O grupo optou pela "devolução" ao abrigo do Artigo 28.º e rescindiu o contrato logo no primeiro dia. A exportação chegou na segunda semana com 210 000 registos. Destes, 31 000 não tinham carimbo de data/hora de consentimento e foram importados para o Purple Engage como não comercializáveis. O projeto-piloto decorreu num hotel Meraki com 120 quartos durante 14 dias. Os restantes hotéis Meraki migraram em duas fases de 10 e 11, utilizando modelos de painel de controlo. A rede de hotéis Aruba teve o seu próprio projeto-piloto, tendo depois migrado numa única fase de sete.

Resultado. Todos os 30 hotéis estavam no novo portal até à sétima semana. A interrupção mais longa em qualquer local foi de 12 minutos, dentro de uma janela de manutenção noturna. Os registos diários de início de sessão no projeto-piloto coincidiram com os números do fornecedor anterior com uma margem de 3%. O contrato antigo terminou ainda com 40 dias de sobreposição de sobra.

Como provar que os novos relatórios coincidem com os anteriores?

Execute ambos os sistemas em paralelo no projeto-piloto

Não é possível comparar relatórios de dois sistemas que nunca mediram os mesmos visitantes. Durante a quinzena do projeto-piloto, mantenha o painel de controlo do fornecedor antigo ativo com as exportações ativadas. Extraia as mesmas cinco métricas de ambos os sistemas para as mesmas datas e o mesmo local:

• Inícios de sessão diários.
• Visitantes únicos.
• Visitantes novos versus visitantes habituais.
• Duração média da sessão.
• Taxa de aceitação de comunicações de marketing.

O WiFi Analytics da Purple apresenta estas métricas por local e em todo o conjunto de propriedades. A duração da sessão depende da contabilização de RADIUS, pelo que deve confirmar a receção dos registos de contabilização antes de confiar nesse número.

Efetue a conciliação com base nas definições, não nos totais

Os totais raramente coincidem no primeiro dia, e isso não é necessariamente uma falha. A maioria das divergências resulta de definições diferentes. Um fornecedor pode contabilizar cada associação de dispositivo como uma visita. Outro pode contabilizar apenas as sessões autenticadas. Um pode agrupar sessões com menos de 30 minutos de intervalo, enquanto outro pode não o fazer.

Registe a definição de cada fornecedor e, em seguida, compare dados comparáveis. As funcionalidades de privacidade dos dispositivos também afetam as contagens de visitantes habituais. A Apple introduziu endereços privados no iOS 14, e o Android randomiza os endereços por predefinição a partir do Android 10. Um fornecedor que identifique visitantes habituais apenas pelo endereço MAC reportará menos retornos do que outro que faça a correspondência pela identidade no início de sessão.

Defina uma tolerância antes de começar, por exemplo, 5% nos inícios de sessão diários. Sem um número acordado previamente, qualquer diferença dará origem a um debate.

Obtenha a validação antes do término do período de aviso prévio

Elabore um documento de validação de uma página: as métricas comparadas, a definição de cada fornecedor, a divergência e a respetiva justificação. Solicite a assinatura da equipa de TI, de marketing e de compras. Em seguida, realize uma exportação final dos relatórios históricos do fornecedor antigo, assegurando que as comparações homólogas continuam disponíveis após a mudança.

Cenário prático: uma cadeia de retalho com 120 lojas

Os números abaixo são um exemplo prático e não uma implementação específica. Uma cadeia de moda com 120 lojas opera Ruckus pontos de acesso através de um controlador central. O departamento de marketing do grupo necessita que as tendências homólogas de visitas de clientes continuem disponíveis após a transição. A nossa página sobre o setor de Retalho aborda este segmento com mais detalhe.

O que foi feito. Na loja piloto, verificou-se que o início de sessão através de redes sociais falhava em dispositivos Android. O walled garden incluía os domínios do portal, mas não os domínios de início de sessão do fornecedor de identidade. A equipa de TI corrigiu isto antes da fase 1. Na elaboração de relatórios em paralelo, o fornecedor anterior apresentava mais 18% de visitas diárias do que a Purple. O fornecedor anterior contabilizava todas as associações. A Purple contabilizava apenas as sessões autenticadas. Ao executar novamente a exportação antiga considerando unicamente as sessões autenticadas, a diferença reduziu-se para 2%.

Resultado. As 120 lojas migraram em quatro fases semanais. Nenhuma loja perdeu o WiFi para visitantes durante o horário de funcionamento. A reconciliação foi validada com uma discrepância de 2%, abaixo da tolerância estipulada de 5%, três semanas antes do término do contrato anterior.

Quais são as configurações dos pontos de acesso que falham com maior frequência durante a migração de um portal cativo?

A maior parte das falhas deve-se a um número reduzido de configurações. Esta tabela apresenta cada uma delas, o respetivo sintoma e a solução.

Configuração	Sintoma de erro	Solução
Domínios do novo portal em falta no walled garden	O telemóvel liga-se, mas o portal nunca carrega	Adicione todos os domínios do guia do fornecedor da Purple e, em seguida, remova os do fornecedor anterior
Domínios de início de sessão em redes sociais em falta no walled garden	O início de sessão por e-mail funciona, mas o início de sessão pelas redes sociais falha	Adicione os domínios do fornecedor de identidade indicados no guia do fornecedor
Incompatibilidade no segredo partilhado do RADIUS	O início de sessão é aceite, mas o dispositivo nunca obtém acesso à Internet	Introduza novamente o segredo tanto no controlador como no novo servidor
Gestão de contas (accounting) do RADIUS desativada	Os inícios de sessão surgem no sistema, mas a duração da sessão aparece a zero	Ative a gestão de contas (RFC 2866) com atualizações intercalares
Firewall a bloquear as portas do RADIUS	O início de sessão expira (timeout) apenas num dos locais	Permita o tráfego de saída UDP nas portas 1812 e 1813, atribuídas nos RFC 2865 e RFC 2866
Mapeamento incorreto do identificador do local	As sessões surgem associadas ao local incorreto	Faça corresponder o identificador do local no controlador ao ID de local da Purple
Redirecionamento antigo mantido num grupo de pontos de acesso	Metade do local apresenta o portal antigo	Audite todos os SSID e grupos de pontos de acesso, e não apenas o predefinido
Tempo limite de sessão (timeout) copiado do fornecedor anterior	É solicitada nova autenticação aos visitantes a meio da visita	Defina o tempo limite de acordo com a duração habitual da visita; consulte Como Implementar Restrições de Tempo e de Largura de Banda no WiFi para Visitantes

Políticas que residiam no fornecedor anterior

Certos fornecedores aplicam filtragem de conteúdos ou limites de largura de banda na sua própria cloud e não no seu hardware. Ao mudar, essas políticas deixam de funcionar silenciosamente. Registe todas as políticas implementadas pelo fornecedor anterior e volte a criá-las antes da transição definitiva. Os estabelecimentos de diversão noturna são os mais afetados por esta situação, conforme detalhado no artigo Fornecedores de WiFi para discotecas e espaços noturnos: filtragem de conteúdos, capacidade de pico e acesso de colaboradores.

Problemas de relógio e certificados

A contabilização RADIUS e os certificados do portal dependem de uma hora correta. Um controlador com desvio no relógio produz registos de sessão com datas incorretas. Aponte todos os controladores para uma fonte NTP (Network Time Protocol) fiável antes do piloto.

Quanto custa a mudança e qual é o retorno?

As rubricas de custos a orçamentar

Uma mudança no hardware existente tem quatro rubricas de custos, nenhuma delas relacionada com hardware:

• Licença de sobreposição. Planeie pagar a ambos os fornecedores durante, pelo menos, 30 dias.
• Tempo de TI por local. Os painéis de controlo baseados em modelos reduzem drasticamente este tempo após o piloto. Os locais com controladores autónomos demoram mais tempo.
• Limpeza de dados. Alguém tem de mapear as versões de consentimento, desduplicar registos e carregar a lista de supressão.
• Verificação local. Uma pessoa designada em cada local verifica se o portal carrega no próprio dia.

A Purple licencia através de três planos: Connect, Capture e Engage. O departamento de compras deve orçamentar o plano pretendido com base no período de sobreposição e não num ano completo a partir da transição.

O que recebe em troca

Mantém os pontos de acesso que já possui, pelo que não há despesas de capital em hardware. Mantém uma lista de marketing à qual pode enviar e-mails de forma legítima, dado que o comprovativo de consentimento acompanha cada registo. Obtém um modelo de relatórios único em todos os locais, pelo que as comparações globais deixam de depender de qual fornecedor geria cada espaço.

Além disso, passa a usufruir de uma plataforma comprovada à escala. A Purple está presente em mais de 80 000 espaços em mais de 90 países e processa 500 milhões de utilizadores e inícios de sessão por ano. A Purple oferece 99,999% de disponibilidade, detém a certificação ISO 27001 e está em conformidade com o GDPR.

Perguntas frequentes

Precisamos de novos pontos de acesso para mudar o fornecedor de WiFi para visitantes para a Purple?

Não, a Purple funciona nos pontos de acesso que já possui. A Purple é agnóstica em termos de hardware e é compatível com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A mudança altera as configurações de portal cativo, walled garden e RADIUS no seu controlador ou painel de controlo. Os seus pontos de acesso, cablagem e switches permanecem inalterados, pelo que a mudança de fornecedor é um projeto de configuração e não uma renovação de hardware.

Podemos continuar a enviar e-mails para a nossa lista de visitantes existente após a mudança?

Sim, desde que o comprovativo de consentimento acompanhe a lista. O Artigo 7.º, n.º 1, do GDPR exige a demonstração do consentimento, pelo que cada registo necessita de um carimbo de data/hora, canal, local de recolha e o texto exato apresentado ao visitante. O Purple Engage importa os registos com consentimento associados a esse histórico. Os registos sem comprovativo devem ser importados como não comercializáveis. O consentimento concedido ao antigo fornecedor em nome próprio, e não em nome da sua marca, não é transferível.

Quanto tempo demora uma migração de WiFi para visitantes em vários locais?

Preveja entre seis a oito semanas para a maioria dos parques de 20 a 150 locais. Isto cobre uma exportação de duas semanas, um projeto-piloto de 14 dias e fases de transição dimensionadas de acordo com o que a sua equipa consegue verificar num único turno. Os locais que partilham um dashboard na cloud transitam mais rapidamente, uma vez que um modelo comprovado se aplica a vários. Inicie o planeamento a partir da data de rescisão do seu contrato anterior, prevendo pelo menos 30 dias de sobreposição para relatórios paralelos.

Os nossos locais ficarão offline durante a transição?

Não, caso siga a sequência de projeto-piloto e posteriores fases. Cada local é alterado durante o período de menor atividade comercial, com a configuração antiga guardada para permitir uma reversão em minutos. A maioria das interrupções dura apenas o tempo necessário para o controlador aplicar as novas definições. As anomalias que causam períodos de inatividade mais longos, como a falta de domínios no walled garden ou portas RADIUS bloqueadas, são detetadas no local do projeto-piloto e não em todo o parque.

A transferência de dados de convidados entre fornecedores está em conformidade com o GDPR?

Sim, desde que atue como responsável pelo tratamento e ambos os fornecedores atuem como subcontratantes ao abrigo de contrato. O artigo 28.º, n.º 3, alínea g), do GDPR exige que o subcontratante anterior devolva ou apague os dados pessoais no termo do serviço, à sua escolha. Opte por escrito pela "devolução" antes de apresentar a rescisão. Transfira primeiro a lista de supressão, para que qualquer pessoa que tenha recusado permaneça com essa opção registada. O Purple está em conformidade com o GDPR e possui certificação ISO 27001.

O que acontece aos dados que o fornecedor anterior ainda detém?

O fornecedor anterior tem de os apagar assim que o serviço terminar, caso o seu contrato respeite o artigo 28.º do GDPR. Solicite a confirmação por escrito da eliminação após ter verificado a sua exportação e concluído a validação dos relatórios. Efetue primeiro uma exportação final dos relatórios históricos, uma vez que as comparações homólogas dependem desse histórico. Guarde a confirmação de eliminação com os seus registos das atividades de tratamento, caso um regulador ou visitante a solicite.

Como provamos que os relatórios do Purple correspondem aos números do fornecedor anterior?

Execute ambos os sistemas em paralelo no local do projeto-piloto durante 14 dias e compare cinco métricas: inícios de sessão diários, visitantes únicos, novos versus habituais, duração da sessão e taxa de adesão (opt-in). A maior parte das discrepâncias advém de diferentes definições de visita e não de dados incorretos. Documente a definição de cada fornecedor, acorde previamente uma margem de tolerância, como 5%, e conclua a validação antes do término do contrato anterior.

O Purple pode ligar-se ao nosso CRM e à nossa plataforma de e-mail atuais?

Sim, o Purple integra-se com plataformas de CRM e marketing. Os perfis de convidados importados, os novos inícios de sessão e as alterações de consentimento podem fluir para o sistema que a sua equipa de marketing já utiliza. Estabeleça a ligação da integração antes da sua primeira campanha pós-migração, para que os cancelamentos de subscrição de qualquer um dos lados sejam respeitados desde o primeiro envio. Isto mantém um registo único de consentimento entre o início de sessão de WiFi e o e-mail, tal como previsto nas orientações de consentimento do ICO.