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.
Certificação PowerBi com Projeto Integrado
Parte do resultado do meu foco nos temas e no desenvolvimento de skills técnica de análise de dados.
Curso de Power BI Impressionador da Hashtag Treinamentos com projeto integrado e com mais de 110 horas.
Ementa para obtenção do Certificado:
1. Instruções Obrigatórias (Assista)
2. Introdução ao Power BI
3. Importação e Tratamento de Bases de Dados com PowerQuery
4. Relacionamentos
5. Funções DAX
6. Storytelling
7. Dashboard & Visualização de Dados
8. Checkpoint
9. Power BI Online
10. Exercícios de revisão
11. DAX Avançado
12. Conectando o Power BI com Bancos de Dados SQL e Introdução à linguagem SQL
Módulos opcionais (estou a fazê-los):
13. Biblioteca de Relatórios Impressionadores
14. Checkpoint 2
15. Introdução à Power Platform
16. Mentorias Tira Dúvidas Ao Vivo
17. Lives Dashboards
18. Certifcação Microsoft PL-300 (Antiga DA-100)
19. Lives Power Query & Linguagem M
20. Lives Power BI Online & Criação de Portfólio
21. Lives Modelagem de Dados
22. Lives DAX
23. Intensivão de Power BI – Edição 2.0
24. Intensivão de Power BI – Edição 3.0
25. Feedback Final
Para melhor visualização do dashboard aconselha-se a sua consulta em ambiente desktop
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.
Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Introdução
Já vimos na PARTE 1 – O que são Produtos Digitais. E na PARTE 2 – O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum.
Vamos agora ver na PARTE 3 – se Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Ambiente Waterfall
Em ambiente waterfall significa, de forma não exaustiva, o seguinte:
- O tipo de projeto não envolve incertezas. Ou seja já se sabe o que se vai desenvolver/construir. Por exemplo, uma casa ou uma piscina.
- As as atividades desse projeto, por estar inserido num ambiente de certeza e não de incerteza, são desenvolvidas sequencialmente. Ou seja, após o términos de uma atividade, começa-se a segunda.
- Não existe um envolvimento direto do cliente e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas
- Havendo possibilidade e vontade em fazer testes, estes são feitos em grande escala no final de todas as atividades estarem concluídas
Ambiente Agile
O ambiente agile significa, o contrário do ambiente waterfall. Ou seja, e de forma não exaustiva:
- Os projetos mais adequados para serem desenvolvidos neste tipo de ambiente são projetos complexos e que envolvem algum grau de incerteza. Por exemplo, o desenvolvimento de um produto digital, enquadra-se neste tipo de projetos.
- Todas as atividades que se consideram necessárias para produzir um incremento, são realizadas no sprint correspondente. E, portanto, daqui surgem duas grandes diferenças de projetos em ambiente waterfall e ambiente agile:
- As equipas devem ser multi-disiplinares e autónomas
- Os testes, devem ser considerados uma atividade que produz um incremento e, portanto, são realizados em cada sprint e não no final do projeto. Até porque, e passamos para o ponto 3…
- Tem de existir um envolvimento direto do cliente. Isto porque não sabemos a 100% como vai ser o produto final. E o cliente também não sabe. E, portanto o cliente tem de estar envolvido no desenrolar do projeto. Por exemplo, criando atividades de UX Research na fase em que Visão do Produto está a ser desenvolvida. E com isso, valorizamos e muito o início do projeto, porque a Visão do Produto incorpora findings e insights daquilo que são as necessidades, frustrações e motivações dos cliente.
- Outra altura onde o cliente pode estar presente será nas cerimónias de review para recolha direta de feedback. e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas. Ou seja, e vamos para o ponto 4…
- Há iterações entre as equipas, clientes e stakeholders. Iterações essas que nos vão permitindo afinar o produto final. Como? Redefinindo e refinando o backlog prioridades de produto e, posteriormente, o backlog da sprint.
Conclusão
Poder-se-ia dizer que se as metodologias, ou melhor, se os ambientes ou frameworks são diferentes, então, obrigatoriamente, será diferente criar um produto digital em ambiente agile do ambiente waterfall. E dizer isto não está errado. Afinal é uma verdade de La Palice.
O problema é que não basta dizer que estamos ou adotamos uma metodologia agiela e o desenvolvimento do produto digital, per si, será diferente.
Quem faz os ambientes serem waterfall ou agile ou de outro tipo são as pessoas. E, portanto, se não houver vontade, motivação, aprendizagem e um step-up, sem medos e com compreensão 100% da hierarquia de quais são os papéis de cada um e o que isso implica, para mudar a cultura da Empresa e assim efetivamente implementar o ambiente agile, o que vai acontecer é que estaremos a desenvolver um produto digital em ambiente “pseudo-agile”; ou seja na realidade o ambiente é waterfall.
Há várias de formas de perceber isso, elenco apenas quatro:
- O cliente não é envolvido de início e ao longo do desenvolvimento
- As equipas não são multi-disciplinares nem autónomas
- A priorização das atividades ou a re-priorização das mesmas ou de algumas delas, não é feita pelo PO, mas está dependente do cargo da pessoa que faz um pedido.
- Os testes são feitos “em barda” dias antes do lançamento do produto para o mercado
Espero que tenham gostado e aprendido alguma coisa neste conjunto de 3 artigos sobre produtos digitais.
O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum
Introdução
Já vimos na PARTE 1 – O que são Produtos Digitais. Vamos agora ver o que envolve, em termos de negócio e de equipas, criar um produto digital.
A PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall? Será publicada no final do mês de Agosto.
O que Envolve Criar um Produto Digital?
Criar um produto digital não é pensar o design e depois bater código. Desenvolver um produto digital envolve muito mais do que design e desenvolvimento. Tal como a construção de uma casa não envolve apenas um desenho do arquiteto. Ainda que a construção de uma casa seja um projeto fechado e um projeto que decorre em ambiente certo.
Existem diferentes temas que são essenciais para descobrir, posicionar, desenvolver, monitorar, comunicar e impulsionar a adoção deste tipo de produtos.
Visão do Produto – Envolve identificar os diferenciais do produto, definir a proposta de valor única e criar mensagens de marketing que comuniquem esses aspectos de maneira convincente.
User Experience Research – Antes de se criar um produto digital, é crucial realizar perceber quais as necessidades, motivações, frustrações, expectativas e emoções dos clientes ou potenciais clientes.
O trabalho de desenvolvimento de um produto digital deve ser feito com base em Outcomes e não em Outputs.
As atividades de UX Research fornecem uma base sólida para as decisões de design, permitindo que as equipas validem hipóteses, identifiquem problemas de usabilidade e iterem rapidamente com base no feedback dos utilizadores. Além disso, o foco contínuo nas atividades de UX Research possibilita a adaptação às mudanças ao longo do projeto, tornando o Scrum ainda mais eficiente e eficaz na entrega de soluções inovadoras e centradas no usuário.
User Interface Design – Aspeto fundamental do processo de desenvolvimento de produtos, dedicado a criar interfaces visualmente atraentes e user friendly que melhoram a experiência geral dos utilizadores. Estas atividades de desenho do user interface concentram-se em temas que permitam desenvolver interações entre os utilizadores e esses produtos digitais, garantindo que cada interação seja fluida e intuitiva
O User Interface Design não é só algo estético; deve haver um esforço para se encontrar o equilíbrio entre forma e função. Um interface bem pensado (UX Research) guiará os utilizadores ao longo do produto de forma suave e sem atritos, ajudando-os a realizar as suas atividades de forma eficiente e com o mínimo de frustração.
Podem saber mais sobre o tema Como Definir os Princípios de Design.
UX Writing ou Marketing de Conteúdo – A criação de conteúdo relevante e valioso é fundamental para a atração e retenção de potenciais utilizadores dos nossos produtos. O UX Writing não se restringe só à escrita de textos para blogues. Todo o conteúdo de um website ou loja online ou de outro produto digital deve ter uma estratégia de UX Writing. Além dos de vídeos, animações, white papers ……
E é preciso saber como escrevê-los; onde colocá-los no nosso produto e quando colocá-los.
SEO – A otimização para os motores de pesquisa é fundamental para garantir que o produto digital seja encontrado online, quando os utilizadores pesquisarem por keywords relevantes. Isso envolve a criação pensada e estruturada da arquitetura de Informação desse produto digital, a inserção/utilização adequada de keywords de forma a otimizar o conteúdo e a criação de backlinks.
O UX Writing ou Marketing de Conteúdo e o SEO são disciplinas que têm muita interligação entre si.
Acessibilidade – A acessibilidade no contexto do design, dentro de uma equipa que utiliza o Scrum, refere-se às atividades e práticas implementadas para garantir que o produto desenvolvido seja inclusivo e facilmente utilizado por todas as pessoas, independentemente de suas capacidades e/ou necessidades específicas. Este tema, tal como os anteriores e os a seguir devem ser considerados pelas equipas desde o início das atividades do projeto, incorporando-a em todas as etapas do ciclo Scrum.
Este tema, deverá ser também tido em conta aquando das atividades de UX Research. Podem ler mais sobre Empathy as a Service.
Analytics — Desempenha um papel fundamental no desenvolvimento de produtos dentro de um ambiente ágil. Ao aproveitar o poder dos dados e os insights que se obtêm a partir deles, as equipas podem tomar decisões informadas em cada etapa do processo de desenvolvimento.
Análises qualitativas — A incorporação de análises qualitativas capacita as equipas a adaptar estratégias com base no feedback dos clientes e em tempo real, garantindo que as suas necessidades, motivações, frustrações são tidas em conta no desenvolvimento do produto.
Análises quantitativas — Essas análises permitem compreensão profunda dos comportamentos, preferências e pontos problemáticos dos usuários, o que influencia significativamente o aperfeiçoamento e a otimização de produtos digitais. Podemos utilizar ferramentas de web analytics e/ou de user behaviour analytics.
Desenvolvimento – As atividades de desenvolvimento é tudo aquilo que engloba colocar em prática todo o trabalho desenvolvido nas atividades anteriormente descritas. O trabalho de desenvolvimento não é só olhar para o “design” e começar a programar. Algumas atividades que devem ser tidas em conta antes do desenvolvimento front-end e back-end apresentam-se abaixo.
-
- Arquitetura funcional
- Arquitetura técnica
- From-end development
- Back-end development e Gestão de Base de Dados
- Integração de sistemas e desenvolvimento de infra-estruturas
Testes – Em ambiente agile todas as user stories devem ser testadas pelo membro da squad para o efeito. Desenganem-se aqueles que acreditam que os testes são feitos pelas pessoas das organizações ou que se podem fazer depois testes de usabilidade com os clientes. Deixarmos a realização dos testes, com as funcionalidades já em produção, para outras pessoas e/ou para os clientes fazerem é meio caminho andado para que a dívida técnica/UX aumente. Além de que não cumpre com aquilo que a framework do scrum apregoa.
-
- Testes de Carga do Servidor
- Testes das Funcionalidades
- Produção de quick reports com as respetivas conclusões/correções a fazer
Depois numa fase já mais estabilizada do produto, podemos desenvolver então os testes com os utilizadores.
Gestão da Release – A gestão da release no contexto do Scrum refere-se ao processo de planeamento, coordenação e entrega dos outputs, sempre baseados em outcomes (o que defendo) desenvolvidas ao longo das várias sprints pronto para ser disponibilizado aos utilizadores.
Muito importante na gestão da release, nomeadamente se for uma gestão da release já com o produto “fechado” (se bem que o produto nunca estará fechado) é a definição da estratégia de lançamento.
Estratégia de Lançamento – A estratégia de lançamento engloba as atividades que têm como objetivo informar os utilizadores sobre as diversas vertentes do produto. A estratégia de lançamento focam-se, na sua maioria, em temas de comunicação como:
- Campanhas offline (TV, rádio, jornais, revistas, outro tipo de publicações)
- Organização de Eventos
- Campanhas online (e-mail, ppc, social media, afiliados, ….)
- Redes Sociais
- Influenciadores
Conclusão
É fundamental ter em atenção a todos estes temas quando se desenvolve um produto digital, seja em ambiente agile ou ambiente waterfall. Nomeadamente, é imperativo considerar estes temas em cada uma das fases dos ambientes agile:
- visão do negócio/produto
- Desenvolvimento do backlog do produto
- Desenvolvimento do backlog da sprint (Priorização de acordo com aquilo que é a visão do negocio)
- Cerimónias de Planeamento
- Cerimónias de Review
- Cerimónias de Retrospective
Além disso, fica bem patente, tal como o Scrum advoga, que um desenvolvimento de um produto digital não é só desenhar e programar o desenhado.
Sabe mais sobre Scrum neste artigo – Scrum for Dummies”: Papéis e Eventos – Comparação com o Futebol
Outcomes over Outputs - Key points da Leitura do Livro de Joshua Seiden
Introdução
Recentemente, tive a oportunidade de ler o livro “Outcomes over Output” de Joshua Seiden. Trata-se de um livro técnico, mas de leitura acessível e agradável. Para os verdadeiros amantes da leitura, é possível concluí-lo em apenas 40 minutos. É um livro que todos aqueles que trabalham na área de gestão, especialmente em responsabilidades relacionadas à Experiência do Usuário (UX), Experiência do Cliente (CX), Pesquisa, Proprietários de Produtos e Profissionais de Marketing Digital, devem adquirir, ler e implementar nas empresas em que atuam.
Apresento aquilo que foi a meu entendimento dos Key Points do livro com algumas anotações a azul que julgo ajudarem a compreender, na minha perspetiva, aquilo que é a ideia do livro.
Podem encontrar o livro na Amazon.
Key Points da Leitura do Livro Outcomes Over Output
1. Outcomes podem ser definidos como mudanças no mundo que melhoram, simplificam ou facilitam a vida das pessoas. De acordo com a definição de Joshua, são mudanças no comportamento das pessoas que geram valor para o negócio. Em minha opinião, essa definição implica que tornar a vida das pessoas mais fácil resultará em mudanças em seu comportamento, inclusive emocionalmente, o que, por sua vez, gerará valor tanto para elas quanto para o negócio.
2. Existem três abordagens para a gestão de equipas: a gestão baseada em Outputs, em que todo o trabalho se concentra em funcionalidades (nesse caso, o trabalho de pesquisa geralmente é praticamente inexistente); a gestão baseada no Impacto, que estabelece um objetivo de alto nível, muitas vezes abstrato e que as equipes operacionais não compreendem completamente, como o crescimento do produto; por fim, a gestão baseada em Outcomes, em que a equipa se pergunta que mudanças no mundo ou no comportamento das pessoas podem criar para tornar suas vidas mais fáceis, gerando assim valor para o negócio.
3. Para realmente entender se nosso trabalho está a causar uma mudança no comportamento das pessoas, tornando as suas vidas melhores, mais fáceis e/ou mais simples, devemos criar checkpoints que sejam curtos, mensuráveis e relacionados ao trabalho que estamos a realizar.
Em UX, chamamos isso de UX Progessive Metrics, que se baseiam no Outcome = UX Success Metrics.
4. Pensar em Outcomes coloca efetivamente as pessoas no centro e torna as empresas verdadeiramente orientadas para o cliente – Customer Centric.
Infelizmente, na maioria dos casos em Portugal, esse jargão é usado, mas na prática o que está no centro é o negócio e as funcionalidades, e uma das razões para isso é a falta de trabalho estratégico de pesquisa. Adotar a metodologia de estabelecimento de objetivos por meio de OKR (Objectives and Key Results) facilita esse trabalho e alinha todas as equipes e direções da empresa.
5. O MVP (Produto Mínimo Viável) não é apenas a versão 1.0 do produto, mas sim uma experiência que representa a menor ou mais simples “coisa” que podemos e devemos fazer para testar as hipóteses iniciais.
6. Independentemente de realizarmos o trabalho de UX Research junto dos clientes, precisamos responder às seguintes perguntas para criar Outcomes eficazes: 1 – Que mudança no mundo (incluindo o comportamento das pessoas) devemos criar para tornar suas vidas melhores, mais fáceis, mais simples e proporcionar valor a elas, gerando valor para o negócio? 2 – O que podemos ou devemos fazer para que as pessoas percebam e adotem essa mudança? 3 – Como iremos medir nosso trabalho para avaliar se estamos no caminho certo?
Lembrem-se das UX Progressive Metrics, aquelas métricas que nos ajudam a monitorar o progresso ao longo do tempo.
7. Uma vez definidos os Outcomes, é crucial adotar uma abordagem iterativa de aprendizado, que envolve três etapas principais: pesquisa, criação de experiências e medição dos Outcomes.
Se repararem o descrito pelo Joshua no seu livro nada mais é do que: Definir o problema; definir hipóteses de como resolvê-lo – How Might We. E por fim, perceber se estamos no caminho certo: Are we solving people’s problems? Ou seja, Are We developing the right thing?
Definir o Problema com base em UX Research: É fundamental realizar pesquisas contínuas para compreender as necessidades, desejos e dores dos utilizadores. Este trabalho de UX research pode incluir métodos qualitativos, como entrevistas e observação, e métodos quantitativos, como análise de dados e testes A/B.
How Might We com base na Criação de Experiências/Hipótrses: Com base nas descobertas iniciais, devemos gerar hipóteses e ideias para resolver os problemas dos utilizadores. Utilizando a técnica “How Might We”, podemos definir hipóteses claras sobre como resolver esses problemas e criar experiências relevantes.
Are We Developing the right Thing – Medição de Outcomes: É crucial medir os resultados das experiências criadas para verificar se estamos resolvendo efetivamente os problemas dos utilizadores. Devemos perguntar-nos constantemente: “Estamos a resolver os problemas das pessoas? Estamos a desenvolver a coisa certa?”
8. Diferentemente dos roadmaps baseados em funcionalidades, os roadmaps centrados em Outcomes tornam o trabalho mais ágil e as equipes mais informadas e focadas. Em vez de simplesmente adivinhar quais funcionalidades devem ser desenvolvidas, baseamos nossas decisões em pesquisas e evidências.
9. Todo esse trabalho parte da compreensão da jornada do cliente, também conhecida como Experiência As-Is. Ao entender a jornada atual do cliente, podemos ter uma percepção clara de como será a experiência futura e a visão de negócio.
10. Isto porque obriga-nos a responder a questões vindas do Research e não partimos do “guessing” que desenvolver a feature A ou B vai ser estupendo, porque é digital e, portanto é melhor e porque a concorrência também tem.
Conclusão
No campo da Experiência do Cliente – CX, a perspectiva compartilhada por Joshua Seiden no livro “Outcomes over Output” traz insights valiosos para o trabalho das equipas envolvidas em projetos desse tipo. Acredito firmemente que essa abordagem será altamente produtiva, pois concentra-se em proporcionar valor para o cliente, o que, por sua vez, resultará em benefícios significativos para o negócio, a curto, médio e longo prazo.
Proporcionando Valor para o Cliente – Outcomes e não Outputs
Quando nos dedicamos a criar Outcomes que ofereçam valor real aos clientes, estamos construindo uma base sólida para o sucesso do negócio. Ao pensar estrategicamente sobre como podemos melhorar a vida das pessoas, tornando-a mais fácil, mais simples e mais satisfatória, estamos investindo na criação de relações duradouras e gerando valor sustentável.
Por outro lado, quando colocamos o foco apenas no valor para o negócio, concentrando-nos em outputs ou impactos, nem sempre conseguimos traduzir esse valor para o cliente de forma direta e eficaz. Podemos observar isso em setores como o de telecomunicações, em que, por exemplo, somos “fidelizados” por um contrato de dois anos, mas acabamos pagando mais mensalmente. Essa situação claramente beneficia o negócio, mas não agrega valor real ao cliente. Além disso, pode resultar em um mercado com pouca concorrência, prejudicando a inovação e a oferta de alternativas melhores.
A Importância dos Outcomes
Ao adotar uma abordagem centrada em Outcomes, colocamos o cliente no centro de nossas ações e decisões. Ao proporcionar valor para o cliente, estamos investindo em sua satisfação e fidelidade, o que se reflete diretamente nos resultados do negócio. Afinal, clientes satisfeitos são mais propensos a recomendar produtos ou serviços, gerando um impacto positivo no crescimento e na reputação da empresa.
Acredito firmemente na abordagem proposta por Joshua Seiden, em que o foco nos Outcomes é fundamental para o sucesso de projetos de UX. Ao proporcionar valor real para o cliente, estabelecemos uma base sólida para o crescimento e a rentabilidade do negócio. Portanto, devemos sempre buscar soluções que tornem a vida das pessoas melhor, mais fácil e mais simples, promovendo uma relação de confiança e benefícios mútuos a longo prazo. Lembremo-nos de que o verdadeiro sucesso empresarial está intrinsecamente ligado ao sucesso e à satisfação dos clientes.