Como definir uma métrica confiável

Duas pessoas calculam a “taxa de conversão” e chegam a números diferentes. Quase sempre a causa é que a métrica nunca foi definida com precisão. Esta página mostra quatro decisões que tornam uma métrica reproduzível.

Objetivo de aprendizagem

Ao final você será capaz de:

1. Declarar a granularidade de uma tabela antes de calcular qualquer coisa.
2. Escrever numerador e denominador de forma que não possam ser lidos de duas maneiras.
3. Agregar uma razão sem cair no erro de “média das taxas”.
4. Aplicar checagens de validação simples que pegam os erros mais comuns.

1. Granularidade: o que representa uma linha?

A granularidade (grain) é a resposta a “o que uma linha desta tabela representa?”. Exemplos: um pedido, um item de pedido, uma sessão por dia. Declare-a em uma frase antes de escrever a métrica.

Tabela pedidos: uma linha por pedido. Tabela itens_pedido: uma linha por item dentro de um pedido.

O erro clássico é juntar tabelas de granularidades diferentes e somar. Veja:

-- pedidos: o1 = 100, o2 = 50, o3 = 80  (total correto: 230)
-- itens_pedido: o1 tem 2 itens, o2 tem 1, o3 tem 2

SELECT SUM(o.valor)
FROM pedidos o
JOIN itens_pedido i USING (pedido_id);   -- resultado: 410

O JOIN produz 5 linhas (uma por item), então o valor de cada pedido é somado uma vez por item: 100×2 + 50×1 + 80×2 = 410, e não 230. Esse efeito é chamado de fan-out.

Como evitar

Some o valor na tabela cuja granularidade já é a do valor (pedidos). Se precisar filtrar por itens, use WHERE pedido_id IN (SELECT pedido_id FROM itens_pedido), que devolve 230.

2. Numerador e denominador

Uma razão só é confiável quando as duas partes estão escritas com a mesma precisão.

Parte	Pergunte	Exemplo para “taxa de conversão”
Numerador	O que conta como sucesso? Em qual janela?	Pedidos pagos, não cancelados, na mesma sessão
Denominador	Quem tinha a chance de converter?	Sessões com ao menos uma visita a produto
Janela de tempo	Qual fuso e qual data (evento, pagamento)?	Data da sessão, fuso America/Sao_Paulo

A definição completa vira uma frase única:

Taxa de conversão diária = pedidos pagos e não cancelados originados em sessões do dia ÷ sessões do dia com visita a produto, por data da sessão em America/Sao_Paulo.

Se o numerador contar pedidos de sessões que não estão no denominador, a razão pode passar de 100% sem que ninguém perceba.

3. Agregar razões: some partes, não taxas

Para calcular a taxa de um período, some numeradores e denominadores separadamente e divida no final.

-- dia 1: 10 pedidos em 100 sessões (10%)
-- dia 2: 45 pedidos em 900 sessões (5%)

SELECT AVG(1.0 * pedidos / sessoes) FROM diario;             -- 0,075 (errado)
SELECT 1.0 * SUM(pedidos) / SUM(sessoes) FROM diario;        -- 0,055 (correto)

A média das taxas dá o mesmo peso a um dia de 100 sessões e a um de 900. A taxa real do período é 55 ÷ 1000 = 5,5%. Por isso, guarde numerador e denominador como colunas, e calcule a razão só na apresentação.

4. Validação: o que checar antes de publicar

Estas checagens são curtas e pegam a maior parte dos problemas.

1. Limites: uma taxa entre 0 e 1 não pode ter numerador maior que o denominador.

   SELECT COUNT(*) FROM diario WHERE pedidos > sessoes;   -- esperado: 0

2. Unicidade da granularidade: a chave declarada não pode repetir.

   SELECT dia, COUNT(*) FROM diario GROUP BY dia HAVING COUNT(*) > 1;   -- esperado: vazio

3. Conciliação: a soma do numerador deve bater com a fonte, por exemplo o total de pedidos do sistema transacional no mesmo período.
4. Nulos e denominador zero: decida o que mostrar quando sessoes = 0, em vez de deixar a divisão falhar ou virar NULL sem aviso.
5. Estabilidade: recalcule um período antigo e compare. Se o número mudou, descubra por quê (dados atrasados, regra alterada).

Exercício

Dada a tabela diario(dia, sessoes, pedidos) abaixo, calcule a taxa do período e rode as duas primeiras checagens.

CREATE TABLE diario (dia TEXT, sessoes INT, pedidos INT);
INSERT INTO diario VALUES ('2026-01-01', 100, 10), ('2026-01-02', 900, 45);

Resultado esperado: taxa de 0,055, nenhuma linha com pedidos > sessoes e nenhuma chave duplicada. Os exemplos usam SQL padrão e rodam, por exemplo, em SQLite ou DuckDB.

Referências

• Kimball Group, Dimensional Modeling Techniques: a ideia de declarar a granularidade (grain) antes de modelar.
• dbt Labs, About MetricFlow: como uma camada semântica define métricas, incluindo métricas de razão com numerador e denominador.

Próximo passo

Escolha uma métrica que você usa hoje e escreva a frase de definição da seção 2. Se não conseguir escrevê-la em uma frase sem ambiguidade, esse é o primeiro problema a resolver.