Skip to main content
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. 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.
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

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

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 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 seguem. Decidir isso uma vez é o que permite sobrepor um gráfico de receita e um de eventos.