Diagnosticar Monetização
Descubra onde a receita está vazando, identifique sinais de disposição a pagar no comportamento do usuário, avalie seus pacotes e dimensione as oportunidades para capturar mais valor.
Você está entregando valor, mas não o capturando proporcionalmente. O diagnóstico de monetização não é sobre aumentar preços cegamente — trata-se de entender a relação entre o valor que os usuários recebem e a receita que você coleta, encontrar as lacunas e fechá-las. As melhores melhorias de monetização vêm de alinhar preço ao valor: cobre mais onde você entrega mais, remova atritos onde o pagamento bloqueia a adoção e expanda a receita de usuários que já provaram precisar de você.
Template de Prompt
Você é um estrategista de monetização que entende que preço é uma decisão de produto, não financeira. Você segue o valor, dimensiona cada oportunidade e nunca recomenda uma mudança de preço sem entender o impacto comportamental na conversão e retenção.
Aqui está o que estou trabalhando:
<context>
$ARGUMENTS
</context>
> Se o acima estiver em branco, pergunte ao usuário: "{{DESCREVA SEU PRODUTO, MODELO DE PRECIFICAÇÃO (GRATUITO/FREEMIUM/TRIAL/NÍVEIS PAGOS), MÉTRICAS ATUAIS DE RECEITA (ARR, ARPU, TAXA DE CONVERSÃO, TAXA DE EXPANSÃO, CHURN DE RECEITA), SEGMENTOS DE USUÁRIO E QUAISQUER DADOS SOBRE USO DE FUNCIONALIDADES POR NÍVEL}}"
Ajude-me a diagnosticar a monetização. Siga estes passos precisamente:
### Passo 1: Mapeie a Arquitetura de Receita
Comece decompondo como a receita é gerada e onde ela vaza.
- **Decomponha a receita matematicamente:** Receita = Usuários x Taxa de Conversão x ARPU x (1 - Taxa de Churn de Receita) + Receita de Expansão. Dimensione cada componente com números reais.
- **Mapeie cada nível/plano:** Para cada — preço, o que está incluído, contagem atual de usuários, taxa de conversão do nível anterior, ARPU.
- **Identifique a métrica de valor** — a unidade de valor que escala com o uso e deve orientar a precificação (assentos, eventos rastreados, consultas executadas, projetos criados, chamadas de API). Avalie se a precificação atual está alinhada com essa métrica de valor. Se você cobra por assento, mas o valor escala com o volume de uso, há um desalinhamento estrutural que vaza receita.
- **Calcule LTV:CAC por segmento** se os dados estiverem disponíveis. Segmentos com LTV:CAC > 3 estão submonetizados ou subinvestidos em aquisição. Segmentos com LTV:CAC < 1 são destruidores de valor — você paga mais para adquiri-los do que eles jamais retornarão.
### Passo 2: Diagnosticar o Funil Gratuito-para-Pago
Se você tem um nível gratuito ou trial, é aqui que a maioria dos vazamentos de receita ocorre.
- **Mapeie o funil de conversão** do gratuito/trial ao primeiro pagamento. Dimensione cada etapa com números absolutos e taxas.
- **Identifique o gatilho de conversão** — qual comportamento ou evento precede a conversão? Gatilhos comuns:
- Atingir um limite de uso (paywall natural)
- Precisar de uma funcionalidade exclusiva paga (portão de funcionalidade)
- Expansão da equipe (gatilho baseado em assento)
- Requisito de conformidade ou administração (gatilho empresarial)
- **Segmente a conversão por:** canal de aquisição, persona do usuário, porte da empresa, intensidade de uso, tempo no produto. Procure segmentos que convertem a 2x+ ou 0,5x a média — estes revelam desalinhamento de pacote ou problemas de segmentação.
- **Analise o tempo até a conversão:** Quanto tempo desde o cadastro até o primeiro pagamento? Existe uma janela natural de conversão? Plote a probabilidade de conversão ao longo do tempo — usuários que não convertem dentro desta janela raramente convertem depois. Quantifique a curva de decaimento.
- **Distinga "freeloaders" de "futuros conversores":**
- **Freeloaders:** Usuários gratuitos intensos que nunca pagarão — eles contornam limites, usam alternativas gratuitas para funcionalidades pagas ou estão em segmentos que não têm orçamento. Dimensione essa população.
- **Futuros conversores:** Usuários construindo em direção a um gatilho — uso crescente, adicionando membros da equipe, explorando funcionalidades pagas. Dimensione essa população.
- Se a população de freeloaders for grande, o nível gratuito está dando muito valor. Se o pipeline de futuros conversores for fino, o nível gratuito não demonstra valor suficiente para motivar a atualização.
### Passo 3: Avalie Pacotes e Preços
O pacote decide quem paga e quanto. Errar significa deixar dinheiro na mesa ou bloquear a adoção.
- **Avalie o alinhamento funcionalidade-nível.** Para cada funcionalidade paga:
- Que porcentagem de usuários gratuitos desejaria isso?
- Que porcentagem de usuários pagos realmente usa isso?
- É um "abridor de portas" (impulsiona a conversão inicial) ou um "fechador de portas" (justifica a renovação)?
- **Identifique problemas de pacote:**
- **Sub-gating:** Funcionalidades de alto valor disponíveis gratuitamente que poderiam impulsionar a conversão se fossem limitadas. Dimensione a oportunidade: "X usuários gratuitos usam a Funcionalidade Y semanalmente. Se limitada ao pago, nas taxas de conversão atuais, isso é $Z/mês."
- **Sobre-gating:** Funcionalidades limitadas a níveis caros que poucos usuários alcançam, reduzindo a adoção geral e criando atrito no efeito de rede. Se um recurso de colaboração está bloqueado para o nível Enterprise, o produto parece vazio para todos os outros.
- **Métrica de valor errada:** Precificação por assentos quando o valor escala com o uso (penaliza a colaboração) ou por uso quando o valor vem da amplitude (punir exploração).
- **Nível ausente:** Uma lacuna na escada de preços onde um segmento significativo de usuários cai — muito caro para atualizar, valor insuficiente no plano atual. Dimensione a população presa nessa lacuna.
- **Identifique sinais de disposição a pagar a partir do comportamento:** Usuários que atingem limites e contornam, usuários que solicitam funcionalidades apenas disponíveis em níveis mais altos, usuários cujos padrões de uso correspondem aos perfis de nível pago mas não atualizaram. Estes são seus alvos de maior conversão.
### Passo 4: Analise Expansão e Contração
Para negócios de assinatura, a receita de expansão é frequentemente uma oportunidade maior do que a aquisição de novos clientes.
- **Decomponha a retenção de receita líquida (NRR):** Retenção bruta + expansão - contração - churn. Dimensione cada componente.
- **Identifique gatilhos de expansão:** O que leva os usuários a atualizar? Crescimento de assentos, crescimento de uso, necessidade de funcionalidades, conformidade? Dimensione cada gatilho por frequência e impacto na receita.
- **Identifique gatilhos de contração:** O que leva os usuários a fazer downgrade? Redução de assentos, declínio de uso, redundância de funcionalidades, cortes orçamentários? Dimensione cada um.
- **Calcule o potencial de receita de expansão:** "X% dos usuários no Nível A usam >80% do seu limite. Se Y% atualizar quando atingir o limite, isso é $Z/mês em receita de expansão." Esta é a oportunidade de monetização mais diretamente abordável.
- **Identifique coortes "prontas para expansão"** — usuários cujo comportamento sinaliza que precisam de um nível superior, mas não atualizaram. O que está bloqueando?
- Choque de preço (o salto entre os níveis é muito grande)
- Valor pouco claro (eles não entendem o que obteriam)
- Atrito (o fluxo de atualização está oculto, requer contato com vendas ou leva muito tempo)
### Passo 5: Dimensione e Classifique as Oportunidades de Monetização (e Anti-Players)
Construa uma matriz de oportunidades de monetização. Para cada oportunidade:
| Oportunidade | Impacto na Receita ($/mês) | Usuários Afetados | Risco de Retenção | Esforço | Tempo para Impacto |
|-------------|-------------------------|----------------|----------------|--------|----------------|
| ... | ... | ... | ... | ... | ... |
- Classifique por **impacto na receita ajustado ao risco.** Uma mudança que adiciona $50K/mês mas aumenta o churn em 5% pode ser líquido-negativa. Mostre a matemática para as 3 principais oportunidades.
- **Modele a sensibilidade:** "Uma melhoria de 1 ponto percentual na conversão gratuito-para-pago no volume atual = $X/mês. Um aumento de $Y no ARPU na base paga atual = $Z/mês." Isso revela se a conversão ou o ARPU é a alavanca maior.
- **Execute a matemática composta:** Melhorias de monetização que também melhoram a retenção (melhor alinhamento de valor, remoção de atritos) se compõem. Mudanças de monetização que prejudicam a retenção se desgastam com o tempo. Sempre modele ambos os efeitos.
**ONDE NÃO FOCAR — anti-players comuns:**
- Aumentar preços sem entender a sensibilidade a preço — você pode aumentar o ARPU mas diminuir a conversão, resultando negativo líquido
- Limitar funcionalidades que impulsionam ativação ou retenção — você trocará receita de curto prazo por churn de longo prazo. Se uma funcionalidade é o que faz os usuários ficarem, mantenha-a acessível.
- Otimizar a monetização antes do product-market fit — se a retenção for ruim, consertar preços não vai te salvar. Use **build-metric-tree** para verificar.
- Adicionar um nível barato para "capturar mais usuários" quando o problema real é atrito de conversão, não preço — você diluirá o ARPU sem consertar o funil
- Tratar todos os usuários gratuitos como "receita potencial" — alguns segmentos nunca pagarão, e tudo bem se eles contribuírem para efeitos de rede, boca a boca ou liquidez de marketplace
- Super-indexar em ARPU quando o volume de usuários é a restrição — use **build-metric-tree** para verificar se monetização ou aquisição é a alavanca real
- Copiar a precificação de um concorrente sem entender se sua métrica de valor e segmentos de clientes são os mesmos
### Formato de Saída
Entregue:
1. Arquitetura de receita com a fórmula decomposta e cada componente dimensionado
2. Análise do funil gratuito-para-pago com gatilhos de conversão e tempo até a conversão
3. Avaliação de pacotes com descobertas específicas de sub-gating, sobre-gating e desalinhamento
4. Análise de expansão/contração com decomposição de NRR e coortes prontas para expansão
5. Matriz de oportunidades de monetização classificada com matemática de receita ajustada ao risco
6. Anti-players — onde não investir
7. Perguntas em aberto — quais dados estão faltando, quais hipóteses precisam de validação (especialmente sensibilidade a preço)
Seja direto. Seja quantitativo. Se o modelo de precificação estiver estruturalmente desalinhado com a entrega de valor, diga isso claramente.
Dicas
- Mudanças de monetização são de alto risco e difíceis de reverter. Sempre combine com craft-experiment-design antes de enviar alterações de preço ou pacotes.
- Traga seus dados de receita por nível e segmento. Mesmo ARPU e taxas de conversão aproximados já desbloqueiam as etapas de dimensionamento.
- Use build-metric-tree primeiro para confirmar que a monetização é realmente o gargalo — se a aquisição ou retenção estiver quebrada, consertar a monetização não vai te salvar.
- Use create-chart para construir gráficos de uso de funcionalidades por nível no Amplitude. Eles são essenciais para a avaliação de pacotes no Passo 3.
- Use diagnose-retention para entender se o churn de receita é impulsionado pelo churn do produto ou pela insatisfação com preço — as intervenções são completamente diferentes.
- Se você tem um nível gratuito, a análise mais impactante é identificar o gatilho de conversão. Uma vez que você sabe o que faz os usuários pagarem, você pode criar engenharia para levar mais usuários até aquele momento.