Unit economics

“A conta de nuvem subiu 30% este ano” é uma frase sem informação. Se o negócio cresceu 60%, o custo por unidade caiu — e a engenharia entregou eficiência. Se o negócio cresceu 5%, existe um problema sério. O custo absoluto não distingue os dois casos, e é por isso que ele produz decisões ruins.

Unit economics é a prática de dividir o custo por algo que o negócio entende: pedido, cliente, requisição, gigabyte processado, minuto de vídeo.

Escolhendo a unidade

Uma boa unidade tem três propriedades: cresce com o negócio, é entendida fora da engenharia e é medida de forma confiável.

Tipo de negócio	Unidade típica
E-commerce	custo por pedido
SaaS B2B	custo por cliente ativo (ou por assento)
API / plataforma	custo por mil requisições
Streaming / mídia	custo por hora assistida ou por GB entregue
Dados	custo por TB processado, por pipeline

Comece com uma unidade principal para a empresa e, se fizer sentido, uma por domínio. Cinco unidades disputando atenção não mudam decisão nenhuma.

Instrumentando

A conta é simples; a dificuldade é ter os dois números com a mesma granularidade e o mesmo recorte de tempo.

-- custo por pedido, por mês: faturamento cruzado com o dado de negócio
WITH custo AS (
  SELECT DATE_TRUNC(usage_date, MONTH) AS mes, SUM(cost) AS total
    FROM faturamento
   WHERE tags.produto = 'checkout'
   GROUP BY 1
), pedidos AS (
  SELECT DATE_TRUNC(criado_em, MONTH) AS mes, COUNT(*) AS n
    FROM pedidos WHERE status = 'concluido'
   GROUP BY 1
)
SELECT c.mes, ROUND(c.total / p.n, 4) AS custo_por_pedido, p.n AS pedidos
  FROM custo c JOIN pedidos p USING (mes)
 ORDER BY c.mes;

Decida e registre o que entra no numerador: só a infraestrutura do produto, ou também observabilidade, plataforma e licenças rateadas? Não existe resposta certa — existe resposta consistente. Mudar a definição no meio invalida a série histórica, que é o maior valor da métrica.

Publique como painel, ao lado das métricas de negócio, com a série de pelo menos doze meses.

Usando na decisão de arquitetura

É aqui que a métrica paga o esforço. Ela transforma discussões subjetivas em comparação:

• “Migrar o processamento para spot reduz o custo por pedido de R$ 0,21 para R$ 0,14.”
• “Este cliente grande custa 4× a média por causa dos relatórios sob demanda” — informação que muda precificação, não só arquitetura.
• “O custo por requisição cresce mais rápido que o tráfego” — sinal de que algo escala pior que linearmente, e vale investigar antes do próximo pico.
• “Cada nove adicional de disponibilidade acrescenta R$ 0,03 por pedido” — a conversa sobre SLO deixa de ser abstrata.

O último ponto liga esta página ao SLO: confiabilidade e custo são o mesmo orçamento, e decidir sem os dois números é decidir no escuro.

Metas que não distorcem

Se você definir meta, defina em custo unitário, nunca em custo absoluto. Meta de custo absoluto num negócio em crescimento força o time a escolher entre a meta e atender os clientes — e alguém vai desligar redundância para bater o número.

E acompanhe o unitário junto de uma métrica de qualidade (disponibilidade, latência p95). Reduzir custo por pedido derrubando o serviço é fácil; o par é o que impede.

Um alerta de escala: abaixo de certo volume, o custo unitário é dominado por custo fixo (cluster, observabilidade, base de dados) e cai naturalmente com o crescimento — sem que ninguém tenha otimizado nada. Interprete a série com isso em mente e separe, se possível, a parcela fixa da variável.

Próximo passo: você fechou a trilha de FinOps. Ligue custo a confiabilidade em SLO na prática e traga o número para a revisão em Custo no pull request.