Base de instalações de PWA em iGaming: o ativo que sobrevive à sua conta de anúncios

Quando um media buyer conta um PWA, ele conta um funil: clique, instalação, cadastro, depósito. O bundle morre e, na cabeça dele, tudo morre junto. Mas as instalações não morrem com a conta de anúncios. O ícone fica no celular, a inscrição de push continua ativa, e esse é o único elo da cadeia que continua funcionando depois que a campanha para. A questão é a que ele está preso, porque é isso que acaba decidindo tudo.

O que realmente sobrevive quando o bundle morre

A sua conta de anúncios, o criativo e o pixel vivem todos na infraestrutura de outra pessoa. Podem ser tirados de você sem aviso. Um PWA instalado fica no aparelho do usuário: o Facebook não consegue banir um ícone no celular de alguém.

Junto com a instalação você ganha uma segunda coisa que quase ninguém conta separadamente: a permissão para enviar notificações push. É um canal até uma pessoa real pelo qual você já não paga por clique. Ele não depende do leilão, da moderação nem de quanto custa um depósito naquele GEO nesta semana.

Uma ressalva honesta antes que o otimismo dispare. O ícone está fora de alcance, mas o domínio de onde o app foi instalado não está. Ele fica a um redirect atrás do anúncio, um moderador que percorrer o anúncio vai chegar até ele, e ele pode ser bloqueado como qualquer outro domínio. O que sobrevive a uma conta de anúncios morta não sobrevive automaticamente a um domínio morto, e essa diferença é todo o assunto da próxima seção.

Os números

Num lançamento na Argentina, o funil ficou assim: 5.938 usuários únicos, 2.938 instalações (cerca de 50%), 1.007 inscrições de push, 958 cadastros, 130 primeiros depósitos. Spend de $1.620, receita de $2.340, ROI de 44%.

Agora leia os mesmos números por outro ângulo. A campanha terminou, o spend parou, e sobraram 1.007 inscrições. É um público do tamanho de um terço de todas as instalações, alcançável amanhã, na semana que vem e no mês que vem sem pagar mais um centavo ao Facebook.

A mesma linha também mostra o gargalo. Foram 2.938 instalações e 1.007 inscrições. Cerca de dois terços da base nunca se tornaram alcançáveis, e não porque o tráfego fosse ruim.

A restrição que ninguém coloca na conta: um PWA está preso à sua origem

Este é o fato técnico sobre o qual todo o ativo se apoia, e é o que menos se diz em voz alta. Um PWA pertence à origem de onde foi instalado. O manifest, o service worker, o ícone na tela inicial e a inscrição de push vivem todos naquele domínio específico. Não há exportação, nem migração, nem transferência. Uma base não pode ser movida para outro domínio em nenhuma circunstância.

Disso decorrem duas consequências, e as duas são caras.

Troque o domínio e você não move a base, você começa uma segunda do zero. Tudo o que foi instalado a partir do domínio antigo fica no domínio antigo. Se esse domínio antigo sair do ar, cada uma dessas instalações quebra e cada inscrição ligada a ele fica em silêncio, para sempre.

E se o domínio por trás de uma base viva for bloqueado em vez de aposentado, a base não fica danificada, ela some. Não “mais difícil de alcançar”, não “parcialmente recuperável”. Some.

Isso coloca o domínio por trás de uma base de instalações numa posição realmente incômoda. Domínios nesta vertical queimam, e a resposta habitual é tratá-los como consumíveis e renová-los. Mas o domínio que guarda a sua base não é consumível, porque a base é o domínio. O que significa que a decisão real não é com que frequência trocar, é quanto histórico você está disposto a acumular num domínio que não pode se dar ao luxo de perder, e essa é uma troca que vale a pena fazer de forma deliberada, em vez de descobri-la depois do fato.

Por que a base morre antes do tráfego

Três motivos, e nenhum deles tem a ver com a qualidade do tráfego.

Rotatividade de domínios, conforme a seção acima. A forma mais comum de uma base desaparecer é alguém aposentar um domínio queimado sem perceber que o público estava guardado nele.

Um PWA por rodada de tráfego. Se cada bundle ganha o próprio build, o próprio domínio e o próprio pool de inscrições, você não acaba com uma base. Acaba com uma dúzia de fragmentos de 200 a 300 contatos cada, nenhum dos quais tem a massa crítica para valer o trabalho.

Nenhum motivo para voltar além de um bônus. Um push dizendo “resgate 100 rodadas grátis” no terceiro dia após a instalação funciona uma vez. Depois disso é silenciado ou ignorado, e o canal se esgota mais rápido do que a conta de anúncios.

Onde a permissão de push realmente se perde

Esta é a parte descrita errado com mais frequência do que qualquer outra coisa nos funis de PWA, inclusive por quem vende as ferramentas.

Você só pode pedir a permissão de notificação enquanto a pessoa está na sua própria página. Isso não é uma escolha de design, é como o navegador funciona. Depois da instalação, o usuário vai para a oferta, e a oferta é o site de outra pessoa: lá você não existe. No momento do cadastro, no momento do primeiro depósito, você não está na tela, então ninguém pode pedir a permissão nessa hora. Qualquer conselho construído em cima de “peça depois que ele se cadastrar” descreve algo que não pode acontecer.

O que deixa exatamente dois momentos que são seus. O primeiro é a própria instalação, quando a pessoa não viu quase nada e tem o menor motivo para dizer sim. O segundo é uma abertura pelo ícone: a abertura do app é a sua origem de novo, e é um momento muito melhor, porque uma reabertura significa que a pessoa voltou por conta própria.

Então a versão prática é: não gaste a sua única chance na hora da instalação. Peça numa abertura pelo ícone, de preferência não na primeira, para que a primeira abertura continue instantânea e leve o usuário aonde ele queria ir.

Há um custo envolvido, e vale nomeá-lo. Se a abertura pelo ícone redireciona direto para a oferta sem renderizar um único byte seu, você não tem nenhuma tela em que pedir, e o segundo momento também não existe. Trazer essa tela de volta deixa a abertura um pouco mais lenta. Essa tela é o preço de ter uma base, e nos números da Argentina ela é a diferença entre 1.007 pessoas alcançáveis e 2.938.

A direção aqui está bem estabelecida: um pedido de permissão depois de algum engajamento converte bem melhor do que um pedido frio no primeiro contato. Deliberadamente não colocamos porcentagens nisso, porque a resposta honesta é que depende do seu funil, e você deve medir no seu próprio tráfego em vez de herdar o número de outra pessoa.

Onde se esconde a economia real

Um ponto de referência do mercado: em lançamentos no Uzbequistão, o install-to-registration fica em 10 a 12%, uma instalação pode ser obtida de forma realista por um dólar, e os jogadores depositam repetidas vezes. Com esse preço de entrada, uma base de alguns milhares de instalações custa alguns milhares de dólares uma única vez, e você pode falar com ela quantas vezes quiser.

Um segundo ponto de referência mostra o quanto essa economia é frágil. Na mesma oferta, com os mesmos criativos e as mesmas campanhas, trocar o serviço de PWA elevou o install-to-registration no iOS de 10% para 39%. Todo o resto era idêntico. Metade da sua base pode simplesmente não existir porque a plataforma técnica por baixo dela rende pior do que parece numa demo.

Sinais de que a sua base de instalações está funcionando (ou não)

Está funcionando se:

• você consegue dizer o seu opt-in de push como fração das instalações, e é um número que você moveu de propósito;
• você sabe quantos depósitos vieram do push, contados separadamente dos depósitos da rodada de tráfego;
• domínios que carregam uma base viva são tratados como de longa duração e nunca são tirados do ar de qualquer jeito;
• um bundle novo começa com uma base existente, e não do zero.

Não está funcionando se:

• a sua única métrica de push é “enviados”;
• a base está fatiada entre bundles e nunca é consolidada em lugar nenhum;
• nada chega da base quando o spend para;
• você não sabe dizer quantas inscrições ativas tem neste momento.

Resumo

• Um PWA te dá duas coisas, e os times costumam contar só a primeira: o funil do clique ao depósito, que vive tanto quanto a conta de anúncios, e a base de instalações com permissão para contatá-la, que continua funcionando depois que o spend para.
• A base está presa à origem de onde foi instalada. Não pode ser movida, trocar o domínio começa uma base nova em vez de realocar a antiga, e perder esse domínio destrói a base por completo.
• A permissão só pode ser pedida na sua própria página, então a oferta, o cadastro e o depósito são todos momentos em que pedir é impossível.
• O momento útil é uma abertura pelo ícone, e não a instalação, o que significa manter uma tela sua na abertura em vez de redirecionar direto.
• Fragmentar um PWA por bundle produz fragmentos, não uma base.
• Se você não consegue dizer agora o tamanho da sua base, você não tem uma.

Nossos media buyers pediram, então construímos: um construtor de PWA feito para o uso diário, rápido e simples, sem nada a mais no caminho. Há uma promoção rolando agora: instalações grátis nos dois primeiros meses. Fale com a gente enquanto ela dura.

Você também pode gostar

• PWA como funil para iGaming BlackHat em 2026: cloaking, tracking, FTD e erros críticos
• App, PWA e WebView: explicado de forma simples para media buyers
• Por que os dados do tracker não batem com o Facebook