Engenharia de Dados Aplicada ao Crescimento (Growth Tech)

Engenharia de Dados Aplicada ao Crescimento (Growth Tech)

O modo de falha mais comum de um time de dados é construir infraestrutura excelente que responde perguntas que ninguém está fazendo. Os pipelines rodam limpos, os dashboards ficam bonitos, o data warehouse está perfeitamente modelado — e o negócio ainda toma decisões baseadas em intuição porque ninguém conectou os dados às decisões que realmente geram receita.

Growth Tech é a disciplina que fecha essa lacuna. É a intersecção de engenharia de dados, analytics de produto e economia de negócio — o conjunto de práticas que torna os dados um input direto para decisões sobre onde investir, o que construir e se o investimento está funcionando.

Este artigo cobre os conceitos fundamentais: análise de funil, LTV e CAC, infraestrutura de testes A/B e arquitetura de pipeline analítico. Ao final, você terá um framework para medir se seu produto está realmente crescendo — e uma abordagem de engenharia para obter os dados que tornam essas medições possíveis.

O framework de contabilidade de crescimento

Antes de construir qualquer infraestrutura, você precisa de clareza sobre o que está medindo. A contabilidade de crescimento é o framework conceitual que torna o desempenho de negócio visível.

Em sua essência, o crescimento em qualquer negócio de assinatura ou transacional se reduz a uma única identidade:

Receita(t) = Receita(t-1) + Nova Receita - Receita Perdida + Receita de Expansão

Isso se desdobra ainda mais:

• Nova Receita = novos clientes adquiridos × seu pagamento inicial
• Receita Perdida = clientes que saíram × seu pagamento
• Receita de Expansão = clientes existentes que fizeram upgrade, compraram mais ou expandiram o uso

Toda métrica que você rastreia deve se conectar a um desses três componentes. Se uma métrica que você está monitorando não tem uma linha clara para receita nova, perdida ou de expansão, pergunte se ela precisa existir.

Pensamento por coorte: a fundação da análise de crescimento

A mudança mais importante de análise ingênua para análise de crescimento é o pensamento baseado em coortes. Em vez de perguntar "quantos usuários temos hoje?", o pensamento por coorte pergunta "dos usuários que se juntaram em março, quantos ainda estão aqui em junho, e quanto valem?"

Uma coorte é um grupo de usuários que compartilha uma característica comum, geralmente a data de cadastro. Rastrear o comportamento de coortes ao longo do tempo revela:

• Curvas de retenção — quando os usuários tipicamente saem? Isso está melhorando?
• Desenvolvimento de receita — como a receita por usuário evolui ao longo da vida deles?
• Períodos de payback — quão rapidamente a receita de uma coorte recupera o custo de adquirir essa coorte?

Sem análise de coortes, você não consegue distinguir entre um negócio crescendo com retenção ruim (aquisição está mascarando o churn) e um negócio crescendo com boa retenção (aquisição adiciona a uma base composta). Esses dois negócios têm futuros radicalmente diferentes.

Análise de funil: mapeando onde usuários convertem e onde saem

Um funil é uma sequência de passos que um usuário deve completar para alcançar um resultado desejado. Todo produto tem múltiplos funis: o funil de cadastro, o funil de onboarding, o funil de compra, o funil de renovação.

A análise de funil responde: em cada etapa, que fração dos usuários prossegue vs. abandona? E por quê?

Construindo infraestrutura de análise de funil

Um funil bem instrumentado requer:

1. Rastreamento de eventos em cada etapa significativa — cada ação do usuário que faz parte do funil emite um evento: "pagina_cadastro_visualizada", "email_inserido", "email_verificado", "perfil_completado", "primeira_compra_concluida". Eventos precisam de convenções de nomenclatura consistentes e devem carregar o identificador do usuário (ou ID de sessão anônima antes do cadastro) para vincular as etapas.

2. Governança do schema de eventos — nomes de eventos, nomes de propriedades e tipos de dados devem ser consistentes entre times e ao longo do tempo. Um evento compra_concluida emitido pelo app iOS e pelo app web deve ter schemas idênticos. Deriva aqui é um problema de qualidade de dados que se compõe.

3. Resolução de sessão e identidade — usuários frequentemente interagem anonimamente antes de se cadastrar. Sua instrumentação deve mesclar o identificador anônimo pré-cadastro com o identificador de usuário pós-cadastro, para que você possa atribuir toda a jornada pré-conversão a cada usuário.

4. Uma camada de consulta de funil — uma vez que os eventos estão no seu warehouse, você precisa de queries que podem reconstruir funis: "de todos os usuários que viram a página de checkout nesse período, que fração completou a compra em 24 horas?" Ferramentas como dbt, Metabase, Amplitude ou Mixpanel tornam isso consultável sem SQL bruto para cada análise.

O que a análise de funil revela

Um funil típico de checkout pode se parecer com isso:

| Etapa | Usuários | Taxa de Conversão | Taxa de Abandono | |---|---|---|---| | Carrinho visualizado | 10.000 | — | — | | Checkout iniciado | 6.200 | 62% | 38% | | Info de pagamento inserida | 4.100 | 66% | 34% | | Compra concluída | 2.300 | 56% | 44% | | Conversão geral | — | 23% | — |

O maior abandono nesse funil é entre info de pagamento inserida e compra concluída — 44% dos usuários que inseriram info de pagamento não completaram a compra. Esse é o alvo de otimização de maior valor. É uma falha de pagamento? Um momento de sensibilidade a preço? Um call-to-action pouco claro? O funil diz onde olhar; a investigação qualitativa diz por quê.

LTV e CAC: o motor econômico do crescimento

Customer Lifetime Value (LTV) e Customer Acquisition Cost (CAC) são os dois números que determinam se um negócio pode crescer de forma sustentável.

LTV é a receita total esperada de um cliente ao longo da sua relação com o produto. Como clientes saem ao longo do tempo, você pondera a receita futura esperada pela probabilidade de retenção em cada período.

Uma fórmula simplificada de LTV para um negócio de assinatura:

LTV = ARPU × (1 / Taxa Mensal de Churn)

Onde ARPU é a Receita Média Por Usuário. Se ARPU é R$250/mês e o churn mensal é 5%, LTV = R$250 × (1/0,05) = R$5.000.

Isso é uma simplificação — um modelo de LTV adequado considera diferenças de churn no nível de coorte, receita de expansão, falhas de pagamento e taxas de desconto. Mas a intuição é importante: LTV é determinado primariamente pelo churn. Reduzir o churn mensal de 5% para 3% aumenta o LTV em 67%, enquanto aumentar o ARPU em 20% aumenta o LTV em apenas 20%.

CAC é o custo total de adquirir um novo cliente: todos os custos de vendas, marketing e geração de demanda divididos pelo número de novos clientes adquiridos no mesmo período.

CAC = (Custos de Vendas + Custos de Marketing) / Novos Clientes Adquiridos

A relação LTV:CAC e o período de payback

A métrica de saúde central para qualquer negócio de crescimento é a relação LTV:CAC:

• < 1:1 — Você está gastando mais para adquirir clientes do que eles vão pagar de volta. Isso não é um negócio; é destruição de valor.
• 1:1 a 3:1 — Você está cobrindo os custos de aquisição mas as margens são finas. Sustentável apenas com altas taxas de crescimento.
• 3:1 a 5:1 — O benchmark padrão para um negócio SaaS ou de assinatura saudável. Você recupera os custos de aquisição significativamente.
• > 5:1 — Frequentemente indica subinvestimento em crescimento. Você poderia estar adquirindo mais clientes lucrativamente.

O período de payback é o tempo que leva para a receita acumulada de um cliente reembolsar seu CAC. Um período de payback de 12 meses significa que você precisa que um cliente fique por um ano antes de se tornar lucrativo. Em um negócio de alto churn, muitos clientes vão embora antes de pagar de volta.

Construindo infraestrutura de LTV/CAC

O rastreamento preciso de LTV e CAC requer conectar três fontes de dados que frequentemente estão em sistemas diferentes:

1. Dados de receita — do seu processador de pagamentos (Stripe, PagSeguro), CRM ou sistema de faturamento. Devem incluir identificadores de cliente, datas de pagamento, valores e reembolsos.
2. Dados de custo — das suas plataformas de marketing (Google Ads, Meta, LinkedIn), ferramentas de vendas (CRM) e qualquer outro gasto de aquisição. Devem ser atribuídos por canal e período de tempo.
3. Dados de produto — eventos de usuário e dados de engajamento que podem servir como indicadores antecedentes de retenção e churn.

O pipeline: extraia essas fontes para o seu data warehouse, vincule-os no identificador de cliente e construa modelos que computam LTV e CAC no nível de coorte, canal e período de tempo. Isso permite responder: "A relação LTV:CAC é melhor para clientes que adquirimos via busca paga vs. orgânica? Está melhorando ao longo do tempo? Quais meses produziram as coortes mais valiosas?"

Testes A/B: a infraestrutura de experimentação

Testes A/B são o mecanismo que transforma hipóteses em evidências. Sem eles, decisões de produto são baseadas em opinião e suposições. Com eles, são baseadas em evidências causais dos seus usuários reais.

Mas testes A/B são uma disciplina de engenharia, não apenas uma prática de produto. Executar experimentos corretamente em escala requer infraestrutura real.

Os componentes centrais de uma plataforma de experimentação

Atribuição — dividir aleatoriamente usuários em grupos de controle e tratamento de forma que seja consistente (um usuário que estava no grupo de controle ontem ainda deve estar no grupo de controle hoje para o mesmo experimento) e balanceada (os grupos devem ser estatisticamente comparáveis antes do tratamento).

Log de exposição — registrar quais usuários foram atribuídos a qual variante, com timestamps. Sem logs completos de exposição, você não consegue computar o denominador dos seus cálculos de métricas.

Computação de métricas — para cada experimento, computar o valor da métrica para cada variante e o teste estatístico que determina se a diferença entre variantes é sinal ou ruído.

Métricas de guardrail — experimentos otimizando para uma métrica podem inadvertidamente degradar outra. Um experimento que aumenta a taxa de cliques ao adicionar um CTA confuso pode diminuir a conclusão de compra. Métricas de guardrail são verificadas automaticamente para cada experimento e sinalizam degradações inesperadas.

Validade estatística — o erro mais comum em testes A/B é o "peeking": verificar resultados antes que o tamanho de amostra planejado seja alcançado e parar o experimento quando os resultados parecem bons. Isso infla dramaticamente a taxa de falsos positivos. Uma plataforma de experimentação adequada usa testes sequenciais ou métodos Bayesianos que são válidos sob monitoramento contínuo.

O stack mínimo viável de experimentação

Para a maioria dos times começando:

• Feature flags — LaunchDarkly, Unleash ou um serviço de flag simples baseado em banco de dados. Controla a exposição ao experimento sem deploys de código.
• Instrumentação de eventos — os mesmos eventos estruturados usados para análise de funil, com o ID da variante do experimento como atributo em cada evento.
• Análise de experimentos — pode ser feita no seu data warehouse (dbt + Metabase) para experimentos simples. A verificação de validade estatística requer uma biblioteca estatística ou ferramenta de propósito específico.

Em maior escala (centenas de experimentos rodando simultaneamente), plataformas de propósito específico — Statsig, Eppo, GrowthBook — fornecem a consistência de atribuição, monitoramento de guardrail e rigor estatístico que a escala requer.

O que medir em um experimento

O erro mais comum é medir apenas a métrica que o experimento foi projetado para melhorar. Uma análise completa de experimento inclui:

• Métrica primária — a hipótese que você está testando (taxa de cliques, taxa de conversão, receita por usuário).
• Métricas secundárias — métricas relacionadas que devem melhorar na mesma direção se a hipótese estiver correta.
• Métricas de guardrail — métricas que não devem degradar mesmo que a primária melhore. Geralmente engajamento, retenção e receita.
• Segmentações — o efeito difere por tipo de usuário, plataforma, geografia ou coorte? Uma feature que melhora conversão para usuários avançados mas prejudica novos usuários tem uma implicação muito diferente de uma que melhora ambos uniformemente.

Arquitetura de pipeline analítico para crescimento

Tudo acima requer um pipeline analítico bem projetado. Aqui está a arquitetura que suporta analytics de crescimento em escala.

O stack de dados moderno

| Camada | Tecnologia | Papel | |---|---|---| | Ingestão | Fivetran, Airbyte, CDC customizado | Carrega dados de origem no warehouse | | Streaming de eventos | Segment, Rudderstack, Kafka customizado | Coleta e roteia eventos de produto | | Warehouse | BigQuery, Snowflake, Redshift | Datastore analítico central | | Transformação | dbt | Define lógica de negócio, constrói modelos | | Camada de métricas | dbt Metrics, Cube | Definições consistentes de métricas | | BI / Exploração | Metabase, Looker, Superset | Dashboards e queries self-serve | | Experimentação | Statsig, Eppo, Growthbook | Atribuição e análise de testes A/B |

A camada de modelos centrada em dbt

dbt (data build tool) é o padrão para transformações analíticas. Permite que seu time de dados defina lógica de negócio em SQL com práticas de engenharia de software: controle de versão, testes, documentação e composição modular.

Um projeto dbt para analytics de crescimento tipicamente tem estas camadas de modelos:

sources/          → tabelas brutas de sistemas de origem (eventos, pagamentos, CRM)
staging/          → tabelas de origem limpas e tipadas (1:1 com sources)
intermediate/     → lógica de negócio reutilizável (atribuição de sessão, resolução de identidade)
marts/
  ├── growth/     → modelos de funil, retenção por coorte, LTV, CAC
  ├── product/    → uso de features, engajamento, DAU/WAU/MAU
  └── finance/    → receita, MRR, ARR, churn

O benefício central de uma camada de métricas (dbt Metrics ou Cube): a definição de "Receita Recorrente Mensal" ou "retenção de 7 dias" é escrita uma vez, em código versionado, e é consistente em todos os dashboards e relatórios que a referenciam. Isso elimina o problema de credibilidade de dados mais comum: dois dashboards mostrando valores diferentes para a mesma métrica porque a computam de forma diferente.

A importância da qualidade de dados para decisões de crescimento

Decisões de crescimento tomadas com dados incorretos são piores do que decisões tomadas sem dados — porque criam falsa confiança. Um time que acha que sua conversão de funil é 25% quando é realmente 17% vai subinvestir em otimização de conversão.

Qualidade de dados para pipelines analíticos requer:

• Testes de sistema de origem — valide que dados de origem estão chegando no prazo e em volumes esperados. Alerte sobre dados faltando antes que cause dashboards desatualizados.
• Testes dbt — testes integrados de unicidade, não-nulo, relacionamentos e valores aceitos em cada modelo. Testes customizados para asserções de lógica de negócio ("receita deve sempre ser positiva").
• Detecção de anomalias — monitoramento estatístico de métricas chave. Um pico ou queda inesperada em uma métrica pode ser um evento de negócio real ou uma falha de pipeline. Distinguir esses rapidamente é crítico.
• SLAs de freshness — dashboards de crescimento visualizados por executivos precisam de dados nunca mais obsoletos do que algumas horas. Defina e monitore compromissos de freshness por dataset.

Conectando dados a resultados financeiros: um framework prático

O passo final é o que a maioria dos times de dados pula: tornar visível o impacto de negócio do trabalho de engenharia e produto em termos financeiros.

A Métrica North Star

Uma North Star Metric é uma única métrica que melhor captura o valor central que seu produto entrega aos usuários. É o indicador antecedente da saúde de receita de longo prazo. Para diferentes tipos de produto:

• Spotify → Ouvintes Ativos Mensais (tempo de escuta é o valor entregue; receita de anúncios e conversão de assinatura seguem)
• Airbnb → Noites Reservadas
• Slack → Mensagens Enviadas (por workspaces pagantes)
• SaaS B2B → Times Ativos Semanalmente (ou qualquer seja a ação de uso central do seu produto)

Escolher a North Star Metric certa é uma decisão estratégica, não de dados. Mas instrumentá-la, rastreá-la por coorte e conectá-la a resultados de receita é um problema de engenharia.

A revisão semanal de crescimento

A revisão de crescimento é o ritual que conecta dados a decisões. Uma revisão semanal de crescimento bem estruturada responde:

1. O que aconteceu com nossas métricas chave esta semana vs. semana passada e vs. a mesma semana do ano passado?
2. Quais experimentos foram concluídos esta semana e o que mostraram?
3. Quais são os maiores problemas de conversão ou retenção sinalizados pelos dados esta semana?
4. Como está a relação LTV/CAC para as coortes mais recentes?

O trabalho do time de dados é tornar a resposta a essas perguntas rápida, confiável e self-serve. Se a revisão de crescimento requer um engenheiro de dados para executar queries customizadas toda semana, o pipeline ainda não está terminado.

Reflexão final

Engenharia de dados aplicada ao crescimento não é sobre a sofisticação do seu tech stack. É sobre fechar o loop entre comportamento do usuário (o que as pessoas fazem), resultados de negócio (quanto esse comportamento vale) e decisões de produto (o que devemos construir a seguir).

Os times que fazem isso bem são os que tratam sua infraestrutura analítica com o mesmo rigor que aplicam aos seus sistemas de produção: propriedade clara, testes de qualidade de dados, contratos definidos e SLOs mensuráveis.

A vantagem competitiva dos dados não está em tê-los — quase todo mundo os tem. Está em tê-los limpos, atualizados e conectados às decisões que realmente movem o negócio. Esse é o problema de engenharia que vale resolver.