Cómo construir un panel de administración RGPD en solitario
Un desarrollador en solitario necesita métricas tanto como un equipo de 50 personas. Quizás incluso más. Cuando estás solo gestionando el backend, el frontend, el marketing y el soporte, no puedes permitirte adivinar lo que está pasando. Necesitas ver: cuántos usuarios están activos, qué funciones se utilizan, si el backend soporta la carga, si el pipeline de voz se cae.
He construido un panel de administración completo para TAMSIV, un sistema de alertas por correo electrónico para incidentes críticos y un seguimiento analítico conforme al RGPD. Así es como todo esto encaja y por qué cada pieza es indispensable cuando operas en solitario.
Puntos clave a recordar:
- Un panel de administración no es un lujo, es vital para un desarrollador en solitario en producción
- GA4 con Consent Mode permite cumplir con el RGPD sin sacrificar las métricas
- Las alertas por correo electrónico (AlertService) detectan problemas antes que los usuarios
- El consentimiento de cookies con 3 interruptores y versionado es el mínimo RGPD en Europa
- El doble seguimiento (GA4 + Supabase) cubre las métricas web Y las métricas de negocio
¿Por qué un desarrollador en solitario necesita un panel de administración?
La respuesta corta: porque no tienes un equipo SRE, ni un gerente de producto, ni un analista. Eres todo eso a la vez. Y sin visibilidad de lo que sucede en tu aplicación, tomas decisiones a ciegas.
Antes del panel, descubría los problemas a través de los comentarios de los usuarios (cuando se tomaban la molestia de escribir). Un fallo en el pipeline de voz podía pasar desapercibido durante horas. Un pico de inscripciones pasaba inadvertido. Una funcionalidad que nadie usaba seguía costándome tiempo de mantenimiento.
El panel de administración cambió eso. Accesible en /admin/dashboard en tamsiv.com, me da una vista en tiempo real de todo lo que importa:
- Usuarios: Inscripciones diarias, usuarios activos (DAU/WAU/MAU), retención
- Funcionalidades: Uso del dictáfono, creación de tareas/notas/eventos, gamificación
- Infraestructura: Latencia WebSocket, tasa de error STT, fallbacks LLM activados
- Negocio: Conversiones Free → Pro, ingresos RevenueCat, tasa de cancelación
¿Cómo construir un panel de administración con Recharts y Supabase?
El panel está construido con Recharts, una librería de gráficos React basada en D3.js. ¿Por qué Recharts? Porque se integra de forma nativa con React, soporta SSR (importante para Next.js) y el renderizado es limpio sin una configuración compleja.
La arquitectura es simple:
- Datos: Todo proviene de Supabase a través de funciones RPC. Cada gráfico tiene su propia RPC que agrega los datos en el lado del servidor.
- Tarjetas de estadísticas: En la parte superior del panel, las tarjetas muestran los KPI en tiempo real (usuarios totales, activos hoy, tareas creadas, etc.).
- Gráficos temporales: Curvas de inscripciones diarias, uso por funcionalidad, histogramas de retención.
- Tablas: Lista de los últimos eventos (inscripciones, errores, alertas).
Un punto importante: las RPC de Supabase utilizan parámetros con el prefijo p_ (convención del proyecto). Por ejemplo, p_start_date, p_end_date, p_metric_type. Estas RPC realizan los cálculos de agregación directamente en PostgreSQL, mucho más eficiente que traer miles de líneas al cliente.
El panel está protegido por una verificación de rol de administrador a nivel del middleware de Next.js. Solo los usuarios con el rol admin en Supabase Auth pueden acceder a él.
¿Qué es el AlertService y por qué es crítico en producción?
El panel es para cuando estás frente a tu pantalla. Pero los incidentes no esperan a que abras el panel. El AlertService es mi sistema de monitoreo automático que me envía un correo electrónico cuando algo anormal sucede.
Aquí están las alertas configuradas:
- Fallback LLM activado: Cuando el modelo principal (a través de OpenRouter) falla y el fallback toma el relevo. Esto indica un problema con el proveedor o un pico de carga.
- Errores repetidos en el pipeline de voz: Si el STT o el TTS fallan más de X veces en Y minutos, recibo un correo electrónico. Esto puede indicar una interrupción de Deepgram o un problema de cuota de OpenAI.
- Rate limiting excesivo: Si un usuario o una IP activa el rate limiter repetidamente, podría ser un abuso o un bot.
- Fallo de inscripción: Si el flujo de inscripción (correo electrónico o código QR) falla para varios usuarios, probablemente hay un error.
Los correos electrónicos se envían a través de Resend, un servicio de correo electrónico transaccional simple y confiable. Cada alerta también se registra en una tabla de Supabase para el historial; puedo encontrar el historial de incidentes en el panel de administración.
¿Cómo implementar GA4 con el Consent Mode RGPD?
El RGPD (Reglamento General de Protección de Datos) no es negociable para un sitio europeo. Esto significa: no hay seguimiento sin consentimiento explícito. Google Analytics 4 soporta de forma nativa el Consent Mode, un mecanismo que ajusta su comportamiento según el consentimiento del usuario.
Así es como funciona en tamsiv.com:
- Inicialización en modo "denied": GA4 se carga al inicio del sitio, pero con
analytics_storage: 'denied'yad_storage: 'denied'. No se recopila ningún dato. - Consentimiento explícito: Cuando el usuario acepta las cookies de análisis en el banner, el consentimiento se actualiza a través de
gtag('consent', 'update', { analytics_storage: 'granted' }). - Modelado: Con el Consent Mode, Google utiliza el modelado para estimar los datos de los usuarios que no han dado su consentimiento. Obtienes tendencias fiables incluso si el 50% de los visitantes rechazan el seguimiento.
La etiqueta GA4 (G-VVLHW673V3) se inicializa una sola vez, en la primera carga de la página. El consentimiento se persiste en una cookie de origen y se restaura en cada visita. Si el usuario cambia de opinión, puede modificar sus preferencias en el banner de cookies accesible desde el pie de página.
¿Cómo diseñar un consentimiento de cookies conforme al RGPD?
El banner de cookies de TAMSIV tiene 3 interruptores, cada uno con un rol preciso:
- Necesarias (siempre activas, no desactivables): Sesión de autenticación, preferencias de idioma, el propio consentimiento de cookies. Sin estas cookies, el sitio no funciona.
- Analíticas (desactivadas por defecto): GA4, métricas de navegación de Supabase. Activas solo después del consentimiento.
- Marketing (desactivadas por defecto): Previstas para el futuro (retargeting, píxeles publicitarios). Desactivadas por ahora porque no se utilizan.
Un punto a menudo pasado por alto: el versionado del consentimiento. Si la política de cookies cambia (adición de un nuevo rastreador, modificación de las finalidades), el banner debe reaparecer para todos los usuarios, incluso para aquellos que ya han dado su consentimiento. He implementado esto con un número de versión almacenado en la cookie de consentimiento. Cuando la versión cambia, el banner se vuelve a mostrar.
¿Por qué usar un doble seguimiento GA4 + Supabase?
GA4 es excelente para las métricas web estándar: páginas vistas, tasa de rebote, fuentes de tráfico, conversiones. Pero hay métricas que GA4 no puede capturar, o no con suficiente detalle:
- Recorrido de conversión detallado: El camino exacto de un visitante desde la página de destino hasta la inscripción, con las interacciones intermedias (clic en CTA, apertura de FAQ, cambio de idioma).
- Métricas de negocio: Número de tareas creadas a través de la web vs. la aplicación móvil, tasa de finalización de tareas, actividad de gamificación.
- Atribución multidispositivo: Un usuario que descubre el sitio en el escritorio y descarga la aplicación en el móvil. GA4 no hace esta conexión. Supabase, con el UUID de autenticación, sí.
El seguimiento de Supabase funciona con un UUID anónimo por visitante (generado en la primera carga, almacenado en el localStorage). Cada interacción significativa se registra en una tabla de Supabase. Cuando el visitante se inscribe, el UUID anónimo se vincula a su cuenta de autenticación, lo que permite reconstruir el recorrido completo, desde el primer clic hasta la inscripción.
Este doble seguimiento me proporciona dos lecturas complementarias: GA4 para las tendencias macro (de dónde vienen los visitantes, qué páginas funcionan) y Supabase para los insights micro (cuál es el recorrido típico que lleva a una conversión).
¿Qué métricas priorizar para una aplicación móvil?
Cuando empiezas, te sientes tentado a medirlo todo. Mala idea: te ahogas en datos sin actuar sobre nada. Aquí están las métricas que priorizo en el panel de TAMSIV:
- DAU (Daily Active Users): El pulso de la aplicación. Si baja, algo no va bien.
- Tasa de retención D1/D7/D30: Cuántos usuarios regresan. Es la métrica más importante para un producto de productividad.
- Tasa de finalización de la primera tarea: ¿Logran los nuevos usuarios crear su primera tarea? Si no, el onboarding tiene un problema.
- Conversión Free → Pro: El quid de la cuestión. Cuántos usuarios gratuitos se convierten en de pago, y después de cuántos días de uso.
- Tasa de error del pipeline de voz: El porcentaje de conversaciones de voz que fallan. Debe permanecer por debajo del 2%.
Cada una de estas métricas tiene su gráfico en el panel, con una tendencia de 7 y 30 días. Un sistema de umbrales de colores (verde/naranja/rojo) me permite ver de un vistazo si todo va bien.
¿Cómo las alertas por correo electrónico salvaron mi producción?
Ejemplo concreto: un sábado por la noche, recibí un correo electrónico "Fallback LLM activado — 12 veces en 15 minutos". El modelo principal en OpenRouter estaba sobrecargado. Sin la alerta, lo habría descubierto el lunes al revisar las métricas. Gracias a la alerta, verifiqué que el fallback funcionaba correctamente (funcionaba) y pude comunicarme proactivamente si era necesario.
Otro ejemplo: un pico de rate limiting en una IP específica. Al investigar, descubrí un script automatizado que intentaba crear cuentas en masa. El rate limiter había hecho su trabajo, pero la alerta me permitió bloquear la IP y reforzar la protección.
El AlertService es mi red de seguridad. No reemplaza el monitoreo (también uso los logs de Railway para el backend), pero me avisa de los incidentes más críticos sin que tenga que monitorear activamente.
Preguntas Frecuentes
¿Se necesita un panel de administración desde el lanzamiento?
No necesariamente el día 1, pero tan pronto como tengas usuarios en producción, sí. Lo construí unas semanas antes del lanzamiento y me salvó varias veces. Como mínimo, configura las alertas por correo electrónico, es más urgente que el panel visual.
¿GA4 es compatible con el RGPD sin consentimiento?
No. Incluso con el Consent Mode en modo "denied", GA4 envía pings anónimos a Google. Para ser 100% conforme, debes mostrar un banner de cookies y cargar GA4 solo después del consentimiento, o usar el Consent Mode que ajusta el comportamiento. El Consent Mode es la solución recomendada por Google y aceptada por la mayoría de las DPA europeas.
¿Por qué Recharts en lugar de Chart.js o D3 directamente?
Recharts es un wrapper de React sobre D3. La ventaja: los gráficos son componentes declarativos de React, no código imperativo. Es más natural en un proyecto Next.js. Chart.js también funciona, pero requiere más código de integración con React.
¿Cuánto cuesta el sistema de alertas por correo electrónico con Resend?
El plan gratuito de Resend incluye 3000 correos electrónicos al mes. Para alertas (unas pocas decenas al mes en funcionamiento normal), es más que suficiente. El costo es, por lo tanto, cero para un pequeño proyecto en producción.
¿El seguimiento de Supabase no se superpone con GA4?
No, miden cosas diferentes. GA4 sobresale en el tráfico web (fuentes, comportamiento, conversiones). Supabase mide el comportamiento dentro de la aplicación (tareas creadas, funcionalidades utilizadas, recorrido multidispositivo). Ambos son complementarios, no redundantes.