Cada dólar gasto em aquisição paga de usuários é tão inteligente quanto os dados de atribuição que o julgam. Se você investe no canal errado, não perde só esse dólar — você alimenta o algoritmo com um sinal pior e ele encontra mais do mesmo para você. A camada de medição não é um assunto de back-office. É o painel de instrumentos de todo o motor de crescimento.

E é exatamente aí que a abordagem «WebView primeiro» quebra em silêncio.

As fissuras ficam onde o app nativo encontra a web

Quando um app de tráfego roda sua jornada central — cadastro, compra, indicação — dentro de um WebView apontado para um documento remoto, os analíticos não fluem por um cano limpo. Eles caem na costura entre dois mundos.

O Google Analytics 4 deixa isso concreto. Um app nativo e um WebView dentro do app são medidos por dois fluxos de dados diferentes: um App Data Stream e um Web Data Stream. Por padrão, o GA4 não unifica sessões nem usuários entre eles. No momento em que o usuário passa de uma tela nativa para o WebView e volta, a sessão se divide. O app nativo identifica a pessoa por um App Instance ID; o WebView a identifica por um Client ID. A menos que todos façam login e você conecte o User-ID, a mesma pessoa é contada como duas. O tráfego anônimo — a maioria no topo do funil — é duplicado por design.

Na fronteira com o mundo exterior, piora. Cada navegador dentro do app é, na prática, uma janela de navegação anônima nova que esquece tudo ao fechar. Cookies de terceiros costumam ser bloqueados sumariamente. O app que referencia frequentemente elimina o HTTP referrer antes de carregar a página. O resultado, bem documentado por analistas, é que boa parte do tráfico WebView dentro do app aparece nos relatórios como «(direct) / (none)» — como se esses usuários tivessem decorado sua URL. Sua linha de tráfego direto é inflada em silêncio, e a campanha social ou de e-mail que realmente os enviou não recebe crédito algum.

Por que a distorção chega ao resultado

Isso não é uma curiosidade de relatório. Chega às decisões de orçamento.

A atribuição de último clique já sobre-credita o último toque e sub-credita o canal que fez o trabalho duro de criar intenção. O próprio CEO da AppsFlyer chamou a atribuição de último clique de «uma grande mentira», e pesquisas da indústria ainda encontram 45–75% dos profissionais de marketing dependendo dela. Some um WebView que perde referrers e divide sessões por cima disso, e a distorção se compõe: canais que trazem instalações baratas parecem eficientes, canais que trazem instalações caras com alto valor de vida útil parecem desperdício, e o orçamento migra exatamente na direção errada.

O desperdício não é hipotético. No Q1 de 2024, 23% do tráfico móvel programático dentro do app foi classificado como inválido — cerca de 1,4 bilhão de dólares em gastos desperdiçados em um único trimestre. Você não pode se defender do que seu próprio painel não consegue ver.

Há um segundo custo, mais silencioso: os experimentos. Testes A/B, rastreamento de loops de indicação e análise de coortes presumem uma identidade estável por usuário. Quando a mesma pessoa vira duas, seu grupo de controle é contaminado e seu coeficiente viral se torna incognoscível. Você está otimizando contra o ruído.

O que muda um runtime próprio do host

A solução não é um painel melhor parafusado em um cano com vazamento. É tirar a jornada do WebView ingovernável e movê-la para um runtime que o host controla.

Um runtime próprio do host roda o mini-programa como um componente de primeira parte dentro do app, não como um documento remoto dentro de um shell de navegador. A instrumentação vive em um único limite confiável: os eventos não se perdem na costura nativo↔web, as sessões não se dividem por um descompasso de fluxo, e os referrers não são eliminados por um navegador que você não opera. O host mantém seu próprio registro de eventos de primeira parte — limpo, completo e conciliável com a receita do backend — em vez de confiar que um contêiner de terceiros informe o que aconteceu dentro dele.

Essa única mudança restaura três coisas que as equipes de crescimento precisam desesperadamente: uma identidade estável por usuário, uma sessão ininterrupta ao longo de toda a jornada, e a soberania de dados sobre o comportamento que ocorre dentro do seu próprio produto.

Medição WebView vs. medição runtime

Modo de falhaWebView / H5Runtime próprio do host
Identidade de sessãoApp Instance ID ≠ WebView Client ID; usuários anônimos duplicadosUma identidade de primeira parte única em toda a jornada
Referrer e cookiesEliminados na fronteira do navegador dentro do app; o tráfico cai em (direct)/(none)Preservados dentro do próprio limite do host
Perda de eventosEventos perdidos na costura nativo↔web; eventos automáticos podem não dispararEventos capturados em uma única rota de instrumentação confiável
Soberania de dadosO comportamento é informado por um contêiner de terceiros que você não controlaRegistro de eventos de primeira parte detido e conciliável pelo host
Integridade de experimentosGrupos de controle contaminados, coeficiente viral incognoscívelIdentidade estável habilita A/B e análise de coortes limpas

O ponto não é que os WebView sejam malignos. É que cada camada que você não controla é uma camada onde sua medição pode mentir em silêncio. Para um app de tráfego cuja estratégia inteira é «comprar usuários com eficiência e retê-los», rodar a jornada dentro do shell de navegador de outra pessoa é entregar o painel de instrumentos a uma caixa preta.

Possua o runtime, e você possui a verdade sobre se seu motor de crescimento realmente funciona.

Fontes