Analytics para MVPs: Por qué descarté GA4 y aposté por Umami

Cuando lanzas un MVP (Producto Mínimo Viable), tu activo más valioso no es el código, es la información. Necesitas saber si la gente usa tu producto, qué características tocan y dónde se van.

El “default” de la industria es instalar Google Analytics 4 (GA4). Sin embargo, para un Business Engineer, GA4 presenta problemas estructurales en la etapa de validación: latencia, ceguera por Ad-Blockers y una complejidad de configuración que desvía recursos del desarrollo del producto.

Para mis últimos desarrollos, he migrado a Umami. No es solo una cuestión de privacidad; es una decisión de arquitectura de software y eficiencia operativa.

1. La trampa de la “Instrumentación”

En GA4, medir un clic en un botón específico (“Comprar”) suele requerir una configuración tripartita: configurar el evento en Google Tag Manager (GTM), crear el trigger y luego definir la conversión en la interfaz de GA4. Es frágil y lento.

En un MVP, el código cambia a diario. Umami permite la instrumentación declarativa directamente en el JSX/HTML. La analítica vive junto al código, no en una interfaz externa.

La diferencia en el código:

1
// En tu componente de React / Astro / Next.js
2

3
// Opción A: GA4 (Requiere useEffect, librerías externas o GTM)
4
<button onClick={() => {
5
  gtag('event', 'click', { 'event_category': 'ecommerce', 'event_label': 'buy_btn' });
6
  handleBuy();
7
}}>
8
  Comprar
9
</button>
10

11
// Opción B: Umami (Nativo, limpio, declarativo)
12
<button
13
  className="btn-primary"
14
  onClick={handleBuy}
15
  data-umami-event="Boton Comprar - Header" // <--- Magia
16
  data-umami-event-price="29.99"            // <--- Metadata extra
17
>
18
  Comprar
19
</button>

Business Value: El desarrollador mantiene el control de las métricas. Si cambias el botón de lugar, la métrica viaja con él. La deuda técnica de analítica se reduce a cero.

2. Soberanía de datos: SQL vs. interfaces opacas

Con Google, tus datos están secuestrados tras una interfaz diseñada para vender anuncios. Hacer preguntas complejas requiere exportar a BigQuery (costo extra) o sufrir con el “Sampling” (datos incompletos).

Con Umami, tú eres el dueño de la base de datos (PostgreSQL). Esto transforma la analítica en inteligencia de negocio real. Puedes conectar tu base de datos de producción con tus analíticas para responder preguntas que GA4 no puede.

El caso de uso: El embudo real (funnel) Imagina que quieres saber el drop-off exacto en tu flujo de registro.

1
-- Query SQL directo a tu base de datos de Umami
2
WITH funnel AS (
3
    SELECT
4
        session_id,
5
        MAX(CASE WHEN url_path = '/landing' THEN 1 ELSE 0 END) as step_1_landing,
6
        MAX(CASE WHEN url_path = '/pricing' THEN 1 ELSE 0 END) as step_2_pricing,
7
        MAX(CASE WHEN url_path = '/checkout' THEN 1 ELSE 0 END) as step_3_checkout
8
    FROM website_event
9
    WHERE created_at > NOW() - INTERVAL '30 days'
10
    GROUP BY session_id
11
)
12
SELECT
13
    SUM(step_1_landing) as visits,
14
    SUM(step_2_pricing) as viewed_pricing,
15
    SUM(step_3_checkout) as started_checkout,
16
    (SUM(step_3_checkout)::float / NULLIF(SUM(step_1_landing),0)) * 100 as conversion_rate
17
FROM funnel;

Este nivel de granularidad es gratuito y propietario. Es tratar la analítica como infraestructura, no como un servicio de terceros.

3. Arquitectura de evasión (bypass ad-blockers)

Si tu MVP está dirigido a un público técnico, el 40% usará bloqueadores. Umami permite una configuración avanzada llamada proxying. En lugar de pedir el script a umami.tusitio.com, puedes configurar tu servidor (Next.js Middleware o Nginx) para que sirva el script desde una ruta interna.

El truco del middleware (Next.js/Nuxt):

1. El navegador pide: tusitio.com/js/script.js (Parece un archivo local inofensivo).
2. Tu servidor reenvía esa petición internamente a Umami.
3. Resultado: Los Ad-Blockers no ven nada sospechoso. Obtienes data del 100% de tus usuarios, no solo del 60%.

4. Performance: 2KB vs 45KB

En un MVP, cada milisegundo cuenta para la retención.

• GA4: Carga múltiples librerías y tracking de publicidad. Pesa ~45KB+ y bloquea el hilo principal.
• Umami: Es un script minimalista. Pesa menos de 2KB.

Matemáticamente, es una reducción del 95% en la carga útil de analítica. Esto mejora directamente tus métricas de LCP (Largest Contentful Paint), cruciales para el SEO desde el día 1.

Despliegue técnico recomendado

No te cases con una herramienta, cásate con la eficiencia. Aquí tienes dos “sabores” probados para desplegar tu MVP + Umami a coste cero:

Opción A: El estándar (React/Next.js)

• Frontend: Vercel (Next.js).
• Base de datos: Supabase o Neon (PostgreSQL).
• Analytics: Umami Self-Hosted.

Opción B: Alto rendimiento (Nitro/Nuxt)

• Engine: Nitro (el motor de servidor universal de Nuxt). Despliegue en Cloudflare Workers o Netlify Edge.
• Base de datos: Supabase o Neon (Serverless Postgres).
• Analytics: Umami Self-Hosted.

Caso real: La arquitectura de este sitio

Para validar esta tesis, predico con el ejemplo. El sitio que estás leyendo ahora mismo opera bajo una arquitectura Serverless de alto rendimiento diseñada para costar $0 en mantenimiento hasta escalar.

• Framework: Astro + MDX (Gestión de contenido basada en Git, sin base de datos para máxima velocidad).
• Hosting: Vercel (Edge Network).
• Analytics: Umami Self-Hosted conectado a Neon (Proyecto dedicado).

Anexo: Guía de instalación de Umami Self-Hosted

Así es como puedes desplegar tu propia instancia gratuita paso a paso:

1. Fork: Ve al repositorio oficial de Umami y haz un “Fork” a tu cuenta personal de GitHub.
2. Base de datos: Crea un nuevo proyecto en Neon llamado analytics. Copia la “Connection String” (debe terminar en ?sslmode=require).
3. Vercel: Crea un nuevo proyecto en Vercel e importa el repositorio que acabas de forkear.
4. Variables: Configura las Environment Variables antes de desplegar:
   • DATABASE_URL: Copia la “Connection String” desde Neon.
   • HASH_SALT: Cualquier cadena de texto larga y aleatoria.
5. Deploy: Dale a desplegar. Vercel construirá la app y generará las tablas en tu base de datos automáticamente.

Arquitectura Multi-tenant: Eficiencia a escala

Una vez desplegado, te preguntarás: “¿Tengo que repetir esto para cada cliente o proyecto nuevo?”. La respuesta es un rotundo no.

Umami es multi-tenant por diseño. Esto significa que una sola instancia (un solo despliegue en Vercel + una sola base de datos en Neon) puede gestionar infinitos sitios web de forma aislada pero centralizada.

¿Cómo funciona por debajo? Todo convive ordenadamente gracias a dos tablas maestras:

1. Tabla website: Guarda un registro por cada propiedad (ej: “MVP 1”, “E-commerce Cliente”, “Landing Page”). Cada uno recibe un website_id único (UUID).
2. Tabla website_event: Es un gran lago de datos donde caen todos los clics de todos tus proyectos, segregados por la columna website_id.

La ventaja para el Business Engineer

• Coste marginal cero: Solo mantienes una instancia. Puedes trackear 1, 10 o 50 sitios sin aumentar tu factura de infraestructura base.
• Visión de portafolio: Desde un solo login administras la analítica de todo tu imperio digital.
• Inteligencia cruzada (SQL): Al estar todo en la misma base, puedes lanzar queries globales.

Ejemplo: ¿Cuál de mis proyectos tuvo más tráfico en las últimas 24 horas?

1
SELECT
2
    w.name as project_name,
3
    COUNT(*) as total_visits
4
FROM website_event e
5
JOIN website w ON e.website_id = w.website_id
6
WHERE e.created_at > NOW() - INTERVAL '24 hours'
7
GROUP BY w.name
8
ORDER BY total_visits DESC;

GA4 es excelente si tu modelo de negocio depende de comprar tráfico en Google Ads y necesitas optimizar el ROAS con algoritmos de caja negra.

Pero si estás construyendo un producto, validando un mercado y valoras la agilidad, Umami te da algo que Google no puede: La verdad completa de tus datos y la propiedad absoluta de ellos.