Monetización, pricing y experimentos «coste ↔ calidad»

1. Por qué pensar en la monetización justo ahora

Hasta este módulo, la pregunta principal era «¿esto siquiera funciona?». Ahora añadimos el siguiente nivel de dificultad: «¿sale rentable?».

Para las aplicaciones LLM esto duele especialmente: los costes variables (tokens LLM, modelos de rerank, embeddings) te vuelan la cabeza en lugar de tus habituales «servidor por $20 y Postgres por $15». Ignorarlo — significa acabar el mes con una factura de OpenAI comparable a una hipoteca.

Así que hoy, tres temas grandes:

1. Qué modelos de monetización hay para una ChatGPT App y, en concreto, para nuestro GiftGenius.
2. Cómo vincular pricing ↔ cost_per_task y no vender «100 selecciones de regalos por $1» si una sola selección ya cuesta $0.15.
3. Cómo montar experimentos A/B «coste ↔ calidad»: cambiar modelo, prompts, UX y registrarlo de forma que, en un par de semanas, tomes decisiones con datos y no con sensaciones.

Al mismo tiempo preparamos suavemente el terreno para el siguiente módulo sobre LLM‑evals y quality_score, pero sin meternos aún en código.

2. Modelos de monetización de una ChatGPT App: B2C, B2B, freemium y upsell

Si dejamos a un lado la magia LLM, los modelos de monetización aquí se parecen mucho a los de los SaaS y apps móviles habituales. Pero la interfaz conversacional tiene matices: el usuario a menudo no siente «dónde está lo gratis y dónde lo de pago», y hay que diseñarlo con cuidado en el UX.

Veamos las opciones principales con GiftGenius.

B2C: usuarios finales y regalos

Aquí tus clientes son personas corrientes que llegan a ChatGPT y piden: «elige un regalo para un fan del espacio por 50 dólares». Puedes no vender productos propios, sino solo seleccionar regalos para el usuario.

Modelos B2C típicos:

1. Compra única.
   El usuario paga por un escenario concreto. Por ejemplo: 3 ideas gratis, y después — un «paquete» de pago con 10 ideas más para un destinatario.
2. Suscripción.
   Pago mensual por acceso. En GiftGenius podría ser «hasta 100 selecciones al mes» o «selecciones ilimitadas para quien regala con frecuencia».
3. Freemium (niveles gratis vs de pago).
   El escenario básico es gratis (hasta N selecciones al mes, funcionalidad recortada) y el de pago ofrece más límites, un modelo potente, formatos adicionales de selección e historial. Es el modelo más típico para una ChatGPT App: «dentro de ChatGPT — básico gratis, y funciones premium — de pago».
4. Upsell dentro de la app.
   El usuario hace una selección básica gratuita, ve un resultado decente y tú propones suavemente: «¿quieres que por $X haga una selección profunda teniendo en cuenta wishlist, redes sociales, etc.?» o «tramita ahora mismo un cheque regalo».

B2B: equipos, empresas y regalos corporativos

Aquí entran en juego RR. HH., marketing y «las personas responsables de los regalos para empleados/clientes».

El conjunto tradicional:

• Licencia por usuario (per seat).
  Por ejemplo, plan «HR‑Team» para 10 personas, cada una con acceso a GiftGenius, informes sobre regalos y presupuestos.
• Licencia por empresa (per company).
  «Hasta 500 empleados, precio fijo al mes y dentro — las selecciones que quieras».
• Funcionalidades enterprise adicionales.
  Panel de administración separado, integraciones con HRIS/CRM, informes a medida, SLA.

En ambos casos no cuentas «cuánto cuesta una selección», sino cost_per_user_per_month o cost_per_tenant_per_month y lo comparas con el precio de la licencia.

Cómo elegir el modelo para GiftGenius

Para no perdernos en la teoría, podemos tomar una opción inicial sencilla:

• B2C: freemium.
  3 selecciones al mes gratis; después — suscripción de $5/mes con selecciones ilimitadas y modelo premium.
• B2B: por empresa.
  Tarifa «equipo de RR. HH.» por $99/mes, que incluye hasta 500 selecciones para empleados, integración con el sistema de RR. HH. e informes.

Luego, cuando aparezcan datos reales de cost_per_task y conversión, podrás ajustar todo esto. De hecho, estas cifras, por ahora, están cogidas «del aire»: parecen razonables, pero aún no hemos comprobado cuánto nos cuesta un escenario completado. En la siguiente sección vincularemos tales tarifas con el coste real — cost_per_task.

3. Vincular precio y coste: qué es cost_per_task

Ahora pasamos a lo más importante: cómo no montarte una ONG a nombre de GPT‑5.

Intuición: precio ≥ cost_per_task × margen

En el tema anterior ya viste el concepto de cost_per_task — es el gasto total por un escenario exitoso: desde «el usuario inicia la selección» hasta «recibe el resultado» (y, posiblemente, paga algo).

Incluye:

• costes del LLM (tokens * price_per_token en entrada/salida, incluyendo, quizá, modelos de rerank, embeddings, etc.);
• la parte de los costes de infraestructura por tarea (servidores, BD, colas, MCP‑gateway) — a menudo se calcula con datos agregados;
• opcionalmente — costes transaccionales (Stripe fee, controles antifraude), si consideras cost_per_task antes de «dinero neto».

La idea es simple: el precio del escenario o de la suscripción debe estar por encima del coste medio de un escenario multiplicado por un «colchón de margen».

Si lo simplificamos mucho:

price_per_task >= cost_per_task * ( 1 + margin )

No vamos a llenar la lección con cifras y márgenes en porcentaje; lo importante es la regla intuitiva.

Ejemplo para GiftGenius

Supongamos que ya has implementado el registro de costes de la lección anterior y tienes un informe agregado:

• coste medio cost_per_task (una selección de regalo completada) = 0.15 USD;
• esto ya incluye tokens LLM (varias llamadas a suggest_gifts, rerank y el resumen final) y la parte de infraestructura.

Luego miras el escenario:

• un usuario gratuito hace una selección y, a veces, compra un cheque regalo de $50;
• la conversión a compra entre las selecciones completadas es, digamos, del 5 %.

Sin meternos aún en la unidad de economía completa, ya podemos estimar que, de 100 selecciones:

• gastas 100 × $0.15 = $15;
• de ellas, 5 terminan con checkout de $50;
• ingresos 5 × $50 = $250.

Tiene buena pinta: en bruto ($250 – $15) más comisiones de Stripe, impuestos y demás dolor. Pero es importante entender que, con una suscripción demasiado generosa (digamos, 100 selecciones por $1), te vas a pérdidas fácilmente.

Mini‑ejemplo de código: guardar cost_per_task en TypeScript

Supongamos que tienes una herramienta MCP que finaliza el workflow de selección y conoce su coste total:

// Tipo para las métricas finales del escenario
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// Función ficticia para registrar métricas
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// En algún lugar del manejador de finalización de la selección:
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // calculado a partir de los tokens
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

Ese log luego se agrega fácilmente en un dashboard para ver la distribución de cost_per_task por modelos, usuarios y escenarios.

4. Pricing: cómo convertir cost_per_task en precios reales

Ahora que tenemos cost_per_task, hay que decidir cuánto y por qué cobrar al usuario.

Regla sencilla para B2C

Para B2C puedes elegir una regla empírica:

«Estamos dispuestos a gastar en LLM+infra como mucho X % de los ingresos».

Por ejemplo, decides que no quieres gastar más del 20 % de la facturación en costes LLM. Entonces:

• si cost_per_task = $0.15, el precio mínimo por un escenario de pago debería ser ≈ $0.75, para que 0.15 sea aproximadamente el 20 % de 0.75;
• si vendes una suscripción, estimas cuántos escenarios medios corresponderán a un suscriptor por mes y multiplicas.

Es totalmente normal empezar «a ojo» y ajustar precios cuando aparezcan datos reales (spoiler: no aparecerán de inmediato).

Regla sencilla para B2B

En B2B se suele mirar a:

• cost_per_user_per_month o cost_per_tenant_per_month;
• la disposición del negocio a pagar (el tamaño del problema que resuelves).

Por ejemplo, si un equipo de RR. HH. gestiona a través de GiftGenius regalos por decenas de miles de dólares al año, una suscripción de $99/mes se ve modesta, incluso si tus costes LLM para ese equipo son solo $10/mes. Lo principal es entender que no quieres acabar en una situación donde cost_per_tenant = $80 y la suscripción — $50.

Y sí, eso pasa si «somos AI, pongámoslo todo gratis de momento y ya veremos».

Pequeña función «guard» en el servidor

Puedes tener en el código un «guard» sencillo que te avise si el coste se sale de los márgenes razonables al elegir precio:

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

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

No sustituye a un modelo financiero, pero te da una sanity check rápida (comprobación «de sentido común»), especialmente cuando experimentas con precios.

5. Experimentos «modelo/agente vs coste y conversión»

Ahora pasamos a lo más interesante: experimentos A/B.

La intuición es simple:

• Variante A — modelo caro / workflow más complejo;
• Variante B — modelo barato / workflow simplificado;
• queremos entender cómo impacta a la vez en:
  • cost_per_task,
  • la calidad del resultado (según la percepción del usuario y según futuras evaluaciones LLM),
  • métricas de negocio (conversión, ingresos).

Con qué experimentar exactamente

Hay tres ejes principales de experimentos:

1. Modelo.
   Por ejemplo, GPT‑5 vs GPT‑5‑mini o incluso otra familia. Normalmente un modelo caro da mejor calidad y mayor cost_per_task, uno barato — al revés.
2. Lógica del agente / prompts.
   Más pasos, prompts largos, razonamiento complejo — más calidad pero más caro; lógica minimalista — más barata y, a veces, casi igual en calidad.
3. Formato de UX.
   Un asistente largo con muchos campos y ayudas vs un modo inline rápido. Incluso con el mismo modelo, la cantidad de tokens y pasos puede variar mucho.

Todas estas variaciones ya puedes implementarlas; lo importante es envolverlas en experimentos con logging.

Qué campos registrar para los experimentos

Sobre los campos que ya registras para costes (tokens, model, cost_estimate, user_id, request_id, etc.), añade campos de experimento:

• experiment_id — identificador único del experimento (por ejemplo, "gift_model_ab_2025_11").
• variant — qué rama le tocó al usuario: "A", "B", "control", "treatment", etc.
• model_name o agent_version — para no tener que recordar después qué configuración estaba activa.
• resultado del escenario:
  • si hubo workflow_completed;
  • si hubo checkout_success;
  • cost_per_task final.
• opcional — quality_score (más sobre esto luego; es el puente al módulo de LLM‑evals).

Ejemplo de registro JSON de un evento de experimento

Un evento típico de log puede verse así:

{
  "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"
}

Este tipo de registros se agregan muy bien en cualquier analítica: puedes construir tablas del tipo «variant A vs B por coste/conversión/ingresos».

Ejemplo de código: registro del experimento en una herramienta MCP

Imagina que tu servidor MCP ya ha calculado el coste del escenario (cost_per_task) y sabe en qué rama del experimento está el usuario:

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));
}

En algún lugar más arriba decides a qué variante pertenece el usuario (por user_id, tenant_id o aleatoriamente), y pasas el ExperimentContext al manejador del workflow. A este nivel hemos fijado qué y cómo registrar para los experimentos: qué campos hacen falta y dónde escribirlos. A continuación hablaremos de cómo convertir estos experimentos en hipótesis de producto claras y decisiones de pricing, y no solo en un conjunto de logs.

6. Un poco sobre quality_score y LLM‑evals

Lo contaré con más detalle en el módulo 20; ahora solo comparto la idea: quality_score es una puntuación de calidad de la respuesta/solución en una escala, por ejemplo, de 0 a 10, a menudo emitida por un modelo LLM «juez». Más sobre LLM‑as‑judge en el módulo 20.

Ahora no necesitamos detalles de implementación — es tema del siguiente módulo — pero es importante entender el concepto:

• además del dinero, queremos medir también la calidad;
• podemos pedir a una persona o a un segundo modelo que evalúe: «¿qué tan bien ha seleccionado GiftGenius el regalo en una escala de 0 a 10?»;
• después podemos ver cómo quality_score correlaciona con:
  • la conversión a compra;
  • la retención de usuarios;
  • willingness‑to‑pay (disposición a pagar).

Desde el punto de vista de los logs, es solo otro campo:

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

Aquí nos detenemos en el marco de la lección de hoy: los detalles de LLM‑evals, golden cases y «LLM‑as‑judge» aparecerán más adelante en el curso; por ahora basta con entender dónde encajar luego este score en los experimentos. Precisamente quality_score evita el error clásico de optimizar «solo por coste»: permite ver numéricamente dónde ya hemos abaratado demasiado el escenario, empezamos a perder calidad y, con ella, conversión e ingresos.

7. Cómo usar los experimentos para pricing y monetización

Ahora no solo registramos experimentos, sino que los formulamos como hipótesis de negocio claras con métricas de éxito e impacto en la monetización. Registrar experiment_id no basta: es importante formalizar los cambios del producto como hipótesis con una métrica de éxito explícita.

Ejemplo de hipótesis: modelo caro vs barato

Imagina este experimento para GiftGenius:

• Variante A — modelo caro (GPT‑5), razonamiento rico, asistente largo.
• Variante B — modelo barato (GPT‑5‑mini), prompt algo más sencillo y conversación más corta.

Hipótesis: cambiar a un modelo barato reducirá cost_per_task al menos un 50 %. Al mismo tiempo, la calidad para el usuario y la valoración LLM (nuestro quality_score) caerán no más de un 5–10 %, y la conversión a compra no empeorará.

Técnicamente, para cada task registras los mismos campos que en la sección 5.2:

• experiment_id = "gift_model_ab_2025_11";
• variant = "A" o "B";
• model_name;
• cost_per_task_usd;
• workflow_completed;
• checkout_success;
• quality_score (cuando haya LLM‑evals).

En una o dos semanas puedes:

• calcular el cost_per_task medio para A y B;
• comparar el checkout‑rate (proporción de escenarios con pago exitoso);
• comparar el quality_score medio, si existe.

Si B pierde poco en calidad pero cuesta la mitad, puedes:

• pasarte a B y aumentar el margen;
• o mantener el precio pero bajar el coste de la suscripción para el usuario (impulsando así el crecimiento).

Ejemplo de hipótesis: upsell de calidad

Otra hipótesis: si después de 3 ideas gratuitas mostramos un upsell premium «informe completo de regalos + recomendaciones para el texto de la tarjeta» por $4.99, la conversión a compra aumenta al menos 2 puntos porcentuales (2 p. p.). Al mismo tiempo, cost_per_task aumentará como mucho $0.05.

Aquí el experimento no va tanto del modelo, sino del UX y la lógica de producto. Pero técnicamente es lo mismo:

• diferentes variantes de UX por variant;
• registro de coste e ingresos por escenario;
• análisis del incremento (en qué medida la nueva lógica generó más dinero sin disparar los costes).

Ejemplo de código: registrar un ingreso sencillo por tarea

A veces conviene registrar junto al coste también los ingresos por escenario:

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 después task_revenue y experiment_task_result por taskId, puedes calcular para cada variante:

• revenue_per_task medio;
• cost_per_task medio;
• y construir un ROI sencillo.

8. Ejercicio práctico: experimento A/B para GiftGenius

Para tener algo en lo que apoyarnos y aterrizar la teoría, digamos paso a paso cómo sería el experimento «modelo caro vs barato» para GiftGenius.

Qué cambiamos

• Variante A:
  • modelo gpt-5;
  • system‑prompt y pasos del agente más detallados;
  • quizá más llamadas de reasoning intermedias.
• Variante B:
  • modelo gpt-5-mini;
  • prompt algo más compacto;
  • menos llamadas a herramientas auxiliares, flujo simplificado.

Cómo repartimos a los usuarios entre variantes

La forma más simple — por el hash de 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";
}

Así garantizamos una distribución más o menos uniforme y un mismo usuario siempre cae en la misma variante.

Qué registramos

Al finalizar el workflow de selección registras el mismo conjunto de campos que en las secciones anteriores (5.2 y 7.1), y añades los ingresos:

• experiment_id = "gift_model_ab_2025_11";
• variant de la función anterior;
• model_name, el modelo realmente usado;
• cost_per_task_usd, el coste total de tokens e infraestructura;
• workflow_completed (true/false);
• checkout_success (true/false);
• revenue_usd (0 o el importe de la compra).

De forma opcional (un poco más adelante en el curso) se añadirá quality_score.

Y estos datos van a tu log/analítica, donde los puedes plasmar en tablas:

De esa tabla se ve que B aporta casi el mismo dinero con coste dos veces menor, y eso es un argumento fuerte a su favor.

9. Esquema visual: cómo se ve el circuito «coste ↔ calidad ↔ monetización»

Para juntar todo mentalmente, dibujemos un esquema tipo «los datos van y vienen»:

flowchart TD
    U[Usuario en ChatGPT] --> A["ChatGPT App (GiftGenius)"]
    A --> E[Módulo de experimentos
asigna variant A/B]
    E --> AG[Agente / MCP tools
con distintos modelos]
    AG -->|Llamadas LLM| L[Logs de uso y coste]
    AG -->|Resultados de selección| UI[Widget / respuesta en el chat]
    UI -->|comportamiento: clics, compras| BE[Backend de comercio]

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

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

Ahora estás justo en medio de este esquema: sabes registrar costes e ingresos, y añades encima experimentos y pricing. En el siguiente módulo llegará el tema Juez Dredd (LLM‑juez).

10. Errores típicos al trabajar con monetización y experimentos

Cuando tienes el esquema general en la cabeza, es más fácil ver dónde suele romperse todo. Abajo — un conjunto de errores típicos que conviene tener a mano como checklist al trabajar con monetización y experimentos de coste.

Error n.º 1: optimizar solo por coste, olvidando la calidad.
Escenario común: pasas a un modelo más barato, ves que la factura de OpenAI es más amable y declaras la victoria. Y luego, al cabo de un mes, notas que los usuarios compran menos cheques regalo, vuelven peor, crece el soporte de «me sugeristeis cualquier cosa». Si no registras quality_score ni, al menos, métricas proxy (clics en ideas, guardados, conversiones), es fácil caer en el modo «barato pero inútil».

Error n.º 2: calcular cost_per_task solo por el LLM, ignorando infraestructura y pagos.
A veces los desarrolladores cuentan con cuidado los tokens, pero olvidan Redis, colas, APIs de terceros, la comisión de Stripe y demás. Como resultado, cost_per_task queda muy infravalorado y los precios parecen más cómodos de lo que son. La infraestructura suele calcularse con datos agregados, pero su parte debe incluirse igualmente en el coste del escenario.

Error n.º 3: cambiar modelos/UX sin experiment_id y variant explícitos.
«Hemos reescrito un poco el prompt, parece que va mejor» — un mes después nadie recuerda cuándo se cambió, en qué datos se basó y a qué condujo. Sin un marcado explícito de experimentos en los logs (experiment_id, variant) y sin vincularlo a releases concretos, es difícil analizar la retrospectiva y demostrar que las mejoras no son casuales.

Error n.º 4: tomar decisiones con datos demasiado pequeños o demasiado pronto.
Si el experimento lleva dos días y, con base en diez pagos, decides que el modelo B «es mucho más rentable», es un ejemplo clásico de conclusión ruidosa. Hace falta al menos un horizonte mínimo — una semana, mejor más — y un número suficiente de escenarios para comparar medias y conversiones. En la lección no entramos en estadística, pero la regla «no saques conclusiones por 5 eventos» conviene tenerla presente.

Error n.º 5: usar un pricing complejo sin una regla mental sencilla.
Puedes dibujar un plan de tarifas en tres niveles, precios en distintas divisas y descuentos por referidos, pero no tener una regla de producto sencilla del tipo «estamos dispuestos a gastar como mucho X % de ingresos en costes LLM» o «el precio del escenario no debe bajar de 3× el cost_per_task medio». Sin tales limitadores es fácil perder margen y no notarlo hasta fin de mes.

Error n.º 6: olvidar la relación entre monetización, marketing y crecimiento.
La monetización y el pricing no viven en el vacío: cuanto más cara la suscripción, mayor el churn y menor la conversión; cuanto menor el precio, mayores las exigencias de optimización de costes. El error — mirar solo «cuánto ganamos ahora» sin vincularlo con las métricas de adquisición/activación/retención, de las que hablaremos en el siguiente tema del módulo. Es mejor registrar los experimentos de pricing en la misma clave que los de calidad y coste, para ver el cuadro completo.