El Problema: Analytics Como Afterthought
Llevas tres meses construyendo tu SaaS. La API funciona bien, los usuarios están contentos, y de repente tu jefe (o tu instinto emprendedor) te pregunta: "¿Cuántos usuarios han visto esta feature? ¿Cuántos la han usado?"
Y aquí es donde todo se desmorona.
No porque no tengas datos. Los tienes. Pero están esparcidos por logs que nadie lee, eventos que nunca capturaste, y métricas que viven en Vercel Analytics pero que no te dicen nada útil sobre el comportamiento de tus usuarios.
La mayoría de desarrolladores comete el mismo error: integra analytics directamente en el core de la API. Crea dependencias. Ralentiza las respuestas. Y cuando necesita cambiar de proveedor (Mixpanel, Segment, Posthog), tiene que refactorizar todo.
No tiene que ser así.
La Arquitectura Correcta: Analytics Como Capa Opcional
Piénsalo así: tu API es el corazón de tu aplicación. Las analytics son el sistema nervioso que monitorea cómo late ese corazón. No debería estar acoplado.
La clave es diseñar analytics como un add-on desacoplado que pueda estar ahí o no estar, sin afectar el flujo principal.
Esto significa:
1. Eventos, no datos en tiempo real: En lugar de hacer queries complejas cuando algo ocurre, emite eventos simples 2. Procesamiento asincrónico: Las analytics nunca bloquean tu respuesta HTTP 3. Flexible en el proveedor: Cambiar de Posthog a Segment no requiere tocar tu API core
El Flujo Real
``` Usuario hace clic ↓ API procesa la acción ↓ API responde (200 OK) ↓ Eventualmente, se emite evento de analytics ↓ Proveedor de analytics lo recibe ```
Nota lo importante: el usuario nunca espera a que las analytics se procesen.
Implementación Práctica: Qué Datos Capturar
Ahora viene la pregunta que todos se hacen: ¿qué mido exactamente?
Hay tres categorías de eventos que importan:
1. Impresiones
Un usuario ve algo. Puede ser:
- Carga de una página
- Visualización de un componente
- Aparición de un modal o diálogo
Esto es lo más fácil de capturar. En el frontend, típicamente lo haces con un simple POST a tu API:
```javascript // En tu componente React/Next.js const trackImpression = async (componentId) => { try { await fetch('/api/events/impression', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ componentId, timestamp: new Date().toISOString(), userId: getCurrentUserId(), sessionId: getSessionId() }) }) } catch (e) { // Silenciosamente falla. Las analytics nunca deben romper la UX console.error('Analytics error:', e) } }
// Usa esto en useEffect useEffect(() => { trackImpression('hero-section') }, []) ```
2. Clicks y Interacciones
El usuario hace algo activo. Ejemplos:
- Click en un botón
- Envío de un formulario
- Descarga de un archivo
Estos son más valiosos que las impresiones porque indican intención real.
```javascript const trackClick = async (buttonId, metadata = {}) => { await fetch('/api/events/click', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ buttonId, userId: getCurrentUserId(), sessionId: getSessionId(), timestamp: new Date().toISOString(), ...metadata // Puedes agregar datos contextuales }) }) }
// En tu botón <button onClick={() => trackClick('upgrade-button', { plan: 'pro' })}> Upgrade </button> ```
3. Engagement
Esto es más sofisticado. Mide cómo interactúa el usuario con tu producto:
- Tiempo en página
- Scroll depth
- Búsquedas realizadas
- Filtros aplicados
El Lado del Backend: Recibir y Almacenar Eventos
Ahora, ¿cómo procesas estos eventos en tu API?
La respuesta correcta es: no los proceses inmediatamente.
En su lugar, emítelos a una cola. Puede ser:
- Una tabla en tu base de datos (Supabase, por ejemplo)
- Un servicio de colas (Bull, RabbitMQ)
- Un servicio externo (Vercel KV, Redis)
```typescript // En tu endpoint de API (Next.js) export async function POST(req: Request) { const body = await req.json()
// Valida mínimamente if (!body.userId || !body.componentId) { return Response.json({ error: 'Invalid event' }, { status: 400 }) }
// Emite el evento a una cola (sin esperar) queueEvent({ type: 'impression', payload: body, timestamp: Date.now() }).catch(err => { // Log, pero no falles la respuesta console.error('Queue error:', err) })
// Responde inmediatamente return Response.json({ success: true }, { status: 200 }) } ```
Luego, un worker asincrónico procesa esos eventos:
```typescript // Un Cron job o worker que corre cada minuto export async function handleAnalyticsQueue() { const events = await getQueuedEvents()
for (const event of events) { // Envía a tu proveedor de analytics await posthog.capture({ distinctId: event.payload.userId, event: event.type, properties: event.payload })
// Marca como procesado await markEventAsProcessed(event.id) } } ```
Eligiendo el Proveedor Correcto
Esto depende de tus necesidades:
- **Posthog**: Open source, self-hosted option, bueno para startups
- **Segment**: Centraliza eventos de múltiples fuentes
- **Mixpanel**: Enfocado en product analytics
- **Google Analytics 4**: Gratis, pero menos flexible
- **Plausible**: Privacy-first, bueno si RGPD es crítico
La ventaja de tu arquitectura desacoplada es que puedes cambiar entre ellos sin tocar tu API core.
El Aspecto Importante que Muchos Olvidan: Privacidad
Estamos en España/Europa. RGPD es real.
Cuando captures datos de usuarios: 1. Necesitas consentimiento (generalmente mediante cookie banner) 2. Debes anonimizar datos sensibles (no guardes emails en eventos de click) 3. Permite opt-out (algunos usuarios no quieren ser rastreados)
Una implementación segura:
```javascript const trackEvent = async (eventName, data) => { // Verifica que el usuario ha consentido analytics if (!hasAnalyticsConsent()) { return }
// No incluyas datos personales sensibles const safeData = { ...data, email: undefined, // Nunca phone: undefined, // Nunca userId: hashUserId(data.userId) // Anónimo }
await fetch('/api/events', { method: 'POST', body: JSON.stringify(safeData) }) } ```
Caso Real: Cómo Lo Uso en Mis Proyectos
En mis SaaS típicamente:
1. Día 1-30: Sin analytics. Solo logs básicos en Vercel. 2. Día 30-90: Agrego un endpoint `/api/events` que guarda en una tabla de Supabase. 3. Día 90+: Conecto Posthog si necesito dashboards complejos.
Esta progresión funciona porque nunca acoplé analytics al core.
Cuando decidí cambiar a Posthog, solo tuve que: 1. Agregar el SDK de Posthog 2. Cambiar el worker para enviar a Posthog en lugar de Supabase 3. Listo. Cero cambios en la API core.
Takeaway: Diseña para el Futuro
La lección aquí no es sobre qué herramienta usar. Es sobre arquitectura.
Cuando construyes APIs, piensa en las capas:
- Core (lógica de negocio)
- Observabilidad (logs, errores)
- Analytics (comportamiento de usuarios)
- Monetización (pagos, límites)
Cada capa debe ser independiente. Cada una debe poder cambiar sin romper las otras.
Analytics como add-on opcional es solo una aplicación de este principio.
Construye así desde el principio. Tu yo del futuro te lo agradecerá cuando necesites pivotar.