--- id: educacao/infoprodutos-renovacao industria: Educação uso: comum esforco: médio grao: Transação (fatura ou parcela) e assinatura (próxima cobrança) --- # Infoprodutos e renovação Quanto cada curso vendeu de novo, quanto renovou, quanto voltou em reembolso, quanto veio de afiliado e vendedor, e quanto está previsto entrar de renovação. ## Resumo executivo **Para quem:** Infoprodutores e escolas que vendem cursos, assinaturas e mentorias por plataformas como Hotmart e Eduzz. **O que resolve** - Venda nova, renovação e parcela seguinte separadas, sem contar a mesma compra várias vezes. - Reembolso, afiliado e vendedor de cada venda decididos por uma regra única, que o time inteiro usa. - Uma previsão de renovação do mês que não soma cancelados nem confunde atraso reagendado com inadimplência. **Por que importa:** Em infoproduto, a renovação costuma ser uma das maiores linhas de receita do mês e a única previsível. Uma previsão que soma assinaturas canceladas ou chuta a moeda engana a meta. E sem uma regra de canal, comercial, afiliado e marketing disputam a mesma venda. **Perguntas de negócio que responde** - Quanto o curso faturou neste mês até ontem, e quantas vendas foram? - Quanto foi venda nova e quanto foi renovação no mês passado? - Qual o ticket médio do último lançamento e quantos reembolsos ele já teve? - Quanto vendeu o comercial, quanto os afiliados e quanto o marketing? - Quanto está previsto entrar de renovação no próximo mês, por curso? - Quanto de renovação perdemos neste mês por cancelamento? **O que você precisa** - Hotmart ou Eduzz conectado na Nekt, incluindo comissões, participantes e assinaturas de todas as contas - Tabela de referência de produtos (curso e tipo de compra) e de vendedores e afiliados (código, conta e canal) - Definição de qual valor vale como receita: bruto com imposto ou líquido do produtor **O que você recebe** - Uma tabela de compras com classificação, fase, canal, vendedor e valores em real - A previsão de renovação por assinatura, com flag de considerar e moeda da assinatura - Painel de receitas por curso, com reembolso na data da venda - Um agente de IA que responde vendas e renovação com as regras aplicadas ## Detalhado ### O problema A plataforma devolve uma linha por parcela ou cobrança, com status em várias grafias e sem data do reembolso. Quem soma as linhas conta a mesma compra várias vezes, mistura renovação com venda nova e leva para a receita até venda cancelada. A previsão de renovação, vinda de um export manual, soma assinaturas canceladas e trata como real a moeda de quem paga em euro. ### Regras de negócio 1. **Venda é a primeira parcela, contada por transação.** O grão é a parcela ou cobrança. Venda = código de transação distinto com a primeira parcela aprovada (`purchase.recurrency_number` vazio ou 1). As parcelas seguintes são continuação: entram no recebido do mês, nunca como venda nova. Vendas, clientes e reembolsos são contagens distintas e não se somam entre meses, cursos ou canais: recalcule no recorte pedido. (Evite: Contar linhas do histórico de vendas como vendas.) 2. **Status válido aceita aprovado e completo.** Venda válida = `purchase.status` APPROVED ou COMPLETE: a plataforma passa de APPROVED para COMPLETE ao fim da garantia. Reembolso = REFUNDED e CHARGEBACK. Quando os status chegam em grafias mistas (português e inglês), use flags calculadas uma vez e nunca filtre por literal. A consulta de histórico sem filtro de status devolve só aprovadas e completas: peça os demais status explicitamente para enxergar reembolso e cancelamento. Nunca some valor sem filtro de status. (Evite: Filtrar só COMPLETE e perder as vendas ainda na garantia.) 3. **Nova, renovação e continuação pela referência de produtos.** A classificação vem da tabela de referência de produtos (tipo de compra de cada id de produto) e do número da parcela: parcela seguinte = continuação; primeira parcela de produto de renovação = renovação; produto de taxa inicial = taxa inicial; o resto = compra nova. Primeira compra é a primeira vez daquela pessoa naquele produto, não cliente novo na escola. Um curso pode ter vários ids de produto (à vista, assinatura, 6 e 12 meses): não deduplique por nome. (Evite: Chamar de cliente novo toda primeira compra de um produto.) 4. **Reembolso fica no dia da venda.** A plataforma não grava a data do reembolso: o estorno vira status na linha da venda original. Reembolso é contado no mês da venda, e o número de um mês continua crescendo por semanas depois que ele acaba. Compare meses com a mesma idade e diga isso. Para acompanhar a maturação, use fases: aprovada, garantia da plataforma cumprida (`warranty_expire_date`), consolidada pela regra da casa (por exemplo, 30 dias da aprovação) e reembolsada. (Evite: Comparar o reembolso do mês passado com o de seis meses atrás como se os dois estivessem fechados.) 5. **Canal: o afiliado vence o código do link.** Ordem de decisão: 1) afiliado da venda (o cookie, em `hotmart_sales_participants` com papel AFFILIATE) se a conta estiver na referência como comercial, ex-vendedor ou afiliado externo; 2) código de vendedor encontrado no `tracking.source_sck`; 3) senão, marketing, inclusive venda sem sck. Grave o motivo (afiliado, sck, os dois, cookie contra sck) e o vendedor que decidiu. A lista de códigos e contas mora na tabela de referência, nunca no código da transformação. Afiliado fora da lista conta como marketing. (Evite: Decidir o vendedor por texto do sck, cada relatório com uma regra.) 6. **Canal não é oferta.** O comercial também vende lançamento e renovação. A oferta de origem (perpétuo, lançamento, webinário, live, renovação, orgânico) é outra coluna, derivada do padrão do sck. No funil, resuma em direta (oferta do próprio funil), indireta (lançamento e eventos), renovação e não identificada. Quando a venda indireta aparece num funil, o custo do lançamento não está na conta desse funil: diga isso. (Evite: Atribuir ao comercial toda venda de lançamento que passou por um vendedor, e ao lançamento o canal.) 7. **Receita bruta ou líquida, declarada.** Bruto = preço da transação convertido para real: BRL direto, EUR pela PTAX do dia, outras moedas pela taxa da plataforma para dólar vezes a PTAX do dólar. Líquido = comissão do produtor (`hotmart_sales_commission`, fonte PRODUCER), o que fica para a escola. Escolha uma régua para faturamento e ROAS e declare. Contratado (preço x parcelas na primeira parcela do parcelamento) é diferente de recebido no mês, e parcelas futuras não estão na base. (Evite: Somar valor na moeda de origem com valor em real.) 8. **Previsão de renovação só com o que pode entrar.** Grão: uma linha por assinatura, de todas as contas. Considerar = status ACTIVE, DELAYED ou OVERDUE e produto marcado para considerar. Projetado = soma de `price.value` das assinaturas consideradas por mês de `date_next_charge`, na moeda da assinatura (`price.currency_code`), nunca na moeda da última transação. Churn agendado = não considerar. Declare o denominador: só ativas ou ativas mais atraso. Atraso não é fila de cobrança: DELAYED já tem a próxima cobrança reagendada; a fila real é a próxima cobrança até hoje. (Evite: Somar a tabela inteira de assinaturas como previsão do mês.) 9. **Previsão é uma foto do dia.** A tabela de previsão é sobrescrita a cada execução: grave a data da foto em coluna. Para série histórica, grave em modo append com a data da foto, e nunca some fotos diferentes. Forecast do mês = realizado até ontem + projetado restante x taxa de conversão (realizado / projetado até ontem). No começo do mês, a taxa de 3 ou 4 dias é instável: use a taxa fechada do mês anterior até por volta do dia 10. Repasse contratado que entra como assinatura fica fora da taxa. (Evite: Juntar fotos de vários dias e multiplicar o projetado.) 10. **Cancelamento por status, segmentado por quem cancelou.** Cancelamento = status CANCELLED_BY_CUSTOMER, CANCELLED_BY_SELLER ou CANCELLED_BY_ADMIN, com a data em `end_accession_date`. Filtre pelo status, nunca por ter data: assinaturas reativadas também trazem a data. Segmente por quem cancelou: um lote cancelado pelo admin é evento operacional, não churn. Contas lidas por duas fontes geram a mesma assinatura e a mesma transação duas vezes: deduplique por código. (Evite: Contar como churn tudo que tem data de cancelamento.) ### Status da assinatura e previsão de renovação Status da plataforma e onde cada um entra. - **ACTIVE** → Em dia: entra no projetado (`considerar = true`) - **DELAYED** → Atraso com cobrança reagendada (`considerar = true; fora da fila de cobrança`) - **OVERDUE** → Venceu e não pagou (`considerar = true; fila de cobrança`) - **CANCELLED_BY_CUSTOMER** → Cancelado pelo assinante (`churn agendado`) - **CANCELLED_BY_SELLER** → Cancelado pelo produtor (`churn agendado`) - **CANCELLED_BY_ADMIN** → Cancelado pela plataforma (`separar: pode ser evento operacional`) - **STARTED, INACTIVE** → Fora do escopo (`considerar = false`) ### Definições | Métrica | Definição | |---|---| | Vendas | transações distintas com a primeira parcela em status válido (APPROVED ou COMPLETE), pela data da venda em America/Sao_Paulo | | Faturamento | soma do valor em real das transações válidas do período, na régua declarada (bruto com imposto ou líquido do produtor) | | Ticket médio | faturamento / vendas do mesmo recorte, agregando antes de dividir | | Reembolsos | transações distintas com status REFUNDED ou CHARGEBACK, no mês da venda; valor complementar | | Clientes compradores | e-mails distintos com transação válida no período; não se somam entre meses | | Venda nova x renovação | classificação da primeira parcela pelo tipo de compra do produto na referência; parcelas seguintes são continuação | | Projetado de renovação | soma de price.value das assinaturas com considerar = true e próxima cobrança no mês, na moeda da assinatura | | Churn agendado | valor das assinaturas com considerar = false cuja cobrança cairia no mês; diferente dos cancelamentos registrados no mês | | Coorte de compra | das pessoas que entraram num funil ou pediram contato no mês, quantas compraram em até 7, 30, 60 e 90 dias, sem quem já tinha comprado antes, com flag de janela completa | ### Armadilhas - **Venda cancelada de valor absurdo.** Uma medida de faturamento do painel não filtrava status e somava uma transação cancelada com valor na casa dos trilhões, além de vendas estornadas. Como evitar: Todo valor passa pelo filtro de status válido, inclusive em medidas derivadas. - **Moeda chutada como real.** A moeda vinha da última transação da assinatura. O cruzamento falhava em mais da metade das linhas e o padrão BRL transformava assinaturas em euro e dólar em real. Como evitar: Use a moeda da própria assinatura (price.currency_code), sempre preenchida. - **A mesma conta lida duas vezes.** Duas fontes apontavam para a mesma conta da plataforma e cerca de 15% das linhas da previsão eram duplicata exata. Como evitar: Deduplique por código da transação e da assinatura depois de unir as contas. - **Export manual acima do real.** O relatório de previsão exportado à mão ficava 33% a 56% acima do que a API mostrava, e era tratado como a verdade. Como evitar: Automatize pela API e, onde divergir, investigue o export antes de ajustar o número. - **Atraso inflando a cobrança.** Contar todo atraso como fila de cobrança superestimou a fila em 3,7 vezes: a maior parte já tinha a próxima cobrança reagendada para o futuro. Como evitar: Fila = OVERDUE ou próxima cobrança até hoje; DELAYED reagendado fica separado. - **Valor quebrado na origem.** Numa conta, várias assinaturas vinham com valor de R$ 1,00 e a previsão daquele curso por valor não fazia sentido. Como evitar: Liste cursos com valor de assinatura fora da faixa do preço e use contagem até corrigir na origem. ### Teste de aceitação - [ ] Para um mês fechado, vendas, faturamento, clientes compradores e reembolsos batem ao centavo com o relatório oficial da plataforma ou do painel validado. - [ ] Compra nova + renovação + continuação + taxa inicial = total de transações válidas do período. - [ ] Nenhuma assinatura cancelada entra no projetado, e a previsão tem uma linha por assinatura depois da deduplicação. - [ ] Toda venda tem canal e motivo de canal; nenhuma venda cujo afiliado está na referência como vendedor cai em marketing. - [ ] Recalculado 30 dias depois, o reembolso de um mês é igual ou maior que antes, nunca menor. ### Context document ```text Infoprodutos e renovação - Grão: transação (parcela). Venda = transação distinta da primeira parcela (recurrency_number vazio ou 1) com status APPROVED ou COMPLETE. Parcelas seguintes = continuação. - Reembolso = REFUNDED ou CHARGEBACK, contado no mês da venda. A data do reembolso não existe. O reembolso de meses recentes ainda vai crescer: comparar meses na mesma idade. - Classificação pela referência de produtos : continuação, renovação, taxa inicial ou compra nova. Primeira compra = primeira vez naquele produto, não cliente novo. - Canal: 1) afiliado da venda na referência de vendedores; 2) código de vendedor no sck; 3) marketing. Usar a coluna canal_venda; não recalcular pelo sck. Canal não é oferta de origem. - Valor: , em real. EUR pela PTAX do dia; outras moedas pela taxa da plataforma para USD x PTAX USD. - Não somar valor sem filtro de status. Vendas, clientes e reembolsos não se somam entre linhas. - Previsão de renovação: só considerar = true (ACTIVE, DELAYED, OVERDUE e produto marcado). Valor = price.value; moeda = price.currency_code da assinatura; eixo = date_next_charge. Churn agendado = considerar = false. - Declarar o denominador do forecast (só ativas ou ativas + atraso). Fila de cobrança = próxima cobrança até hoje. - A previsão é uma foto diária: usar uma foto por consulta e declarar a data dela. - Cancelamento = status CANCELLED_*, data em end_accession_date, separado por quem cancelou. - Responder com totais. Dados de comprador só dentro da consulta. Exceções por cliente: - : a previsão de renovação é liberada só para . - : o curso tem valor de assinatura quebrado na origem; usar contagem, não valor. - : pagamentos por não estão na base. ``` ### Variações - **Ingressos de evento:** Produtos do tipo ticket; evento pelo nome antes do separador, com de-para de grafias; cortesia x pago pelo tipo de pagamento; fora de receita recorrente. - **Escada de produtos:** Sequência de programas comprados por quem entrou nos funis, da isca até o programa principal. - **Calls e compra:** Quantos compram depois da sessão estratégica, em quanto tempo e com que ticket, casando agenda e comprador por e-mail.