“Vagner tinha uma importante missão, precisava analisar dados de diversas fontes do departamento de marketing da empresa que recém entrou. Alguns dados procediam de sistemas como o Google Analytics, Google Ads, Google Search Console. Outros, vinham de planilhas, oriundas do CRM da empresa e também da própria equipe de vendas. Ele também descobriu que alguns dados originavam-se de campanhas de e-mail marketing, em um sistema contratado pela organização para esse tipo de campanha. Ele pensou que poderia organizar esses dados em um único banco, para centralizar seus estudos. Vagner conversou com um especialista em banco de dados de sua empresa, pedindo ajuda para montar um banco de dados com base em SQL, onde pudesse centralizar essas informações e através de consultas SQL realizar análises e combinações importantes.”

Como comentei em um artigo anterior, um dos hard skills mais importantes para quem busca colocação na área de análise de dados é conhecer os bancos de dados baseados em SQL. A verdade é que – embora tenhamos no mercado muitos bancos de dados não estruturados em funcionamento, principalmente quando se trata de big data – ainda existem muitos bancos estruturados com base em SQL sendo utilizados. Sendo assim, é muito importante que o analista conheça essa linguagem.

Existem muitos sistemas de gerenciamento de bancos de dados (SGBDs) baseados em SQL. Alguns exemplos:

1. MySQL: Um SGBD de código aberto que é amplamente utilizado em aplicativos da web devido à sua velocidade e confiabilidade.

2. Microsoft SQL Server: Desenvolvido pela Microsoft, é uma escolha popular para ambientes Windows e é conhecido pela escalabilidade e recursos avançados.

3. Oracle Database: É um SGBD poderoso usado por muitas empresas para gerenciar grandes volumes de dados. É conhecido por sua escalabilidade, segurança e recursos avançados.

4. PostgreSQL: Outro SGBD de código aberto que é altamente respeitado pela sua conformidade com os padrões SQL, extensibilidade e suporte a recursos geoespaciais.

Esses são apenas alguns dos SGBDs baseados em SQL mais conhecidos, e há muitos outros disponíveis, cada um com suas próprias vantagens e casos de uso específicos. A escolha do SGBD depende das necessidades e requisitos do projeto.

Modelos de banco de dados

Se imaginarmos um banco de dados tradicional, geralmente seu projeto pode começar de uma modelagem conceitual, onde é feito um rascunho do banco de dados, com as informações necessárias a serem guardadas e algumas regras de negócios importantes que podem fazer a diferença no futuro sistema que irá alimentar. 

Nessa fase, já existe uma visão dos dados que serão captados, quais os tipos (número, texto, data, etc), entre outras informações importantes para ser possível construir sua estrutura.

Voltando para nossa história, o DBA  (database administrator – colega de Vagner) irá fazer uma modelagem lógica desse banco, e, assim, projetar suas tabelas e o relacionamento entre elas. Após, irá incluir os dados de todos os sistemas de marketing, e, por fim, disponibilizar esses dados. Assim, será possível Vagner realizar suas análises, enviar informações para os gestores da empresa, de modo que possam tomar decisões importantes.

Todas as ações nesse tipo de organização, como às do nosso personagem, são fundamentadas nos dados. Sendo assim, o analista de business intelligence (Vagner) pode ter várias fontes de informação oriundas de vários sistemas e pode trabalhar com essas informações em um único local, o que irá ajudar muito o trabalho, afinal esses dados estarão limpos, padronizados e armazenados. 

Nesse ponto, na minha visão, bancos de dados baseados em SQL ajudam muito, pois eles podem funcionar como uma espécie de data warehouse.

Scripts de consulta importantes

Para começar a trabalhar com dados e iniciar sua análise, o analista precisa dominar scripts importantes, ou seja, ele precisa conhecer a cadeia de comandos SQL para consultar e combinar informações.

Com o banco de dados pronto e suas tabelas organizadas com seus respectivos dados, Vagner começa a executar alguns scripts de consulta. Sendo assim, conversando com o DBA da empresa que trabalha, Vagner foi convencido que o Bigquery seria o banco de dados ideal para o que ele precisa, pois já haveria uma conexão nativa de diversos sistemas para esse banco, além de ele poder executar algumas consultas de forma rápida e fácil. Vagner concordou e dessa forma seu colega montou o banco e disponibilizou o acesso para ele”.

Vagner já é experiente no uso de SQL, e usou essa linguagem para saber quais os dias com maior visitas no site.

Os dados de visitas estavam vindo do Google Analytics. Sendo assim, ele escreveu o comando a seguir.

WITH DailyVisits AS ( SELECT DATE(date) AS Day, COUNT(*) AS Visits FROM `seu_projeto.sua_dataset.sua_tabela` WHERE DATE(date) BETWEEN 'AAAA-MM-01' AND 'AAAA-MM-31' GROUP BY Day ) SELECT Day FROM DailyVisits ORDER BY Visits DESC LIMIT 1;

Nesta consulta, por exemplo, nosso personagem escreveu uma cláusula CTE (Common Table Expression) chamada DailyVisits para criar uma tabela temporária que contém duas colunas: “Day” (Dia) e “Visits” (Visitas). Nesta tabela temporária, ele contou o número de visitas para cada dia no mês desejado.

Na consulta principal, ele selecionou o “Day” (Dia) com o maior número de visitas (ordenado em ordem decrescente) usando a cláusula ORDER BY e limitando o resultado a 1 com LIMIT 1.

Esta consulta retornará o dia com o maior número de visitas no mês especificado.

Vagner também quis saber qual foi o dia com maior número de vendas naquele mês. Ele criou uma hipótese, que o dia com mais visitas fora o dia que mais teve vendas:

WITH DailySales AS ( SELECT DATE(date) AS Day, COUNT(DISTINCT transaction_id) AS Sales FROM `seu_projeto.sua_dataset.sua_tabela` WHERE DATE(date) BETWEEN 'AAAA-MM-01' AND 'AAAA-MM-31' AND transaction_id IS NOT NULL GROUP BY Day) SELECT Day FROM DailySales ORDER BY Sales DESC LIMIT 1;

Nesta consulta, mais uma vez Vagner usou cláusula CTE chamada DailySales para criar uma tabela temporária que contém duas colunas: “Day” (Dia) e “Sales” (Vendas). Nesta tabela temporária, ele contou o número de transações (vendas) para cada dia no mês especificado.

Continuando com sua análise, Vagner percebeu que o dia com maior receita, teve uma quantidade de visitas menor do que dia com maior número de usuários. Percebeu, porém, que naquele dia com maior receita, os usuários que entraram no site, contribuíram para aumentar o ticket médio das compras.

Vagner fez outras pesquisas através do SQL, obtendo mais informações sobre campanhas, clientes que mais compraram no site, entre outras informações que permitiram entender o motivo de menos tráfego e mais vendas. Alguns colegas relataram ao nosso herói que algumas campanhas-teste foram lançadas para públicos importantes naquela data, mas que a verba era mais restrita para a operação da empreitada, pois gastaram boa parte do orçamento com uma campanha que trouxe muitos usuários e poucas vendas.

Vagner percebeu que, com uma verba mais restrita, os analistas de marketing necessitavam ser mais precisos no atingimento de públicos que realmente iriam clicar nas campanhas e comprar os produtos que estavam veiculando. Ele montou uma apresentação com os dados obtidos, onde, através de gráficos, mostrava o que ele tinha visto em suas consultas e combinações no banco de dados, para defender sua hipótese. Os executivos da empresa concordaram com sua hipótese e defenderam que mais campanhas fossem feitas nas regiões campeãs de vendas e que, posteriormente, fossem mensurados os dados novamente.

O banco de dados ajudou para que Vagner reunisse os dados em um único local, mas é importante comentar que, mesmo com suas análises e primeiras impressões, ele conversou com os executores das campanhas para que fosse possível contextualizar e comprovar o cenário que ele via através dos números. 

Conclusão

Nesse artigo, através da história de Vagner, mostrei como o personagem pôde utilizar um banco de dados baseado em SQL para reunir informações do marketing da sua empresa com a finalidade de realizar análises de navegação e de clientes, entre outras informações importantes e que, além disso, a contextualização desses fatos foram cruciais para que o analista pudesse trabalhar com uma hipótese e ajudar os executivos a tomarem boas decisões de marketing.