Seu portfólio provavelmente se parece com isto: um sportsbook principal no .com, uma marca regional licenciada no .ca, um white-label de cassino que você lançou na primavera passada e um rebranding planejado para o Q4. Uma equipe de retenção é dona de tudo isso. E se você gerencia web push em múltiplos domínios da maneira padrão, você também possui quatro listas de assinantes desconectadas, cada uma crescendo por conta própria, nenhuma delas se comunicando com as outras.
Essa fragmentação não é um erro de configuração que você cometeu. É assim que a arquitetura de push da web funciona. O navegador anexa cada assinatura a um único domínio, e nenhuma configuração de painel muda isso.
Existe, no entanto, uma maneira suportada de contornar isso. Este artigo cobre a mecânica: por que uma assinatura de web push está vinculada a uma origem, o que realmente sobrevive a uma mudança de domínio (mais do que você pensa), o que quebra (menos do que você teme, mas a parte que se acumula) e a arquitetura de origem estável que cria uma lista de assinantes em todas as marcas que você gerencia hoje e em todas as marcas que você lançar no futuro.
Por que uma assinatura de web push está vinculada a um domínio
Quando um visitante clica em Permitir, o navegador não o assina à sua marca. Ele o assina a uma origem: o protocolo e o nome do host exatos na barra de endereços. A API Push cria a assinatura contra um service worker registrado nessa origem, usando a chave do servidor de aplicação da sua plataforma. O registro 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 criptografia (p256dh e auth) que bloqueiam payloads para aquele navegador específico.
A permissão de notificação segue a mesma regra. Ela é concedida por origem, não por empresa. sportsbook.com e sportsbook.ca são estranhos no nível do protocolo, mesmo que compartilhem um logotipo, uma carteira e um banco de dados de jogadores. Cada um solicita separadamente, assina 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 assinatura 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 sua plataforma de envio detém. A assinatura é criada sob a chave pública, e o serviço de push aceita um envio apenas quando é autenticado com a chave privada correspondente. Sua plataforma prova que detém o par de chaves em cada envio; o próprio registro de assinatura carrega apenas a metade pública.
O navegador também impõe uma assinatura por origem. Chamar subscribe novamente com uma chave de servidor de aplicação diferente falha até que a assinatura existente seja removida. Essa restrição importa mais tarde, quando chegarmos à consolidação: na mesma origem, um novo service worker pode assumir um assinante existente silenciosamente. Entre origens, isso nunca é possível.
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 equipes erra em uma migração de domínio: elas assumem que a lista antiga morre. Ela não morre. Inscritos que optaram pelo domínio antigo continuam recebendo suas notificações.
A entrega nunca toca seu site. Quando você envia, sua plataforma faz uma solicitação autenticada com suas chaves VAPID para o serviço de push que detém cada inscrição (o do Google para Chrome, o da Mozilla para Firefox, o da Apple para Safari), e esse serviço entrega o payload criptografado ao service worker já instalado no navegador do assinante. O domínio antigo pode ser redirecionado, estacionado ou ter desaparecido completamente. A notificação ainda chega.
O destino do clique também é seu. Os URLs de clique são definidos por campanha, então um assinante que optou por um domínio que você aposentou há dois anos pode clicar na notificação de hoje e pousar no site ativo de hoje.
| Após uma mudança de domínio | Ainda funciona? |
|---|---|
| Entrega para assinantes existentes | Sim — os pushes são roteados através dos serviços de push dos fornecedores de navegador, 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 |
| Assinantes do antigo domínio entrando automaticamente na lista do novo domínio | Não — a permissão é por origem, então entrar na nova lista é um novo opt-in |
| Novos cadastros na antiga origem | Não — e essa é a perda que se acumula |
Portanto, uma migração de domínio não lhe custa os assinantes que você tem. Ela custa a máquina que os produzia. No dia em que o tráfego muda, a captura de cadastros no novo domínio reinicia do zero enquanto a lista antiga decai lentamente. Execute isso em um portfólio de marcas e cada propriedade está pagando esse imposto de reinício independentemente.
O custo real: cada novo domínio começa sua lista do zero
A captura fragmentada seria um incômodo em um canal de baixo churn. Apostas não é um canal de baixo churn. Entre sites de apostas e jogos no PushEngage, em uma janela de 90 dias, os cancelamentos de inscrição apagaram aproximadamente 91% da aquisição de novos assinantes em todo o segmento. Uma lista nesse vertical é uma banheira com a torneira aberta; a única coisa que mantém o nível é a torneira funcionando continuamente.
A fragmentação desliga a torneira, uma propriedade por vez. A lista de cada marca só cresce enquanto esse domínio específico obtém opt-ins. Uma migração reinicia sua torneira para zero. Um novo white-label começa do zero. Enquanto isso, os navegadores continuam drenando: a revogação automática de permissão do Chrome, anunciada em outubro de 2025, remove silenciosamente a permissão de notificação de sites com engajamento muito baixo e alto volume de notificações. Uma lista que não está capturando não está estável. Ela está encolhendo.
O enquadramento do CAC torna as apostas claras. Você pagou para adquirir cada um desses visitantes, e o opt-in é o único ativo de retargeting durável que a visita deixa para trás. O caso para push neste vertical repousa sobre a acumulação desse ativo. A fragmentação anula parte dele toda vez que um domínio muda.
A arquitetura de origem estável: um domínio de inscrição para cada marca
A correção é parar de criar assinaturas em domínios de marca. Ancore cada assinatura a uma única origem HTTPS estável que seu grupo controla, uma que sobreviverá a qualquer domínio de marca individual, e deixe que cada propriedade a alimente.
O PushEngage oferece isso como o fluxo de subdomínio personalizado, criado exatamente para este caso: vários domínios que precisam de administração unificada de assinantes sob um domínio controlado. A configuração:
- Escolha uma origem estável e neutra em relação à marca que você possui, como
notify.yourbrandgroup.com. Escolha um nome que você goste que os assinantes vejam, pois os navegadores exibem a origem da assinatura nas notificações. - Faça o upload do arquivo service worker do PushEngage para a raiz desse domínio e ative o recurso em Configurações do Site » Configurações Avançadas. A origem estável terá 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 participar em qualquer um deles, o fluxo é roteado pela origem estável, onde a assinatura real é criada.
Dois requisitos são inegociáveis neste modo. Primeiro, o opt-in é apenas de duas etapas: o prompt de permissão do navegador deve ser acionado na origem que possui a assinatura, portanto, um prompt nativo de uma etapa no domínio da marca não é possível. Segundo, a Instalação Rápida permanece ativada.
Seja honesto sobre a troca. O modo de duas etapas adiciona um clique antes do prompt de permissão e converte menos no momento da captura. Vale a pena ler junto com as alavancas mais amplas para aumentar sua taxa de opt-in. Mas um assinante de uma etapa capturado em um domínio que você migrar posteriormente é um ativo depreciado. Um assinante de duas etapas na origem estável sobrevive a todas as reformulações de marca, lançamentos regionais e migrações que você executar. Em qualquer horizonte que inclua uma mudança de domínio, a lista consolidada vence em alcance total.
Notificações push para vários sites, uma lista de assinantes
Uma vez que a origem estável esteja em vigor, as notificações push para vários sites deixam de significar várias listas. Cada domínio de marca alimenta a mesma base de assinantes. Lançar um novo domínio regional ou white-label no próximo trimestre significa adicionar o snippet; seus opt-ins caem na lista consolidada desde o primeiro dia. Aposentar um domínio não significa nada para a lista: a captura continua nas propriedades sobreviventes, a entrega continua através dos serviços de push e os URLs de clique apontam para onde você estiver ativo.
Consolidando as listas de assinantes que você já fragmentou
A maioria dos operadores chega a essa arquitetura com histórico: listas ativas espalhadas por domínios antigos, algumas dormentes, outras em outro fornecedor. A consolidação ocorre em três trilhas em paralelo.
| Trilha | O que você faz | O que isso te traz |
|---|---|---|
| 1. Mantenha as listas antigas funcionando | Continue enviando para cada lista de origem antiga; aponte os URLs de clique para o domínio ativo atual | O alcance pago continua produzindo sessões em vez de ser descartado |
| 2. Capture novos na origem estável | Mude o opt-in de cada propriedade ativa para o fluxo da origem estável | A fragmentação para no dia em que é implementada; toda nova aquisição cai em uma lista |
| 3. Deixe as listas antigas se auto-organizarem | Cada envio para uma lista antiga direciona uma revisita a um domínio atual, onde o prompt de origem estável aguarda | Assinantes ativos se consolidam, sem re-permissão forçada |
O Rastreamento 3 é o cavalo de batalha silencioso. A permissão do navegador é por origem, então assinantes de origem antiga tecnicamente precisam de um novo opt-in para entrar na lista consolidada, mas você nunca precisa exigi-lo. Dado a rapidez com que os públicos de apostas ciclam, a lista consolidada se torna a maioria do seu alcance ativo em meses, simplesmente porque os jogadores ativos continuam visitando.
Se alguns fragmentos residem com outro fornecedor de push em um domínio que você possui, eles também podem vir. O caminho padrão do PushEngage é uma re-inscrição silenciosa: na próxima visita de um assinante, o service worker de notificação push do SDK assume e os reinscreve sem um segundo prompt de permissão, porque a permissão em nível de origem persiste. Para o OneSignal, o PushEngage pode buscar a lista diretamente através da API do OneSignal. A migração é premium e gratuita em 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 poderiam gerenciar.
Capture a marca de origem como um atributo do assinante no momento do opt-in, 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 post #1 descreve no guia 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 cassino vai para seus jogadores; um alerta de jogo em todo o portfólio vai para todos 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 site de apostas vê ~2,1% de CTR 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 você não pode construir coortes comportamentais em quatro fragmentos desconectados. A consolidação é o que torna a segmentação como prática de entregabilidade viável em escala de portfólio. Isso importa mais agora que o Chrome pontua todas as origens de envio diariamente e limita remetentes disruptivos (ao vivo desde janeiro de 2026). Uma origem estável concentra 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 é um recurso, não uma nota de rodapé. Um jogador autoexcluído suprimido em um segmento de portfólio é suprimido em todos os lugares de uma vez, não marca por marca onde um fragmento pode passar despercebido. Horários de silêncio e limites de frequência se aplicam no nível do assinante 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 regressiva em prompts de depósito.
Execute push da web em vários domínios sem dividir sua lista
Toda a configuração é menor do que parece: um registro DNS para a origem estável, o arquivo do service worker em sua raiz, o alternador em Configurações Avançadas, o snippet isSubscriptionOnSubDomain e o snippet padrão em cada domínio de marca com opt-in de dois passos configurado e Instalação Rápida ativada. As equipes geralmente o lançam no mesmo dia, sem replataformar. Esse é todo o esforço para gerenciar notificações push para vários sites a partir de uma origem.
O que você recebe de volta é o que a fragmentação de coisas impõe silenciosamente: uma lista de assinantes que se acumula. Cada marca contribui, cada mudança de domínio é refletida nela, e cada campanha pode segmentar todo o portfólio ou uma marca por vez. Se você quiser ver a mecânica em relação ao seu próprio mapa de domínio, comece com a visão geral do recurso de notificações push da web e os planos de preços. Os planos pagos oferecem uma garantia de devolução do dinheiro em 14 dias, para que a arquitetura possa provar seu valor em seu tráfego antes que a decisão seja final.
