Transformando Dados de Pets e Tutores em Insights

No mundo atual, dados são o novo petróleo — mas, assim como o petróleo bruto, precisam ser refinados para gerar valor real. Foi com essa mentalidade que desenvolvi este projeto de dashboard no Power BI, integrado a um ecossistema completo que inclui um formulário de coleta de dados e uma API Rest.

O projeto faz parte de uma iniciativa maior disponível nesse projeto, que visa automatizar o relacionamento com clientes de uma empresa do setor pet, utilizando inteligência artificial para personalizar comunicações com base nos dados dos pets e tutores.

O processo de ETL é a espinha dorsal de qualquer projeto de Business Intelligence (BI). Ele consiste em três etapas fundamentais:

ETL – Extrair, Transformar e Carregar

O processo de ETL foi fundamental para garantir consistência:

1. Extrair: dados vindos de três fontes — banco de clientes, pedidos e produtos, além do formulário online.
2. Transformar: padronização de IDs, normalização de datas, categorização de condições de saúde e porte dos pets.
3. Carregar: integração em um modelo relacional otimizado para análises no Power BI.

Esse fluxo resolve problemas comuns como duplicidade de registros, inconsistência de status e ausência de chaves primárias bem definidas.

1. Extração (Extract)

Nesta fase, os dados são coletados de suas fontes originais. No meu projeto, isso significou conectar-me a:

• Banco de dados de clientes: contendo informações como CPF, email, endereço, estado e nome do tutor.
• Banco de dados de pedidos: com dados de data do pedido, status, valor total e relação com clientes e produtos.
• Banco de dados de produtos: incluindo nome, preço, desconto e frete grátis.
• Formulário: que coleta informações específicas dos pets, como porte, condição de saúde, data de nascimento e motivo do uso do produto Condropure.

A extração foi realizada via API Rest, que atua como uma ponte entre o formulário e o sistema de armazenamento de dados. O formulário está hospedado em pet-form.wuaze.com e é responsável por coletar dados essenciais que não estavam disponíveis nas bases tradicionais.

2. Transformação (Transform)

Esta é a etapa mais crítica e trabalhosa. Aqui, os dados brutos são limpos, padronizados e preparados para análise. No Power BI, isso é feito principalmente utilizando o Power Query com a linguagem M.

As principais transformações realizadas incluíram:

• Padronização de formatos: datas foram convertidas para um formato consistente, permitindo análises temporais precisas.
• Criação de colunas calculadas: por exemplo, a idade do pet foi calculada a partir da data de nascimento.
• Normalização de categorias: as condições de saúde dos pets (como "Artrite/Artrose", "Displasia coxofemural" e "Pós-cirurgia ortopédica") foram padronizadas para permitir análises agregadas.
• Conversão de tipos de dados: garantir que campos como valores monetários e números estejam nos formatos corretos para cálculos.

Utilizei a função buildPetRecordPayload no PHP para estruturar os dados dos pets de forma consistente antes de enviá-los para o CRM, garantindo que cada pet tivesse campos como nome, data de nascimento, porte e condição de saúde devidamente formatados.

3. Carregamento (Load)

Com os dados transformados, o próximo passo é carregá-los no modelo de dados do Power BI. Essa etapa envolve não apenas a importação dos dados, mas também a definição de como as diferentes tabelas se relacionam — o que discutiremos em detalhes a seguir.

O poder de um dashboard está na capacidade de conectar diferentes conjuntos de dados para gerar insights que não seriam possíveis analisando cada fonte isoladamente . Para isso, é essencial entender os tipos de relacionamento entre tabelas.

A relação entre Pets e Tutores (Clientes) é um dos pontos centrais do projeto:

• 1:1 (um para um): ocorre quando cada tutor tem exatamente um pet cadastrado. É raro nesse contexto, mas pode existir em bases simplificadas.
• 1:N (um para muitos): o caso mais comum, onde um tutor pode ter vários pets. Esse relacionamento é essencial para análises de faturamento por tutor e condição de saúde.
• N:1 (muitos para um): vários pedidos podem estar associados a um único produto.
• N:N (muitos para muitos): pode surgir em cenários mais complexos, como quando um pet participa de múltiplos planos ou serviços.

No Power BI, configurar corretamente esses relacionamentos evita problemas como valores duplicados ou Em branco nos visuais.

Relacionamento 1:1 (Um para Um)

Este tipo de relacionamento ocorre quando um registro em uma tabela corresponde a exatamente um registro em outra tabela. Por exemplo, se cada cliente tivesse apenas um pet cadastrado, teríamos um relacionamento 1:1 entre a tabela de clientes e a tabela de pets.

No entanto, este relacionamento não é recomendado na prática, pois geralmente indica um design de modelo ineficiente . Como a documentação da Microsoft orienta, relacionamentos 1:1 "contribuem para a desordem do painel Dados, dificultam a localização de campos relacionados por autores de relatório e limitam a capacidade de criar hierarquias" . Em vez disso, o ideal é consolidar as tabelas em uma única.

Relacionamento 1:N (Um para Muitos)

Este é o relacionamento mais comum e poderoso no Power BI. Ele ocorre quando um registro em uma tabela pode estar associado a múltiplos registros em outra.

No meu projeto, o relacionamento entre clientes (um) e pets (muitos) é um exemplo clássico de 1:N — um tutor pode ter vários pets. Este relacionamento foi implementado através do campo ID-PET na tabela de clientes e ID-OWNER na tabela de pets.

A importância deste relacionamento foi destacada no projeto Pet Form Twenty API, onde a função createOrUpdatePerson busca ou cria um tutor no CRM e, para cada pet, cria um registro vinculado ao tutor via petOnwerId . Isso permite que um tutor tenha vários pets e cada pet tenha características específicas.

Relacionamento N:1 (Muitos para Um)

Este é simplesmente a visão inversa do relacionamento 1:N. No Power BI, é a direção padrão para relacionamentos entre tabelas fato (que contêm transações) e tabelas dimensão (que contêm descrições).

Por exemplo, na relação entre pedidos (muitos) e clientes (um), o Power BI entende que muitos pedidos podem pertencer a um único cliente.

Relacionamento N:N (Muitos para Muitos)

Este relacionamento ocorre quando vários registros em uma tabela podem estar relacionados a vários registros em outra, como entre produtos e pedidos no meu projeto — um pedido pode conter vários produtos, e um produto pode aparecer em vários pedidos.

Embora o Power BI suporte relacionamentos N:N, eles são geralmente evitados por introduzirem ambiguidade nos dados . É preferível criar tabelas de ponte (também conhecidas como tabelas de fato) para resolver esse tipo de relacionamento.

Direcionalidade do Filtro e Relacionamentos Ativos/Inativos

Além da cardinalidade, o Power BI permite controlar a direção do filtro entre as tabelas. Em relacionamentos 1:N, o filtro flui da tabela "um" para a tabela "muitos" por padrão .

Também podemos ter relacionamentos inativos (representados por linhas tracejadas), que não propagam filtros automaticamente, mas podem ser ativados em medidas DAX específicas usando a função USERELATIONSHIP. Isso é útil para cenários onde uma tabela de fato tem múltiplas relações com uma tabela dimensão, como uma tabela de pedidos que tem tanto data do pedido quanto data de entrega.

No meu projeto, após carregar os dados e estabelecer os relacionamentos corretos, o modelo de dados ficou pronto para receber métricas personalizadas.

O Poder do DAX: Criando Métricas Personalizadas

Com o modelo de dados estabelecido, o próximo passo é criar medidas e colunas calculadas utilizando DAX (Data Analysis Expressions).

A linguagem DAX permite criar cálculos dinâmicos que respondem às interações dos usuários com os filtros e slicers do dashboard. Algumas medidas que criei incluíram:

• Faturamento Total: SUM(pedidos[VALOR-TOTAL])
• Faturamento por Porte de Pet: utilizando CALCULATE e FILTER para cruzar dados de pedidos com informações dos pets.
• Média de Valor por Pedido: AVERAGE(pedidos[VALOR-TOTAL])
• Contagem de Clientes por Estado: COUNT(clientes[ID-CLIENTE])

Após todo o processo de ETL, modelagem e criação de métricas, o dashboard revelou padrões interessantes:

1. Concentração de Vendas por Porte de Pet

Os dados mostraram que a maior parte das vendas do período analisado foi para cães de Porte Gigante, Médio e Mini. Esta distribuição sugere que o produto Condropure atende bem tanto donos de cães de grande porte — que podem ter maior predisposição a problemas articulares devido ao peso — quanto de portes menores, onde a condição de saúde pode ser o fator determinante.

2. Condições de Saúde Prevalentes

As três principais condições de saúde associadas às compras foram:

• Artrite / Artrose
• Displasia coxofemural
• Pós-cirurgia ortopédica

3. Relação entre Porte e Condição de Saúde

Uma análise mais aprofundada permitiu cruzar porte e condição de saúde, revelando que:

• Cães de porte gigante com displasia são os maiores consumidores
• Cães de porte mini em pós-cirurgia ortopédica também representam um segmento significativo

Desafio 1: Integração de Múltiplas Fontes

O principal desafio foi unificar dados de três fontes diferentes com estruturas variadas. A solução foi realizar um ETL robusto, padronizando os dados no Power Query antes de carregá-los no modelo.

Desafio 2: Relacionamento entre Tabelas de Diferentes Granularidades

Conectar dados de clientes (nível indivíduo) com dados de pedidos (nível transação) e dados de pets (nível animal) exigiu atenção especial à cardinalidade e à criação de chaves estrangeiras consistentes.

Desafio 3: Performance com Grandes Volumes

À medida que os dados cresciam, a performance do dashboard poderia ser comprometida. Para mitigar isso, evitei ao máximo relacionamentos 1:1 e N:N, seguindo as recomendações da Microsoft para um modelo mais eficiente .

Desafio 4: Objetos Customizados no CRM

A integração com o Twenty CRM exigiu a criação de objetos customizados para representar os pets, conforme detalhado no projeto Pet Form Twenty API . Utilizando os conceitos de Metadata do Twenty, foi possível criar objetos "Pet" com campos específicos como porte, idade e condição de saúde, sem necessidade de alterações no backend.

Um aspecto fundamental do projeto foi a capacidade de criar objetos customizados no CRM para representar os pets . No Twenty CRM, objetos customizados são definidos através de metadados, não de código:

Custom Objects in Twenty are defined through metadata, not code.

Isso significa que é possível criar novos tipos de dados no CRM sem escrever uma linha de código no backend.

A estrutura implementada permite que um tutor tenha vários pets, cada um com suas próprias características:

• Nome
• Data de nascimento
• Porte
• Idade
• Condição de saúde
• Motivo do uso do produto
• Primeira vez usando o produto

A vinculação entre tutor e pet é feita através do campo petOnwerId, que atua como uma chave estrangeira no banco de dados .

Este design hierárquico é essencial para que o sistema de IA possa:

• Identificar que múltiplos pets pertencem ao mesmo tutor
• Entender as condições de saúde específicas de cada animal
• Recomendar produtos personalizados com base no porte, idade e condição de cada pet

Este projeto demonstrou como a combinação de ETL eficiente, modelagem de dados adequada, relacionamentos bem definidos e métricas personalizadas pode transformar dados brutos em insights acionáveis.

O dashboard não apenas revelou que a maioria das vendas se concentra em cães de Porte Gigante, Médio e Mini com condições como Artrite, Displasia ou em pós-cirurgia ortopédica, mas também permitiu compreender o perfil dos clientes e suas necessidades específicas.

Projeto Completo no Power BI.