Data Science - Tipos de Análise de Dados
Introdução
Todas as análises depende da pergunta de quem precisa dessa análise, da interpretação dessa necessidade e esclarecimentos da pergunta e noção ou descoberta de bloqueios. E só após isso é que se percebe qual o tipo de análise de dados vai ser necessária fazer e se é possível fazer na sua integridade ou não.
O QUÊ?
Análise Descritiva – Dados para tomar uma decisão, entender uma ação realizada ou antecipar um comportamento.
Esta análise tem como principal objetivo descrever o que aconteceu ou o que está a acontecer num determinado momento. Deve estar sempre limitada ao âmbito do projeto, utilizando técnicas estatísticas para resumir os dados brutos.
Principais características:
- Medidas de Tendência Central: média, moda, mediana
- Medidas de Dispersão: variância, desvio padrão, quartis
- Visualizações: gráficos de colunas, barras, linhas, dispersão, correlação
- Identificação de tendências e padrões nos dados
- Exploração inicial dos dados, permitindo detectar problemas e entender a distribuição
Exemplo:
Vendas do produto X nos últimos 3 anos.
Objetivo: entender o estado da métrica e o comportamento dos atores que influenciam essa métrica.
A análise pode ser encerrada aqui, ou pode seguir para uma análise mais aprofundada – análise de diagnóstico.
PORQUÊ
Análise Diagnóstica – Dados para entender as causas por trás do que foi identificado na análise descritiva.
Esta análise tenta responder ao “porquê” de um fenómeno acontecer, identificando relações e padrões que ajudam a explicar as variações observadas.
Principais características:
- Investigativa por natureza
- Baseada em hipóteses, priorizando aquelas que devem ser testadas primeiro
- Utiliza dados históricos para compreender comportamentos
- Multivariada, já que normalmente não há uma única causa para um fenómeno
- Requer interpretação cuidadosa e um conhecimento mais avançado de estatística
- Evolui naturalmente a partir da Análise Descritiva
- Técnicas utilizadas: regressão, correlação, análise de clusters (clusterização), entre outras
Exemplo:
O número de conversões diminuiu no último mês.
Objetivo: identificar as causas possíveis para essa diminuição, como mudanças no comportamento do consumidor, campanhas de marketing ou fatores externos.
A análise pode ser encerrada aqui, ou seguir para prever o que poderá acontecer no futuro.
QUANDO?
Análise Preditiva – Esta análise procura antecipar eventos futuros com base em dados históricos e técnicas de modelagem estatística.
Principais características:
- Criação de modelos para prever comportamentos futuros
- Baseada em dados históricos, com ajustes e simulações
- Utiliza análises multivariadas
- Insere-se no campo da Ciência de Dados
- Emprega Machine Learning e modelos estatísticos
- Reduz a dependência de suposições baseadas apenas em experiência
- Fornece orientações às equipas de negócio sobre o que pode vir a acontecer
Exemplo:
Com base nos dados dos últimos 3 anos, é possível prever as vendas do produto X para o próximo trimestre, considerando fatores como sazonalidade, comportamento de clientes e campanhas previstas.
A análise pode ser encerrada aqui, ou pode avançar para uma análise prescritiva, indicando o que deve ser feito com base nas previsões.
COMO?
Análise Preescritiva – Dados para recomendar ações futuras.
É o nível mais avançado de análise, oferecendo recomendações específicas sobre o que fazer após as análises anteriores.
Principais características:
- Suporte à tomada de decisão baseada em dados (data-driven)
- Redução de riscos nas decisões
- Baseia-se em simulação de múltiplos cenários
- Considera diferentes variáveis e restrições
- Pode utilizar técnicas de otimização, modelagem matemática e sistemas de apoio à decisão
Exemplo:
Com base na previsão de queda nas vendas do produto X, a análise preescritiva pode recomendar o melhor mix de canais de marketing, distribuição de orçamento e ações promocionais para mitigar essa tendência.
Conclusão
As diferentes análises – Descritiva, Diagnóstica, Preditiva e Preescritiva – formam um ciclo contínuo de melhoria e aprendizado a partir dos dados.
Cada uma tem seu momento e valor dentro de uma estratégia de análise mais ampla e, quando combinadas, ajudam as organizações a compreender melhor o presente, explicar o passado e moldar o futuro com decisões mais informadas.
Data Science for Business Strategy
Introdução
O objetivo deste artigo e dos possíveis artigos seguintes é o de acompanhar os estudos que estou a fazer na Pós-Graduação em Data Science for Business Strategy da Universidade Nova – Faculdade de Ciência e Tecnologia.
É também uma forma de estudar a tentar assimilar melhor os conteúdos ministrados.
O que é Data Science
Data Science, em português, é a Ciência de Dados. OK. Mas o que significa Ciência de Dados? Se formos traduzir DataScience é a Ciência de trabalhar os dados.
Vamos analisar uma definição mais conceptual de Data Science.
Data Science é uma área interdisciplinar que utiliza métodos científicos, processos, sistemas, ferramentas e algoritmos para extrair insights e inteligência dos dados, com o objetivo de descobrir padrões, gerar novos insights para informar o processo de decisão.
Conceitos importantes a reter:
- Interdisciplinaridade – É uma disciplina que envolve 3 disciplinas: estatística, ciências da computação, conhecimento de negócio
- Método Científicos, Processos, Algoritmos e Sistemas – Métodos científicos porque um projeto de Data Science envolve a constatação de um problema, uma declaração de hipóteses e a execução de testes para não rejeitar ou rejeitar a hipótese inicial.
- Processos – Envolve seguir um procedimento, ou seja e por exemplo…não se deve começar a trabalhar os dados sem antes termos feito: 1) o entendimento dos dados, 2) o tratamento dos dados e 3) a análise exploratória dos mesmos.
- Algoritmos – Os algoritmos nada mais são do que um conjunto de procedimentos que levam à criação de um processo. Quando, por exemplo somamos 1 + 1 isso é o algoritmo da soma. Ou quando o fazemos tendo a expressão 1 + 1 * 3.
- Ferramentas – As ferramentas, nomeadamente as tecnológicas auxiliam-nos na execução das disciplinas que compõe a disciplina maior de Data Science: Matemática e Estatística, Ciências da Computação e (Conhecimento do Negócio.
Depois desta definição mais teórica, a minha definição de Data Science é simples: Em termos de conteúdo eu diria que Data Science é o estudo dos dados de modo a conseguir responder a perguntas sobre um ou mais problemas que têm o seu enquadramento no contexto atual e que, concumitantemente ou não, nos permite também descobrir e aturar no naquilo que poderá ser o contexto futuro. Relativamente à forma eu diria, que todo o conteúdo da definição pode e deve ser feito através de pergunta críticas e curiosidade, análises quantitativas e qualitativas, visualizações de dados e comunicação.
As Disciplinas que Compõe Data Science
Então, Data Science envolve três disciplinas: Matemática/Estatística, Ciências da Computação e Conhecimento de Negócios. E estas 3 disciplinas embora possam sejam áreas distintas e devem sê-lo também a nível empresarial e de constituição de equipas e departamentos de Data Science, elas intersectam-se.
Os Papéis em Data Science
A disciplina de Data Science é colaborativa, como tantas outras disciplinas técnicas (e Data Science não é só parte técnica) como Digital Marketing, Product Management, UX-Research. E por serem colaboravas as Empresas devem ter papéis e responsabilidades bem definidas para o efeito…mas sobre este tema talvez faça um publicação só sobre isso – “A Falta de Conhecimento Real sobre o que as Empresas necessitam”. Normalmente o que as Empresas Portuguesas querem para todas as áreas são “Full-Stack Unicorns”.
Portanto, num mundo real e ideal, ou seja, no mundo onde as Empresas querem a serio criar e desenvolver equipas dentro da áreas de Dados e Data Science motivada, interdisciplinar e que cresça, terá na sua génese as funções e responsabilidades seguintes:
NÃO EXAUSTIVO
- Data Engineers (Database Administradores de Bases de Dados e Desenvolvedores de Software) – Têm o seu foco no back-end: desenho e concepção das estrutura dos servidores, desenho, arquitetura e administração das bases de dados, desenvolvimento particular de software específico, servidores e nas bases de dados. É quem fornece a base para que todo o restante trabalho possa ser desenvolvido.
- Big Data Specialists (Machine Learning Engineers, Computer Science Engineers) – Têm o seu foco no desenvolvimento de algoritmos de Machine Learning por forma a que se consiga processar e analisar grandes quantidades de dados, e responsáveis também, se necessário, pela criação de “Produtos de Dados”. Um produto de Dados pode ser um dashboard, mas a este nível estamos a falar mais de produtos de dados que ajudam as pessoas por exemplo qual o melhor produto que ela pode comprar se já comprou os produtos a, b,c,d.
- Database Administradores de Bases de Dados e Desenvolvedores de Software) – Têm o seu foco no back-end: desenho e concepção das estrutura dos servidores, desenho, arquitetura e administração das bases de dados, desenvolvimento particular de software específico, servidores e nas bases de dados.
- Data Analysts – Têm o seu foco no dia a dia do negócio e na análise dos respectivos dados. Podem ser por exemplo análises de dados web, análises de dados de produto, análises de dados de RH e por ai fora. Importante ter conhecimento de SQL, consoante o volume de dados
- Business Analysts – Têm o seu foco nas perguntas importantes para o negócio (tal como os Data Analysts) e gerem ou podem gerir projetos relacionados com dados.
Este artigo pode vir a ser adaptado e complementado ao longo de 2025
Como Fazer e Interpretar uma Análise de Cohort: Exemplo Prático
O exemplo de construção e análise de Cohort apresentado no artigo faz parte do portfólio de trabalhos que fiz durante a formação em Análise de Dados da Comunidade DS.
O que é a Análise Cohort
A Análise de Cohort é uma técnica de analítica cujo objetivo é caracterizar pessoas ou eventos que tenham em comum uma determinada característica durante um determinado período de tempo, e com isso observar o seu comportamento ao longo desse período temporal.
Dando um exemplo simples do nosso quotidiano e depois passando para o ambiente online de desenvolvimento de produtos digitais.
Exemplo offline: Imaginando que vais almoçar fora com os teus pais, mais com os teus 2 irmãos e com os teus avós ao restaurante “Almoça Aqui”. E imagina que esse almoço foi o almoço do primeiro dia do ano – 1 Janeiro de 2025.
Ou seja, e considerando apenas a tua família, o restaurante “Almoça Aqui” recebeu no dia 1 Janeiro de 2025, 7 pessoas, nesse dia, mês e ano. E tu e a tua família, partilham uma característica em comum: foram almoçar a esse restaurante simultaneamente nesse dia.
Soubeste que os teus pais foram jantar ao restaurante no dia seguinte com mais um casal de amigos e o seu filho de 7 anos (considera novamente apenas os teus pais e o casal de amigos como únicos clientes nesse restaurante ao jantar).
E tu foste no dia 3 de janeiro, com a tua namorada e fechaste o restaurante só para vocês e fizeste-lhe uma surpresa :).
Soubeste mais tarde pelos teus pais que o casal de amigos dos teus pais foi ao restaurante no mesmo dia que foste com a tua namorada, mas almoçar.
Ou seja e em termos de Análise de Cohort, teríamos que se representa na tabela abaixo:
|
Primeira visita / Atividade |
Dia 1.1.25 |
Dia 2.1.25 |
Dia 3.1.25 |
|
Dia 1.1.25 |
7 |
2 |
1 |
|
Dia 2.1.25 |
– |
3 |
2 |
|
Dia 3.1.25 |
– |
– |
1 |
Exemplo de E-commerce: O exemplo de e-commerce segue exatamente, mesma lógica, sendo que desta vez estamos a analisar meses.
|
First-purchase / Atividade |
Jan 25 |
Fev 25 |
Mar 25 |
|
Jan 2025 |
1000 |
700 |
300 |
|
Fev 2025 |
– |
600 |
400 |
|
Mar 2025 |
– |
– |
500 |
Notas Importantes
- A característica comum às pessoas, não precisa de ser obrigatoriamente a primeira visita, ou a primeira compra. Pode ser, por exemplo e para o caso do restaurante o “prato” escolhido. E para o caso de e-commerce a categoria de produto comprado “sapatos”. A característica escolhida para a análise depende da própria análise que se pretende fazer.
- Mais à frente veremos melhor a interpretação dos dados da tabela de Análise de Cohort. Aqui quero apenas deixar a nota que, por exemplo para o dia 2 de Janeiro de 2025 (que será a data de cohort) a célula 1 de Janeiro de 2025, porque esse cohort/safra não existia (logicamente) nesse dia. O mesmo raciocínio aplica-se para os meses na loja online
Para que serve a Análise Cohort
O objetivo principal de uma Análise Cohort é para medir o comportamento das pessoas na utilização de um determinado produto ou serviço. Agora esse comportamento traduz-se nalguma métrica que pode variar, consoante as características dos grupo que foi selecionada:
- Retenção
- Life-Time Value
- Melhores Produtos
Que Dimensões e Métricas Precisamos para fazer uma Análise Cohort
As dimensões estarão relacionadas com o tempo ou inteligência de tempo. No exemplo do Restaurante estaríamos a falar da dimensão de tempo em dias. Já no caso do E-commerce a dimensão de inteligência de tempo seria o mês.
Outra dimensão que vamos precisar e que, de certa forma está relacionada com o tempo é, no exemplo do restaurante da data da “primeira visita”. E no caso do E-commerca da data da “primeira compra”.
As métricas que vamos precisar seria o Nº de primeiras visita ao restaurante e para o E-commerce, o Nº primeiras Compras.
No exemplo prático, temos de pensar no binómio “Facto-Dimensão”.
Exemplo de uma Análise Cohort feita em Excel
Enquadramento rápido:
Um Grupo de Beleza com várias lojas físicas espalhadas por Portugal, com o objetivo fazer acreditar no poder transformador da beleza e comercializar diferentes categorias de produtos de beleza.
Recentemente, foi identificado um desafio crescente: a retenção de clientes. A empresa percebeu que, embora as vendas continuem ocorrendo, a frequência de compras de clientes recorrentes tem diminuído.
O objetivo é criar indicadores que mostrem como os clientes interagem com o Grupo de Beleza ao longo de um determinado período de tempo.
Procedimento
Para não tornar o artigo longo e exaustivo, admite que todos os dados que seriam precisos estão na base de dados em Excel denominada de Customers. E nela temos as seguintes dimensões: Customer_Id, Order_Id, Order_Date.
1 – Que dimensões, métricas e factos vamos precisar
Facto:
-
- Customer_ID
Dimensões:
-
- Order_Date (Recorrência de compras) e precisamos de fazer a análise mensal
Dimensões de tempo derivadas da Order_Date:
-
- Order_Date (da primeira compra) e precisamos de fazer a análise mensal
|
Customer_ID |
Order_Date (first-purchase) |
Order_date (Recorrência) |
|
AA123 |
1.1.23 |
1.1.23 |
|
BB321 |
1.2.23 |
1.2.23 |
|
AA123 |
1.1.23 |
2.3.23 |
|
BB321 |
1.2.23 |
1.2.24 |
|
AC123 |
2.2.23 |
2.2.23 |
|
AC123 |
2.2.23 |
5.5.23 |
|
CA321 |
4.8.23 |
4.4.24 |
|
CD123 |
4.6.24 |
4.6.24 |
|
CD123 |
4.6.24 |
1.3.25 |
|
EF123 |
8.7.24 |
8.8.24 |
2 – Como vamos construir a Análise Cohort em Excel
2.1 Criar uma tabela com 3 colunas:
Coluna 1 – Customer_ID
-
- Não precisamos de fazer nenhum cálculo
Coluna 2 – Order_Date (data da primeira compra, em mês)
-
- Utilizando duas fórmulas:
- Formatar os valores de “Date” da coluna Order_Date (first_purchase) em formato custom do tipo “MM-YYYY”
- Utilizar a fórmula: =MINIFS[min_range;criteria_range1;criteria]
- Utilizando duas fórmulas:
Coluna 3 – Order_Date (recorrência de compras)
-
- Utilizando três fórmulas:
- Formatar os valores de “Date” da coluna Order_Date (Recorrência) em formato custom do tipo “MM-YYYY”
- Utilizar, por exemplo a fórmula =DATEDIF[initial_date;final_date;format], neste caso meses
- Utilizando três fórmulas:
Ou seja, vamos ter uma tabela similar a esta:
|
Customer_ID |
Order_Date (first-purchase) |
Order_date (Recorrência) |
Recorrência calculada (meses) |
|
AA123 |
1.23 |
1.23 |
0 |
|
BB321 |
2.23 |
2.23 |
0 |
|
AA123 |
1.23 |
3.23 |
2 |
|
BB321 |
2.23 |
2.24 |
12 |
|
AC123 |
2.23 |
2.23 |
0 |
|
AC123 |
2.23 |
5.23 |
3 |
|
CA321 |
8.23 |
4.24 |
8 |
|
CD123 |
6.24 |
6.24 |
0 |
|
CD123 |
6.24 |
3.25 |
9 |
|
EF123 |
7.24 |
8.24 |
1 |
4 – A Tabela de Cohort no Excel – Exemplificativa
A tabela de cohort resulta de uma pivot table em que utilizamos os facto-dimensões trabalhadas anteriormente. Ou seja, o facto será o “customer_Id” colocado em valores. E as dimensões serão em colunas e linhas respetivamente,“order_date” e “first_purchase”. Para termos os valores em %, temos de dividir o número de clientes em cada um dos meses pelo total de clientes no mês em que aconteceu a Order_Date – first_purchase.
5 – Interpretação dos Resultados
Em linha:
Conseguimos analisar a retenção dos clientes ao longo dos meses que estamos a analisar. Por exemplo, analisando a primeira linha, percebemos que dos clientes que fizeram a primeira compra no mês 0, só cerca de 10% voltaram a comprar no mês seguinte e nenhum comprou no 3º mês.
Podes analisar a média de cohorts, tendo em atenção o período de maturação do cohort. Por exemplo, considerando um mês
Em coluna:
Conseguimos analisar a retenção de novos clientes, e em relação aos níveis de retenção do mesmo mês. Considerando o exemplo de cima, verificamos que na 2ª linha e no mês 1, ao invés dos 9,9% de retenção, foi conseguida uma retenção de cerca de 17% e no mês seguinte de 8%.
O melhor cohort foi o mês de Novembro, analisando a retenção para um mês, e teve cerca de 24% de retenção de clientes.
Este tipo de análise, certamente que poderá ser feito recorrendo a outras ferramentas, como SQL, Python ou até mesmo em ferramentas já “prontas” como o GA4 que nos proporciona uma análise de cohort para o número de visitas. Tudo depende do conhecimento do problema e do conhecimento e da disponibilidade das ferramentas disponíveis.
A Importância do UX na Criação de Eventos para Analytics
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.
O que são Tabelas Facto e Tabelas Dimensão - Análise de Dados
Introdução
A distinção de dados dentro de Tabelas Facto e de dados dentro de Tabelas Dimensão, é especialmente importante quando falamos de estruturas de dados estruturais que se relacionam de alguma maneira.
Tabelas Facto
O nome da tabela diz tudo – Facto. Ou seja, as Tabelas Facto (fact_table ou fnomedatabela) contém as informações sobre todos os factos que aconteceram numa determinada instituição numa determinada data. Por exemplo, todas as informações de vendas, de devoluções, de ocorrências médicas, como uma cirurgia, etc.
As Tabelas Facto têm em cada uma das linhas toda a informação sobre esse mesmo facto.
Por exemplo, uma Tabela Facto Consulta Médica – pode ter informações sobre todas as consultas ocorridas num hospital, em linhas. Em coluna podemos ter as dimensões: ID da consulta, data da consulta, especialidade da consulta.
Já uma Tabela Facto de Vendas pode conter informações sobre todos os factos relativos a vendas e em que as dimensões em colunas podem ser: ID Venda, SKU, data da venda, quantidade vendida.
Tabelas Dimensão
As Tabelas Dimensão (dim_tables ou dnomedatabela) têm informação sobre as características, atributos, dimensões, que complementam a informação contida na Tabela Facto.
Por exemplo, para a Tabela Facto de Consulta Médica, poderemos ter, entre outras Tabelas Dimensão, uma tmedicos associada à Tabela Facto Consulta Médica em que os atributos poderiam ser: ID do Médico, nome do médico, especialidade do médico.
Já a Tabela Facto Vendas, poderá, entre outras, uma dprodutos contendo informações como: nome do produto, categoria do produto, cor do produto, tamanho do produto, preço do produto.
A Importância de ter Tabelas Facto e Tabelas Dimensão
Por três razões essenciais:
Por ser a forma mais eficiente de trabalhar com análise de dados, independentemente de utilizarmos o SQL, PowerBi ou outra ferramenta. Como as tabelas facto contêm todos os factos ocorridos numa determinada instituição num determinado período de tempo, elas vão ser tabelas com um volume de dados gigante, podendo ter centenas milhões de linhas, dependendo da Empresa e do evento a que essa tabela faz referência. Cada coluna a mais nestas tabelas, serão mais informações adicionadas e novas linhas a mais, o que deixará o arquivo mais pesado e mais lento.
Já as tabelas de dimensão são tabelas pequenas, e cada médico/medicação/paciente irá aparecer uma única vez.
Se tivéssemos estas informações médico/medicação/paciente na Tabela Facto, iríamos ter informações repetidas, sempre que esse paciente tivesse uma consulta
Por isso deixamos as tabelas dimensão como uma tabela de ‘cadastro’, auxiliar, para conseguir deixar os arquivos de SQL, PowerBI e de outro tipo muito mais leve e eficiente, sem
ficar com informação repetida desnecessariamente.
Exemplo em GA4
O exemplo que quero dar em termos de Tabela Facto e Tabela Dimensão para o Google Analytics 4 é muito simples. Até porque ainda não tive oportunidade de utilizar/trabalhar com o BigQuery para fazer análises simples e mais profundas.
Se souberem de bons cursos sobre este tema, deixem comentem o artigo.
Possível Tabela Facto
- Utilizadores
Possíveis Tabelas Dimensão
- Eventos
- Dispositivos
- Países
Espero que tenham gostado do artigo. A área de dados, nomeadamente a área de MarTech é uma área na qual me estou a debruçar devagarinho.