10 milhões de usuários e quase nenhuma receita

Depois de duas doses, muitos fundadores te contam a mesma história: «Chegamos a um milhão de DAU. Por lógica já devíamos ser ricos». Aí abrem o painel e a linha de receita está basicamente reta.

Esse filme eu já vi umas vinte vezes. Um app de utilidades, um app de conteúdo, algo com olhos de verdade em cima — e um motor de monetização que parece colado com fita adesiva. O instinto é sempre o mesmo: enfia um H5 lá dentro, linka pra algum afiliado ou pra um caixa de terceiro, e chama de «e-commerce». E aí não acontece nada, porque o H5 nunca teve a intenção de fechar esse ciclo por você.

O vazamento que você não vê no painel

Tem uma coisa que ninguém bota no deck de investidor. Quando você embute um H5 de terceiro para «vender algo», o usuário entra, é jogado num caixa que não é seu, paga outro, e fecha a aba. Você capturou o olhar. Não capturou mais nada. A transação —e os dados, e o relacionamento— vivem com o terceiro. Seu app é um corredor por onde a gente passa para entrar na loja de outro.

O mini-programa vira isso do avesso. Roda dentro do seu próprio runtime: o mesmo login, a mesma carteira, o mesmo canal de notificação que você controla. A venda acontece na sua casa. O recibo, o re-engagement, a próxima oferta —tudo fica com você. Esse é o jogo inteiro de um app de tráfego. Não é «consigo mostrar um produto a eles?», é «consigo ser dono da transação?».

Por que o H5 mata a conversão (e você culpa tudo o mais)

É a velocidade, principalmente. Cada abertura de H5 baixa recursos, dá voltas, espera scripts. Num fluxo de pagamento isso é fatal: a gente sai no primeiro tropeço. E tem o imposto da confiança: uma página web dentro do seu app que de repente pede um número de cartão parece phishing para um humano normal. Fecham. Você culpa a criatividade. Era o contêiner.

Os mini-programas pré-carregam e usam componentes nativos. O pagamento parece parte do seu app, porque é. As taxas de conclusão que davam vergonha no H5 param de dar.

Pra onde o dinheiro vai de verdade

Para onde vai o dinheiro	Mini-programa (runtime do host)	H5 (página WebView)
A transação	Fecha no seu app, é sua	Rebote pra um caixa de terceiro, não é sua
Os dados do usuário	Ficam no seu runtime	Estão com o terceiro
O re-engagement	O centro de mensagens do host lembra	Cortado ao fechar; não sabe quem foi
A composição	Cada serviço sobe o ARPU	Cem links seguem sendo cem links

Cem links não são um negócio

O mais brutal: mesmo que o H5 «funcione», ele não composta. Cada página é uma ilha isolada. Você pode embutir cem e ainda tem cem ilhas, sem catálogo, sem controle de qualidade, sem comissão. O usuário vê um cardápio de estranhos.

Um catálogo de mini-programas é o oposto. Terceiros desenvolvem sobre seu runtime; você põe as regras, cobra sua parte, e fiscaliza a experiência. Cada serviço novo faz os usuários existentes valerem mais —mais motivos para abrir o app, mais superfícies para converter, ARPU maior—. Composta. O H5 te mostra uma placa; o catálogo te constrói um shopping que é seu.

O que as super-apps entenderam há uma década

Vai ver o que as grandes super-apps asiáticas realmente fizeram. Elas não «embutiram sites». Construíram um runtime e deixaram milhares de comerciantes rodarem dentro, levando uma fatia de cada transação. Foi de lá que veio a valorização —não dos olhos, mas da camada de comércio em cima dos olhos. Um app de tráfego que só vende atenção está alugando a própria audiência. Um app de tráfego com runtime está vendendo o espaço na prateleira, pra sempre.

Um limite honesto

Se sua meta é uma campanha de uma vez —levar tráfego, converter uma vez, esquecer— o H5 é bom e barato. Todo esse argumento é pra apps que querem que o usuário volte e gaste de novo. Pra essas, o contêiner tem que ser um runtime, porque a receita só composta quando a transação é sua.

Você não tem um problema de tráfego. Você tem um problema de «o dinheiro escapa antes de ser seu».