Um Dia na Vida de um Data Analyst

A descrição da vaga dizia "gerar insights para embasar decisões de negócio". Então o primeiro ping no Slack às 8h47 é "ei, pergunta rápida: por que o MRR está $3K abaixo do board deck da semana passada?" e você passa os próximos noventa minutos provando que o deck estava certo.

Essa distância entre a vaga e o dia a dia é o motivo pelo qual a rotatividade de analistas em empresas SaaS gira em torno de 22% a 28% ao ano. Ninguém te avisa que o cargo é metade SQL, metade tradução e um quarto defender números que você escreveu há três meses. (Sim, isso dá 125%. A matemática faz parte do problema.)

É assim que uma terça-feira real parece para um Data Analyst IC em empresa B2B SaaS ou de médio porte, com 1 a 4 anos de experiência. Não a versão do LinkedIn. A versão de verdade.

Por que isso importa agora

O volume de solicitações pontuais praticamente dobrou desde que as ferramentas de BI self-service se tornaram mainstream. Todo PM acha que precisa de um corte de coorte personalizado até terça. Todo VP tem uma hipótese que quer validada até sexta. O ferramental prometeu dados democratizados e entregou uma avalanche de pedidos.

Os candidatos que entram nessa vaga imaginando um trabalho tranquilo onde se constroem modelos o dia inteiro pedem demissão antes de dezoito meses. Os que ficam aprendem a fazer algo que a descrição da vaga nunca menciona: proteger o tempo de pensar sem parecer não responsivo. Essa é a habilidade sênior de verdade.

Se você está contratando, saber disso muda como você filtra candidatos. Se você trabalha como analista, nomear esses padrões os torna suportáveis. Vamos percorrer o dia.

8h00: Verificação do Painel de Controle

Antes de abrir o Slack, antes que o primeiro stakeholder acorde, percorra os seis a oito painéis de controle que seus executivos realmente abrem. Não todos os vinte que você construiu. Os que recebem cliques.

Você está procurando três coisas:

• Valores nulos onde não deveria haver nenhum. Um número de receita em branco para ontem. Uma contagem de cadastros que diz zero numa quarta-feira.
• Junções de tabelas quebradas após o run do dbt da noite anterior. Um modelo falhou silenciosamente e o painel de controle está exibindo dados antigos com um timestamp recente. Esse é o pior tipo de bug, porque ninguém percebe até tomar uma decisão com base nele.
• Picos estranhos. O tráfego está 4x acima do normal? Ou o marketing lançou algo que ninguém te avisou, ou um evento de rastreamento está disparando em duplicata. Ambos valem uma mensagem no Slack antes que alguém pergunte.

A varredura completa leva quinze minutos se tudo estiver limpo. Quarenta e cinco se não estiver. O ponto é encontrar o bug antes que o CFO abra o painel de controle às 9h15 e te mande um "isso está certo?"

Uma verificação matinal limpa é trabalho invisível. Você nunca vai receber crédito por ela. Mas o dia em que você pular vai ser o dia em que um membro do board vê números quebrados, e esse dia é muito mais barulhento do que as cem manhãs tranquilas anteriores.

9h30: Triagem de Solicitações Pontuais

A fila do Jira tem onze novos tickets. O Slack tem seis mensagens diretas. Um VP mandou mensagem no seu celular pessoal, o que você se arrepende de ter dado a ele na festa de fim de ano.

Triagem é classificar, não resolver. Cada solicitação vai em um de quatro grupos:

• Pull de 10 minutos. Alguém quer uma contagem, uma lista, um filtro rápido. Faça na hora, poste a resposta na thread, siga em frente.
• Análise de 2 dias. Perguntas reais que precisam de um modelo, uma coorte ou um documento escrito. Agende-as.
• Duplicata. Alguém está perguntando o que outra pessoa perguntou no mês passado. Encontre a resposta antiga, mande o link, feche o ticket. Com gentileza.
• Impreciso. O pedido não diz qual decisão ele vai embasar. Esses precisam de uma resposta de cinco minutos fazendo a pergunta que vai poupar quatro horas.

Essa pergunta é: "Que decisão isso vai mudar?"

Formulada com cuidado: "Tudo bem, fico feliz em investigar. Só uma verificação rápida antes: o que você planeja fazer de diferente dependendo do que os dados mostrarem?" Se a resposta for "nada, só estou curioso", você pode despriorizar com honestidade. Se a resposta for "vamos decidir se matamos o fluxo de trial na sexta", você escala. De qualquer forma, você fez seu trabalho antes de escrever qualquer SQL.

Um modelo de formulário de entrada para usar no Jira/Linear/o que sua empresa usar:

**Decisão que esta análise vai embasar:**
**Data em que você precisa:**
**Quem mais vai revisar o resultado:**
**O que você já verificou:**
**Nível de precisão aceitável (estimativa aproximada vs. auditoria completa):**

Metade dos pedidos para antes do primeiro campo, porque quem solicitou percebe que ainda não tem uma decisão. Isso é um recurso, não um bug.

11h00: Entrevista de Requisitos no Meio do Dia

Trinta minutos no Zoom com um PM que disse "preciso de dados de churn".

O pedido real sempre está três camadas mais fundo. Seu trabalho é ir do vago ao específico sem fazer a pessoa se sentir ignorante. O truque é fazer perguntas diagnósticas, não perguntas de interrogatório.

Um fluxo que funciona:

1. Reformule e expanda. "Então você quer entender o churn. Para garantir que eu faço o corte certo: estamos falando de churn por cliente, churn de receita ou churn por logo? Eles se movem de formas diferentes."
2. Pergunte sobre a decisão. "O que você vai fazer depois de ter isso? Você está dimensionando a equipe de retenção ou tentando descobrir qual segmento corrigir primeiro?"
3. Defina a coorte. "Quando você diz 'clientes que cancelaram', você quer dizer cancelamentos dos últimos 30 dias ou cancelamentos sem reativação? E downgrade conta?"
4. Defina o nível de precisão. "Você precisa disso de forma direcional até o EOD, ou com precisão de auditoria para o QBR? A resposta muda o tempo de execução em cerca de um dia."

A maioria dos PMs não quer parecer insegura diante da liderança, então pede coisas na linguagem do deck que precisa apresentar. Seu trabalho é traduzir isso de volta para uma pergunta que o SQL consegue responder. Você não está questionando a competência de ninguém ao perguntar. Você está protegendo a pessoa de apresentar um gráfico que não diz o que ela pensa que diz.

A regra da Camellia: nunca deixe um stakeholder sair de uma reunião de requisitos sem que vocês dois tenham dito em voz alta qual é o entregável, qual é a coorte e qual decisão ele vai embasar. Se você não consegue resumir isso em uma mensagem no Slack após a reunião, você ainda não tem uma especificação.

13h30: Assíncrono com Eng e Produto

A janela entre o almoço e as 16h é quando você faz o trabalho que ninguém pede, mas que determina se o próximo trimestre será sustentável.

Este é o bloco assíncrono. Três tipos de entradas:

Revisões de PR do dbt. Um engenheiro de dados mudou como o modelo fct_subscriptions trata conversões de trial. Você lê o diff. Um comentário de revisão realmente útil:

Esta mudança parece correta para trials novos, mas acho que vai
fazer dupla contagem para qualquer conta que converte, faz downgrade
e reconverte no mesmo trimestre. Temos ~40 dessas por trimestre
(verifiquei em #data-quality no mês passado). Podemos adicionar um
teste de unicidade de `subscription_id` no modelo de staging antes
de fazer o merge? Fico feliz em escrever.

Específico. Referencia dados reais. Oferece ajuda. Não bloqueia o PR por razões vagas.

Comentários em specs de produto. Um PM adicionou uma spec para um novo fluxo de onboarding. A seção de rastreamento de eventos diz "disparar onboarding_completed quando o usuário terminar". Você deixa um comentário: qual etapa conta como "terminar"? E se o usuário pular o passo três? Devemos disparar onboarding_completed para cada variante do fluxo ou ter eventos separados? Melhor perguntar agora do que gastar horas minerando dados ruins daqui a seis semanas.

Alertas de mudança de esquema. A engenharia vai renomear uma coluna em produção na sexta. Você busca em todos os explores do Looker, notebooks do Hex e modelos do dbt por esse nome de coluna. Quatro painéis de controle vão quebrar. Você manda uma mensagem ao líder de engenharia com a lista e coordina a migração. Essa tarefa de vinte minutos é a diferença entre um sábado tranquilo e um sábado reconstruindo painéis de controle executivos enquanto seu filho assiste TV.

É aqui que analistas sênior ganham seu título. O IC escreve o SQL. O sênior detecta a quebra três semanas antes de ela acontecer.

16h00: Pull de Dados para Executivos no Fim do Dia

O CFO precisa de três números para a preparação do board de amanhã. Ele te mandou mensagem às 15h47. O board meeting é às 8h.

Este é o momento em que SQL encontra as apostas reais. Você consulta o Snowflake (ou BigQuery, ou Postgres, o que sua empresa usa) e confere cada número com os valores reportados no trimestre anterior. Se o novo pull não bate com o número antigo, você não envia nada até entender o motivo.

O entregável não são três números. São três números mais contexto. Um formato que funciona para a nota no Notion ou Confluence:

**Pull rápido do Q1 2026 para preparação do board**

1. ARR líquido novo: $1,42M
   (vs. $1,38M reportado no deck do Q4, +3%, dentro do esperado)
   Ressalva: inclui 2 deals com data de fechamento 31/03 mas
   contabilizados em 02/04; excluídos da visão estrita do Q1 abaixo.

2. Taxa de churn por logo: 4,1% (anualizado)
   Visão estrita do Q1: $1,40M, 4,4%
   Pull feito às 16h35 de 28/04; atualizo se precisar antes das 8h.

3. Trial para pago: 18,7%
   (vs. 17,2% no Q4, impulsionado pela coorte do teste de precificação
   de fevereiro, que é um aumento temporário, não uma mudança estrutural.
   Não extrapole essa linha.)

Modelos de origem: fct_subscriptions, fct_trials, dim_accounts.
Me avise se algo aqui não bater com o que você está vendo.

Quatro pontos, quatro linhas de ressalvas. O CFO pode apresentar isso sem precisar perguntar nada de novo. E quando alguém no board meeting disser "espera, isso não bate com o que você disse em fevereiro", o CFO já tem a resposta pronta.

Esse é o trabalho que te promove. Não o SQL. As quatro linhas de contexto abaixo dele.

As Duas Crises Recorrentes

Dois padrões vão consumir sua semana se você deixar. Nomeá-los ajuda.

Crise Um: A Explosão de Solicitações Pontuais

Você disse sim a um pedido rápido na segunda. Quem pediu contou a um colega que você foi prestativo. Agora quatro pessoas estão no seu chat direto na quarta. Na sexta, você tem dezoito tickets e nenhum tempo para o projeto estratégico pelo qual seu gestor realmente te avalia.

Esse é o ciclo de pedidos duplicados. Ele se agrava porque dizer sim é mais rápido no momento do que criar um processo, e porque cada "perguntinha rápida" não parece um pedido. Parece apenas uma conversa.

O padrão que realmente funciona:

• Horário de atendimento, duas vezes por semana. Um bloco de 60 minutos onde qualquer pessoa pode aparecer com uma pergunta. A maioria dos pedidos de "preciso de um número rápido" se encaixa nesse formato e nem precisa de ticket no Jira.
• Formulário de entrada para todo o resto. Com link no seu perfil do Slack e no tópico do canal. Se alguém te mandar mensagem direta, sua resposta é "ótima pergunta, registra no formulário para eu conseguir priorizar junto com os outros doze que tenho, aqui está o link".
• Um resumo semanal do que você fechou. Postado no #data na sexta. Três linhas por ticket fechado: quem pediu, o que queriam, qual foi a resposta. Cria um histórico pesquisável, reduz pedidos duplicados e mostra à equipe o que você realmente entregou.

Você não está sendo obstrutivo. Você está protegendo as dez horas de trabalho focado por semana onde você constrói as coisas que importam.

Crise Dois: O Pânico por Definições Divergentes

Mensagem de um diretor às 17h55 numa quinta-feira: "Esse relatório está errado. Os usuários ativos caíram 30% semana a semana e não é isso que o marketing está vendo."

Noventa por cento das vezes, o relatório está certo e o diretor está comparando duas definições diferentes. O marketing conta como "ativo" qualquer pessoa que acessou o site. O painel de controle de produto conta como "ativo" qualquer pessoa que completou uma ação significativa. Os dois estão certos. Nunca vão coincidir.

O roteiro de triagem:

1. Reconheça a urgência, sem entrar no pânico. "Estou verificando agora, volto em dez minutos com o que encontrar."
2. Verifique a definição primeiro, o número depois. Qual campo a fonte do diretor está usando? Qual campo o painel de controle está usando? Se forem diferentes, você já resolveu o problema.
3. Ofereça uma comparação lado a lado. Não diga apenas "eles estão usando métricas diferentes". Mostre os dois números lado a lado com as definições embaixo. "Fonte do marketing: ativo por page view, 142 mil. Painel de controle: ativo por ação, 98 mil. A queda de 30% é real se você usa ativo por ação; é uma queda de 4% se você usa ativo por page view."
4. Documente a divergência. Adicione uma nota no seu dicionário de dados ou documento de definições. Inclua o link na sua resposta. Na próxima vez que isso acontecer, você responde com o link.

O diretor não está errado. Ele está trabalhando com uma definição diferente. Seu trabalho é evidenciar a divergência de definição rápido o suficiente para que ninguém precise refazer um deck.

Verificação da Stack Real

As ferramentas que você vai realmente usar:

• SQL. Snowflake, BigQuery ou Postgres. Escolha o da sua empresa. Aprenda um bem, os outros se traduzem. Funções de janela, CTEs e QUALIFY (Snowflake/BQ) cobrem 90% do trabalho.
• Uma ferramenta de BI. Looker, Tableau, Hex ou Mode. Cada uma tem uma filosofia diferente: Looker se apoia em camada semântica, Tableau é visual com arrastar e soltar, Hex e Mode são estilo notebook com SQL e Python. Você vai se especializar na que sua empresa escolheu. Não tente ser especialista em Looker e Tableau ao mesmo tempo; LookML e a sintaxe de cálculos do Tableau não se transferem facilmente.
• dbt para modelagem. Lê YAML e escreve SQL. Se sua empresa tem uma equipe de engenharia de dados, você vai revisar os PRs deles mais do que escrever seus próprios modelos, mas precisa ler dbt com fluência para entender o que está upstream de cada painel de controle.
• Notion ou Confluence. Para documentação, registros de decisão e as notas de ressalva de quatro linhas. A ferramenta não importa; a disciplina de escrever as coisas importa.
• Jira (ou Linear, ou Shortcut). Para a fila de solicitações. Seja qual for o sistema que sua empresa usa para tickets de engenharia, roteie o trabalho de dados por ele também. Se os dados ficam em um sistema separado, são ignorados.

Se uma descrição de vaga lista todas as cinco como obrigatórias e espera proficiência de nível especialista em cada uma, isso é um sinal de alerta. Ninguém é especialista nas cinco. A versão honesta é: profundo em uma ferramenta de BI, fluente em SQL, confortável para ler dbt, organizado no Notion, responsivo no Jira. Só isso.

O que a Descrição da Vaga Não te Conta

Aproximadamente cinquenta por cento da sua semana é comunicação e tradução, não análise. Reuniões de requisitos, threads no Slack, discussões sobre definições, revisões de PR assíncronas, notas de ressalva no fim do dia. O SQL é a ponta do iceberg.

Sua habilidade mais usada é perguntar "que decisão você está tentando tomar?" A segunda mais usada é dizer não sem parecer obstrutor. A terceira é documentar decisões para que o próximo analista não precise revivê-las.

Os analistas IC que esgotam são os que acham que o SQL é o trabalho. Os que são promovidos percebem que o SQL é vinte por cento do valor, e os outros oitenta por cento são tudo ao redor: a triagem, a tradução, as ressalvas, a documentação de definições, o resumo de sexta.

Se isso parece o trabalho que você quer, você vai se sair bem. Se parece uma isca e troca, tudo bem também. Melhor saber agora do que três anos depois.

Saiba Mais

• Modelo de Descrição de Vaga para Data Analyst
• Como Fazer Triagem de Solicitações Pontuais de Dados
• Como Conduzir uma Entrevista de Requisitos com Partes Interessadas
• Defendendo Seus Números Quando um Diretor Diz "Isso Está Errado"