Marketing y crecimiento ligados a métricas de producto

1. Por qué el marketing de un ChatGPT App es analítica de producto y no «ruido»

En la web clásica puedes poner Google Analytics, colgar etiquetas UTM en todos los enlaces, colocar un par de píxeles de retargeting y vivir así. En el ecosistema de ChatGPT todo es distinto. El usuario está en la interfaz de ChatGPT y tu App es un «invitado» dentro de ese diálogo. Aquí las cookies, el iframe y Facebook Pixel no tienen cabida.

Esto convierte automáticamente a los eventos de producto en la fuente principal (y a menudo la única) de verdad sobre el crecimiento. ¿Con qué frecuencia abren el App? ¿Llegan al flujo clave? ¿Vuelven? ¿Cómo se relaciona con los ingresos? A todas estas preguntas responde no un contador externo, sino tus eventos MCP y la analítica del servidor.

Aquí encaja muy bien el término product‑led growth (PLG): el crecimiento no viene de cuántos banners has comprado, sino de lo bien que el producto resuelve el caso de uso del usuario y de cómo lo evolucionas basándote en datos.

Por eso el protagonista de esta lección es el embudo de eventos dentro de GiftGenius, y no el canal de marketing externo. Los canales estarán, pero solo como hipótesis que afectan a esos eventos.

AARRR para GiftGenius: nuestro embudo pirata

El modelo AARRR (Acquisition, Activation, Retention, Revenue, Referral) encaja perfectamente en un ChatGPT App; solo hay que traducirlo al lenguaje de eventos de nuestra aplicación.

Para GiftGenius se puede describir así:

app_opened

workflow_completed (primera vez)

workflow_completed / app_opened repetidos

checkout_started, checkout_success

referral_sent, referral_activated (opcional)

Es importante que este embudo se describa no por «clics de front‑end», sino por «eventos de uso» a nivel MCP/App: el usuario abrió, siguió el flujo, compró, volvió. A diferencia de la web, donde a veces rastreas «cada movimiento del ratón», aquí la analítica debe ser compacta y con sentido: menos sobre «dónde hizo clic», más sobre «qué hizo en el flujo».

Para la versión básica de GiftGenius nos centramos primero en los cuatro primeros niveles (Acquisition, Activation, Retention, Revenue). Referral sigue siendo importante, pero más bien como siguiente etapa de evolución que se puede activar cuando el núcleo del producto y los pagos ya estén estabilizados.

2. Diseñamos el modelo de eventos: de logs a analítica

En el módulo sobre observabilidad ya acordamos escribir logs JSON estructurados, y no «novelas de logs» en forma libre. Ahora, sobre ellos construimos el modelo de eventos del producto.

La idea mínima: cada paso importante en el App genera un objeto de evento. En el lado MCP puedes tanto registrarlo en logs como enviarlo a un sistema analítico externo (BI, ClickHouse, BigQuery — lo que prefieras).

Una definición sencillísima de eventos para GiftGenius puede ser así:

// Forma general del evento
type GiftGeniusEventType =
  | 'app_opened'
  | 'workflow_started'
  | 'workflow_completed'
  | 'ideas_shown'
  | 'idea_clicked'
  | 'checkout_started'
  | 'checkout_success'
  | 'checkout_failed';

interface AnalyticsEvent {
  type: GiftGeniusEventType;
  userId?: string;          // desde auth, si existe
  sessionId: string;        // UUID de la sesión en ChatGPT
  timestamp: string;        // cadena ISO
  properties?: Record<string, unknown>;
}

Por separado, es útil tener un pequeño helper para enviar eventos desde la parte de Next.js de la aplicación:

async function trackEvent(event: AnalyticsEvent) {
  await fetch('/api/analytics', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(event),
  });
}

En el servidor /api/analytics ya puedes decidir qué hacer con esto: guardar en la base, enviar a un logger o hacer streaming a un data‑pipeline. Lo principal es que todos los eventos estén en un formato unificado. En la práctica tendrás el mismo conjunto de eventos de producto, pero varios puntos de nacimiento: parte de los pasos es más cómodo fijarlos directamente en el servidor MCP vía logger.info, y parte enviarlos desde el widget como AnalyticsEvent a /api/analytics. No importa cuántas «tuberías» técnicas tengas, lo importante es que los tipos de eventos ("app_opened", "workflow_completed", etc.) y sus campos sigan siendo únicos y coherentes.

3. Adquisición: cómo entender de dónde vienen los usuarios

La primera tarea del marketing es responder quién llega y cuántos son. En un ChatGPT App esta «llegada» se fija con el inicio del App en el chat. Lo que queremos registrar se llama "app_opened".

Para GiftGenius esto se puede hacer tanto desde el widget (reaccionando al montaje del componente) como en el servidor (por ejemplo, en el primer callTool de la sesión). Es más fiable en el servidor para no depender de particularidades del renderizado, pero veamos el front por simplicidad.

Ejemplo de componente del widget de GiftGenius con llamada a trackEvent en el primer render:

import { useEffect, useRef } from 'react';
import { trackEvent } from '../lib/analytics';

export default function GiftGeniusWidget() {
  const reported = useRef(false);

  useEffect(() => {
    if (reported.current) return;
    reported.current = true;

    trackEvent({
      type: 'app_opened',
      sessionId: crypto.randomUUID(),
      timestamp: new Date().toISOString(),
      properties: { source: 'chatgpt_app' },
    });
  }, []);

  return (
    <main>
      {/* ...UI principal del widget... */}
    </main>
  );
}

En la práctica querrás obtener sessionId y userId del contexto ya existente (por ejemplo, de _meta o de un token de autorización), y no generarlos en el cliente. Pero la idea es que cada inicio de GiftGenius debe generar ese evento.

El problema de las fuentes de tráfico se resuelve peor que en la web: referers y etiquetas UTM están limitados. Normalmente se usan dos estrategias. La primera: asumir que la fuente principal de tráfico es el Store y analizar solo "app_opened" en el tiempo: si publicaste un nuevo listing en el Store, mira el pico de "app_opened" y los niveles siguientes del embudo. La segunda: usar parámetros explícitos: si das al usuario un enlace como https://chat.openai.com/...&utm_source=blog2025, entonces en el primer "app_opened" puedes tomar esa etiqueta del contexto y ponerla en el campo referral_source.

Es decir, las métricas de adquisición se ven así: «número de "app_opened" por día», «número de userId únicos que iniciaron el App por semana», «distribución por referral_source, si existe».

4. Activación: encontramos el «momento ajá» dentro de GiftGenius

La adquisición por sí sola no significa nada si la gente cierra el App de inmediato. Por eso la segunda capa clave es la Activación. Es el momento en que el usuario sintió por primera vez que el App hace algo realmente útil.

Para GiftGenius ese momento se relaciona lógicamente con finalizar el flujo: el usuario introdujo información del destinatario, configuró filtros y el App le mostró, por ejemplo, 10 ideas relevantes. Justo entonces ve valor por primera vez.

Esto se fija cómodamente con el evento "workflow_completed". Es mejor registrarlo en el servidor MCP cuando ya reuniste los regalos y envías el resultado al widget:

logger.info('event.workflow_completed', {
  type: 'workflow_completed',
  userId,
  sessionId,
  requestId,
  ideasCount: giftIdeas.length,
  timestamp: new Date().toISOString(),
});

Aquí logger es tu logger estructurado, que ya añadiste para SLO e instrumentación de costes. Simplemente le hemos añadido un evento de producto.

Justo con "workflow_completed" calcularás el activation‑rate: activation_rate = (número de userId únicos con al menos un "workflow_completed") / (número de userId únicos con "app_opened" en el período).

También se puede mirar más «grueso»: «proporción de sesiones sessionId en las que hubo "workflow_completed"». Lo importante es que sea una métrica habitual para ti: cuanto mayor sea la activación, mejor arranque tendrá el App.

5. Retención: ¿los usuarios vuelven a tu App?

La retención en un ChatGPT App es un poco más compleja que en un producto web tradicional. Por un lado, ChatGPT en sí es un lugar al que la persona ya vuelve. Por otro, puede volver a muchos otros Apps, no al tuyo. Nos importa entender si vuelve a GiftGenius.

Si hay autenticación (módulo 10), tienes un userId o tenantId estable. En ese caso, la definición clásica es sencilla: el usuario se considera «retenido» (retained) si, digamos, 7 días después del primer "workflow_completed" tiene un nuevo "workflow_completed" o al menos un "app_opened".

Si no hay auth, puedes usar una métrica más débil basada en sessionId y userKey heurísticos (por ejemplo, un hash sobre la cuenta de OpenAI, si está disponible en _meta), pero en la lección asumiremos que sí tenemos userId.

En forma de lógica tipo SQL se ve más o menos así (pseudo‑código):

-- primera activación
WITH first_activation AS (
  SELECT user_id, MIN(timestamp) AS first_ts
  FROM events
  WHERE type = 'workflow_completed'
  GROUP BY user_id
),
retained_d7 AS (
  SELECT fa.user_id
  FROM first_activation fa
  JOIN events e
    ON e.user_id = fa.user_id
   AND e.timestamp >= fa.first_ts + INTERVAL '7 day'
   AND e.timestamp <  fa.first_ts + INTERVAL '14 day'
   AND e.type IN ('app_opened', 'workflow_completed')
)
SELECT COUNT(*) / (SELECT COUNT(*) FROM first_activation) AS d7_retention
FROM retained_d7;

No es obligatorio escribir esta «belleza SQL» en producción, pero es importante entender la idea: la retención trata de si la gente vuelve a usar el App, no solo si llegaron una vez al pago.

6. Ingresos (Revenue): vinculamos el embudo con el dinero

La capa de Revenue para GiftGenius refuerza por qué hacemos todo esto. En el módulo sobre commerce ya añadimos eventos alrededor del pago: "checkout_started", "checkout_success", "checkout_failed". Estos mismos eventos se convierten en la clave de las métricas de ingresos del producto: conversión y ticket medio.

En el momento en que el usuario pulsa «Comprar regalo» y creas la sesión de checkout (a través de ACP/Stripe), en el lado MCP conviene registrar el evento:

logger.info('event.checkout_started', {
  type: 'checkout_started',
  userId,
  sessionId,
  requestId,
  amount: checkout.amount,
  currency: checkout.currency,
  timestamp: new Date().toISOString(),
});

Cuando llega el webhook exitoso del PSP:

logger.info('event.checkout_success', {
  type: 'checkout_success',
  userId,
  sessionId,
  orderId,
  amount: payment.amount,
  currency: payment.currency,
  timestamp: new Date().toISOString(),
});

Ahora puedes calcular fácilmente la conversión:

• «de "workflow_completed" a "checkout_started"» — con qué frecuencia la gente llega siquiera al pago;
• «de "checkout_started" a "checkout_success"» — qué tan bien funciona tu flujo de commerce (errores de tarjeta, fraude, UX de pago).

Y al mismo tiempo, estos eventos se conectan con los logs de costes del tema anterior sobre control de costes e instrumentación: por requestId o sessionId sabes qué llamadas a tools y cuántos tokens/dinero costaron el camino hasta esa compra. Esto da métricas como «promedio de cost_per_paid_workflow» y «ingresos menos coste por cada pedido exitoso».

7. Referral: cuando los usuarios traen a otros

La capa de Referral en un ChatGPT App es un poco inusual. No tienes tus propios push ni newsletters, pero los usuarios pueden compartir chats, enlaces y simplemente decir a otros «busca GiftGenius en el Store».

Técnicamente, puedes introducir los eventos "referral_sent" y "referral_activated", si:

• das a los usuarios un código de referido o un parámetro en el enlace al App (?ref=friend123),
• o procesas referral_source/campaign en el contexto de "app_opened".

En el MVP básico de GiftGenius, Referral se puede dejar para más adelante: primero es importante afinar Acquisition/Activation/Revenue y asegurarte de que el núcleo del embudo funciona. Pero hay que entender dónde «engancharlo»: a los mismos logs de eventos y métricas, y no a un Excel aparte con códigos promocionales.

Embudo visual de GiftGenius

Para mantener la idea en mente, es útil dibujar un pequeño diagrama:

flowchart LR
  A[app_opened] --> B[workflow_started]
  B --> C[workflow_completed]
  C --> D[checkout_started]
  D --> E[checkout_success]

Cada arista aquí es una conversión que se puede medir. Marketing, cambios de UX, experimentos con modelos: todo, al final, debe mejorar una o varias de estas conversiones. Si haces algo y no puedes decir qué arista debería mejorar, es sospechoso.

Dashboards de crecimiento: qué informes hacen falta primero

Imaginemos un dashboard mínimo de crecimiento para GiftGenius. No montamos aquí un sistema BI espacial; queremos al menos una tabla a la que mirar cada semana.

Ejemplo de informe agregado por días:

Se ve enseguida que el día 3 «echamos gasolina» a la adquisición (subió "app_opened"), pero bajaron la activación y la conversión: quizá llegó tráfico inadecuado o rompiste algo en el UX. Precisamente tablas así ayudan a separar el buen marketing del simplemente ruidoso.

Además del tiempo, es útil mirar cohortes: usuarios que llegaron en una semana determinada y su retención a los 7/30 días. Pero para empezar, alcanza con construir cortes simples por días y semanas.

8. Marketing como una serie de experimentos sobre eventos

Pasemos ahora al punto más «de marketing»: cómo vincular actividades externas (artículos, listing en el Store, partnerships) con lo que vemos en los eventos del App.

Principio clave: cualquier idea de marketing se formula como una hipótesis sobre qué métricas de producto deben cambiar.

Por ejemplo, para GiftGenius:

• «Si mejoramos el listing del Store (iconos, descripción, vídeo demo), debería aumentar el número de "app_opened" de usuarios nuevos y, idealmente, su tasa de activación».
• «Si escribimos un artículo sobre cómo elegir regalos para Año Nuevo y ponemos ahí un enlace a GiftGenius, en los próximos 3 días deberían subir los "app_opened" con referral_source = "blog_ny2025" y después los "workflow_completed" en esa cohorte».

Técnicamente, esto se implementa a menudo con un campo adicional campaign o referral_source en el evento "app_opened". Por ejemplo, si al inicializar el App obtuviste del contexto de ChatGPT cierta etiqueta:

trackEvent({
  type: 'app_opened',
  sessionId,
  timestamp: new Date().toISOString(),
  properties: {
    referral_source: openaiContext.referralSource ?? 'organic',
    app_version: '1.3.0',
  },
});

Ahora puedes construir informes «por campaña»: cuántos "app_opened" y "workflow_completed" tienen los que llegaron con referral_source = "blog_ny2025", y cómo se diferencia de la orgánica.

Es importante que no consideramos el marketing exitoso solo por los «alcances» que alguien dibujó en otro sitio. Si un blogger dice que su vídeo lo vieron un millón de personas, genial, pero para GiftGenius el éxito será «el crecimiento de "app_opened" y "workflow_completed" dentro de nuestro App».

9. Ejemplo: experimento de marketing para GiftGenius

Juntemos todo en un escenario concreto y, de paso, vinculemos cuidadosamente una campaña externa con los eventos de producto dentro de GiftGenius.

Imagina que quieres probar la hipótesis: un artículo en un blog popular sobre regalos traerá usuarios «adecuados». En el artículo no enlazas directamente a ChatGPT, sino a tu landing, por ejemplo:

https://giftgenius.app/landing?utm_source=giftblog2025

El usuario llega a una landing corta con la descripción de GiftGenius y un botón «Abrir en ChatGPT». En el backend de la landing lees utm_source y lo guardas en el perfil del usuario (o en una tabla aparte), por ejemplo como acquisitionSource = "giftblog2025". El botón de la landing ya lleva a tu ChatGPT App en el Store; después el usuario conecta el App y empieza a usarlo.

Cuando ese usuario inicia GiftGenius en ChatGPT y tu backend recibe la primera llamada desde Apps SDK / MCP, recuperas el acquisitionSource guardado y lo añades a los eventos de producto. Para "app_opened" puede verse así:

logger.info('event.app_opened', {
  type: 'app_opened',
  userId,
  sessionId,
  referral_source: user.acquisitionSource ?? 'organic',
  timestamp: new Date().toISOString(),
});

Igual marcas los eventos "workflow_completed", "checkout_started", "checkout_success". Luego el experimento se reduce a comparar cohortes: usuarios con referral_source = "giftblog2025" frente a orgánica. Si la cohorte del blog tiene mayor proporción de flujos completados y pagos con ingresos por usuario similares o mejores, se puede considerar la campaña exitosa; si solo crecen los inicios de la app pero la conversión a "workflow_completed" y "checkout_success" cae, entonces el artículo trae sobre todo curiosos, no compradores.

Este enfoque es bueno porque una vez «traduces» cuidadosamente la etiqueta UTM del mundo web a tu campo interno referral_source y luego trabajas solo con la analítica de producto del App — sin magia y sin intentar pasar parámetros de URL directamente dentro de ChatGPT.

Al mismo tiempo, puedes mirar la estructura de costes si en algún lugar fijas el CAC (cuánto costó la colocación) y el cost_per_task. Entonces la hipótesis se convierte en un experimento más «financiero»: «¿Se rentabiliza este canal?».

10. Analítica privacy‑first: no rompemos la política ni el sentido común

Un punto importante aparte — cómo no convertirse un poco en Facebook. A diferencia de la web clásica, OpenAI es bastante estricto con la privacidad en ChatGPT Apps: no se puede rastrear datos personales, recopilar PII innecesaria ni enviar el texto completo de diálogos a cualquier parte.

Las buenas prácticas para la analítica de GiftGenius son:

1. No guardar el texto en claro de los mensajes del usuario en los eventos. En su lugar, registrar solo «hechos del flujo»: tipo de flujo, número de ideas mostradas, hecho de pago exitoso.
2. Si necesitas distinguir usuarios, usar identificadores seudonimizados (userId, tenantId), no email/nombre. Cualquier PII se guarda en la base con autenticación; la analítica opera con claves anonimizadas.
3. Evitar en logs y eventos campos que puedan identificar directamente a la persona si no son necesarios para el funcionamiento (por ejemplo, la dirección de envío completa no nos hace falta en un evento; su lugar está en la base protegida de commerce).
4. Usar al máximo analítica agregada: te interesan activation‑rate y retención sobre cientos de usuarios, no los inquilinos uno por uno.

Y no olvidemos que ya tuvimos un módulo sobre auditoría y ciclo de vida: si un usuario pide eliminar sus datos, la lógica de retención debe tenerlo en cuenta. Pero eso ya es más del módulo 15; aquí basta con recordar que la analítica no da indulgencia para recoger cualquier basura.

11. Relación con la instrumentación de costes y SLO: marketing que lo cuenta todo

Desde el punto de vista técnica, el cuadro ideal es así: tienes un flujo único de eventos estructurados, donde a cada sesión de usuario se asocian:

• eventos de producto ("app_opened", "workflow_completed", "checkout_success");
• datos de costes (tokens, cost_estimate, duration_ms por herramientas);
• métricas de SLO (latencia y errores de MCP/herramientas, disponibilidad).

Entonces cualquier decisión de marketing y producto pasa a ser realmente data‑driven casi automáticamente. Puedes preguntar:

• «¿Cuál es el activation_rate de los usuarios de la campaña X y cuánto cuesta de media su workflow exitoso?»
• «¿No está creciendo el error_rate o la p95 de latencia a medida que aumenta el tráfico desde el Store?»
• «Si abaratamos el modelo en el experimento «coste ↔ calidad» de la lección anterior, ¿no cayó la conversión a "checkout_success" ni bajaron los revenue por usuario?»

Y todo esto ya no requiere inventar sistemas nuevos: simplemente usas los mismos logs e instrumentos de costes que implantaste antes.

En definitiva, el marketing de un ChatGPT App no va de tráfico por sí mismo, sino de mejorar métricas concretas de producto dentro de tu aplicación. Registra los pasos clave del flujo ("app_opened", "workflow_completed", "checkout_success"), conéctalos con la instrumentación de costes y SLO, y formula actividades de marketing como hipótesis sobre qué eslabón del embudo quieres mejorar. Si mantienes este embudo y las restricciones de privacidad en mente, las decisiones de producto y crecimiento se vuelven casi automáticamente más sensatas y sostenibles.

12. Errores típicos al trabajar con métricas de producto y marketing

Error n.º 1: marketing por el tráfico y no por la activación.
A menudo los equipos se alegran por un pico de "app_opened" tras algún artículo o tuit y dan el experimento por exitoso sin mirar activación y conversión. Al final, obtienen un montón de «turistas» que elevan la carga y el coste, pero no traen dinero ni se convierten en usuarios reales. El enfoque correcto es mirar siempre el embudo más allá del primer paso: cuántos de los que llegaron alcanzaron "workflow_completed" y "checkout_success".

Error n.º 2: ausencia de un identificador de usuario unificado.
A veces el App empieza a registrar eventos, pero sin un userId estable o al menos un tenantId. En ese modo solo puedes contar algo como «número de eventos por día», pero no retención ni cost_per_user. Más tarde añadir un tracking de usuario correcto puede ser difícil, especialmente si ya hay limitaciones fuertes de privacidad. Es mejor pensar el esquema de identificación ya en la fase de autenticación (módulo 10) y usarlo en todos los eventos.

Error n.º 3: trackear «cada estornudo» en lugar de eventos clave.
La primera reacción ante la analítica de eventos es registrar absolutamente todo: hover del ratón, cada focus de un input, cada re‑render. En el contexto de ChatGPT esto es especialmente dañino: estos eventos encajan mal con el modelo de uso, crean toneladas de ruido y elevan riesgos de privacidad. Es mucho más útil limitarse a unos pocos eventos clave del flujo y analizarlos bien.

Error n.º 4: campañas de marketing sin atribución.
Patrón frecuente: el equipo lanza una campaña (artículo, vídeo, partnership) pero no etiqueta el tráfico entrante y luego se pregunta «¿funcionó o no?». Como resultado, todos los cambios en las métricas se diluyen. Mucho mejor usar campos explícitos referral_source o campaign en los eventos "app_opened", aunque sea con parámetros tipo UTM sencillos, y luego comparar esas cohortes con la orgánica.

Error n.º 5: ignorar las restricciones de privacidad por «analítica total».
A veces, persiguiendo el detalle, se empiezan a escribir en los eventos textos de las consultas, datos personales del destinatario del regalo, direcciones y otra PII. Esto es peligroso en dos frentes: por las políticas de OpenAI/Store y por el riesgo legal real (GDPR, CCPA, etc.). La analítica correcta se construye sobre rasgos agregados del flujo e identificadores anónimos, no sobre guardar toda la conversación «por si acaso».

Error n.º 6: optimizar solo por coste, sin tener en cuenta calidad y crecimiento.
Tras el módulo sobre costes es fácil caer en el «modo ahorro extremo», intentando reducir tokens a toda costa. Si con ello cae la activation‑rate, la retención y "checkout_success", el ahorro es ficticio: estás matando el valor del producto. Mantén siempre en mente el triángulo «coste ↔ calidad ↔ crecimiento»: cualquier cambio en prompts, modelos y UX hay que mirarlo a través del prisma tanto del coste como de las métricas de producto.