Recebi uma base de vendas com 35 clientes distribuídos em 6 cidades. O objetivo era analisar a distribuição geográfica das vendas, mas havia um problema grave: coordenadas inconsistentes.

Inicialmente tentei usar métodos estatísticos tradicionais (média, desvio padrão, z-score). Mas eles falharam por um motivo simples:

Exemplo Recife:
Pontos válidos: -8.05, -8.12
Outlier: 51.51 (Londres!)
Média: 11.78 (Nenhum ponto está perto disso)
Z-score: Todos seriam outliers ou nenhum

Recife tinha 3 clientes. Dois com coordenadas corretas e um com coordenadas de Londres (51.5074, -0.1278).

desvio = √[(-8.0476-51.5074)² + (-34.877+0.1278)²] / √2
desvio = √[59.555² + (-34.7492)²] / 1.414
desvio = 48.4 (muito alto)

Latitude corrigida = (-8.0476 + -8.1200) / 2 = -8.0838
Longitude corrigida = (-34.8770 + -34.9500) / 2 = -34.9135

Compare visualmente o impacto da correção. Os pontos vermelhos são os outliers identificados. Após a correção, eles se reposicionam para o centro geográfico correto de sua cidade (pontos laranjas). O tamanho do círculo representa a quantidade de itens comprados.

Tudo começou com uma conversa rápida. Meu gestor chegou e disse: “Precisamos de um acompanhamento semanal do estoque de propostas por superintendência. Dá pra fazer?”.

Até então, essa tarefa não era feita de forma consistente. Não porque fosse difícil no papel, mas porque executá-la manualmente para 11 superintendências era inviável.

O que acontecia na prática? Não acontecia. A rotina era tão pesada que o acompanhamento era feito esporadicamente, quando sobrava tempo. E quando era feito, os erros eram constantes: gráfico trocado, valor da meta errado, destinatário incorreto. A informação chegava errada ou simplesmente não chegava.

A demanda foi deixada de lado por meses. Até que meu gestor reativou o assunto e perguntou se eu conseguiria automatizar. Eu disse que sim.

Eu sabia que o maior risco não era técnico, era de aderência. O código precisava entregar exatamente o que o analista faria manualmente, senão ninguém confiaria.

1. Entendendo a lógica de negócio

A primeira semana foi só conversa. Entendi como os analistas calculavam o "mês limite do estoque" - a lógica usava percentuais cumulativos sobre a meta anual. Mas tinha uma pegadinha: o valor contratado no ano também entrava na conta. Se eu somasse errado, a projeção mensal ficava distorcida.

# Lógica validada com o time de negócios
def estoque(super, meta):
    credito = sum(base_credito[super])   # estoque atual
    contratado = sum(base_contratacao[super])  # valor já contratado no ano
    total = credito + contratado
    
    for i, perc in enumerate(percentuais):
        if total/meta <= perc:
            return meses[i]  # mês correspondente

2. O desafio dos gráficos

Gerar gráfico no Python é fácil. Inserir no Excel, na aba certa, com a cor da empresa, protegido e com o título correto... essa foi a parte mais demorada.

Usei openpyxl para criar chartsheets, mas descobri que o gráfico só aceitava referências de uma aba de dados. Solução: criar abas auxiliares e ocultá-las como "veryHidden", protegendo o workbook com senha. O usuário final nem vê, mas o gráfico funciona perfeitamente.

3. O e-mail que não podia falhar

O corpo do e-mail era um HTML gigante, com placeholders espalhados: nome do interlocutor, meta, valores calculados, projeção de meses, ticket médio, quantidade de propostas necessárias...

No começo, eu substituía tudo com .replace(). Funcionava, mas era frágil. Reestruturei para usar funções específicas de formatação e centralizei a lógica de cada cálculo. Hoje, se a regra de negócio mudar, eu altero um único ponto do código.

A primeira versão rodou. Os gráficos saíram. Os e-mails foram enviados.

E veio o retorno: “O título do gráfico está repetido”, “A cor da barra não é a da empresa”, “O valor do ticket médio está em reais, mas deveria estar em milhares”.

Foram semanas de ajustes finos. Corrigi formatação, padronizei cabeçalhos, inseri tratamento para bases vazias, normalizei datas e criei funções de limpeza para evitar erros.

No final, o código ficou robusto o suficiente para rodar sem supervisão. Hoje, o processo que antes era ignorado agora entra na caixa de entrada dos superintendentes toda semana, sem falhas, com 5 minutos de execução.

Projeto em produção desde então. O código é executado semanalmente e qualquer ajuste na regra de negócio é implementado em horas, não dias.

Picos de faturamento: abril (R$ 1,06M) e dezembro (R$ 1,02M).

A lição: Meses como Janeiro (48,75%) e Fevereiro (48,44%) vendem menos, mas tem uma ótima margem de lucro.

Criei uma coluna no Power BI que compara cada produto com a média geral de faturamento e margem. O resultado é uma classificação em 4 grupos, que me permitiu enxergar o problema principal.

A base é muito saudável: o risco de depender de um único grande cliente é baixíssimo.

Top 10 clientes < 1% do faturamento total.

Mas os melhores clientes (Diamante/Ouro) mostraram um problema. Eles gastam 27% do seu dinheiro nos produtos de baixa performance (os de baixa margem). Ou seja, eles estão acostumados a comprar o que é mais famoso, mas não o que é mais rentável para a confeitaria.

O lucro de R$ 2,45 Mi é a diferença entre o faturamento (R$ 8,49 Mi) e o custo total (R$ 6,03 Mi). A folha de pagamento não é a vilã. O problema real é o custo dos produtos, especialmente o custo dos itens de baixa performance.

• 15 produtos "Vermelhos" drenando quase 1/4 do faturamento total.
• Alta dependência dos picos de Abril e Dezembro. E se um deles der errado?
• Clientes Diamantes comprando os produtos errados (os "Vermelhos"). É um hábito que precisa ser mudado.

Este projeto nasceu da necessidade de tornar a disciplina diária mais engajante. Aplicando conceitos de gameficação com Python, criei um sistema onde cada atividade produtiva rende XP, conquistas desbloqueiam recompensas, e faltas geram penalidades.

Uma cliente trabalhava em uma empresa que oferecia cursos de segurança do trabalho. No final de cada curso, os alunos faziam uma prova e quem tirava nota acima de 7 recebia um certificado validado pelo ClickSign.

Em um projeto crítico no setor de Agronegócio do Banco do Nordeste, foi identificada a necessidade de enriquecer a base de clientes com informações de contato atualizadas, incluindo DDD, telefone/celular e uma flag indicando disponibilidade no WhatsApp para comunicação.

Os dados eram obtidos através de uma consulta SQL complexa que cruzava múltiplas tabelas do sistema bancário, porém inconsistências estruturais comprometiam a qualidade da informação.

• Identificador Incompatível: O código do cliente retornado pelo SQL possuía um dígito adicional, impossibilitando o relacionamento direto com a base principal de clientes.
• Duplicidade Maciça: A base de telefones apresentava repetição excessiva, com alguns clientes possuindo o mesmo número registrado milhares de vezes em diferentes datas.
• Distorção de Métricas: A junção direta das tabelas geraria multiplicação indevida de valores financeiros, comprometendo a precisão dos relatórios executivos.

O processo garantiu que cada cliente permanecesse representado por uma única linha no modelo final, preservando a integridade dos dados e evitando inconsistências nos indicadores financeiros. A solução foi implementada em produção e atende diariamente mais de 500 usuários da área de Agronegócio.

Todo analista de dados já recebeu uma base com esses problemas: datas em formatos diferentes, valores como texto, cidades sem padronização e IDs duplicados. Resolver manualmente consome horas, mas com Python, a solução leva 2 minutos.

A equipe de análise gastava 8 horas semanais coletando, tratando e consolidando dados de 5 fontes diferentes (Excel, CSV, API, Banco de Dados, PDF) para gerar relatórios de performance.

O processo era propenso a erros humanos, inconsistências nos dados e atrasos na entrega para a diretoria.

Quando você escreve WHERE DATEDIFF(MONTH, dt_ctr, GETDATE()) <= 6, o banco de dados precisa calcular essa diferença para cada linha da tabela antes de aplicar o filtro. Isso geralmente impede o uso de índices e pode deixar a consulta muito lenta em bases grandes.

SELECT *
FROM contratos
WHERE DATEDIFF(MONTH, dt_ctr, GETDATE()) <= 6

O DATEADD move uma data no tempo. Quando você escreve WHERE dt_ctr >= DATEADD(MONTH, -6, GETDATE()), o SQL calcula a data de referência uma única vez e depois compara valores diretos - permitindo o uso do índice da coluna dt_ctr.

SELECT *
FROM contratos
WHERE dt_ctr >= DATEADD(MONTH, -6, GETDATE())

DATEDIFF é ideal para exibir ou analisar diferenças: tempo de permanência de clientes, idade de registros, prazos. Exemplo: SELECT DATEDIFF(DAY, '2026-01-01', GETDATE()) retorna quantos dias se passaram desde o primeiro dia do ano.

DATEADD é ideal para filtros e cálculos de intervalo. Mova a data de referência, não a coluna indexada.

O banco roda 100% no seu browser via SQL.js (WebAssembly). Nenhum dado é enviado a servidor algum. Edite a query livremente.

Use quando precisa saber quantos ou quanto: total de pedidos por cliente, faturamento por região, média por categoria.

SELECT nome_cliente, COUNT(*) as total_pedidos
FROM pedidos
GROUP BY nome_cliente

Resultado: João (3), Maria (2), Pedro (2).

Use quando precisa saber se existe pelo menos um registro que satisfaz uma condição. O EXISTS para assim que encontra o primeiro resultado - não processa o restante. Isso o torna mais eficiente para filtros de presença.

-- Clientes que fizeram ao menos 1 pedido do tipo 1
SELECT DISTINCT nome_cliente
FROM pedidos p1
WHERE EXISTS (
    SELECT 1 FROM pedidos p2
    WHERE p2.id_cliente = p1.id_cliente
      AND p2.id_tipo = 1
)

Maria não aparece porque nenhum de seus pedidos tem id_tipo = 1. O EXISTS encontrou isso sem precisar agregar nenhum dado.

Banco rodando 100% no browser via SQL.js. Edite a query livremente.

Precisava entender o que cada código de tipo de segmentação representava no sistema. Pelo SQL, não havia tabela com a descrição desses códigos de forma direta.

A solução manual era filtrar a consulta por um tipo de segmentação, pegar o ID do cliente e do contrato e visualizar no sistema. Cada código exigia uma consulta diferente - para N tipos, N execuções.

Em vez de continuar filtrando um tipo por vez, usei ROW_NUMBER() OVER (PARTITION BY tipo_segmentacao ORDER BY data_inicio DESC). O PARTITION BY numera os registros dentro de cada código separadamente. Com rn <= 5, trago os 5 registros mais recentes de cada tipo em uma única execução.

SELECT * FROM (
  SELECT
    op.cli_id,
    data_inicio,
    contrato_id,
    tipo_segmentacao,
    ROW_NUMBER() OVER (
      PARTITION BY tipo_segmentacao
      ORDER BY data_inicio DESC
    ) AS rn
  FROM database..tabela_operacoes op
  LEFT JOIN database..tabela_clientes cli
    ON op.cli_id = cli.cli_id
  WHERE forma_quitacao IN (0, 1, 2)
) x
WHERE rn <= 5
ORDER BY tipo_segmentacao, rn

O resultado: todos os tipos de segmentação em uma única consulta, com os registros mais recentes de cada um - prontos para consultar no sistema e entender o significado de cada código.

Banco rodando 100% no browser via SQL.js. Edite a query livremente.

Todo dia 10, entrego o relatório dos 10 maiores clientes PF. A necessidade de incluir a renda de cada um trouxe um desafio: a base de renda é histórica. O cliente atualiza a renda periodicamente, gerando múltiplos registros.

Ao fazer um JOIN convencional, o relatório triplicava as linhas e distorcia completamente a soma dos valores. A informação chegava errada.

SELECT
  [ID Cliente]   = CLI.ID,
  [Renda Anual]  = SUM(REC.VALOR_RECEITA),
  [Data Base]    = MAX(REC.DATA_REFERENCIA)
FROM BASE_CLIENTES CLI

CROSS APPLY (
  SELECT TOP 1 * FROM BASE_RENDA RD
  WHERE RD.ID_CLIENTE = CLI.ID_CLIENTE_BASE
    AND RD.TIPO_OPERACAO = 1
    AND RD.NOTACREDITO IS NOT NULL
    AND RD.CLASSIFICACAO IS NOT NULL
) AV

INNER JOIN BASE_RECEITAS REC ON
  REC.ID_CLIENTE = CLI.ID AND
  REC.VALOR_RECEITA IS NOT NULL AND
  REC.VALOR_RECEITA <> 0 AND
  REC.STATUS = 'A'

WHERE REC.DATA_REFERENCIA = (
  SELECT TOP 1 REC2.DATA_REFERENCIA
  FROM BASE_RECEITAS REC2
  WHERE REC2.ID_CLIENTE = REC.ID_CLIENTE
    AND REC2.STATUS = 'A'
  ORDER BY REC2.DATA_REFERENCIA DESC
)
GROUP BY CLI.ID

Resultado: um único registro por cliente com todos os indicadores corretos.

Banco rodando 100% no browser via SQL.js. Edite a query livremente.

Sistemas antigos frequentemente armazenam CPF como campo numérico. O problema: CPFs que começam com zero perdem o dígito inicial. Um CPF como 012.345.678-90 vira 12345678 no banco - e qualquer JOIN com outra tabela que espera 11 dígitos quebra silenciosamente.

Nesse sistema, o CPF estava dividido em dois campos: NR_CPF (os 9 primeiros dígitos) e DV_CPF (os 2 dígitos verificadores). Ambos numéricos, ambos sujeitos a perder zeros.

REPLICATE cria uma string de zeros com o tamanho necessário para completar. RIGHT garante que o resultado final tenha exatamente o tamanho correto. MissingField.Ignore no Power Query equivaleria ao terceiro parâmetro aqui - segurança sem alterar a fonte.

SELECT ID_CLI, NM_CLI,
  CASE
    WHEN LEN(NR_CPF) < 9
    THEN RIGHT(
      REPLICATE('0', 9 - LEN(NR_CPF)) + CAST(NR_CPF AS VARCHAR), 9)
    ELSE CAST(NR_CPF AS VARCHAR)
  END +
  CASE
    WHEN LEN(DV_CPF) < 2
    THEN RIGHT(
      REPLICATE('0', 2 - LEN(DV_CPF)) + CAST(DV_CPF AS VARCHAR), 2)
    ELSE CAST(DV_CPF AS VARCHAR)
  END AS CPF
FROM DB..TABELA
WHERE ID_TP_CLI = 'F'

O resultado é um CPF formatado com 11 dígitos, pronto para JOIN com qualquer outra tabela - sem tocar na estrutura original do banco.

SQLite não tem REPLICATE - usamos SUBSTR('000000000'||NR_CPF, -9) que produz o mesmo resultado. Banco rodando 100% no browser.

Você compara R$ 8M de 2025 inteiro com R$ 4M de 2026 até maio. Parece queda de 50% - mas na verdade é crescimento. O problema é comparar períodos diferentes: um ano fechado contra outro em andamento.

O valor de 2025 vai de 01/01/2025 até o mesmo dia e mês de hoje, mas em 2025. Assim os dois períodos são sempre comparáveis, independente de quando o relatório for aberto.

Contratado 2025 =
CALCULATE(
  SUM('base2026'[valor]) + 0,
  'base2026'[data] >= DATE(2025,1,1),
  'base2026'[data] <= DATE(2025, MONTH(TODAY()), DAY(TODAY()))
)

Contratado 2026 =
CALCULATE(
  SUM('base2026'[valor]) + 0,
  'base2026'[data] >= DATE(2026,1,1),
  'base2026'[data] <= TODAY()
)

%Variação =
IF(
  AND([Contratado 2025]=0, [Contratado 2026]>0), 1,
  IF(
    AND([Contratado 2025]=0, [Contratado 2026]=0), 0,
    DIVIDE([Contratado 2026], [Contratado 2025], 0) - 1
  )
)

Um dashboard de análise de performance precisa mostrar o custo total em diferentes contextos: por cliente, por mês, ou visão geral. O problema é o custo de salário: ele é fixo anual, mas se você filtra por um único cliente, incluir o salário inteiro distorce completamente a margem daquele cliente.

A medida detecta qual filtro está ativo usando ISCROSSFILTERED e ISFILTERED, e ajusta o salário automaticamente para cada contexto.

Custo Total =
VAR TemFiltroCliente = ISCROSSFILTERED(dim_clientes)
VAR TemFiltroMes    = ISFILTERED('calendário'[Nome do Mês])
VAR SalarioAjustado =
    SWITCH(TRUE(),
        TemFiltroCliente,  0,
        NOT TemFiltroMes,  [Custo Salário] * 12,
        TRUE,              [Custo Salário]
    )
RETURN [Custo Comissão] + [Custo Produtos] + SalarioAjustado

Sou responsável por atualizar uma base mensal consolidada a partir de arquivos separados por mês em pasta. O arquivo de março chegou com os nomes de coluna em minúsculo - diferente do padrão de janeiro e fevereiro.

Não pude alterar a fonte porque outros usuários dependiam do arquivo original. E pela interface padrão do Power Query, o rename é aplicado depois da consolidação - quando os valores de março já chegaram como nulo por falta de correspondência.

A correção precisa acontecer antes da consolidação, dentro do parâmetro Transformar Arquivo - onde o Power Query processa cada arquivo individualmente.

let
  Fonte = (Parâmetro as binary) => let
    Fonte = Excel.Workbook(Parâmetro2, null, true),
    Planilha1_Sheet = Fonte{[Item="Planilha1",Kind="Sheet"]}[Data],
    #"Cabeçalhos Promovidos" = Table.PromoteHeaders(
      Planilha1_Sheet, [PromoteAllScalars=true]),
    #"Renomear coluna" = Table.RenameColumns(
      #"Cabeçalhos Promovidos",
      {{"uf_ag","UF_AG"},{"Fonte","NM_FONTE"},
       {"somadeqtde","SomaDeQtde"}},
      MissingField.Ignore)
  in
    #"Renomear coluna"
in
  Fonte

Ao refazer um relatório de agronegócio, encontrei uma tabela com 8 etapas de substituição de valores na coluna "Porte". Cada valor tinha sua própria etapa, e os valores originais tinham espaços em branco ocultos que faziam as substituições não funcionarem.

Tentei usar List.Accumulate para consolidar tudo em uma etapa, mas ele causava efeito cascata: como processa as substituições em sequência, "MEDIO II" podia virar "MEDIOI" porque a regra de "MEDIO I" processava o resultado intermediário.

Criei uma medida de ranking por valor e o resultado veio com duplicatas - dois clientes com rank 3, dois com rank 4, dois com rank 6. Além disso, o ranking não corrigia quando eu aplicava filtros nas segmentações de Vendedor ou Mês.

Ranking Errado = RANKX(ALL('base'), [valor],, DESC, Dense)

Trocando para ALL('base'[Cliente]), o RANKX remove o filtro apenas da coluna que está sendo ranqueada - mantendo todos os outros filtros ativos (vendedor, mês, etc). O ranking passa a funcionar corretamente tanto na ordem quanto na resposta às segmentações.

Ranking Correto = RANKX(ALL('base'[Cliente]), [valor],, DESC, Dense)

O argumento Dense garante que quando dois clientes têm o mesmo valor, eles recebem o mesmo rank e o próximo rank é sequencial - sem pular números. Sem ele, o comportamento padrão é Skip, que pula ranks quando há empate (1, 2, 2, 4 em vez de 1, 2, 2, 3).

Em indicadores como positivação e cobertura por cidade, rankings com ALL('base') retornariam a mesma posição independente do filtro de estado ou região aplicado. Um gestor filtrando apenas o Ceará veria rankings calculados sobre o Brasil inteiro - sem nenhum aviso de que o número está errado.

Precisei gerar uma base com clientes que têm um produto específico e somente esse produto. Um filtro simples WHERE PRODUTO = 'PRODUTO_X' retornaria clientes que também têm outros produtos - o que não era o objetivo.

O NOT IN parece a solução natural, mas tem um problema crítico: se a subquery retornar qualquer valor NULL, o NOT IN retorna vazio sem avisar. Em bases de produção com dados inconsistentes, isso é uma armadilha silenciosa.

Em produção, com dados inconsistentes e históricos, prefira sempre NOT EXISTS. A diferença de performance é visível em bases com centenas de milhares de registros, e o comportamento com NULLs é correto por padrão.

Banco rodando 100% no browser via SQL.js (WebAssembly). Nenhum dado é enviado a servidor. Edite a query livremente.