Quando publicamos o artigo mostrando as novidades da nova versão do blog, o dpw2019, no fim do ano passado, algo, digamos, incomum começou a acontecer: a Taxa de Rejeição (a famosa bounce rate) das páginas do blog explodiu!
Antes de inaugurar a nova versão, a taxa de rejeição ficava em uns 15-20%; depois, algo em torno de 90%. Não erramos ao digitar: é noventa por cento, mesmo.
Nossa primeira reação foi pensar: “Nossos leitores e visitantes detestaram o novo layout”! No dia seguinte ao lançamento da nova versão, a bounce rate subiu absurdamente; provavelmente, você também teria pensado o mesmo.
Imediatamente após o susto inicial, estávamos mais tranquilos (embora não menos decepcionados), e decidimos deixar a nova versão do dpw maturando. Vai que era uma questão de o público se acostumar ou algo assim… Ainda mais que era fim de ano, um período de acessos atípico e tudo mais.
Se fosse o caso, bastaria deixar o site rodando normalmente e, com o tempo, a bounce rate tenderia a chegar aos patamares pré-lançamento da nova versão, certo? E se você acha que o caso não era tão grave, dá uma olhada no gráfico da rejeição:
Ficamos 1 mês desviando o olho da bounce rate quando olhávamos o Analytics…
Antes de continuar para saber como continua a história, neste ponto, depois de 1 mês maturando a nova versão, o que você acha que aconteceu?
- A bounce rate voltou ao normal
- A bounce rate continuou ruim como estava
- A bounce rate piorou ainda mais
.
.
.
Acertou se você acha que foi o “2”, a “A bounce rate continuou ruim como estava”. Deixamos o blog rodando normalmente e, mesmo com as melhorias de performance, infra e vários outros aspectos, aquele elefante branco na sala, a taxa de rejeição, não queria diminuir.
Mudanças visuais, UX e navegação
Neste ponto, tínhamos 2 possibilidades: continuar amargando essa métrica medonha da nova versão ou tentar descobrir o que estava causando esse aumento da taxa.
O número de visitantes e sessões permanecia o mesmo (aumentava, inclusive), então algo que não estávamos identificando estava acontecendo.
Então resolvemos promover uma série de mudanças visuais e prover mais elementos de navegação.
Para começar, desfizemos o hero mais estilizado da nova versão. Antes aquele grande imagem que vem no início de cada artigo ficava no formato de nosso logo, em forma de “dpw”. Pensamos que isso poderia estar causando estranheza e afastando visitantes. Voltamos com este que você pode ver hoje, mais “tradicional”.
Acrescentamos mais elementos de navegação e facilitamos visualmente outros que já existiam. Por exemplo, no final de cada página há a listagem completa de links de todos os assuntos que tratamos no blog. Você pode clicar no assunto do interesse e ver todos os artigos relacionados.
Depois que implementamos essas mudanças visuais, de UX e navegação, o que você acha que aconteceu com a bounce rate?
- Voltou ao normal
- Continuou ruim como estava
- Piorou ainda mais
.
.
.
Se você escolheu “2” e acha que, mesmo após essas alterações visuais, de navegação e UX, a bounce rate continuou nos mesmos patamares… Você acertou. Mesmo depois de fazer tudo isso, a danada da taxa de rejeição continuou igual!
RTFM
Com o desespero batendo à porta, amargando meses de bounce rate na estratosfera, só nos restava uma coisa: RTFM.
Encurtando essa parte da história, começamos a rever diversos tutoriais sobre SEO e Analytics, assistir a vídeos etc., revisando muito do que já tínhamos entendido sobre o assunto. Ou pensávamos que tínhamos entendido…
Quer saber onde encontramos a resposta final, que nos levou ao entendimento da coisa e à implementação que salvou nossa pele?
Na po*** do manual! (omitimos o palavrão, então o blog continua sendo de família)
Antes de continuar a ler e saber o fim da história, entra aqui nesse link da documentação oficial da própria Google sobre Taxa de Rejeição e dá uma lida em tudo. Com atenção!
Vai lá, a gente espera:
https://support.google.com/analytics/answer/1009409?hl=pt-BR
.
.
.
Bem, então é isso… A resposta está no manual. Agora você entendeu o que aconteceu e de que maneira a coisa foi resolvida. Até o próximo artigo, pessoal!
Brincadeirinha. 😂
Claro que vamos explicar melhor o que fizemos para diminuir nossa bounce rate em 67,55% — e, sim, estamos repetindo esse número à exaustão no artigo; se fosse no seu blog, você também ficaria feliz de olhar pra ele toda vez que comentasse sobre o assunto.
Tecnicamente falando…
Até então, achávamos que tínhamos entendido completamente o conceito de Bounce Rate, mas a verdade nua e crua é que a gente tinha entendido mais ou menos…
Consultando a página de ajuda do Analytics sobre Taxa de Rejeição (essa que indicamos acima) e lendo com atenção, as coisas ficaram claras. Muito claras.
Veja o que está escrito no primeiro parágrafo da explicação:
Uma rejeição é uma sessão de página única no seu site. No Google Analytics, a rejeição é calculada especificamente como uma sessão que aciona uma solicitação única ao servidor. Isso ocorre, por exemplo, quando um usuário abre uma única página do seu website e, em seguida, sai sem acionar outras solicitações ao servidor do Google Analytics durante essa sessão.
(grifos nossos)
Entendeu, meu consagrado? Se a pessoa entra em uma página do seu site, é disparado o evento de visualização de página do Analytics (até aí, nenhuma novidade), mas, se depois disso, nenhum outro evento é disparado (“sai sem acionar outras solicitações”), isso aumenta a bounce rate!
Se o cara entra em um artigo e fica ali 2 horas, empolgado e feliz em aprender pra caramba e, depois, grato e banhado pelo conhecido recebido, fecha a página, o Analytics considera que ele rejeitou a página porque não executou nenhuma outra ação além do acesso inicial!
Se alguém tiver contato com o pessoal que cria e standariza emoticons para a Web, peça o favor de fazerem um do Sherlock Holmes…
Finalmente resolvido!
Se está acompanhando até aqui, você já sabe como fizemos para resolver o problema dessa bounce rate grotesca que puxava nosso pé de madrugada.
Vamos ver se está prestando atenção, mesmo: o que você acha que fizemos para resolver o problema?
- Lemos a página do manual e deixamos tudo como estava e as coisas se resolveram por uma intervenção divina
- Enviamos um e-mail malcriado para a Google para mudarem a maneira como o Analytics interpreta os acessos
- Começamos a disparar mais eventos na página, enviando solicitações adicionais para o Analytics
.
.
.
Se você chutou o “3”, acertô, miserávi!
Segundo o manual, se na página houver o disparo de mais eventos, isso informa ao Analytics que a página não foi rejeitada (“a rejeição é calculada especificamente como uma sessão que aciona uma solicitação única ao servidor”).
Então, bastou enviarmos algum evento, qualquer um, para informar ao Analytics que o leitor/visitante está sim gostando do conteúdo e interagindo (considerando que ler é uma interação).
No caso, escolhemos registrar o quanto a pessoa rola da página (Scroll Depth), disparando eventos em 25%, 50%, 75%, 90% e 100%. Além de resolver o problema, é uma métrica bem legal de acompanhar e fornecesse excelentes feedbacks sobre quais tipos de conteúdos são mais lidos.
Conclusão
A primeira (e principal) conclusão é que conseguimos resolver o problema e hoje nossa bounce voltou a patamar de 15-20%. \o/
Enquanto fazíamos a nova versão, esquecemos completamente que tínhamos implementado um script “Analytics plus” (ou algo assim) que, automaticamente, disparava alguns eventos, e isso fazia com que a bounce não aumentasse. Na nova versão, migramos os eventos para o GTM.
E quer saber de um efeito colateral positivo muito bom que aconteceu? Consertando a questão da Taxa de Rejeição, outra métrica importante, a Duração Média da Sessão, também ficou mais precisa, igualmente por causa do disparo dos benditos eventos.
A segunda conclusão, que talvez possamos até chamar de lição, é: quando tudo o mais der errado, volte ao básico. Confira se realmente entendeu os conceitos (inclusive técnicos) para saber se o problema não é o seu entendimento sobre como as coisas realmente funcionam.
Uma dica extra que talvez ajude você em algum momento é: saiba qual é seu objetivo ao coletar e analisar suas métricas.
Se você realmente leu aquela página de ajuda sobre Taxa de Rejeição, viu que até mesmo um bounce rate alto pode ter significado importante. Uma taxa de rejeição alta é ruim? Depende.
No nosso caso, queríamos diferenciar quem apenas entrou na página e saiu direito de quem ao menos começou a ler o conteúdo. Daí a importância de termos o scroll depth como evento adicional.
E, também, depois de acompanhar a saga de como diminuímos nossa bounce rate em 67,55% — já falei que gosto muito desse número? –, é possível chegar a um alerta “por tabela”: muito cuidado e muita atenção com o profissional de Analytics que você contrata!
Percebeu que é possível disparar qualquer evento, a qualquer momento, e o Analytics não vai mais considerar que houve rejeição da página? Um gestor malandrinho pode usar isso para diminuir artificialmente a bounce rate do seu site, mostrando o quão eficientes são seus préstimos…
Enfim, esta foi nossa jornada de melhoria de bounce rate na nova versão do dpw, que, depois de muito perrengue, conseguimos diminuir em… Você sabe… Lá vem ele… 67,55%!
E você, já passou por uma situação como essa? Tem alguma dica extra sobre como diminuir a bounce rate (de maneira íntegra e honesta)?