Como trocar de provedor de WiFi para visitantes: checklist de migração para locais com várias unidades

Trocar de provedor de WiFi para visitantes em locais com múltiplos sites requer a exportação dos dados dos visitantes, a configuração de RADIUS em nuvem segundo a RFC 2865 e a RFC 2866, e a execução de um piloto de 14 dias antes da implementação em ondas. O hardware existente de fornecedores como Cisco Meraki ou HPE Aruba integra-se sem a necessidade de substituir equipamentos, enquanto manter relatórios paralelos durante um período de sobreposição de 30 dias protege a continuidade do serviço.

O que a troca de provedor de WiFi para visitantes realmente envolve?

A troca de provedor de WiFi para visitantes envolve a migração de três elementos: seus dados de visitantes, suas configurações de rede e seus relatórios. Seus pontos de acesso permanecem onde estão. Com uma camada de sobreposição em nuvem, como o WiFi para visitantes da Purple, o novo provedor funciona sobre o hardware que você já possui. Esse hardware inclui Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. O motivo disso é explicado em Por que seu próximo upgrade de WiFi não precisa de novos equipamentos.

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

• Portal cativo: a página de login que o visitante visualiza antes de acessar a internet.
• Walled garden: a lista de domínios que um dispositivo pode acessar antes do login, para que o portal e as páginas de login social possam carregar.
• RADIUS: o protocolo definido na RFC 2865 que os pontos de acesso utilizam para consultar um servidor sobre a permissão de acesso de um dispositivo. Sua extensão de contabilização, a RFC 2866, reporta ao servidor o início, o término e a duração da sessão.

As duas falhas mais críticas são a interrupção total ("dark day") e a perda de base de contatos. Uma interrupção total ocorre em um site onde os visitantes não conseguem se conectar devido a uma configuração esquecida. A perda de base de contatos acontece quando sua base de marketing não pode mais receber e-mails porque as comprovações de consentimento permaneceram com o provedor antigo. A ordem de execução a seguir serve para evitar ambos os problemas.

Do que você precisa antes de trocar de provedor de WiFi para visitantes?

Prazos contratuais e cláusulas de dados

Comece pelo contrato antigo, não pela rede. Identifique três datas: o prazo final para notificação de rescisão, o término do serviço e eventuais prazos para devolução de dados. Nos termos do Artigo 28(3)(g) do GDPR, o operador deve excluir ou devolver os dados pessoais ao término do serviço, conforme a decisão de você, como controlador. Escreva para o provedor antigo e opte pela "devolução", por escrito, antes de enviar a notificação formal.

Planeje uma sobreposição de pelo menos 30 dias entre o início da operação do novo serviço e o encerramento do antigo. Esse período é necessário para a execução dos relatórios paralelos descrita mais adiante. Se o aviso prévio for de 90 dias, faça o cronograma de trás para frente: exportação na primeira quinzena, piloto até o 45º dia e onda final até o 75º dia.

Um inventário de cada site

Não é possível sequenciar uma migração que você não consegue visualizar. Crie uma planilha com uma linha por site e as seguintes colunas:

• Fabricante do ponto de acesso e controladora ou dashboard (por exemplo, dashboard da Cisco Meraki, HPE Aruba Central, Ruckus SmartZone).
• Nomes de rede de SSID para visitantes e qualquer VLAN (LAN virtual, um segmento de rede separado) em que o tráfego de visitantes esteja alocado.
• Quem é o proprietário do firewall e do link de banda larga naquele local.
• Um contato local indicado que possa confirmar o carregamento do portal em um smartphone.
• Períodos de pico de atividade comercial e datas de bloqueio.

Uma exportação limpa do provedor anterior

Solicite a exportação por escrito e especifique o formato. Uma solicitação vaga gera um arquivo impreciso. Esta tabela detalha o que deve ser solicitado.

Campo	Por que você precisa dele	Formato a solicitar
Endereço de e-mail	Chave primária para marketing e desduplicação	CSV UTF-8, um registro por linha
Número de celular	Marketing por SMS e correspondência	Formato internacional ITU-T E.164
Marcador de consentimento por canal	O consentimento para e-mail e SMS é separado de acordo com o PECR	Uma coluna de verdadeiro/falso por canal
Registro de data/hora do consentimento	Comprova quando o consentimento foi fornecido (Artigo 7(1) do GDPR)	ISO 8601 com deslocamento UTC
Redação ou versão do consentimento	Comprova o que foi informado ao visitante	ID de versão mapeado para o texto arquivado do portal
Local de captura	Vincula o consentimento ao local onde foi coletado	ID do local correspondente ao seu inventário
Revogações e cancelamentos de inscrição	Evita o envio de e-mails para pessoas que optaram por sair	Arquivo de supressão separado com datas
Histórico de visitas	Linha de base para reconciliação de relatórios	Totais mensais por local, últimos 13 meses

Verifique a contagem de linhas no recebimento. Se o painel antigo mostrar 200.000 perfis e o arquivo contiver 160.000, pergunte o motivo antes de aprovar qualquer documento.

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

O Artigo 7(1) do GDPR determina que, quando o tratamento se basear no consentimento, o controlador deve ser capaz de demonstrá-lo. As diretrizes de consentimento do ICO detalham o que esse registro deve conter: quem consentiu, quando, como, o que foi informado e se houve revogação. Uma planilha de endereços de e-mail com uma coluna "marketing = sim" não atende a nenhum desses requisitos.

Três etapas garantem a preservação integral do consentimento:

1. Arquive a redação do portal antigo. Faça capturas de tela de todas as versões da página de login e do aviso de privacidade, com datas, e mapeie cada uma para o campo de versão do consentimento.
2. Verifique em nome de quem o consentimento foi concedido. O Considerando 42 do GDPR afirma que o titular dos dados deve saber pelo menos a identidade do controlador. O consentimento concedido à marca do seu local permanece válido. O consentimento concedido para o marketing do próprio provedor antigo não se mantém.
3. Importe a lista de supressão primeiro. Qualquer pessoa que tenha cancelado a inscrição deve permanecer com a inscrição cancelada no novo sistema desde o primeiro dia.

Registros sem registro de data/hora ou sem versão da redação não podem ser usados para marketing. Importe-os como contatos sem consentimento para marketing em vez de excluí-los, para que o histórico de visitas seja preservado.

Como executar a migração do WiFi para visitantes local por local?

Etapa 1: importe a lista antes de mexer em qualquer ponto de acesso

Importe primeiro para a Purple Engage. A Purple Engage aceita registros de visitantes consentidos com seu histórico de consentimento, para que cada perfil mantenha seu carimbo de data/hora, canal e versão do texto. Fazer isso antes de qualquer migração garante que nenhum disparo de marketing seja enviado sem a lista de supressão carregada. Isso também significa que os visitantes recorrentes encontram uma base de dados que já contém seu registro.

A Purple Engage se integra a plataformas de CRM e marketing. Se a sua plataforma de e-mail é o sistema de registro oficial para cancelamentos de inscrição, conecte-a antes da primeira campanha, e não depois.

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

O Purple Access gerencia o portal cativo e o RADIUS em nuvem nos pontos de acesso que você já possui. Crie um modelo de portal por marca e, em seguida, clone-o por localidade para que o ID do local 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 registre sua versão antes do lançamento.

No que diz respeito aos pontos de acesso, siga o artigo de suporte da Purple específico para o seu fornecedor em vez de copiar valores do provedor antigo. Endereços de servidor, segredos compartilhados e domínios de walled garden variam entre fornecedores. Uma configuração herdada da estrutura antiga é a causa mais comum de falhas na transição.

Passo 3: faça a transição em um local piloto

Escolha um piloto que seja representativo, não o mais fácil. Ele deve operar com o hardware mais comum, receber um fluxo normal de visitantes e estar ao alcance da sua equipe de TI. Realize a transição durante os períodos de menor movimento comercial, mantendo a configuração antiga do SSID salva para que você possa fazer a reversão em minutos.

Teste em pelo menos quatro dispositivos: um iPhone atual, um celular Android atual, um notebook Windows e um notebook macOS. Teste todos os métodos de login oferecidos. Em seguida, mantenha o piloto em execução por 14 dias antes da onda 1, pois algumas falhas só aparecem sob carga real.

Passo 4: faça a migração em ondas

Agrupe as localidades para que cada onda reutilize uma configuração já homologada. Esta matriz de decisão define a ordem.

Perfil do local	Onda	Motivo
Local representativo, hardware comum, próximo à TI	Piloto	Identifica falhas de configuração em um único local, e não em 30
Mesmo controlador ou painel que o piloto	Onda 1	Modelo homologado, menor risco
Fornecedor de hardware diferente	Piloto próprio, depois a próxima onda	A sintaxe do walled garden e do RADIUS varia conforme o fornecedor
Locais sazonais ou de baixo movimento	Onda 1 ou 2	Menos visitantes afetados caso ocorra alguma falha
Locais principais ou com maior faturamento	Onda final	Recebe a configuração mais validada
Locais com eventos ou datas de pico dentro do cronograma	Fora de uma margem de segurança de 7 dias antes e depois do pico	Sem quebra de congelamento de mudanças no seu momento mais movimentado

Mantenha cada onda em uma quantidade que sua equipe consiga verificar em um único turno. Um contato local deve confirmar que o portal carrega em cada local antes do encerramento da onda.

Cenário prático: uma rede de 30 hotéis

Os números abaixo são um exemplo prático, não uma implantação específica. Um grupo de 30 hotéis opera WiFi para visitantes com WiFi na Cisco Meraki em 22 propriedades e na HPE Aruba em oito. Seu contrato prevê aviso prévio de 90 dias. Você pode saber mais sobre o setor em nossa página de Hotéis.

O que foi feito. O grupo optou pela "devolução" com base no Artigo 28 e notificou a rescisão no primeiro dia. A exportação chegou na segunda semana com 210.000 registros. Desses, 31.000 não tinham registro de data e hora de consentimento e foram importados para o Purple Engage como não comercializáveis. O piloto foi realizado em um hotel Meraki de 120 quartos durante 14 dias. Os demais hotéis Meraki migraram em duas etapas de 10 e 11, utilizando modelos do painel. A rede Aruba teve seu próprio piloto e depois migrou em uma única etapa de sete hotéis.

Resultado. Todos os 30 hotéis estavam no novo portal até a sétima semana. A interrupção mais longa em qualquer local foi de 12 minutos, dentro de uma janela de manutenção noturna. Os acessos diários no piloto corresponderam aos números do provedor antigo com uma margem de 3%. O contrato antigo foi encerrado com 40 dias de sobreposição restantes.

Como provar que os novos relatórios correspondem aos antigos?

Execute ambos os sistemas em paralelo no piloto

Não é possível comparar relatórios de dois sistemas que nunca avaliaram os mesmos visitantes. Durante a quinzena do piloto, mantenha o painel do provedor antigo ativo com as exportações habilitadas. Extraia as mesmas cinco métricas de ambos os sistemas para as mesmas datas e locais:

• Acessos diários.
• Visitantes únicos.
• Visitantes novos versus recorrentes.
• Duração média da sessão.
• Taxa de adesão (opt-in) de marketing.

O WiFi Analytics da Purple relata essas métricas por local e em toda a rede. A duração da sessão depende do monitoramento de contabilidade (accounting) da RADIUS; portanto, verifique se os registros de accounting estão chegando antes de confiar nesse número.

Faça a reconciliaçã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 decorre de definições diferentes. Um provedor pode contabilizar cada associação de dispositivo como uma visita. Outro contabiliza apenas sessões autenticadas. Um pode agrupar sessões em um intervalo de 30 minutos, outro não.

Documente a definição de cada provedor e, em seguida, compare critérios equivalentes. Os recursos de privacidade dos dispositivos também afetam as contagens de visitantes recorrentes. A Apple introduziu endereços privados no iOS 14, e o Android randomiza endereços por padrão a partir do Android 10. Um provedor que identifica visitantes recorrentes apenas pelo endereço MAC reportará menos retornos do que um que faz a correspondência pela identidade de login.

Defina uma tolerância antes de começar, por exemplo, 5% nos acessos diários. Sem um número acordado previamente, qualquer diferença se torna motivo de debate.

Valide a aprovação antes do fim do período de aviso prévio

Elabore um documento de aprovação de uma página: as métricas comparadas, a definição de cada provedor, a divergência e a justificativa. Solicite a assinatura das equipes de TI, marketing e compras. Em seguida, faça uma exportação final dos relatórios históricos do provedor antigo, para que as comparações anuais continuem disponíveis após a migração.

Cenário prático: uma rede varejista de 120 lojas

Os números abaixo são um exemplo prático, não uma implantação real específica. Uma rede de moda com 120 lojas opera Ruckus pontos de acesso sob um controlador central. O marketing do grupo precisa que as tendências de visitas de compradores ano a ano permaneçam consistentes após a migração. Nossa página de Varejo aborda o setor com mais detalhes.

O que foi feito. A loja piloto identificou que o login social falhava em dispositivos Android. O walled garden continha os domínios do portal, mas não os domínios de login do provedor de identidade. A equipe de TI corrigiu isso antes da onda 1. Nos relatórios paralelos, o provedor antigo indicava 18% a mais de visitas diárias do que a Purple. O provedor antigo contabilizava cada associação. A Purple contabilizava sessões autenticadas. A reexecução da exportação antiga considerando apenas sessões autenticadas reduziu a diferença para 2%.

Resultado. Todas as 120 lojas foram migradas em quatro ondas semanais. Nenhuma loja perdeu o WiFi para visitantes durante o horário comercial. A reconciliação foi aprovada com uma diferença de 2% frente a uma tolerância acordada de 5%, três semanas antes do término do contrato anterior.

Quais configurações de pontos de acesso apresentam falhas com mais frequência durante a migração de um portal cativo?

A maioria das falhas está ligada a um pequeno conjunto de configurações. Esta tabela lista cada uma delas, o sintoma e a solução.

Configuração	Sintoma em caso de erro	Correção
Walled garden sem os novos domínios do portal	O telefone se conecta, mas o portal nunca carrega	Adicione todos os domínios do guia do fornecedor da Purple e, em seguida, remova os do provedor antigo
Walled garden sem os domínios de login social	O login por e-mail funciona, mas o login social falha	Adicione os domínios do provedor de identidade listados no guia do fornecedor
Divergência no segredo compartilhado do RADIUS	O login é aceito, mas o dispositivo nunca fica online	Insira novamente o segredo tanto no controlador quanto no novo servidor
Tarifação (accounting) do RADIUS desativada	Os logins aparecem, mas a duração da sessão é exibida como zero	Ative a tarifação (RFC 2866) com atualizações provisórias (interim updates)
Firewall bloqueando as portas do RADIUS	O login expira por tempo limite (timeout) em apenas um local	Permita o tráfego de saída UDP 1812 e 1813, as portas atribuídas na RFC 2865 e na RFC 2866
Identificador de local mapeado incorretamente	As sessões são vinculadas ao local errado	Faça a correspondência do identificador de local do controlador com o ID de local da Purple
Redirecionamento antigo mantido em um grupo de pontos de acesso	Metade de um local exibe o portal antigo	Audite cada SSID e grupo de pontos de acesso, não apenas o padrão
Tempo limite de sessão copiado do provedor antigo	Visitantes recebem novas solicitações de login no meio da visita	Ajuste o tempo limite para a duração média da visita; consulte Como implementar restrições de tempo e largura de banda no WiFi para visitantes

Políticas hospedadas no provedor antigo

Alguns provedores aplicam filtragem de conteúdo ou limites de largura de banda em sua própria nuvem, e não no seu hardware. Ao trocar de fornecedor, essas políticas desaparecem silenciosamente. Liste todas as políticas aplicadas pelo provedor antigo e recrie cada uma antes da transição. Espaços noturnos enfrentam isso com frequência, como explica o artigo Provedores de WiFi para casas noturnas e locais de funcionamento até tarde: filtragem de conteúdo, capacidade máxima e acesso de funcionários.

Problemas de relógio e certificado

A contabilização RADIUS e os certificados do portal dependem da hora correta. Uma controladora com o relógio desregulado gera registros de sessão no dia errado. Aponte cada controladora para uma fonte NTP (Network Time Protocol) confiável antes do piloto.

Quanto custa a migração e qual é o retorno obtido?

As linhas de custo a incluir no orçamento

Uma migração no hardware existente envolve quatro linhas de custo, nenhuma delas referente a hardware:

• Licença de sobreposição. Planeje pagar a ambos os provedores por pelo menos 30 dias.
• Tempo de TI por local. Painéis baseados em modelos reduzem drasticamente esse tempo após o piloto. Locais com controladoras autônomas demoram mais.
• Higienização de dados. Alguém precisa mapear versões de consentimento, deduplicar registros e carregar a lista de supressão.
• Verificação local. Uma pessoa designada em cada local verifica se o portal carrega no dia.

A Purple licencia por meio de três planos: Connect, Capture e Engage. O setor de compras deve precificar o plano de que você precisa com base no período de sobreposição, e não em um ano completo a partir da transição.

O que você recebe em troca

Você mantém os pontos de acesso que já possui, portanto, sem despesas de capital com hardware. Você mantém uma lista de marketing para a qual pode enviar e-mails legalmente, pois a comprovação de consentimento acompanha cada registro. Você obtém um modelo de relatórios unificado em todos os locais, de modo que as comparações em toda a rede deixam de depender de qual provedor gerenciava determinado espaço.

Você também passa a integrar uma plataforma comprovada em escala. A Purple opera em mais de 80.000 locais em mais de 90 países e processa 500 milhões de usuários e logins por ano. A Purple oferece 99,999% de disponibilidade (uptime), possui a certificação ISO 27001 e está em conformidade com o GDPR.

Perguntas frequentes

Precisamos de novos pontos de acesso para migrar o provedor de WiFi para visitantes para a Purple?

Não, a Purple opera nos pontos de acesso que você já possui. A Purple é independente de hardware e funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A transição altera o portal cativo, o walled garden e as configurações de RADIUS na sua controladora ou painel. Seus pontos de acesso, cabeamento e switches permanecem inalterados, portanto, a mudança de provedor é um projeto de configuração, e não uma renovação de hardware.

Podemos continuar enviando e-mails para nossa lista existente de visitantes após a migração?

Sim, desde que a comprovação de consentimento acompanhe a lista. O Artigo 7(1) do GDPR exige que você comprove o consentimento; assim, cada registro precisa de data/hora, canal, local de captura e o texto exato visualizado pelo visitante. A Purple Engage importa registros consentidos com esse histórico anexado. Registros sem comprovação devem ser importados como não comercializáveis. O consentimento concedido ao provedor antigo em nome dele próprio, e não em nome da sua marca, não é transferido.

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

Planeje de seis a oito semanas para a maioria dos ambientes de 20 a 150 locais. Isso cobre uma exportação de duas semanas, um piloto de 14 dias e ondas de migração dimensionadas de acordo com o que sua equipe pode verificar em um único turno. Locais que compartilham um painel em nuvem migram com mais rapidez, pois um modelo comprovado se aplica a vários outros. Inicie o planejamento a partir da data de aviso prévio do seu contrato antigo, reservando pelo menos 30 dias de sobreposição para relatórios em paralelo.

Nossos locais ficarão offline durante a migração?

Não, se você seguir a ordem de piloto e depois ondas. A alteração de cada local ocorre durante o horário de menor movimento comercial, com a configuração antiga salva para uma reversão em questão de minutos. A maioria das interrupções dura apenas o tempo que a controladora leva para aplicar as novas configurações. As falhas que causam indisponibilidades mais longas, como domínios de walled garden ausentes ou portas de RADIUS bloqueadas, são identificadas no local piloto em vez de ocorrerem em todo o ambiente.

A transferência de dados de visitantes entre provedores está em conformidade com o GDPR?

Sim, quando você atua como controlador e ambos os provedores atuam como operadores sob contrato. O Artigo 28(3)(g) do GDPR exige que o operador antigo devolva ou exclua os dados pessoais ao término do serviço, conforme sua escolha. Escolha "devolução" por escrito antes de enviar o aviso prévio. Transfira a lista de supressão primeiro, garantindo que qualquer pessoa que tenha optado por não participar permaneça com essa opção mantida. O Purple está em conformidade com o GDPR e possui certificação ISO 27001.

O que acontece com os dados que o provedor antigo ainda mantém?

O provedor antigo deve excluí-los assim que o serviço for encerrado, caso o seu contrato siga o Artigo 28 do GDPR. Solicite a confirmação da exclusão por escrito após verificar sua exportação e concluir a validação dos relatórios. Faça primeiro uma exportação final dos relatórios históricos, pois as comparações anuais dependem desse histórico. Mantenha a confirmação de exclusão junto aos seus registros de processamento, caso um órgão regulador ou visitante solicite.

Como provamos que os relatórios do Purple correspondem aos números do nosso provedor antigo?

Execute ambos os sistemas em paralelo no local piloto durante 14 dias e compare cinco métricas: acessos diários, visitantes únicos, novos versus recorrentes, duração da sessão e taxa de adesão (opt-in). A maior parte das divergências ocorre por diferentes definições de visita, e não por dados incorretos. Documente a definição de cada provedor, estabeleça com antecedência uma margem de tolerância como 5% e aprove antes do término do contrato antigo.

O Purple pode se conectar ao nosso CRM e à nossa plataforma de e-mail existentes?

Sim, o Purple se integra a plataformas de CRM e marketing. Perfis de visitantes importados, novos cadastros e alterações de consentimento podem ser direcionados ao sistema que sua equipe de marketing já utiliza. Conecte a integração antes da sua primeira campanha pós-migração, para que os cancelamentos de inscrição em ambos os lados sejam respeitados desde o primeiro envio. Isso mantém um registro único de consentimento entre o login no WiFi e o e-mail, atendendo ao que as diretrizes de consentimento do ICO esperam que você mantenha.