Monetização, pricing e experimentos “custo ↔ qualidade”

1. Por que pensar em monetização justamente agora

Até este módulo, a pergunta principal era “isso funciona mesmo?”. Agora adicionamos o próximo nível de complexidade: “e isso se paga?”.

Para aplicativos LLM isso dói especialmente: custos variáveis (tokens de LLM, modelos de rerank, embeddings) rapidamente explodem a sua cabeça, em vez daqueles seus habituais “servidor por $20 e Postgres por $15”. Ignorar isso — significa receber no fim do mês uma fatura da OpenAI comparável a uma hipoteca.

Portanto, hoje temos três grandes temas:

1. Quais são os modelos de monetização para o ChatGPT App e especificamente para o nosso GiftGenius.
2. Como vincular pricing ↔ cost_per_task e não vender “100 seleções de presentes por $1” se uma única seleção já custa $0.15.
3. Como rodar experimentos A/B “custo ↔ qualidade”: trocar modelo, prompts, UX e fazer o logging de modo que em algumas semanas você tome decisões com base em dados, não em sensação.

Ao mesmo tempo, preparamos o terreno para o próximo módulo sobre LLM‑evals e quality_score, mas não mergulhamos lá em código.

2. Modelos de monetização do ChatGPT App: B2C, B2B, freemium e upsell

Se deixarmos a “mágica de LLM” de lado, os modelos de monetização aqui são muito parecidos com os usados em apps SaaS e mobile tradicionais. Mas a interface conversacional tem nuances: o usuário muitas vezes não percebe “o que é gratuito e o que é pago”, e isso precisa ser projetado com cuidado no UX.

Vamos destrinchar as principais opções usando o GiftGenius.

B2C: usuários comuns e presentes

Aqui seus clientes são pessoas comuns que chegam ao ChatGPT e pedem: “selecione um presente para um fã de espaço por 50 dólares”. Você pode não vender seus próprios produtos, mas apenas selecionar presentes para o usuário.

Modelos B2C típicos:

1. Compra avulsa.
   O usuário paga por um cenário específico. Por exemplo: 3 ideias gratuitas, depois — um “pacote” pago com mais 10 ideias para um único destinatário.
2. Assinatura.
   Pagamento mensal pelo acesso. No GiftGenius isso pode ser “até 100 seleções por mês” ou “seleções ilimitadas para quem presenteia com frequência”.
3. Freemium (camadas gratuitas vs pagas).
   O cenário básico é gratuito (até N seleções por mês, funcionalidade reduzida), enquanto o plano pago dá limites maiores, um modelo mais potente, formatos adicionais de seleção e histórico. Este é o modelo mais típico para um ChatGPT App: “dentro do ChatGPT — básico gratuito; recursos premium — pagos”.
4. Upsell dentro do App.
   O usuário faz uma seleção básica gratuita, vê um resultado razoável, e você sugere de forma sutil: “quer que por $X eu faça uma seleção aprofundada considerando wishlist, redes sociais etc.?” ou “emitir um vale‑presente na hora”.

B2B: equipes, empresas e presentes corporativos

Aqui entram em cena RH, departamentos de marketing e “pessoas responsáveis por presentes para funcionários/clientes”.

Conjunto tradicional:

• Licença por usuário (per seat).
  Por exemplo, o plano “HR‑Team” para 10 pessoas, cada uma com acesso ao GiftGenius, relatórios sobre presentes e orçamentos.
• Licença por empresa (per company).
  “Até 500 funcionários, preço fixo por mês, com quantas seleções quiser por dentro.”
• Recursos enterprise adicionais.
  Painel de administração separado, integrações com HRIS/CRM, relatórios customizados, SLA.

Em ambos os casos você não calcula “quanto custa uma seleção”, mas sim cost_per_user_per_month ou cost_per_tenant_per_month e compara com o preço da licença.

Como escolher um modelo para o GiftGenius

Para não se afundar na teoria, dá para começar com uma opção simples:

• B2C: freemium.
  3 seleções por mês grátis; depois — assinatura por $5/mês com seleções ilimitadas e modelo premium.
• B2B: por empresa.
  Tarifa “Equipe de RH” por $99/mês, incluindo até 500 seleções para funcionários, integração com o sistema de RH e relatórios.

Depois, quando surgirem dados reais de cost_per_task e conversão, você pode ajustar tudo isso. Na prática, esses números por enquanto foram “chutados”: parecem razoáveis, mas ainda não verificamos quanto custa um cenário concluído. Na próxima seção, vamos vincular essas tarifas à custo real — cost_per_task.

3. Relação entre preço e custo: o que é cost_per_task

Agora vamos ao mais importante: como não montar uma fundação de caridade chamada GPT‑5.

Intuição: preço ≥ cost_per_task × margem

No tema anterior você já viu o conceito de cost_per_task — é o gasto total por um cenário bem-sucedido: de “o usuário iniciou a seleção” até “recebeu o resultado” (e, possivelmente, pagou algo).

Nele entram:

• gastos com LLM (tokens * price_per_token de entrada/saída, incluindo, talvez, modelos de rerank, embeddings etc.);
• a parcela dos custos de infraestrutura por tarefa (servidores, BD, filas, gateway MCP) — muitas vezes calculada por dados agregados;
• opcionalmente — custos transacionais (Stripe fee, checagens de fraude), se você calcula cost_per_task até o “dinheiro no bolso”.

A ideia é simples: o preço do cenário ou da assinatura deve ser maior que o custo médio de um cenário, multiplicado por uma “folga de margem”.

Se simplificarmos muito:

price_per_task >= cost_per_task * ( 1 + margin )

Não vamos poluir a aula com números e margens em percentuais; o importante é a regra intuitiva.

Exemplo para o GiftGenius

Suponha que você já implementou o cost logging da aula anterior e tem um relatório agregado:

• média de cost_per_task (uma seleção de presente concluída) = 0.15 USD;
• isso já inclui tokens de LLM (várias chamadas suggest_gifts, rerank e um summary final) e a parcela de infraestrutura.

Depois você observa o cenário:

• o usuário gratuito faz uma seleção e às vezes compra um vale de $50;
• a conversão em compra entre as seleções concluídas é, digamos, 5%.

Sem entrar ainda na unit economics completa, já dá para estimar que, de 100 seleções:

• você gasta 100 × $0.15 = $15;
• dessas, 5 terminam em checkout de $50;
• receita de 5 × $50 = $250.

Parece bom: grosseiramente ($250 – $15) mais as taxas da Stripe, impostos e outras dores. Mas é importante entender que, com uma assinatura generosa demais (digamos, 100 seleções por $1), você facilmente vai para o vermelho.

Mini‑exemplo de código: salvar cost_per_task em TypeScript

Suponha que você tenha uma MCP‑tool que conclui o workflow de seleção e sabe seu custo total:

// Tipo para métricas finais do cenário
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// Função hipotética de registro de métricas
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// Em algum lugar no handler de conclusão da seleção:
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // calculado a partir dos tokens
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

Esse log depois é fácil de agregar em um dashboard para ver a distribuição de cost_per_task por modelos, usuários e cenários.

4. Pricing: como converter cost_per_task em preços reais

Agora que temos cost_per_task, é preciso decidir pelo que e quanto cobrar do usuário.

Regra simples para B2C

Para B2C, você pode escolher uma regra empírica:

“Estamos dispostos a gastar em LLM+infra no máximo X% da receita”.

Por exemplo, você decide que não quer gastar mais de 20% do faturamento com custos de LLM. Então:

• se cost_per_task = $0.15, o preço mínimo por um cenário pago deveria ser ≈ $0.75, para que 0.15 seja aproximadamente 20% de 0.75;
• se você vende assinatura, estime quantos cenários médios cabem por assinante ao mês e multiplique.

Não tem problema começar “no olhômetro” e ajustar os preços quando aparecerem dados reais (spoiler: não aparecem de imediato).

Regra simples para B2B

Em B2B normalmente se olha para:

• cost_per_user_per_month ou cost_per_tenant_per_month;
• a disposição do negócio a pagar (o tamanho do problema que você resolve).

Por exemplo, se uma equipe de RH distribui presentes via GiftGenius na casa de dezenas de milhares de dólares por ano, uma assinatura de $99/mês parece modesta, mesmo que seus custos de LLM para essa equipe sejam só $10/mês. O principal é entender que você não quer acabar numa situação em que cost_per_tenant = $80 e a assinatura — $50.

E sim, isso acontece, se “somos IA, vamos deixar tudo grátis por enquanto e depois a gente vê”.

Uma pequena função “guardiã” no servidor

Você pode ter no código um simples “guard” que avisa se o custo saiu de um intervalo razoável ao escolher o preço:

function checkPricingSafety(params: {
  avgCostPerTaskUsd: number;
  plannedPricePerTaskUsd: number;
  maxCostShare: number; // por exemplo, 0.3 = 30%
}): boolean {
  const share = params.avgCostPerTaskUsd / params.plannedPricePerTaskUsd;
  return share <= params.maxCostShare;
}

// Exemplo:
checkPricingSafety({
  avgCostPerTaskUsd: 0.15,
  plannedPricePerTaskUsd: 0.75,
  maxCostShare: 0.3,
}); // true — ok, 20% < 30%

Isso não substitui um modelo financeiro, mas dá uma sanity check rápida (verificação de bom senso), especialmente quando você está experimentando preços.

5. Experimentos “modelo / agente vs custo e conversão”

Agora vamos ao mais interessante: experimentos A/B.

A intuição aqui é simples:

• Variante A — modelo caro / workflow mais complexo;
• Variante B — modelo barato / workflow simplificado;
• queremos entender como isso impacta simultaneamente:
  • cost_per_task,
  • a qualidade do resultado (pela percepção do usuário e por avaliações futuras de LLM),
  • métricas de negócio (conversão, receita).

Com o que exatamente experimentar

Existem três eixos principais de experimentos:

1. Modelo.
   Por exemplo, GPT‑5 vs GPT‑5‑mini ou até outra família. Normalmente o modelo caro oferece melhor qualidade e maior cost_per_task; o barato — o contrário.
2. Lógica do agente / prompts.
   Etapas mais detalhadas, prompts longos, raciocínio complexo — mais qualidade, porém mais caro; lógica minimalista — mais barata e às vezes quase no mesmo nível de qualidade.
3. Formato de UX.
   Um wizard longo com muitos campos e dicas vs modo inline rápido. Mesmo com o mesmo modelo, a quantidade de tokens e etapas pode variar bastante.

Todas essas variações você já pode implementar; o importante é envolvê-las em experimentos com logging.

Quais campos registrar para os experimentos

Por cima dos campos que você já registra para custo (tokens, model, cost_estimate, user_id, request_id etc.), adicione campos de experimento:

• experiment_id — identificador único do experimento (por exemplo, "gift_model_ab_2025_11").
• variant — qual ramificação o usuário recebeu: "A", "B", "control", "treatment" etc.
• model_name ou agent_version — para depois não precisar lembrar qual configuração estava ativa.
• o resultado do cenário:
  • se houve workflow_completed;
  • se houve checkout_success;
  • o cost_per_task final.
• opcional — quality_score (falaremos mais adiante; é a ponte para o módulo de LLM‑evals).

Exemplo de log JSON de evento de experimento

Um evento de log típico pode ser assim:

{
  "level": "info",
  "timestamp": "2025-11-21T20:15:03.123Z",
  "event": "experiment_task_result",
  "experiment_id": "gift_model_ab_2025_11",
  "variant": "A",
  "user_id": "user_123",
  "task_id": "task_456",
  "model_name": "gpt-5.2",
  "workflow_completed": true,
  "checkout_success": false,
  "cost_per_task_usd": 0.18,
  "quality_score": null,
  "request_id": "req_abc",
  "trace_id": "trace_xyz"
}

Esses registros se agregam muito bem em qualquer ferramenta analítica: dá para montar tabelas do tipo “variant A vs B por cost/conversão/receita”.

Exemplo de código: registro do experimento em uma MCP‑tool

Suponha que seu servidor MCP já calculou o custo do cenário (cost_per_task) e sabe em qual variante do experimento o usuário está:

type ExperimentContext = {
  experimentId: string;
  variant: "A" | "B";
};

async function logExperimentResult(params: {
  ctx: ExperimentContext;
  userId: string;
  taskId: string;
  modelName: string;
  costPerTaskUsd: number;
  workflowCompleted: boolean;
  checkoutSuccess: boolean;
}) {
  const event = {
    level: "info" as const,
    event: "experiment_task_result",
    timestamp: new Date().toISOString(),
    experiment_id: params.ctx.experimentId,
    variant: params.ctx.variant,
    user_id: params.userId,
    task_id: params.taskId,
    model_name: params.modelName,
    cost_per_task_usd: params.costPerTaskUsd,
    workflow_completed: params.workflowCompleted,
    checkout_success: params.checkoutSuccess,
  };

  console.log(JSON.stringify(event));
}

Em algum lugar acima você decide a qual variante o usuário pertence (por user_id, tenant_id ou aleatoriamente) e passa o ExperimentContext para o handler do workflow. Neste nível, fixamos o que e como registrar para os experimentos: quais campos são necessários e onde escrevê-los. Em seguida, vamos falar sobre como transformar tais experimentos em hipóteses de produto compreensíveis e decisões de pricing, e não apenas um monte de logs.

6. Agora um pouco sobre quality_score e LLM‑evals

Falarei sobre este tema com mais detalhes no módulo 20; por ora, a ideia é: quality_score é a avaliação da qualidade de uma resposta/solução em uma escala, por exemplo, de 0 a 10, frequentemente dada por um modelo LLM “juiz” separado. Mais detalhes sobre LLM‑as‑judge no módulo 20.

Agora não precisamos dos detalhes de implementação — isso é assunto do próximo módulo — mas é importante entender o conceito:

• além de dinheiro, queremos medir também a qualidade;
• podemos pedir a uma pessoa ou a um segundo modelo para avaliar: “quão bem o GiftGenius selecionou o presente numa escala de 0 a 10?”;
• depois podemos observar como o quality_score se correlaciona com:
  • conversão em compra;
  • retenção de usuários;
  • willingness‑to‑pay (disposição a pagar).

Do ponto de vista de logs, é apenas mais um campo:

type ExperimentResultEvent = {
  experiment_id: string;
  variant: string;
  user_id: string;
  task_id: string;
  cost_per_task_usd: number;
  quality_score?: number; // 0-10, pode ser undefined
};

Por aqui encerramos a aula de hoje: detalhes de LLM‑evals, golden cases e “LLM‑as‑judge” virão mais adiante no curso. Por enquanto, basta entender onde esse score entra nos experimentos. É justamente o quality_score que salva do erro clássico de otimizar “apenas por custo”: ele permite ver numericamente quando barateamos demais o cenário, começamos a perder qualidade e, junto com ela — conversão e receita.

7. Como usar os experimentos para pricing e monetização

Agora não estamos apenas registrando experimentos, mas formalizando-os como hipóteses de negócio claras, com métricas de sucesso e impacto na monetização. Só logar experiment_id não basta: é importante formalizar mudanças de produto como hipóteses com uma métrica de sucesso explícita.

Exemplo de hipótese: modelo caro vs barato

Vamos supor este experimento para o GiftGenius:

• Variante A — modelo caro (GPT‑5), raciocínio rico, wizard longo.
• Variante B — modelo barato (GPT‑5‑mini), prompt um pouco mais simples e conversa mais curta.

Hipótese: trocar o modelo por um mais barato reduzirá o cost_per_task em pelo menos 50%. Ao mesmo tempo, a qualidade pelo usuário e pela avaliação de LLM (nosso quality_score) cairá no máximo 5–10%, e a conversão em compra não cairá.

Tecnicamente, para cada task você registra os mesmos campos da seção 5.2:

• experiment_id = "gift_model_ab_2025_11";
• variant = "A" ou "B";
• model_name;
• cost_per_task_usd;
• workflow_completed;
• checkout_success;
• quality_score (quando houver LLM‑evals).

Depois de uma ou duas semanas você pode:

• calcular a média de cost_per_task para A e B;
• comparar o checkout‑rate (proporção de cenários com pagamento bem-sucedido);
• comparar a média do quality_score, se existir.

Se B quase não perde em qualidade, mas custa metade, você pode:

• migrar para B e aumentar a margem;
• ou manter o preço, mas reduzir o custo da assinatura para o usuário (impulsionando o crescimento).

Exemplo de hipótese: upsell de qualidade

Outra hipótese: se após 3 ideias gratuitas você exibir um upsell premium “relatório completo de presentes + recomendações de texto para o cartão” por $4.99, a conversão em compra aumentará pelo menos 2 pontos percentuais (2 p.p.). Ao mesmo tempo, o cost_per_task aumentará não mais que $0.05.

Aqui o experimento não é tanto sobre o modelo, e sim sobre UX e lógica de produto. Mas tecnicamente é tudo igual:

• variantes de UX diferentes por variant;
• logging de custo e receita por cenário;
• análise de uplift (o quanto a nova lógica trouxe mais dinheiro sem explodir os custos).

Exemplo de código: registrar receita simples por tarefa

Às vezes é conveniente registrar, junto do custo, a receita do cenário:

type RevenueEvent = {
  taskId: string;
  userId: string;
  experimentId?: string;
  variant?: string;
  revenueUsd: number;
  checkoutSuccess: boolean;
};

async function logRevenue(event: RevenueEvent) {
  console.log(JSON.stringify({
    level: "info",
    event: "task_revenue",
    timestamp: new Date().toISOString(),
    ...event,
  }));
}

Vinculando depois task_revenue e experiment_task_result por taskId, é possível calcular para cada variante:

• média de revenue_per_task;
• média de cost_per_task;
• e montar um ROI simples.

8. Exercício prático: experimento A/B para o GiftGenius

Para ter algo concreto e ligar teoria à prática, vamos detalhar como seria o experimento “modelo caro vs modelo barato” para o GiftGenius — passo a passo, em formato de exercício prático.

O que vamos mudar

• Variante A:
  • modelo gpt-5;
  • system prompt mais detalhado e etapas do agente;
  • possivelmente mais chamadas de raciocínio intermediário.
• Variante B:
  • modelo gpt-5-mini;
  • um prompt um pouco mais compacto;
  • menos chamadas de ferramentas auxiliares, fluxo simplificado.

Como distribuímos os usuários entre as variantes

A maneira mais simples — pelo hash do user_id:

function assignVariant(userId: string): "A" | "B" {
  const hash = Array.from(userId).reduce((acc, ch) => acc + ch.charCodeAt(0), 0);
  return hash % 2 === 0 ? "A" : "B";
}

Assim garantimos uma distribuição mais ou menos uniforme, e o mesmo usuário sempre cai na mesma variante.

O que registramos

Ao concluir o workflow de seleção, você registra o mesmo conjunto de campos das seções anteriores (5.2 e 7.1) e adiciona a receita:

• experiment_id = "gift_model_ab_2025_11";
• variant da função acima;
• model_name, o modelo efetivamente utilizado;
• cost_per_task_usd, custo total de tokens e infraestrutura;
• workflow_completed (true/false);
• checkout_success (true/false);
• revenue_usd (0 ou o valor da compra).

Opcionalmente (um pouco mais adiante no curso) será adicionado o quality_score.

E esses dados vão para seu log/analítica, onde podem ser organizados em tabelas:

Dessa tabela dá para ver que B gera quase o mesmo dinheiro com custo duas vezes menor — um argumento forte a seu favor.

9. Esquema visual: como é o circuito “custo ↔ qualidade ↔ monetização”

Para juntar tudo na cabeça, vamos desenhar um pequeno esquema no estilo “dados indo e voltando”:

flowchart TD
    U[Usuário no ChatGPT] --> A["ChatGPT App (GiftGenius)"]
    A --> E[Módulo de experimento
atribui variante A/B]
    E --> AG[Agente / MCP tools
com modelos diferentes]
    AG -->|Chamadas de LLM| L[Logs de uso & custo]
    AG -->|Resultados da seleção| UI[Widget / resposta no chat]
    UI -->|comportamento: cliques, compras| BE[Commerce backend]

    L --> M[Métricas: cost_per_task,
cost_per_user]
    BE --> M
    M --> D[Dashboard de pricing & experimentos]

    subgraph "Módulo futuro 20"
      J[LLM-juiz
quality_score]
      J --> M
    end

Agora você está exatamente no meio desse esquema: sabe registrar custo e receita e está adicionando por cima disso experimentos e pricing. No próximo módulo chega o tema Juiz Dredd (LLM-juiz).

10. Erros típicos ao trabalhar com monetização e experimentos

Quando a visão geral está clara, fica mais fácil enxergar onde tudo costuma quebrar. Abaixo — um conjunto de erros típicos, útil como checklist ao trabalhar com monetização e experimentos de custo.

Erro nº 1: otimizar apenas por custo, esquecendo a qualidade.
Cenário comum: você migra para um modelo mais barato, vê que a fatura da OpenAI ficou mais amigável e declara vitória. Um mês depois percebe que os usuários compram vales com menos frequência, voltam menos, cresce o suporte “sugeriram algo sem sentido”. Se você não registra quality_score nem ao menos métricas proxy (cliques em ideias, salvamentos, conversões), é fácil cair no modo “barato, porém inútil”.

Erro nº 2: calcular o cost_per_task apenas pelo LLM, ignorando infraestrutura e pagamentos.
Às vezes os desenvolvedores contam os tokens direitinho, mas esquecem de Redis, filas, APIs de terceiros, taxa da Stripe e afins. Como resultado, o cost_per_task sai bem subestimado e os preços parecem mais confortáveis do que realmente são. A infraestrutura normalmente é calculada por dados agregados, mas sua parcela ainda precisa entrar no custo do cenário.

Erro nº 3: mudar modelos/UX sem experiment_id e variant explícitos.
“Reescrevemos um pouco o prompt, parece que ficou melhor” — um mês depois ninguém lembra quando exatamente mudou, em quais dados isso se baseia e no que resultou. Sem marcar explicitamente os experimentos nos logs (experiment_id, variant) e sem vinculá-los a releases específicos, é difícil analisar retrospectiva e provar que as melhorias não foram ao acaso.

Erro nº 4: tomar decisões com dados pequenos demais ou cedo demais.
Se o experimento roda por dois dias e, com base em dez pagamentos, você decide que o modelo B “é muito mais vantajoso”, isso é um exemplo clássico de conclusão ruidosa estatisticamente. É preciso ao menos um horizonte mínimo — uma semana, de preferência mais — e quantidade suficiente de cenários para comparar médias e conversões. Não entramos em estatística nesta aula, mas a regra “não tire conclusões com 5 eventos” vale a pena ter em mente.

Erro nº 5: usar pricing complexo sem uma regra mental simples.
Você pode desenhar um plano em três camadas, preços em diferentes moedas e descontos por códigos de indicação, mas não ter uma regra simples do produto, do tipo “em custos de LLM, estamos dispostos a gastar no máximo X% da receita” ou “o preço do cenário não deve cair abaixo de 3× a média de cost_per_task”. Sem esses limitadores, é fácil perder a margem e não perceber até o fim do mês.

Erro nº 6: esquecer a ligação da monetização com marketing e crescimento.
Monetização e pricing não vivem no vácuo: quanto mais cara a assinatura, maior o churn e menor a conversão; quanto mais baixo o preço, maiores as exigências de otimização de custo. O erro é olhar apenas “quanto estamos ganhando agora” e não ligar isso às métricas de aquisição/ativação/retenção, tema da próxima discussão do módulo. Experimentos de pricing devem ser registrados logo no mesmo padrão dos experimentos de qualidade e custo, para ver o quadro completo.