Como Transformar a Experiência Digital em Resultados Reais - CRO
Introdução
Os ativos digitais, nomeadamente, websites e aplicativos móveis têm diferentes objetivos. Pensando em websites e aplicativos móveis mais orientados a conversão seu verdadeiro valor não está apenas em atrair visitas, mas sim em transformar essas visitas em ações concretas — seja uma compra, um pedido de contacto ou uma subscrição. E é nestes casos particulares, ou concretos em que a aplicação de processos, técnicas e ferramentas para otimização da taxa de conversão (CRO) pode ajudar.
Neste artigo abordarei temas relacionados com a metodologia CRO que conjuga dados, psicologia e design de experiência para reduzir fricções, aumentar a confiança e alinhar o produto digital com o comportamento real dos utilizadores.
Desenvolvimento
A CRO é um processo que deve ser estratégico e por isso contínuo e mensurável. Não se pode tratar de um processo tático onde simplesmente se ajusta as cores ou se muda o texto de um botão — é uma prática estruturada que procura compreender o utilizador, formular hipóteses baseadas em dados e validar essas hipóteses por meio de experimentação.
É importante distinguir aqui dois conceitos muitas vezes confundidos: CRO e Testes A/B. Enquanto a CRO é a abordagem estratégica global, que inclui a recolha de dados qualitativos e quantitativos, o desenvolvimento de hipóteses, a execução de testes e a análise dos resultados, os Testes A/B são apenas uma ferramenta dentro desse processo. Um teste A/B aplica-se quando se pretende comparar duas versões de uma página ou elemento, mas sem uma base estratégica e uma leitura interpretativa dos resultados, o teste em si não garante qualquer otimização real.
O sucesso em CRO reside precisamente na combinação de análise, interpretação e aprendizagem contínua. É um ciclo em que cada iteração — mesmo as que “falham” — gera conhecimento e orienta as próximas ações.
A base de qualquer otimização é a análise do comportamento do utilizador. Esta análise pode ser feita sob três perspectivas complementares.
- A análise quantitativa, suportada por ferramentas como o Google Analytics, Hotjar, VWO, entre outras, que quando implementadas de acordo com a estratégia da Empresa, e não adhoc, fornecem dados concretos sobre o que os utilizadores fazem.
- A análise qualitativa, por sua vez, revela o “porquê” por detrás desses comportamentos: inquéritos, entrevistas e gravações de sessão ajudam a perceber o que causa atrito ou frustração.
- O benchmarking que permite comparar o desempenho do website com o website dos concorrentes ou com referências de mercado escolhidos, revelando oportunidades de melhoria que de outro modo passariam despercebidas. Mas é preciso ter muita atenção ao benchmarking, por dois grandes motivos, um deles cultural.
O cruzamento destas três dimensões permite identificar os chamados “pontos de fricção” — elementos que travam o fluxo do utilizador nos ativos digitais — e formular hipóteses de otimização. Por exemplo, se uma percentagem elevada de utilizadores abandona o carrinho de compras ao ver os custos de envio, a formulação das hipóteses válidas, poderia ser:
H₀ (Hipótese nula): Oferecer portes gratuitos acima de determinado valor não altera significativamente a taxa de conversão em comparação com o website atual.
H₁ (Hipótese alternativa): Oferecer portes gratuitos acima de determinado valor aumenta significativamente a taxa de conversão em comparação com o website atual.
Estas hipóteses são então testadas através de experimentação controlada (teste A/B), permitindo validar com rigor estatístico se a mudança deve ser implementada.
Todas as hipóteses levantadas, após o entendimento do comportamento dos utilizadores e do mercado, poderão formar um backlog de testes, que deve ser priorizado com base no impacto potencial para os utilizadores e, consequentemente para o negócio e no esforço de implementação.
A cada ciclo de experimentação, as novas descobertas alimentam o processo, criando uma cultura de melhoria contínua.
Mas a otimização da taxa de conversão não é apenas uma questão técnica — é também profundamente psicológica, não estivéssemos nós a falar de comportamento dos utilizadores online.
O que se pretende é entender o equilíbrio entre motivar e tranquilizar o utilizador, reduzir a fricção e tornar o processo de decisão simples e confiante.
A motivação de um utilizador explica-se por que alguém age e nisso tem particular importância:
- A definição clara e comunicação da proposta de valor da Empresa/Produto;
- A existência de potenciais incentivos como sejam promoções, urgência, prova social;
- A ausência ou a minimizarão da fricção como sejam formulários longos, interfaces confusas, lentidão);
- A ausência ou a minimizarão da ansiedade do utilizador após a realização da ação.
Nota: Baseado no modelo MECLABS
Para identificar e corrigir esses fatores, entram em cena as heurísticas de usabilidade — princípios que orientam a criação de interfaces intuitivas e seguras.
As Heurísticas de Nielsen-Molich, criadas nos anos 90, continuam a ser uma das referências mais sólidas em termos de análise comportamental online dos utilizadores. Entre elas, destacam-se:
- Visibilidade do estado do sistema - o utilizador deve sempre saber o que está a acontecer (exemplo: uma barra de progresso durante o checkout).
- Correspondência com o mundo real - o conteúdo deve falar a linguagem do utilizador, não do sistema (exemplo: “Adicionar ao carrinho” em vez de “Submeter item”).
- Controlo e liberdade - permitir desfazer ações com facilidade (exemplo: botão “Voltar” ou “Remover do carrinho”).
- Consistência e padrões - manter elementos familiares e previsíveis (exemplo: o carrinho no canto superior direito).
- Prevenção de erros - o melhor erro é o que nunca acontece (exemplo: validação automática de campos de formulário).
- Reconhecimento em vez de memorização - facilitar a navegação com ícones e menus claros.
- Flexibilidade e eficiência - atalhos e funcionalidades rápidas para utilizadores experientes.
- Design estético e minimalista menos ruído visual, mais foco no essencial.
- Ajudar a reconhecer e corrigir erros - mensagens claras e construtivas, e não códigos técnicos.
- Ajuda e documentação acessível - FAQs e apoio visível quando necessário.
No contexto do e-commerce, estas heurísticas foram adaptadas e aprofundadas, dando origem às chamadas Heurísticas de E-commerce, que aplicam os mesmos princípios ao comportamento de compra online.
Exemplos práticos incluem:
- Exibir provas sociais (avaliações, testemunhos, número de vendas).
- Garantir transparência de custos logo no início do processo.
- Simplificar o checkout em passos curtos e visíveis.
- Criar descrições de produto ricas e credíveis, com fotografias de qualidade.
- Assegurar otimização mobile, carregamento rápido e segurança de dados.
- Destacar políticas de devolução claras e informações de contacto acessíveis.
Estas boas práticas não são apenas técnicas de design — são ferramentas de confiança e persuasão. Um utilizador que se sente orientado e seguro é um utilizador que converte.
Além da usabilidade e da psicologia, a CRO também tem impacto direto na performance global do marketing digital. Ao melhorar a experiência do utilizador e ao aumentar a taxa de conversão, reduz-se naturalmente o custo de aquisição de cliente (CAC), maximiza-se o ROAS (Return on Ad Spend), melhorando-se a eficiência de todo o funil.
Nota minha: Se bem que hoje em dia já não se fala em funil, mas sim em flywheel, mas quando se trata de adquirir clientes através da experiência e do boca-a-boca, mesmo no digital
Um website otimizado é, acima de tudo, um website competitivo e adaptável. À medida que o comportamento do utilizadores muda, as tendências de design evoluem, a experimentação contínua permite que a marca se mantenha relevante — e isso é talvez o maior ativo do CRO: a sua capacidade de evolução constante.
Conclusão
A CRO é, acima de tudo, uma mentalidade. É a escolha de olhar para cada interação digital como uma oportunidade de compreender melhor o utilizador e de criar uma experiência mais eficaz, confiável e agradável.
Num ecossistema digital em que captar tráfego se torna cada vez mais difícil e cada vez mais caro, investir em CRO significa investir em eficiência e sustentabilidade — é transformar o mesmo número de visitantes em mais resultados.
O que os Algoritmos não Veem: Como a "Nova" Análise de CVs Prejudica a Identificação de Talento Multidisciplinar
Introdução
A nova era da velocidade, mas potencial perda de profundidade
Vivemos na era da eficiência digital. A tecnologia trouxe agilidade às empresas, mas também uma pressa desmedida nos processos humanos. No recrutamento, isso traduz-se na automatização da triagem de currícula, muitas vezes via algoritmos de machine learning, filtros semânticos e sistemas de ATS (Applicant Tracking Systems).
A promessa é boa: filtrar o ruído e identificar o talento. Mas a prática revela um paradoxo cruel: estamos a descartar perfis com competências relevantes, apenas porque não usam a semântica esperada.
Este artigo é uma análise crítica e profissional sobre como a leitura superficial de CVs está a falhar na identificação de talento com experiências transferíveis para áreas como Product Management, Product Analytics e UX Research, através de um exemplo real: o meu.
O novo modelo de análise de CVs
Das heurísticas humanas a inferências automáticas
Historicamente, a análise de currículos era feita com base em julgamento humano, com a possibilidade de vários tipos de interpretações sobre o que se estaria a ler (ou seria analisar?). Hoje, com a pressão por escalar processos de recrutamento, passámos para sistemas automatizados de triagem, denominados de ATS – Automatic Tracking Systems.
Dada Science por detrás dos ATS
Nuances como contexto e transferência de competências
Esses sistemas utilizam técnicas estatísticas aplicadas em contexto de NLP (Natural Processing Language), para modelar features em dimensões categóricas como são os textos, extraindo entidades e vetorizadores de texto para identificar “match semântico” entre a descrição da vaga e o CV do candidato. A ideia é nobre, mas as limitações são técnicas e conceptuais:
Os algoritmos baseiam-se em features como função, hard skills, keywords, anos de experiência e por ai fora. Mas falham em captar, entre outras coisas, as ”soft features” como: pensamento crítico, transferência de conhecimento, contexto de atuação.
Ignoram as experiências que não seguem o padrão semântico estrito do cargo.
Na prática, o ATS clusteriza os candidatos e, como é expectável, com um número (elevado ou não, não está em questão a quantidade, mas a qualidade) de falsos negativos. Ou seja, de perfis que têm à partida as competências certas, mas que são excluídos pela ausência de padrão que o algoritmo necessita.
Isto para não mencionar que não sabemos a forma como o algoritmo foi construído, porque há muitas formas de vetorizar textos e há muitas formas de clusterizar informação. A utilização dessas formas, depende do objetivo que se pretende atingir, do formato e estrutura de dados que o sistema reconhece e por quem faz a manutenção ao sistema.
A transferência de competências: quando o cargo esconde a função real
Look behind the Obvious
Nas áreas digitais, muitas vezes as funções, responsabilidade e atividades inerentes ultrapassam o âmbito formal do cargo. Até diria mais, mesmo em áreas fora do mundo digital, as competências podem perfeitamente ser transferíveis. Por exemplo, um chef de cozinha pode perfeitamente assumir uma função de Product Owner.
|
Experiência como Chef |
Competência Transferível |
Equivalência no Product Management |
|
Planeamento de menus |
Planeamento estratégico e visão de produto |
Definição de roadmap, funcionalidades |
|
Gestão de equipa de cozinha |
Liderança de equipas multidisciplinares |
Alinhamento com design, tech, marketing |
|
Execução sob pressão |
Gestão de dependências e prazos |
Gestão de sprints e releases |
|
Controlo de qualidade |
Foco na experiência do cliente |
Garantia da qualidade do produto |
|
Feedback dos clientes |
Empatia e escuta ativa |
Product discovery |
|
Otimização de processos |
Eficácia operacional |
Priorização baseada em impacto/esforço |
Voltando ao campo Digital, os profissionais de marketing podem exercer funções de análise de produto. UX researchers podem liderar ciclos completos de Product Discovery. Analistas de dados podem estar envolvidos em decisões estratégicas de produto sem nunca serem chamados de Product Managers ou de Product Analysts, ou Business Analysts.
O problema é que os modelos de análise de CV funcionam com base em cargos e rótulos. Se o termo “Product Manager” não aparece, o sistema assume que o candidato não tem experiência. Isto ignora a realidade do mundo digital moderno, onde as fronteiras entre funções são fluidas e interdependentes. Vivemos num mundo diferente, mas está-se a utilizar a IA, no caso dos ATS, como se vivêssemos há 30 ou 40 anos atrás, em que existia uma profissão para a vida e como tal perfis pouco fluídos e interdependentes.
Caso prático: 12 anos de experiência digital and counting, vistos pela lente errada
Antes de enveredar pelo mundo digital, tive responsabilidade de co-liderança durante 3 anos e depois de liderança durante mais 2 anos na implementação e manutenção de Sistemas de Gestão da Qualidade numa Empresa B2B, setor químico-industrial onde a interdependência entre áreas é enorme: áreas de produção, área de investigação e desenvolvimento, área de produção, área de compras, área de expedição, área de controlo de qualidade, área de manutenção. E a tecnicidade dos temas é diária e deve ser constantemente aprofundada.
Será que um ATS é capaz de analisar estas competências transferíveis para as áreas de Produto ou de Web Analytics? Tenho muitas dúvidas mesmo.
No decurso do meu percurso profissional, trabalhei ao longo de mais de uma década em Digital Marketing, Web Analytics, UX Research e, mais recentemente, como Product Owner com foco em Product Analytics. Assumi funções e responsabilidades e executei atividades centrais em qualquer função relacionada com product management:
- Mapeamento de jornadas de utilizador com impacto direto em roadmap
- Implementação de tracking e medição de eventos com GTM e GA4
- Construção de dashboards com Looker Studio e Power BI
- Liderança de discovery qualitativo e quantitativo com utilizadores reais
- Interação direta com equipas de tecnologia, design, desenvolvimento e marketing
- Escrita de documentação funcional e proposta de melhoria de produto
|
Experiência como Digital Marketing |
Competência Transferível |
Equivalência em Product Manager |
|
Product Owner Digital Analytics |
Visão estratégica de produto |
Definição de roadmap e funcionalidades |
|
Criação de measurement plans |
Documentação técnica |
Product Requirements Documentation (PRDs) |
|
Mapeamento de customer journeys |
User journey mapping |
User story creation e journey optimization |
|
Subject-matter expert multidisciplinar |
Conhecimento cross- functional |
Stakeholder management |
|
Análise de campanhas e insights |
Data-driven decision making |
Product analytics e KPI management |
|
Desenvolvimento de dashboards |
Data visualization |
Product performance monitoring |
|
Coordenação de projetos de transformação |
Project leadership |
Product development leadership |
|
Gestão de equipas de consultores |
Team management |
Agile team leadership |
|
Criação de Go-To-Market offers |
Go-to-market strategy |
Product launch strategy |
|
UX-Reseearch e Usability Tests |
User research |
Product discovery e validation |
Tabela de Matriz de Competências desenvolvida com ajuda da AI-Generativa
Esta experiências, apesar de distribuídas por diferentes job titles, são funcionalmente equivalentes àquilo que Empresas com cultura e de produto esperam de um Product Manager ou Product Analyst. Mas essa equivalência é invisível para algoritmos e muitas vezes também para recrutadores com filtros excessivamente formais.
O que empresas de produto procuram (e como isso colide com os filtros de seleção)
- Empresas com verdadeira cultura de produto valorizam:
- Colaboração multidisciplinar e systems thinking
- Capacidade analítica e orientação a dados
- Compreensão profunda do utilizador
- Mentalidade de discovery e experimentação
- Capacidade de priorizar e comunicar com stakeholders
Estas são competências que se desenvolvem em várias funções digitais. Só que os ATS estão orientados com outro paradigma: um check de palavras-chave e um matching linear entre cargo anterior e cargo desejado.
UX Research, Digital Analytics e Product Thinking: a combinação invisível
A integração entre UX-research, Analytics e decisão é a tríade competitiva no digital, nomeadamente em desenvolvimento e gestão de produtos digitais. Mas poucos recrutadores (e responsáveis de áreas, talvez) reconheçam que esta combinação pode surgir de forma orgânica, “líquida” e não formalizada.
A experiência em UX Research permite entender o comportamento humano, levantar problemas reais e validar soluções com base em evidência. A experiência em Digital Analytics permite medir o impacto de cada decisão e orientar equipas de design e de desenvolvimento. E atualmente, com a IA até pode permitir, dependendo da profundidade de conhecimento do tema de Analytics, conversar e compreender o que fazem os algoritmos ou que algoritmo poderá funcionar. Mais uma vez, esta tríade é fundamental para qualquer produto que queira crescer de forma sustentada.
Quando estas experiências coexistem num mesmo profissional, o valor entregue é substancial. Mas essa intersecção não aparece num campo específico do CV e é raramente indexada por algoritmos de triagem.
O desafio do matching semântico em NLP aplicado a recrutamento
No mundo de NLP, o matching semântico entre dois textos envolve técnicas como word embeddings, transformers e modelos de similaridade. Mas aplicar estas técnicas a CVs exige um entendimento contextual que raramente é alcançado por sistemas ATS.
Um bom modelo de NLP precisaria de:
- Captar relações não-lineares entre funções
- Incorporar conhecimento do mundo real sobre transferência de competências
- Contextualizar a experiência em função do impacto, não apenas do cargo
Na prática, os sistemas operam com vetores simplificados e regras de business logic rígidas. Isso perpetua enviesamentos estruturais: candidatos com títulos não convencionais, formação híbrida ou percursos não lineares são penalizados.
O futuro do recrutamento em produto exige inteligência contextual
Se quisermos construir equipas de produto verdadeiramente eficazes, precisamos de abandonar o paradigma da equivalência semântica e adotar uma leitura mais profunda, baseada em inteligência contextual.
Isso implica:
- Reformular os sistemas de ATS para permitir análise narrativa
- Treinar recrutadores para reconhecer competências transferíveis
- Promover o pensamento de produto também no recrutamento
- Incorporar métricas de impacto, e não apenas histórico de cargo
Conclusão
Talento não é uma palavra-chave, é um conjunto de evidências
A experiência profissional é multifacetada. Um CV é uma síntese limitada. E um sistema de análise automatizada, por mais avançado que seja, não pode substituir a capacidade humana de interpretar contexto, transferência e potencial. E porque não dizer mesmo“empatia”. Acredito que muitas das passagens da primeira entrevista para a segunda fase aconteça por empatia entre entrevistador-candidato.
Como profissionais da área digital, devemos ser os primeiros a aplicar o pensamento de produto também ao talento: analisar o problema real (a necessidade da equipa), entender o utilizador (o candidato) e validar soluções com base em dados e experiência, não em atalhos semânticos.
O talento não se define por uma função e atividades. Define-se intrinsecamente pela pessoa pela vontade de crescer, pela motivação do desafio, pela capacidade trabalhar em prol e com os outros, pela capacidade de se entregar, pela vontade de investir em si valor em contexto. E manifesta-se extrinsecamente pelas restantes pessoas a outros níveis que não são o objeto deste artigo.
E isto, muitas vezes, não está contemplado onde o algoritmo procura.
NOTA:
Este artigo não é uma queixa, nem um crítica. É uma reflexão e um convite.
Um convite a todos, todos, todos (profissionais de RH, digital marketers, product managers, managers, c-levels…): olhem para além do cargo atual e anteriores. Não leiam, sim analisei com atenção os verbos, os resultados, os contextos. Perguntem-se e perguntem aos v/ seniores, managers, clientes:
-
Este perfil já viveu algum ou todos os ciclos de vida de um produto?
-
Já resolveu problemas com equipas interdisciplinares?
-
Já usou dados para tomar decisões?
-
Já ouviu utilizadores, testou hipóteses, documentou processos?
- Já esteve em empresas com cultura ou com metodologias agile adotadas em desenvolvimento de produtos?
- Já investiu em conhecimento sobre a função a que se candidata?
Se a resposta for “sim”, talvez tenham à vossa frente o próximo talento de produto — mesmo que o CV diga “Digital Marketing” e a “máquina” confirme-o.
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.