Quase todo time de apps de consumo comete um erro contábil silencioso no primeiro ano. O dashboard diz um milhão de usuários. O instinto é tratar isso como um milhão de ativos. Não é. Se esses usuários chegam a um serviço através de uma página web de terceiros embutida, o que você possui é um corredor, não as salas atrás dele.
Vamos tornar o mecanismo concreto, porque a perda é técnica, não retórica.
Quando você enfia um H5 de terceiros num webview, essa página roda na origem do provedor. Seus cookies, seu armazenamento local, sua sessão: tudo pertence a eles, não a você. A identidade que o usuário estabelece dentro desse fluxo é do provedor. Os dados da transação caem nos sistemas do provedor. O relacionamento pós-compra — reembolsos, reativação, a próxima oferta — também vive lá. Você capturou o clique. Não capturou nada que componha.
Esta é a diferença entre tráfego e ativo, e a maioria dos times só percebe quando tenta ativar a audiência uma segunda vez e descobre que não consegue.
O que você realmente possui, lado a lado
| Dimensão | H5 de terceros embutido | Runtime de mini-programa (do host) |
|---|---|---|
| Identidade | A origem do provedor possui a sessão | Sistema de contas próprio do host |
| Propriedade de dados | Fica com o terceiro | Acumula no repositório do host |
| Reativação | Cortada ao fechar a aba | O canal de mensageria do host recupera |
| Grafo de relacionamento | Pertence ao serviço embutido | O host possui o grafo do usuário |
| Postura regulatória | O host pode não ser o controlador | O host é controlador de primeira parte |
| Portabilidade | Bloqueada no terceiro | Controlada pelo host, portável |
O custo aparece em três lugares.
Primeiro, a reativação. Uma sessão webview termina quando o usuário a fecha. Você não tem um canal durável de volta para aquela pessoa; o provedor tem. Da próxima vez que quiser dizer «seu pedido saiu» ou «aqui está um benefício», você está pedindo permissão ao provedor, ou comprando a audiência de novo com anúncios que já pagou uma vez para adquirir.
Segundo, o grafo de dados. O relacionamento entre um usuário e um serviço — o que comprou, com que frequência, o que abandonou — é o conjunto de dados mais valioso que um negócio de consumo produz. Num H5 de terceiros, esse grafo pertence ao serviço embutido. Você vê um agregado que não controla. Um runtime do host escreve cada evento no repositório próprio do host, então o grafo compõe dentro do seu negócio.
Terceiro, e este é o que os times subestimam, a exposição regulatória. Sob marcos como o GDPR da UE, a LGPD do Brasil e a Lei DPDP da Índia de 2023, a questão de quem é o controlador ou fiduciário de dados não é acadêmica. Quando um terceiro processa dados de usuários dentro do seu app, você pode não ser o controlador — o que significa que entregou tanto o controle quanto a responsabilidade pela parte mais sensível da operação, enquanto ainda carrega o risco de marca quando algo dá errado.
Nada disso significa que o H5 seja inútil. Para uma campanha de uma só vez — trazer tráfego, converter uma vez, esquecer — uma página embutida é barata e funciona. O erro é tratá-la como infraestrutura. Infraestrutura é o que você possui. Uma vitrine alugada não.
Esta é a parte que os super-apps entenderam há uma década, e vale dizer claro porque é a verdadeira fonte de suas valuations. WeChat, Alipay, Grab, Gojek não construíram «sites em que você clica». Eles construíram identidade, uma carteira e um canal de mensageria como infraestrutura própria, e então deixaram milhares de comercios rodarem dentro desse runtime. A camada de comércio se apoiava em um relacionamento que a plataforma controlava ponta a ponta. Os olhos nunca foram o ativo. O relacionamento controlado sim.
Um runtime de mini-programa é o mecanismo que reproduz essa estrutura sem reconstruir um super-app do zero. Quando os serviços rodam dentro do runtime do host, o host fornece identidade, carteira e notificação — então cada interação é escrita nas contas próprias do host, não nas do provedor. O usuário vira um registro que você tem, não um visitante que o provedor registra.
Quero refutar uma versão romântica disso. Controlar o runtime não significa «possuir o usuário» no sentido extrativo, o lock-in pelo lock-in. A vantagem durável é mais estreita e mais sustentável: converte um relacionamento que você alugava, e que podia perder no momento em que o provedor mudasse os termos ou fosse retirado da loja, em um ativo que sobrevive a esses choques porque vive nos seus sistemas. Você deixa de ser um fornecedor de tráfego que aluga sua audiência ao serviço de outro, e passa a ser uma plataforma que possui a prateleira, o caixa e a lista de clientes.
Esta é a linha real. O tráfego se aluga. Os ativos se possuem. Um runtime é como você passa de uma coluna para a outra.
