analise de dados

Introdução

Antes de começarmos, vamos só recordar uma definição importante e que é a definição de “Analytics”. Analytics  é algo que podemos obter através de scripts instalados no código fonte dos websites ou apps. Ou seja, na realidade (e sem muito rigor técnico) são métricas que o computador, através de alguma ferramenta, consegue recolher através desses scripts, em resposta à ação do utilizador num do web browser ou aplicativo móvel.

Desenvolvimento

Portanto, antes de mergulharmos na escolha da ferramenta de analytics e na implementação de eventos, seja via datalayer ou via DOM scrapping é fundamental reconhecer a importância do trabalho de UX e, mais especificamente, da criação de fluxos de tarefas do utilizador.

Trabalhar o UX, significa trabalhar estrategicamente a experiência holística do utilizador, incluindo entender toda a sua jornada desde o início (que pode não ser online) até ao alcançar dos seus objetivos (que pode também não ocorrer online). Como vimos na introdução, ao criarmos eventos “para analytics” estamos, essencialmente, a capturar dados sobre como os utilizadores interagem com o website ou app. E para capturar esses dados da forma mais simples possível (ou seja sem workarounds porque causa do legacy code) e, possivelmente, também de forma o mais precisa e significativa possível (tendo em conta as várias circunstâncias do mundo online, como é o caso da privacidade), é crucial compreender a jornada, para desenharmos o fluxo de interações do utilizador o mais simples possível.

Estes fluxos de utilizador fornecem uma estrutura clara para entender como os utilizadores navegam e interagem com o produto. Ao mapear esses fluxos, podemos identificar pontos de fricção, pontos de abandono e áreas de oportunidade para otimização. Isso traduz-se diretamente na criação de eventos relevantes para analytics. Ao entender os caminhos que os usuários percorrem, podemos identificar os eventos-chave que queremos rastrear para entender melhor o comportamento do utilizador e suas intenções.

Exemplo

Ao analisarmos um website de e-commerce, podemos identificar o fluxo de um utilizador desde a entrada no e-commerce até a conclusão de uma compra. Ao entender cada etapa desse fluxo, podemos identificar os eventos que indicam o seu “engajement”; como visualização de produtos, adição do produto ao carrinho, checkout e finalização da compra. Ao mapear estes eventos numa fase de planeamento da expirência, mais tarde, rastrear esses eventos, podemos obter insights valiosos sobre o desempenho do site, taxas de conversão, comportamento do usuário e muito mais.

Além disso, a criação de eventos com base nos fluxos de utilizador também nos permite personalizar e segmentar as análises. Podemos criar segmentos de utilizadores com base nos seus padrões de interação, o que nos permite entender melhor diferentes grupos e, se possível, adaptar nossa estratégia de marketing e produto de acordo.

Ao implementar esses eventos na datalayer do website e ao configurá-los corretamente no GA4 ou Adobe Analytics ou noutra ferramenta para o efeito, podemos identificar áreas de melhoria, testar hipóteses e iterar continuamente para aprimorar a experiência do utilizador.

Conclusão

Em suma, o UX desempenha um papel fundamental na criação de eventos para analytics, pois nos ajuda a entender a jornada do usuário e a identificar os eventos-chave que queremos rastrear. Ao mapear os fluxos de usuários e criar eventos relevantes, podemos obter insights valiosos que impulsionam o crescimento e o sucesso de nossos negócios online.

Podes saber mais no artigo abaixo:

>Redesenho de Websites e integração com Digital Analytics

“Para Quem Não Sabe Para Onde Vai, Qualquer Caminho Serve” by Lewis Caroll

O redesenho (redesign) de websites e/ou de outros aplicativos digitais são acontecimentos comuns de ocorrerem nas organizações. Este tipo de trabalho pode ser algo pequeno e simples como a mudanças na navegação numa única página, até mudanças mais complexas que interferem tanto no front-end como no back-end.

Em qualquer dos casos, muitas organizações não contam com as equipas de Digital Analytics. E o resultado é escandaloso. O website e/ou os aplicativos são redesenhados, obrigando a novos desenvolvimentos, é colocado em produção, e muitas implementações ou todas as implementações feitas ao nível da implementação de eventos falha,….e de quem é a culpa? Do Digital analytics.

E o tema não deve, não tem e não pode ser ou continuar a ser assim nas empresas. Isto porque existem vários key-points que devem ser acautelados no desenvolvimento destes trabalhos. Aliás, as equipas que trabalham ou que fornecem metodologias de trabalho ágeis, deveriam ter pessoas competentes nestas matérias e não só “puros e duros” software developers.

Estabelecimento dos novos Objetivos de Medição

O “primeiro ato” que as equipas, seja o PO, o SM ou alguém do negócio deve ter em conta e levantar o tema junto da equipa de Digital Analytics é a indicação do que, em termos de features, se pretende medir e monitorizar. Sim, porque parte-se do princípio (ainda que a maioria das empresas e equipas não o façam dessa forma) que uma feature é resultante de um trabalho de UX-Research e vai responder a um outcome para melhorar a vida das pessoas. E esse outcome pode ser medido ou não. E mesmo sendo medido, pode sê-lo de outra forma que não através do Analytics.

Desenvolvimento de Planos de Medição e Guias de Implementação

Em seguida, e tendo em conta o que se pretende medir e como; objetivos e KPIs definidos, passa-se à fase de desenvolvimento dos planos de medição e dos guias de implementação correspondentes a esses objetivos e KPIs. Integrar os requisitos de medição e de tracking na fase de planeamento garante que os data touch points necessários serão capturados com precisão após a entrada em produção do novo website ou aplicativos.

Partilha de Protótipos Hi-Fi

A visualização e partilha dos protótipos Hi-Fi com as pessoas de Digital Analytics vai permitir aos mesmos visualizarem os diferentes fluxos dos utilizadores, identificarem pontos de fricção, data touch points, e perceber se os KPIs definidos inicialmente estão presentes naquilo que foi desenhado. Além disso, e se o protótipo estiver bem especificado, é possível contribuir também com insights sobre como medir melhor as interações do utilizador.

Especificações dos Protótipos

• HTML, CSS e JS – O esqueleto de um website é o HTML e o CSS e depois a inteligência do website vem através da implementação do JS. Se estes elementos forem completamente mexidos e alterados, tudo aquilo que havia sido implementado, muito provavelmente deixa de existir. Assim, é preciso garantir que se algum destes elementos forem alterados essas mesmas alterações tenham em consideração o que já está implementado. Além disso, é necessário estar tudo especificado por exemplo ao nível dos use cases de um cliente autenticado ou não. Ou o que acontece quando um utilizador clica no botão/CTA; para que página vai? Ou não vai para nenhuma página? Se existe a possibilidade de refresh da página e a informação mantêm-se armazenada. Que tipo de estilos vão ser aplicados, por causa dos CSS Selectors e da facilidade ou complexidade da sua utilização no caso de ser necessário implementar um trigger com base nos mesmos.
• DataLayer – Se a DataLayer for alterada ou não for considerada vai ser difícil implementar qualquer tipo de eventos via DataLayer. Relembrando que a implementação via DataLayer dos eventos é a forma mais eficaz e com menos riscos de “quebrar” a medição, que existe.
• Estrutura de URL – Os URLs devem ser especificados e, preferencialmente devem ser o mais “amigáveis” possíveis, ajudando também a performance do website ao nível do SEO. A estrutura deve ser clara o que vai garantir que todas as páginas e ações relevantes sejam capturadas na configuração dos eventos. Criação de Single Page Applications – SPA – é uma complicação para implementar. Ou até mesmo a utilização dos iframes (completamente em desuso).
  Estruturas de URLs mal especificadas e, posteriormente, mal configurada podem levar a discrepâncias nos relatórios.
• Implementação dos Eventos e Custom Dimensions
  Além dos KPIs definidos inicialmente e, consequente e muito provavelmente, dos eventos a implementar, as equipas de digital analytics necessitam de ver especificado o tema das custom dimensions. Para acrescentá-las no UI do GA4. Por exemplo, por algum motivo válido o negócio pode querer saber a hora do login. Lembrando que o GA4 free permite apenas a categorização de 25 custom dimensions.
• Ativação (ambiente de desenvolvimento e produção)
  Isso proporcionará a oportunidade de revisar os dados coletados, identificar discrepâncias ou anomalias e refinar a implementação do rastreamento conforme necessário.

Ao integrar esses pontos ao processo de redesenho do site, podemos aproveitar a experiência de nosso Analista Digital para garantir que nossa configuração de rastreamento esteja alinhada com os objetivos do projeto, as necessidades do usuário e os requisitos de análise de dados.

Conclusão

As empresas muitas vezes descuram o tema do digital analytics quando estão a implementar de raiz websites ou aplicativos ou apps. E ainda mais vezes, esquecem este tema quando estão a fazer o redesenho das mesmas.

É importante sublinhar que a comunicação entre as equipas (e não uma pessoa) de desenvolvimento, design e analytics….e na altura atual até acrescentaria de data, é crucial para garantir o sucesso do projeto de redesenho.

Podem saber mais sobre estes temas nos seguintes artigos:
1 – >Checklist de Atividades de Analytics para (Re)Lançamento de um Website – 11 Atividades a Considerar – PARTE 3
2 – >Checklist de Atividades de SEO para (Re)Lançamento de um Website – 13 Atividades a Considerar – PARTE 2
3 – >Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website – 12 Atividades a Considerar – PARTE 1

Por fim, e acredito que este seja uma conclusão que todos que trabalhamos na área devamos ter é:

Medir apenas o que importa, e nunca medir tudo e mais alguma coisa, nomeadamente quando se utiliza ferramentas free.