O seu portfólio provavelmente parece algo assim: um sportsbook principal no .com, uma marca regional licenciada no .ca, um white-label de casino que lançou na primavera passada e um rebranding planeado para o Q4. Uma equipa de retenção é dona de tudo. E se executar web push em múltiplos domínios da forma padrão, também terá quatro listas de subscritores desconectadas, cada uma a crescer por si só, nenhuma delas a comunicar com as outras.
Essa fragmentação não é um erro de configuração que cometeu. É assim que a arquitetura de push da web funciona. O navegador associa cada subscrição a um único domínio, e nenhuma configuração de painel altera isso.
Existe, no entanto, uma forma suportada de contornar isso. Este artigo aborda a mecânica: por que uma subscrição de web push está associada a uma origem, o que realmente sobrevive a uma alteração de domínio (mais do que pensa), o que se quebra (menos do que teme, mas a parte que se agrava) e a arquitetura de origem estável que cria uma lista de subscritores em todas as marcas que opera hoje e em todas as marcas que lançar no futuro.
Por que uma subscrição de web push está associada a um domínio
Quando um visitante clica em Permitir, o navegador não o subscreve à sua marca. Subscreve-o a uma origem: o protocolo e o nome de anfitrião exatos na barra de endereço. A API Push cria a subscrição contra um service worker registado nessa origem, usando a chave do servidor de aplicação da sua plataforma. O registo que o navegador retorna tem três partes: um URL de endpoint no serviço de push do fornecedor do navegador, mais dois valores de encriptação (p256dh e auth) que bloqueiam payloads para esse único navegador.
A permissão de notificação segue a mesma regra. É concedida por origem, não por empresa. sportsbook.com e sportsbook.ca são estranhos ao nível do protocolo, mesmo quando partilham um logótipo, uma carteira e uma base de dados de jogadores. Cada um solicita separadamente, subscreve separadamente e constrói uma lista separada.
Origem, service worker de notificação push e chaves VAPID: o bloqueio de três partes
Três coisas fixam uma subscrição de web push no lugar. A origem que a criou. O service worker de notificação push que recebe mensagens para ela. E as chaves VAPID que a sua plataforma de envio detém. A subscrição é criada sob a chave pública, e o serviço de push aceita um envio apenas quando é autenticado com a chave privada correspondente. A sua plataforma prova que detém o par de chaves em cada envio; o registo de subscrição em si carrega apenas a metade pública.
O navegador também impõe uma subscrição por origem. Chamar subscribe novamente com uma chave de servidor de aplicação diferente falha até que a subscrição existente seja removida. Essa restrição importa mais tarde, quando chegarmos à consolidação: na mesma origem, um novo service worker pode assumir um subscritor existente silenciosamente. Entre origens, nunca pode.
O que uma migração de domínio quebra no web push (e o que não quebra)
Aqui está a parte que a maioria das equipas erra numa migração de domínio: assumem que a lista antiga morre. Não morre. Os subscritores que optaram pelo domínio antigo continuam a receber as suas notificações.
A entrega nunca toca no seu website. Quando envia, a sua plataforma faz um pedido autenticado com as suas chaves VAPID para o serviço de push que detém cada subscrição (o da Google para o Chrome, o da Mozilla para o Firefox, o da Apple para o Safari), e esse serviço entrega o payload encriptado ao service worker já instalado no navegador do subscritor. O domínio antigo pode ser redirecionado, estacionado ou ter desaparecido completamente. A notificação ainda chega.
O destino do clique é seu também. Os URLs de clique são definidos por campanha, pelo que um subscritor que optou por um domínio que desativou há dois anos pode clicar na notificação de hoje e aterrar no site ativo de hoje.
| Após uma alteração de domínio | Ainda funciona? |
|---|---|
| Entrega a subscritores existentes | Sim — os pushes são encaminhados através dos serviços de push dos fornecedores de navegadores, não através do seu site |
| Destino do clique | Sim — o URL de clique é definido por campanha; aponte-o para o domínio atual |
| Subscritores do domínio de origem antigo a aderir automaticamente à lista do novo domínio | Não — a permissão é por domínio de origem, pelo que aderir à nova lista é uma nova opção |
| Novos registos no domínio de origem antigo | Não — e esta é a perda que se acumula |
Portanto, uma migração de domínio não lhe custa os subscritores que tem. Custa-lhe a máquina que os produzia. No dia em que o tráfego muda, a captura de registos no novo domínio reinicia do zero enquanto a lista antiga decai lentamente. Execute isso num portfólio de marcas e cada propriedade está a pagar esse imposto de reinício independentemente.
O custo real: cada novo domínio começa a sua lista do zero
A captura fragmentada seria um incómodo num canal de baixa rotatividade. Apostas não é um canal de baixa rotatividade. Em sites de apostas e jogos no PushEngage, numa janela de 90 dias, os cancelamentos de subscrição apagaram cerca de 91% da aquisição de novos subscritores em todo o segmento. Uma lista neste vertical é uma banheira com o ralo aberto; a única coisa que mantém o nível é a torneira a correr continuamente.
A fragmentação desliga a torneira, uma propriedade de cada vez. A lista de cada marca só cresce enquanto esse domínio específico obtém novas opções. Uma migração reinicia a sua torneira para zero. Um novo white-label começa do zero. Entretanto, os navegadores continuam a drenar: a revogação automática de permissões do Chrome, anunciada em outubro de 2025, remove silenciosamente a permissão de notificação de sites com muito baixo envolvimento e alto volume de notificações. Uma lista que não está a capturar não está estável. Está a encolher.
O enquadramento do CAC torna as apostas claras. Pagou para adquirir cada um desses visitantes, e a opção é o único ativo duradouro de retargeting que a visita deixa para trás. O caso para o push neste vertical assenta na acumulação desse ativo. A fragmentação anula parte dele sempre que um domínio muda.
A arquitetura de domínio estável: um domínio de subscrição para cada marca
A solução é parar de criar subscrições em domínios de marca. Ancore cada subscrição a uma única origem HTTPS estável que o seu grupo controla, uma que sobreviverá a qualquer domínio de marca individual, e deixe que cada propriedade a alimente.
O PushEngage implementa isto como o fluxo de subdomínio personalizado, construído exatamente para este caso: múltiplos domínios que necessitam de administração unificada de subscritores sob um domínio controlado. A configuração:
- Escolha uma origem estável e neutra em termos de marca que possua, como
notify.yourbrandgroup.com. Escolha um nome que os subscritores possam ver, porque os navegadores exibem a origem da subscrição nas notificações. - Carregue o ficheiro do service worker do PushEngage para a raiz desse domínio e ative a funcionalidade em Configurações do Site » Configurações Avançadas. A origem estável obtém o seu próprio snippet de instalação com
isSubscriptionOnSubDomain: true. - Adicione o snippet do PushEngage a cada domínio de marca. Quando um visitante opta por aderir em qualquer um deles, o fluxo é encaminhado através da origem estável, onde a subscrição real é criada.
Dois requisitos são inegociáveis neste modo. Primeiro, a adesão é apenas em dois passos: o pedido de permissão do navegador tem de ser acionado na origem que detém a subscrição, pelo que um pedido nativo em um passo no domínio da marca não é possível. Segundo, a Instalação Rápida permanece ativada.
Seja honesto sobre a troca. O duplo passo adiciona um clique antes do pedido de permissão, e converte menos no momento da captura. Vale a pena ler em conjunto com as alavancas mais amplas para aumentar a sua taxa de adesão. Mas um subscritor de um passo capturado num domínio do qual mais tarde migrar é um ativo depreciado. Um subscritor de dois passos na origem estável sobrevive a cada rebranding, a cada lançamento regional, a cada migração que alguma vez executar. Em qualquer horizonte que inclua uma mudança de domínio, a lista consolidada vence em alcance total.
Notificações push para múltiplos websites, uma lista de subscritores
Uma vez que a origem estável esteja implementada, as notificações push para múltiplos websites deixam de significar múltiplas listas. Cada domínio de marca alimenta a mesma base de subscritores. Lançar um novo domínio regional ou white-label no próximo trimestre significa adicionar o snippet; as suas adesões caem na lista consolidada desde o primeiro dia. Retirar um domínio não significa nada para a lista: a captura continua nas propriedades sobreviventes, a entrega continua através dos serviços push, e os URLs de clique apontam para onde quer que esteja ativo.
Consolidar as listas de subscritores que já fragmentou
A maioria dos operadores chega a esta arquitetura com histórico: listas ativas espalhadas por domínios antigos, algumas dormentes, outras noutro fornecedor. A consolidação decorre em três faixas em paralelo.
| Faixa | O que faz | O que obtém |
|---|---|---|
| 1. Manter listas antigas a funcionar | Continuar a enviar para cada lista de origem antiga; apontar URLs de clique para o domínio ativo atual | O alcance pago continua a produzir sessões em vez de ser desvalorizado |
| 2. Capturar novos na origem estável | Mudar a adesão de cada propriedade ativa para o fluxo da origem estável | A fragmentação para no dia em que é implementada; toda a nova aquisição cai numa lista |
| 3. Deixe as listas antigas se canalizarem sozinhas | Cada envio para uma lista antiga leva a uma revisita a um domínio atual, onde aguarda o prompt de origem estável | Subscritores ativos consolidam-se, sem necessidade de reautorização forçada |
O Rastreio 3 é o cavalo de batalha silencioso. A permissão do navegador é por origem, pelo que os subscritores de origem antiga precisam tecnicamente de uma nova autorização para aderir à lista consolidada, mas nunca terá de a exigir. Dada a rapidez com que os públicos de apostas mudam, a lista consolidada torna-se a maioria do seu alcance ativo em poucos meses, simplesmente porque os jogadores ativos continuam a visitar.
Se alguns fragmentos residirem com outro fornecedor de push num domínio que possua, também podem vir. O caminho padrão do PushEngage é uma re-subscrição silenciosa: na próxima visita de um subscritor, o service worker de notificações push do SDK assume o controlo e re-subscreve-os sem um segundo pedido de permissão, porque a permissão a nível de origem persiste. Para o OneSignal, o PushEngage pode obter a lista diretamente através da API do OneSignal. A migração é "white-glove" e gratuita nos planos pagos.
Campanhas por marca dentro de uma lista consolidada
Uma lista não significa uma mensagem. Significa um ativo com melhor segmentação do que quatro fragmentos conseguiriam gerir.
Capture a marca de origem como um atributo do subscritor no momento da adesão, e coortes por marca existem desde o primeiro dia. A partir daí, a segmentação faz o que listas separadas nunca poderiam: marca cruzada com geografia, comportamento de depósito, recência da sessão ou preferência de liga. Esse é o modelo que o #1 descreve no manual de notificações push para sites de apostas. A campanha de odds-boost do carro-chefe vai para os apostadores do carro-chefe; o lembrete de cashback do white-label do casino vai para os seus jogadores; um alerta de jogos em todo o portfólio vai para todos os que seguem a liga, independentemente da marca sob a qual se inscreveram.
A vantagem não é cosmética. Em sites de apostas no PushEngage, o remetente mediano de sites de apostas vê um CTR de ~2,1% em notificações visualizadas; o decil superior atinge 6,9% — aproximadamente o triplo. Essa diferença é uma lacuna de segmentação, não uma lacuna de canal, e não é possível construir coortes comportamentais em quatro fragmentos desconectados. A consolidação é o que torna a segmentação como prática de entregabilidade exequível à escala do portfólio. Isso importa mais agora que o Chrome avalia cada origem de envio diariamente e limita os remetentes disruptivos (ativo desde janeiro de 2026). Uma origem estável concentra a sua reputação de remetente; envios segmentados e relevantes são o que a mantêm saudável.
Uma lista também torna a operação de jogo responsável mais simples, e isso é uma funcionalidade, não uma nota de rodapé. Um jogador autoexcluído suprimido num segmento de todo o portfólio é suprimido em todo o lado de uma vez, não marca a marca onde um fragmento pode escapar. Horários de silêncio e limites de frequência aplicam-se ao nível do subscritor em todas as campanhas de cada marca. E as próprias campanhas devem manter a linha: sem recuperação de perdas com foco em perseguir perdas, sem pressão de contagem decrescente em prompts de depósito.
Execute web push em múltiplos domínios sem dividir a sua lista
Toda a configuração é menor do que parece: um registo DNS para a origem estável, o ficheiro do service worker na sua raiz, o interruptor em Definições Avançadas, o trecho isSubscriptionOnSubDomain e o trecho padrão em cada domínio de marca com o processo de dupla confirmação configurado e Instalação Rápida ativada. As equipas normalmente implementam-no no mesmo dia, sem necessidade de replataformização. Esse é todo o esforço para gerir notificações push para múltiplos websites a partir de uma única origem.
O que recebe de volta é a fragmentação de coisas que cobra silenciosamente: uma lista de subscritores que se acumula. Cada marca alimenta-a, cada alteração de domínio reflete-se nela e cada campanha pode visar todo o portfólio ou uma marca de cada vez. Se quiser ver a mecânica em relação ao seu próprio mapa de domínios, comece com a visão geral da funcionalidade de notificações push web e os planos de preços. Os planos pagos incluem uma garantia de devolução do dinheiro em 14 dias, pelo que a arquitetura pode provar o seu valor no seu tráfego antes de a decisão ser final.
