> ## Documentation Index > Fetch the complete documentation index at: https://docs.userkit.dev/llms.txt > Use this file to discover all available pages before exploring further. # Métricas de receita > MRR, ARR, os quatro baldes de movimento, LTV, NRR e receita por canal — com as regras de normalização que decidem o que cada número significa. Cada um desses números é uma decisão de normalização usando um nome. MRR só é "receita, mensal" depois que alguém disse quanto um plano anual contribui, se um trial conta e onde um desconto entra — e dois produtos que respondem isso de formas diferentes produzem dois números que não se comparam. Esta página são as respostas. O painel desenha tudo em **Analytics → Receita** e **Analytics → Visão geral**, atrás de `analytics:read`. ## De onde vêm Elas **não** saem dos [eventos rastreados](/pt-br/guides/analytics). São recalculadas toda noite a partir das suas assinaturas e faturas — o espelho do que seu gateway de pagamento guarda — em uma linha por ambiente, **dia UTC** e **moeda**. ```bash theme={null} curl "https://api.userkit.dev/v1/organization/analytics/metrics?environment=live&from=2026-05-01T00:00:00Z&to=2026-08-01T00:00:00Z" \ -H "Authorization: Bearer uk_st_…" \ -H "X-Organization-Id: …" ``` ```json theme={null} { "metrics": [ { "day": "2026-07-31", "currency": "BRL", "mrr_minor": 4185000, "arr_minor": 50220000, "new_mrr_minor": 29900, "expansion_mrr_minor": 14950, "contraction_mrr_minor": 0, "churned_mrr_minor": 9900, "logo_churn": 1, "active_subscriptions": 141, "ltv_minor": 892000, "nrr_pct": 112.4, "fx_rate": null, "fx_rate_source": "" } ] } ``` Os valores estão na **unidade menor** da moeda — centavos, na maioria delas. ## As linhas são por moeda, e nunca somadas entre si Dois preços em duas moedas são dois valores que alguém escolheu, não conversões um do outro, então nada aqui os soma. `fx_rate` e `fx_rate_source` existem para que, no dia em que um total convertido *for* desenhado, a taxa usada e a origem dela estejam na linha, e não na cabeça de quem desenhou o gráfico. Enquanto não houver uma fonte de taxa, eles ficam em `null` e `""` — o que manda o leitor conferir, em vez de afirmar uma conversão que ninguém fez. ## O que cada número significa | Campo | Significado | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `mrr_minor` | Receita recorrente **no fim daquele dia UTC**, normalizada para um mês | | `arr_minor` | `mrr_minor × 12`. Guardado ao lado para que a linha seja legível sem código, e para que os dois nunca discordem num export | | `new_mrr_minor` | MRR de clientes que ontem não contribuíam nada | | `expansion_mrr_minor` | O aumento, para clientes que já pagavam | | `contraction_mrr_minor` | A queda, para clientes que ainda pagam alguma coisa | | `churned_mrr_minor` | O que os clientes que hoje contribuem zero contribuíam ontem | | `logo_churn` | Quantos clientes estão por trás daquele balde de churn | | `active_subscriptions` | Assinaturas distintas contribuindo mais que zero | | `ltv_minor` | ARPA ÷ taxa mensal de churn de logos. `null` quando a janela não viu churn | | `nrr_pct` | Retenção líquida de receita em 12 meses, em porcentagem. `null` quando ninguém pagava um ano atrás | Os quatro baldes de movimento particionam a diferença **por cliente** entre D-1 e D, por moeda: novo quando ontem era zero, churn quando hoje é zero, expansão e contração para um movimento entre dois valores não nulos. Um cliente que faz upgrade e outro que faz downgrade no mesmo dia aparecem nos dois baldes do meio, em vez de se anularem. ## Normalização **O anual é amortizado.** Um preço anual divide por 12, um semanal multiplica por 52⁄12, um diário por 365⁄12, e um preço cobrado a cada *n* intervalos se espalha pelo próprio período. MRR é uma taxa mensal, então todo intervalo é expresso nela. **Preços avulsos nunca entram no MRR.** Um lifetime é receita, não receita recorrente; ele aparece nas faturas e na receita por canal. **Trials ficam de fora.** Um trial é uma promessa de talvez pagar, e contá-lo lança uma receita que dá churn em silêncio quando o cartão nunca é digitado. Uma assinatura entra no MRR quando o trial termina — lido do timestamp de fim do trial, e não da coluna de status, para que um webhook que ainda não virou `trialing` em `active` não esconda uma conversão. **Descontos, proporcionalidade e imposto entram pela fatura, nunca pelo preço.** O que o cliente concordou em pagar é a linha imutável do catálogo que este rollup lê, então o MRR aqui é **MRR contratado**. Caixa — o que de fato entrou, cupons e proporcionalidade inclusos — é o dinheiro da fatura, e é o que a receita por canal conta. **LTV** é o ARPA dividido pela taxa mensal de churn de logos, sobre uma janela móvel de **30 dias**: clientes que pagavam 30 dias atrás e hoje não pagam nada, sobre clientes que pagavam 30 dias atrás. Sem churn nessa janela a resposta é `null`, não infinito — um LTV indefinido não é um LTV enorme, e o `null` manda o leitor para a coluna de churn em vez de imprimir um número que ninguém deveria usar para planejar. **NRR** é uma janela de **12 meses**: o que os clientes que pagavam 365 dias atrás pagam hoje, sobre o que pagavam então. `null` quando não havia essa coorte. Status sem timestamp que os situe no tempo — pausado, incompleto, desconhecido — ficam de fora em vez de serem chutados. Uma assinatura pausada afirmando receita seria exatamente a tranquilização que faz alguém parar de conferir. ## O que um espelho reconstrói, e o que não Estes números vêm de uma cópia do que seu gateway guarda, e o gateway reescreve as próprias linhas no lugar. O início de uma assinatura, seu cancelamento e o fim do trial têm timestamp, então um dia passado pode ser valorado com honestidade. **Uma mudança de quantidade não tem.** Um número de assentos que foi de 3 para 5 é lido como se sempre tivesse sido 5. Por isso o job noturno recalcula cerca de **8 dias UTC** e congela tudo o que é mais antigo como foi escrito. Esse congelamento é a única história que um espelho consegue guardar — e é por isso que reprocessar mais fundo repintaria o trimestre passado com a contagem de assentos deste. Uma correção dentro da janela entra sozinha na próxima rodada; fora dela, o que está guardado é a história. ## Receita por canal de aquisição ```bash theme={null} curl "https://api.userkit.dev/v1/organization/analytics/revenue-by-channel?environment=live" \ -H "Authorization: Bearer uk_st_…" \ -H "X-Organization-Id: …" ``` ```json theme={null} { "channels": [ { "utm_source": "google", "utm_medium": "cpc", "utm_campaign": "launch", "currency": "BRL", "revenue_minor": 1288000, "invoices": 47, "customers": 21 } ] } ``` Este é o join que nenhuma ferramenta pontual consegue fazer, porque nenhuma delas enxerga a landing page e a fatura ao mesmo tempo: **faturas pagas agrupadas pelo UTM de primeiro toque do contato fundador do cliente**. * **Um cliente é um time, e um time não tem landing page — uma pessoa tem.** O canal de um cliente é, portanto, a atribuição de primeiro toque do contato fundador: a associação mais antiga, com empate resolvido de forma determinística. * **Colegas não ganham canal próprio.** Quem foi convidado para um time chegou pelo seu produto, não por uma campanha, e creditar o UTM dessa pessoa creditaria a porta errada. * **Clientes importados mantêm o canal que os conquistou**, porque uma linha importada carrega a própria atribuição e ela nasce junto com o contato. * **O dinheiro é o da fatura**: o que foi realmente pago, com descontos e proporcionalidade, na moeda da própria fatura, agrupado por moeda e nunca somado entre moedas. * `utm_*` vazio é a forma honesta de "nenhuma atribuição registrada" — direto, ou um contato criado antes de a atribuição existir. Um código `?ref=` viaja nesse mesmo primeiro toque, e é sobre ele que as [indicações](/pt-br/guides/referrals) são devidas — a mesma captura respondendo a uma pergunta diferente: esta aqui diz qual canal ganhou o cliente, aquela diz quem recebe por isso. ## De quem é a meia-noite Os dias são UTC no armazenamento e o fuso da sua organização na exibição, a mesma regra que as [contagens de eventos](/pt-br/guides/analytics) seguem. Decidir isso uma vez é o que permite sobrepor um gráfico de receita e um de eventos.