O que acontece com um link de app aberto dentro do Instagram e do TikTok: 74,000 redirecionamentos medidos

Estes números vêm dos logs de redirecionamento de um serviço de links inteligentes: uma URL que manda o celular para a App Store ou para o Google Play. Toda vez que um link é aberto dentro de um app social, servimos uma pequena página que encaminha o visitante para a loja, e essa página informa o que aconteceu em seguida. Abaixo está o que esses relatos dizem, como os medimos e onde a medição para.

Os dados

Duas coisas chamam a atenção antes de qualquer análise. Os apps da Meta mandam muito mais tráfego que o TikTok. E, no Android, mais de três quartos de todas as chegadas vêm de um navegador in-app, não do Chrome.

Como a página informa o que aconteceu

Quando um link é aberto dentro de um navegador in-app, a página faz três coisas e envia um beacon para cada uma:

• auto: ela inicia o encaminhamento para a loja ao carregar (iOS: location.replace para a URL da App Store; Android: uma URL intent:// que abre o app nativo da Play Store).
• exit: a página fica oculta (Page Visibility API). É o melhor sinal que uma página web tem de que outra coisa, muito provavelmente a loja, tomou conta da tela.
• stuck: a página ainda está visível 2.2 segundos depois do encaminhamento, então revela um cartão de reserva com um botão da loja, uma dica “abra no seu navegador” e um botão para copiar o link.

Uma página web não enxerga a App Store nem a Play Store. Tudo o que vem abaixo é inferido desses três sinais, e a seção de limites diz onde essa inferência deixa de valer.

Descoberta 1: cerca de 1 em cada 11 chegadas Android da Meta é um pré-carregamento que ninguém viu

Nos 30 dias até 12 de outubro, um grupo nítido de sessões Android se comportou como nenhuma visita humana se comportaria: a página carregou, o timer de encaminhamento nunca rodou e a página foi destruída 29 a 31 segundos depois. Nenhum auto, nenhum stuck, nenhum toque. O iOS não mostrou nada parecido.

Essa é a assinatura do navegador in-app do Instagram e do Facebook pré-carregando um link que está no feed, mantendo-o oculto e jogando-o fora quando o usuário continua rolando. A página executou nosso JavaScript, então a chegada foi registrada. Ninguém jamais olhou para ela.

Testamos o critério em sessões claramente humanas: 0 de 17,606 sessões em que a loja abriu 2–3 s depois do encaminhamento se encaixaram nele, e 0 de 244 sessões em que alguém tocou no botão da loja também não.

A participação varia de semana para semana: 6.8% na última semana desse período, e 8.8%, 10.6% e 10.0% nas semanas anteriores. Ela também se concentra onde rodam campanhas pagas no Instagram: 72% dos pré-carregamentos do período vieram de um único link por trás de uma grande campanha no Instagram.

Desde 16 de outubro, a própria página classifica isso em tempo de execução: ela informa um pré-carregamento em vez de uma saída quando morre depois de pelo menos 20 s sem nunca ter sido exibida. Eis o que ela captou desde então:

Essa contagem em tempo de execução é um piso. Um pré-carregamento que morre sem executar nenhum script não deixa beacon, e a regra em tempo de execução é mais rígida que a reconstrução histórica.

Por que isso importa. Se você conta cliques no seu redirecionamento, mais ou menos um em cada 13 “cliques” do Instagram no Android nunca foi visto por uma pessoa. Sua taxa de clique para instalação nesse canal parece pior do que é, e um dashboard de campanha baseado em acessos brutos ao redirecionamento superestima o alcance mais ou menos nessa proporção.

Descoberta 2: o TikTok recusa a Play Store dependendo do webview que usa

Dentro do TikTok no Android, parte dos visitantes nunca sai da página: o encaminhamento dispara e o TikTok mostra o próprio diálogo (“The action cannot be completed”). Não acontece em todo link e, por semanas, pareceu depender do link. Não depende. Depende do navegador in-app que o TikTok usa para aquele visitante, e o user-agent o denuncia:

Uma sessão conta como sucesso quando o encaminhamento disparou e a página ficou oculta, e como falha quando o cartão de reserva apareceu. A taxa é sucesso / (sucesso + falha), por aparelho e por dia:

A comparação que resolve a questão mantém o link e o dia constantes, já que a mistura de formatos muda de semana para semana:

Mesmo link, mesmo código de redirecionamento, mesmo dia: um webview deixa a loja abrir e o outro, na maioria das vezes, não. Domínios próprios não fizeram diferença nos dados de 90 dias. O TikTok não documenta o diálogo, o que o dispara nem quais usuários recebem qual webview, então a divisão por user-agent é tudo o que existe.

Por que isso importa. Nenhum formato de URL resolve isso: a saída por intent:// e uma URL https://play.google.com simples recebem a mesma recusa. O que você pode fazer é não esconder a saída: dentro do TikTok, mostre na hora as instruções “abrir no navegador” e um botão de copiar, em vez de esperar um tempo limite.

Descoberta 3: no iOS, a App Store abre por cima do navegador in-app

No Android, depois do encaminhamento, a página fica oculta na maioria das sessões, normalmente 1 a 3 segundos depois. No iOS, dentro do Instagram e do Facebook, muitas vezes isso não acontece, mesmo com o encaminhamento disparado em quase todas as sessões:

Se dois terços dos visitantes de iOS estivessem mesmo presos diante de um cartão de reserva visível com um botão “Abrir a App Store”, uma boa parte tocaria nele. Não é o que acontece: 0.9% dos carregamentos de página no Instagram iOS e 0.4% no Facebook iOS tocam no botão. Também não existe versão do iOS em que isso “funcione”:

A explicação que se encaixa é que, dentro do Instagram e do Facebook no iOS, a App Store aparece por cima do navegador in-app sem mandá-lo para segundo plano. A página continua “visível” o tempo todo, então visibilitychange e pagehide nunca disparam, mesmo com o visitante olhando para a App Store.

Por que isso importa. Qualquer métrica que deduz a abertura da loja pelo fato de a página sair da tela está errada no iOS. Nós mostrávamos aos clientes uma porcentagem de “alcance da loja” calculada exatamente assim, e ela dizia a 10 de 12 clientes pagantes que links que funcionavam estavam quebrados. Nós a removemos. No iOS, o sinal de instalação confiável fica do lado da loja: os relatórios de campanha do App Store Connect, com um provider token (pt) e um campaign token (ct) na URL da App Store.

Coisas menores que medimos pelo caminho

• A Play Store demora a aparecer no Android. Nas sessões do Instagram no Android em que o encaminhamento disparou, a página ficou oculta 0–1 s depois da chegada em 1,061 sessões, 2–3 s depois em 2,596 e 4–8 s depois em 1,273 (7 dias). Um timer de 2 segundos que pergunta “funcionou?” dispara antes de a loja aparecer em boa parte dos sucessos reais. Nosso próprio funil contava esses casos como falhas até passarmos a aceitar uma saída até 8 s depois do encaminhamento.
• A taxa real de falha é pequena. Em 7,357 sessões do Instagram no Android reconstruídas ao longo de 3 dias no começo de outubro, o padrão “encaminhamento, depois nada” foi 1.9% das sessões, e 24.3% desses visitantes tocaram de novo no link em até 3 minutos. Visitantes cuja sessão mostrou o cartão de reserva tocaram de novo em 5.4% dos casos, mais ou menos como visitantes cuja loja abriu (4.6%): a maioria dessas “falhas” não era falha.
• Exigir um toque custa a maior parte do tráfego. Antes de a página iniciar o encaminhamento ao carregar, ela mostrava um cartão com um botão da loja. Em 30 dias, 10,523 chegadas in-app geraram 2,119 toques: cerca de 80% dos visitantes nunca chegaram à loja.

Método

• Fonte. Cada chegada a um link inteligente e cada beacon da página de encaminhamento são gravados no Cloudflare Workers Analytics Engine com a plataforma, o navegador in-app (a partir do user-agent), o tipo de evento e um timestamp com precisão de segundo. Visitantes cujo user-agent se declara bot, crawler ou gerador de prévia de link são mantidos à parte e excluídos de todos os números aqui.
• Sessões. O Analytics Engine não tem um id de carregamento de página, então as sessões são reconstruídas juntando uma chegada aos beacons que compartilham o mesmo link, país, cidade, user-agent e navegador in-app dentro da hora seguinte, até a próxima chegada com a mesma chave. Cerca de 98% dos beacons se ligam a uma chegada.
• Pré-carregamentos (descoberta 1). Critério histórico: sem encaminhamento, sem cartão de reserva, sem toque e uma saída 20 s a 15 min depois da chegada. Critério em tempo de execução desde 2026-10-16: a página informa um pré-carregamento quando morre depois de pelo menos 20 s sem nunca ter sido exibida e seu timer de encaminhamento nunca rodou (ou ela carregou oculta). O beacon leva um token assinado de uso único, então não dá para reenviá-lo para apagar uma visita real.
• TikTok (descoberta 2). Sessões agrupadas por link, modelo do aparelho, versão do app TikTok e dia. Regra de formato: versão musical_ly_ com pontos → A; senão JsSdk → B; senão C. Visitantes de redes de hospedagem são contados à parte e ficam fora da tabela. A nova medição de 30 dias usa o mesmo script da análise original de 90 dias.
• Totais usam o intervalo de amostragem do Analytics Engine (2–4% das linhas representam mais de um evento). As tabelas de sessões contam linhas.

Limites

• Nunca vemos a loja. “Ficou oculta” é um indicador de “a loja abriu”. Também dispara quando o visitante troca de app ou bloqueia o celular.
• Os timestamps têm precisão de segundo, e as sessões são reconstruções. Dois carregamentos rápidos do mesmo aparelho podem se fundir.
• Concentração. Alguns links grandes dominam certos períodos: uma campanha no Instagram responde por 72% dos pré-carregamentos de 30 dias, e dois links concentram a maior parte das sessões do TikTok. As tabelas de mesmo link existem por isso.
• Nada aqui foi verificado em um celular físico. Os comportamentos são inferidos do que as páginas informam. A explicação do iOS na descoberta 3 é a que se encaixa nos dados, não algo que vimos acontecer.
• O tráfego é o nosso. São os visitantes dos apps que usam nossos links, com peso forte de campanhas no Instagram e no Facebook em poucos países. Outra mistura dará outras porcentagens, embora os mecanismos devam ser os mesmos.
• Pré-carregamentos que nunca executam JavaScript são invisíveis. 12% dos carregamentos de página do Instagram no Android não enviam beacon nenhum, e parte deles provavelmente também são pré-carregamentos.

O que fazer a respeito

1. Inicie o encaminhamento ao carregar. Uma página que espera um toque perde a maioria dos visitantes in-app. Mantenha o botão manual como reserva, exibido só se o encaminhamento falhou de forma visível.
2. No Android, use `intent://` com `S.browser_fallback_url`. Uma URL https://play.google.com dentro de um webview abre o site da Play Store, que não instala nada sem login.
3. Dê tempo a uma loja lenta. Espere pelo menos 3 s antes de concluir que o encaminhamento falhou, e continue contando uma saída tardia.
4. Dentro do TikTok, mostre a saída na hora: “··· → Abrir no navegador” e um botão de copiar o link. Nenhuma mudança na URL faz a recusa do TikTok sumir.
5. Não conte pré-carregamentos da Meta como cliques. Se você reporta cliques a partir de um redirecionamento, espere que 2–9% das chegadas Android do Instagram e do Facebook sejam páginas que ninguém viu.
6. Meça instalações na loja, com links de campanha do App Store Connect (pt + ct) no iOS e o Play Install Referrer no Android, não com eventos de página.

Nós construímos o onestore.link, que faz as seis coisas por padrão em todo link, e os dados acima vêm dos logs de redirecionamento dele.

Perguntas e respostas