É muito mais comum do que você imagina um usuário acessar seu site a partir de um app no celular.
E também é muito mais frequente do que pensa esse tráfego ser reportado como direto no Google Analytics.
Ou seja, é acrescentado a essa caixa negra que é o tráfego direto.
Dependendo do projeto, pode ser um volume considerável, porque estamos falando de apps muito populares, como:
- Gmail.
- A barra de navegação do Android (atenção a ela, porque muita gente nem considera).
- As redes sociais.
- Telegram e WhatsApp.
- Slack e apps semelhantes.
Se você tem uma audiência importante vinda de algum desses canais, o que vou contar interessa a você.
Por que isso acontece
O motivo pelo qual estes casos são atribuídos a tráfego direto é serem sessões que não têm um referrer HTTP.
Basicamente, deixando os tecnicismos de lado, é porque são usuários que não vêm de outra página web, mas de uma app.
Ou seja, clicaram em um link dentro de um app no celular que os levou ao seu site.
Além disso, o mais comum é que vejam seu site no navegador interno incorporado em quase todos esses apps, e não no navegador do próprio celular (Chrome, Safari etc.).
Como eu disse, esse comportamento é mais comum do que pensamos, sobretudo se temos uma boa audiência em algum desses canais (e-mail, Telegram, Instagram…).
Por isso, é interessante ver este tráfego e poder analisá-lo.
Como ver o tráfego web proveniente de apps no GA4
Mais fácil do que você imagina. São só três passos:
Passo 1: criar um relatório de exploração em branco
Para isso, vá ao link “Explorar” na coluna da esquerda e selecione “Relatório em branco”:
Passo 2: adicionar métricas e dimensões
Começamos por importar estas dimensões:
- URL de referência da página.
- Origem/mídia da sessão.
- Página de destino.
Em seguida, importamos as seguintes métricas:
- Sessões.
- Total de usuários.
- Usuários ativos (opcional).
No campo “Linhas”, colocamos a dimensão URL de referência da página.
No campo “Valores”, colocamos as sessões, , total de usuários, ou usuários ativos, dependendo do que queremos analisar.
Passo 3: filtrar o tráfego que nos interessa
E é aqui que entra a magia do truque.
O que vamos fazer é filtrar o tráfego cuja URL de referência contenha “-app:” assim:
Resultado
Aqui está:
Importante: para deixar claro, caso eu ainda não tenha dito antes, este tráfego NÃO é o do seu app, e sim o do seu site, vindo de links colocados em outros apps, ok?
Passos seguintes
Bem, agora que identificamos todo o tráfego que os apps nos trazem, podemos investigar um pouco mais, que é justamente a ideia.
Agora que você já sabe filtrar, ajuste o relatório ao que realmente precisa. Eu sugiro duas ampliações.
Adicionar a origem e a mídia da sessão
A primeira coisa que você pode fazer é adicionar ao relatório a dimensão Origem e mídia da sessão:
Assim você verá que há tráfego de app que não é direto.
A que se deve?
Porque resolvemos o problema: marcamos os links e adicionamos os parâmetros UTM correspondentes. Mais abaixo volto ao assunto.
Adicionar a página de destino
Outra dimensão que recomendo adicionar ao relatório é Página de destino. Assim você saberá mais algumas coisas e terá mais contexto.
Por exemplo, vejamos isto:
Aqui, o “gm” no final da URL de referência indica-me que a app é o Gmail.
E a landing é a página de login do meu site.
Com essa informação, a primeira coisa que pensei foi que o link não estava marcado — o que, como eu disse acima, é a forma de evitar isso —, mas não é o caso. O link no e-mail ESTÁ marcado.
Então, porque é que o GA4 o classifica como tráfego direto?
Por um problema comum: o que acontece é que a URL do meu site que coloquei no link (corretamente marcada), na verdade tem um redirecionamento quando o usuário acessa essa URL.
Um redirecionamento que faz com que os parâmetros UTM se percam e, por isso, o GA4 não consiga atribuir corretamente a origem, a mídia e a campanha.
É um erro meu, não do GA4. E para o corrigir posso seguir uma destas duas vias:
- Alterar o link no e-mail pela URL final à qual o usuário chega (depois do redirecionamento) e marcar essa URL. É a opção mais fácil, mas nem sempre é possível.
- Fazer com que o redirecionamento preserve os parâmetros UTM e os aplique na página final. Um pouco mais complexo tecnicamente, mas funciona sempre.
Saiba que esse problema com redirecionamentos acontece com frequência. E afeta tanto a análise quanto as campanhas pagas, por exemplo, com o parâmetro GCLID.
Exceção
Se você olhar as imagens, talvez tenha notado uma coisa: todos os apps são de Android.
Não percebo muito bem o motivo —suponho que seja alguma característica do Safari in-app que bloqueia o Analytics — mas, seguindo esse sistema, você só poderá ver o tráfego do sistema operacional móvel do Google.
Felizmente, ele é amplamente dominante na Espanha, então você tem muito mais dados do que os que faltam.
Solução para o tráfego direto de apps: como evitá-lo
Como já mencionei algumas vezes, a forma de evitar isso é usar parâmetros UTM. Para isso, basta abrir o Google URL Builder e adicionar os parâmetros corretos.
E é só isso? Se fizer sempre isto, deixarei de ter tráfego direto no site proveniente de apps?
Infelizmente, não.
E o motivo é que você controla os links que publica, mas não os que outras pessoas compartilham. E quanto mais gente compartilhar seu site, melhor. Mas, como essas pessoas não entram no Google URL Builder para marcar os links, você vai ter SEMPRE tráfego direto proveniente de apps.
Por isso é importante saber como visualizá-lo dentro da ferramenta.
Conclusão
Esse é um truque pouco conhecido que permite aprofundar a análise de um segmento do seu tráfego e que, sobretudo em certos projetos, pode ser muito relevante.
Agora você vai encontrar explicação para alguns picos de tráfego que não entendia. E também poderá resolver mais algumas coisas, como os redirecionamentos.
Tudo de forma muito simples, como a maioria dos truques de GA4 que publiquei até hoje.
Se você gosta de análise e Google Analytics, acho que vale a pena dar uma olhada.
E se você tem problemas com a análise do seu projeto e acha que precisa de ajuda, falamos.
Deixe um comentário