Guia de entrevista para analista de dados

Estrutura: Filtrar -> join -> agrupar -> ordenar -> limitar

Vou assumir que temos customers(customer_id, name) e orders(order_id, customer_id, order_date, status, revenue). Primeiro, eu esclareceria se a receita deve incluir pedidos cancelados ou reembolsados. Normalmente, devemos considerar só os pedidos concluídos. A query filtra os pedidos dos últimos 30 dias, mantém apenas os com status concluído, agrupa por cliente, soma a receita, ordena de forma decrescente e limita a 5. Se a lógica ficar mais complexa, uma versão mais limpa usaria uma CTE para os pedidos elegíveis. Detalhes importantes: usar a coluna de data correta, evitar join com tabelas no nível de item a menos que estejam pré-agregadas e decidir como tratar empates. Se o banco permitir, eu usaria uma window function de ranking quando os empates devem ser incluídos, em vez de um simples LIMIT 5. Uma resposta forte também valida o resultado, conferindo a receita elegível total, o número de linhas e se algum dos principais clientes tem linhas de pedido suspeitamente duplicadas.

Estrutura: Definir a coorte -> definir o evento de retorno -> left join -> agregar

Primeiro, eu definiria a retenção com precisão. A coorte de janeiro seria formada pelos usuários com data de cadastro entre 1º de janeiro e 1º de fevereiro. Um usuário conta como retido em 7 dias se tiver pelo menos um evento de atividade válido no 7º dia após o cadastro, ou entre os dias 1 e 7 se a empresa define retenção como voltar em até 7 dias. Eu esclareceria isso antes de escrever a query. Para a retenção exata no dia 7, eu criaria uma CTE de coorte com user_id e signup_date. Depois faria um left join com os eventos por user_id, com event_date igual a signup_date + interval 7 days e event_name sendo um evento de atividade relevante. O denominador é a contagem distinta de usuários da coorte, e o numerador é a contagem distinta de usuários com um evento correspondente. O ponto-chave é preservar os usuários sem atividade usando um left join. Com um inner join, você remove os usuários não retidos e infla a retenção. Também é preciso evitar que vários eventos dupliquem os usuários retidos, contando user_id de forma distinta. Métrica final: retained_users / cohort_users. Se o entrevistador pedir um diagnóstico, eu segmentaria por canal de aquisição, plataforma, região ou semana de cadastro.

Estrutura: Ranquear as compras por usuário

Eu usaria uma window function para ranquear as compras concluídas de cada usuário pelo timestamp da compra. Primeiro, filtro apenas as compras concluídas e depois aplico row_number() over partition by user_id order by purchase_at. A segunda compra é a linha em que row_number = 2. A ordem do filtro importa. Se compras canceladas ou reembolsadas não devem contar, é preciso removê-las antes do ranking. Se várias compras tiverem o mesmo timestamp, eu adicionaria um critério de desempate determinístico, como order_id. A saída pode incluir user_id e second_purchase_at. Se o entrevistador pedir os usuários que fizeram pelo menos duas compras, retorno só as linhas com rank 2. Se ele pedir todos os usuários, com nulo para quem não tem segunda compra, faço um left join do resultado de volta com a tabela de usuários. A complexidade fica a cargo do banco de dados, mas, na prática, em tabelas grandes essa query se beneficia de índices em user_id e no timestamp da compra.

Estrutura: Uma linha por usuário com os timestamps de cada etapa

Eu criaria uma linha por usuário com o timestamp mais antigo de cada etapa do funil. Isso evita contar duas vezes os usuários que disparam o mesmo evento várias vezes. Para isso, uso agregação condicional sobre a tabela de eventos: min(case when event_name = signup then event_at end), min(case when event_name = email_verified then event_at end) e assim por diante. Depois, imponho a sequência, se for necessário. Por exemplo, a verificação de email deve acontecer depois do cadastro, o onboarding depois da verificação e a primeira compra depois do onboarding. Se o negócio quiser uma conversão flexível, independentemente da ordem, eu deixaria essa premissa explícita. Métricas de conversão: cadastro para verificação, verificação para onboarding, onboarding para compra e a conversão geral de cadastro para compra. O numerador é o número de usuários distintos em cada etapa, e o denominador, o da etapa anterior. Eu segmentaria por plataforma, canal de aquisição, dispositivo, região e data da coorte para identificar onde a queda se concentra. Casos de borda importantes: eventos duplicados, usuários que pulam etapas, limites de fuso horário, contas de bots ou de teste e eventos que chegam com atraso.

Estrutura: Validar -> segmentar -> funil -> fatores externos -> recomendação

Primeiro, valide se a queda é real. Verifique mudanças na instrumentação, atrasos no pipeline de dados, problemas de fuso horário, filtragem de bots, mudanças de release do app e se a queda aparece em vários dashboards ou nas tabelas brutas. Depois, segmente a queda: plataforma, versão do app, região, canal de aquisição, tempo de casa do usuário, usuários pagos versus gratuitos, tipo de dispositivo e origem do tráfego. Uma queda geral sugere um problema de tracking, de infraestrutura ou de produto em larga escala. Uma queda localizada aponta para uma plataforma, release, mercado ou canal. Em seguida, analise a jornada do usuário. As aberturas do app caíram? O sucesso de login caiu? A home deixou de carregar? As notificações diminuíram? Ou as ações principais caíram depois que os usuários chegaram? Se as aberturas do app estão estáveis mas a atividade principal caiu, o problema está dentro do produto. Se as aberturas caíram, olhe para notificações, aquisição, sazonalidade, instabilidades ou eventos externos. Por fim, recomende uma ação com base na causa raiz. Se o DAU do iOS caiu depois de um release e a taxa de crashes subiu, faça rollback ou um hotfix. Se só os usuários vindos de mídia paga caíram, verifique o investimento nas campanhas e a atribuição. Se os dados estão atrasados, comunique essa limitação antes de criar uma falsa urgência.

Estrutura: Objetivo -> métrica principal -> métricas de input -> guardrails -> segmentos

Comece pelo objetivo. Uma funcionalidade de recomendação pode buscar aumentar a descoberta, o engajamento, a conversão, a retenção ou o ticket médio. A métrica principal deve refletir o valor pretendido para o usuário, não só os cliques. Por exemplo, em recomendações de ecommerce, uma boa métrica seria compras ou adições ao carrinho de itens recomendados por usuário ativo. As métricas de input incluem impressões das recomendações, taxa de cliques, taxa de adição ao carrinho, taxa de conversão, receita por sessão, cobertura e diversidade. Os guardrails incluem devoluções, reembolsos, cliques de baixa qualidade, latência da página, reclamações de usuários e canibalização da descoberta orgânica. Segmente por usuários novos versus recorrentes, categoria, dispositivo, origem do tráfego e área do produto em que a recomendação aparece. Um modelo pode melhorar o desempenho médio e, ao mesmo tempo, prejudicar os usuários novos ou a descoberta de produtos de cauda longa. Eu avaliaria a funcionalidade com um teste A/B, se possível, e depois acompanharia a retenção de longo prazo e a recompra. Um ganho de cliques no curto prazo não basta se os usuários estão sendo empurrados para itens irrelevantes ou que geram pouca satisfação.

Estrutura: Decompor a receita em tráfego, conversão, ticket médio (AOV), mix, preço e retenção

A receita normalmente é tráfego vezes taxa de conversão vezes ticket médio, com efeitos adicionais de mix de produtos, preços, recompra e reembolsos. Se a receita subiu enquanto a conversão caiu, há várias explicações possíveis. O volume de tráfego pode ter crescido o bastante para compensar a conversão menor. O ticket médio pode ter subido por mudanças de preço, combos, clientes enterprise, carrinhos maiores ou um mix de produtos mais concentrado em itens caros. A empresa pode ter reduzido o tráfego de baixa intenção, gerando uma taxa de conversão menor, porém compras mais valiosas. Também pode haver mudanças de tracking afetando a receita ou a conversão. Eu segmentaria por canal, produto, região, usuários novos versus recorrentes, tier de cliente e dispositivo. Depois decomporia a receita em sessões, conversão, ticket médio, taxa de reembolso e recompras. Também verificaria se a conversão é medida por sessão, por usuário ou por visitante, porque mudanças no denominador podem criar tendências enganosas. A recomendação depende da qualidade dessa receita. Se o crescimento vem de clientes de alto valor e mais saudáveis, uma conversão menor pode ser aceitável. Se vem de um aumento de preço pontual enquanto a conversão de novos clientes está enfraquecendo, isso pode ser um risco para o crescimento futuro.

Estrutura: Público -> decisões -> métricas -> recortes -> alertas

Primeiro, defina o público e as decisões. Executivos precisam de uma visão de alto nível sobre crescimento, retenção, monetização e risco. Eles não precisam de todos os detalhes operacionais na primeira tela. Métricas principais: receita recorrente mensal, retenção líquida de receita, retenção bruta de receita, MRR novo, MRR de expansão, MRR de contração, MRR perdido com churn, clientes ativos, conversão de teste para pago, ARPU, payback do CAC se houver, e previsão versus meta. Recortes úteis: segmento de clientes, canal de aquisição, plano, região, porte da empresa, mês da coorte e venda assistida versus self-service. Os visuais devem incluir linhas de tendência, retenção por coorte, ponte de MRR, motivos de churn e desvio em relação à meta. Princípios de design: mostrar as definições, o horário da última atualização, os filtros, o responsável e os limites de alerta. Evite métricas de vaidade e evite misturar contagens de usuários com métricas de receita sem rótulos claros. O dashboard deve responder: estamos crescendo, por quê, onde está o risco e o que a liderança deve investigar em seguida?

Estrutura: Esclarecer a decisão -> explicar o risco -> propor uma visão melhor

Primeiro, eu esclareceria que decisão a pessoa está tentando tomar. Às vezes um stakeholder pede um gráfico específico porque já tem uma narrativa em mente, mas a necessidade real é uma resposta de negócio. Depois, eu explicaria o risco com clareza e sem ficar na defensiva. Por exemplo, um gráfico de receita acumulada sempre sobe e pode esconder uma desaceleração recente. Um gráfico de pizza com categorias demais pode esconder diferenças. Um gráfico sem intervalos de confiança pode passar uma precisão maior do que a real. Uma taxa de conversão sem o mix de tráfego pode induzir a erro. Eu proporia uma alternativa que responda à mesma pergunta com mais precisão: linha de tendência, gráfico de coortes, funil, distribuição, gráfico de barras segmentado ou decomposição da métrica. Se a pessoa ainda precisar do gráfico original, eu poderia incluí-lo com ressalvas, mas não apresentaria uma análise enganosa como a minha recomendação. O objetivo é preservar a confiança. Analistas devem ser prestativos, mas também são responsáveis pela integridade analítica.

Estrutura: Analisar o perfil -> padronizar -> validar -> documentar

Primeiro, eu faria o perfil dos dados: número de linhas, nomes das colunas, valores faltantes, duplicatas, tipos de dados, valores impossíveis, formatos de data e outliers. Eu guardaria uma cópia dos dados brutos antes de fazer qualquer transformação. Depois, padronizaria os campos: remover espaços extras, uniformizar maiúsculas e minúsculas, converter datas, converter moedas ou unidades, separar campos combinados se necessário e mapear categorias inconsistentes para uma lista controlada. Para duplicatas, eu definiria a chave de negócio antes de remover qualquer coisa. Em seguida, validaria os totais com uma fonte confiável. Por exemplo, a receita total deve bater com as exportações do financeiro, a contagem de pedidos deve corresponder aos sistemas de origem e os intervalos de datas devem estar completos. Eu criaria verificações para taxa de nulos, contagens distintas e valores das categorias. Por fim, documentaria as transformações. Uma planilha usada para tomar decisões deve deixar as premissas visíveis, separar os dados brutos dos dados tratados e evitar edições manuais escondidas que não possam ser auditadas.

Estrutura: Exploração versus cálculo controlado

Tabelas dinâmicas são excelentes para explorar rapidamente, agrupar, fatiar e resumir dados por várias dimensões. São úteis quando a pergunta envolve totais, contagens, médias ou tendências por categoria e quando os stakeholders querem filtrar de forma interativa. A análise baseada em fórmulas é melhor quando a lógica é personalizada, tem várias etapas, precisa ser auditável ou exige controle preciso. Exemplos incluem cálculos de coorte, modelos de cascata, pontuações ponderadas, flags de exceção, verificações de conciliação ou entradas que alimentam uma previsão. Na prática, eu costumo usar os dois: tabelas dinâmicas para explorar padrões rapidamente e depois fórmulas ou um modelo mais limpo para chegar à resposta final. Para relatórios recorrentes, prefiro uma query reproduzível ou um pipeline de BI a uma planilha manual frágil.

Estrutura: Hipótese -> randomização -> métricas -> guardrails -> decisão

Hipótese: a nova página de checkout reduz o atrito e aumenta as compras concluídas sem gerar efeitos negativos mais adiante na jornada. Primeiro, confirme a configuração do experimento: unidade de randomização, tamanho da amostra, duração, registro de exposição, elegibilidade e se os usuários permanecem na mesma variante entre sessões. Randomizar por sessão em vez de por usuário pode contaminar os resultados se os usuários voltarem. Métrica principal: taxa de conversão do checkout, do início do checkout até a compra concluída. Métricas secundárias: taxa de falha de pagamento, tempo até concluir o checkout, ticket médio, adesão a produtos adicionais e visitas de retorno. Guardrails: reembolsos, chargebacks, tickets de suporte, latência, taxa de erros e reclamações de clientes. A análise deve considerar a significância estatística e a significância prática. Um ganho minúsculo pode não justificar a complexidade de engenharia. A análise por segmento pode revelar que o mobile melhorou enquanto o desktop piorou, mas evite reagir demais a subgrupos com muito ruído. Recomendação: lançar se a métrica principal melhorar de forma relevante, os guardrails estiverem saudáveis, a instrumentação for confiável e o efeito se mantiver durante todo o período do teste.

Estrutura: Verificar o poder -> analisar a direção -> avaliar o custo -> decidir

Um resultado não significativo não quer dizer automaticamente que a funcionalidade não tem efeito. Primeiro, verifique se o teste tinha poder estatístico para detectar um efeito relevante. Se a amostra era pequena demais ou a métrica tem muito ruído, o resultado pode ser inconclusivo. Depois, analise o tamanho do efeito e o intervalo de confiança. Se o intervalo inclui tanto um ganho relevante quanto uma perda relevante, o teste é incerto. Se o intervalo está estreito e centrado perto de zero, a funcionalidade provavelmente tem pouco impacto nessa métrica. Em seguida, considere o custo e a estratégia. Se a funcionalidade é cara de manter e não mostra benefício mensurável, não lance ou faça rollback. Se ela é estrategicamente importante, de baixo risco ou melhora a experiência do usuário de forma qualitativa, considere iterar ou medir uma métrica melhor. Eu resumiria o resultado assim: o que testamos, o que observamos, qual o nosso grau de confiança, quais limitações existem e que decisão eu recomendo.

Estrutura: Definições -> fontes -> filtros -> granularidade -> timing -> conciliação

Primeiro, compare as definições. Um dashboard pode mostrar a receita bruta, enquanto outro mostra a receita líquida após reembolsos, descontos, impostos ou chargebacks. O momento de reconhecimento da receita também pode ser diferente: data do pedido, do pagamento, do envio ou da fatura. Depois, compare as fontes de dados, os filtros e a granularidade. Um dashboard pode excluir contas de teste, pedidos cancelados, usuários internos, faturas enterprise ou determinadas regiões. Outro pode fazer o join com os itens do pedido de forma errada e duplicar a receita. Verifique também o fuso horário e a atualização dos dados. Eu faria a conciliação a partir de uma fonte confiável, montando uma ponte: começo com a receita do dashboard A e vou somando ou subtraindo as diferenças passo a passo até bater com o dashboard B. Cada diferença deve ter um motivo identificado. O resultado final não deve ser apenas “o dashboard A está errado”. Deve ser uma definição corrigida, um responsável, uma fonte da verdade e um plano para evitar confusões no futuro.

Estrutura: Medir a ausência -> diagnosticar a causa -> escolher o tratamento -> informar

Primeiro, quantifique a ausência de dados: quais campos, quantas linhas, qual percentual e se a ausência varia por segmento, período, fonte ou plataforma. Dados faltantes nem sempre são aleatórios. Depois, diagnostique por que eles estão faltando. Pode ser um campo opcional para o usuário, uma falha de tracking, dados que chegam com atraso, problemas de integração, restrições de privacidade ou um valor legitimamente não aplicável. O tratamento depende da causa. As opções incluem excluir linhas, imputar valores, criar uma categoria de desconhecido, preencher a partir de outra fonte ou mudar o escopo da análise. Eu evitaria preencher valores faltantes com zero sem pensar, porque zero e desconhecido significam coisas diferentes. Por fim, informe o impacto. Diga como os dados faltantes afetam o grau de confiança e se a recomendação muda sob premissas razoáveis.

Estrutura: Decisão -> análise -> insight -> recomendação -> impacto

Escolha uma história em que a análise claramente influenciou uma decisão. Comece pela decisão de negócio em jogo: lançamento, preço, investimento em marketing, mudança de produto, operações ou priorização. Depois, explique a análise em linguagem simples. Que dados você usou, qual métrica importava, que segmentos você analisou e o que surpreendeu? Não gaste a resposta inteira falando de ferramentas. O entrevistador quer saber como o seu trabalho mudou a forma de pensar do time. Em seguida, apresente a recomendação e o impacto. Por exemplo, a sua análise mostrou que uma campanha parecia lucrativa no geral, mas dava prejuízo em um canal, então o time remanejou o orçamento e melhorou o ROI. Ou uma funcionalidade de produto aumentou os cliques, mas reduziu a retenção, e o time a reverteu. Uma resposta forte inclui ressalvas e a comunicação com os stakeholders. Explique como você lidou com a incerteza e como tornou a recomendação fácil de entender.

Estrutura: Esclarecer a urgência -> dar uma leitura direcional -> explicar as limitações -> planejar os próximos passos

Primeiro, eu esclareceria a decisão e o prazo. Se a decisão é de baixo risco, uma resposta direcional pode ser aceitável. Se ela afeta receita, clientes, compliance ou estratégia, a régua de qualidade precisa ser mais alta. Depois, eu explicaria o que dá para responder agora e o que não dá. Eu poderia apresentar uma leitura preliminar com ressalvas claras: “Com base nos dados disponíveis hoje, a tendência parece negativa, mas o tracking está incompleto para os usuários de Android, então eu ainda não tomaria uma decisão final de lançamento.” Eu separaria a resposta imediata do plano de acompanhamento. Imediato: a melhor estimativa disponível e o grau de confiança. Próximos passos: etapas de limpeza dos dados, verificações de validação, conciliação com a fonte da verdade e quando uma resposta mais sólida vai estar pronta. Essa abordagem mantém o stakeholder em movimento e protege a integridade analítica. A pior resposta é um número dado com confiança, rápido, mas errado.

Estrutura: Impacto -> urgência -> esforço -> dependências -> alinhamento com stakeholders

Eu priorizo com base no impacto no negócio, na urgência, no esforço, nas dependências e em se a análise apoia uma decisão irreversível ou de alto risco. Uma demanda ligada a uma decisão de lançamento amanhã normalmente passa na frente de uma melhoria de dashboard que seria só um extra. Também esclareço que decisão cada demanda apoia. Se uma demanda não tem uma decisão ou um responsável claros, talvez precise ser refinada antes de a análise começar. Para demandas recorrentes, procuro oportunidades de automação, para que o time não fique preso em relatórios manuais. Quando as prioridades entram em conflito, eu comunico os trade-offs: “Consigo terminar hoje a análise de churn ou a atualização do dashboard, mas não as duas. Como a análise de churn afeta o plano de retenção desta semana, recomendo começar por ela.” Bons analistas não aceitam simplesmente todas as demandas por ordem de chegada. Eles ajudam a organização a investir o tempo de análise onde ele muda decisões.