Cómo crear un dashboard: fuentes de datos, KPI, gráficos y accesos
Para crear un dashboard, parta de las preguntas que debe responder y de las personas que lo van a leer, defina con precisión un conjunto pequeño de métricas, conecte los datos de los que salen esas métricas y elija un gráfico sencillo para cada una. Después decida quién puede ver cada cifra. Un creador de aplicaciones con IA puede generar un dashboard pulido en minutos; lo difícil, y lo que decide si alguien confía en él, es tener bien los datos y las definiciones.
Empiece por las preguntas, no por los gráficos
Un dashboard que intenta mostrarlo todo se abre una vez. Antes de pensar en gráficos, responda:
- ¿Para quién es? ¿Para el fundador, un equipo comercial, operaciones, inversores, sus clientes?
- ¿Qué decisiones respalda? "¿Necesitamos contratar a otra persona para soporte?" es una pregunta que un dashboard puede responder. "Enséñame nuestros datos" no lo es.
- ¿Con qué frecuencia lo mirarán? Un dashboard operativo diario necesita datos frescos y alertas; una vista mensual para el consejo no.
Escriba de tres a cinco preguntas. Cada una se convierte en una o dos métricas.
Defina cada métrica con exactitud
La mayoría de las discusiones sobre dashboards son en realidad discusiones sobre definiciones. Escriba una definición breve para cada cifra:
| Métrica | Vaga | Precisa |
|---|---|---|
| Ingresos | "Dinero que ganamos" | Suma de los importes de facturas pagadas, sin impuestos, por fecha de factura, en USD |
| Usuarios activos | "Personas que lo usan" | Usuarios distintos con al menos un inicio de sesión en los últimos 30 días |
| Abandono (churn) | "Personas que se fueron" | Clientes de pago al inicio del mes que cancelaron durante él, dividido entre los clientes al inicio |
| Tiempo de respuesta | "Lo rápido que es soporte" | Mediana de horas desde la creación del ticket hasta la primera respuesta humana, solo días laborables |
Pegue estas definiciones en su prompt. Si no, una IA elegirá un cálculo razonable que quizá no coincida con cómo cuenta su negocio.
De dónde salen los datos
| Fuente | Cómo la lee un dashboard | Cuidado con |
|---|---|---|
| La base de datos de su propia aplicación | Consultas directas | Consultas pesadas que ralentizan la aplicación principal; añada tablas resumen si hace falta |
| Una hoja de cálculo | Importar como CSV o leer mediante una API | Las ediciones manuales rompen formatos; filas de totales y celdas combinadas |
| Herramientas SaaS (Stripe, HubSpot, Shopify, Google Analytics) | Sus API con su clave de API | Límites de peticiones, paginación y que cada herramienta define sus métricas a su manera |
| Un almacén de datos (BigQuery, Snowflake, Postgres) | SQL mediante una conexión del lado del servidor | Credenciales y costes de consulta |
Dos principios valen para todos los casos:
- Mantenga las claves en el servidor. Las claves de API y las contraseñas de base de datos van en las variables de entorno de la aplicación, nunca en el código del navegador.
- Decida la frescura de los datos. Consultar varias API en cada carga de página es lento y puede chocar con los límites de peticiones. Para la mayoría de los dashboards empresariales, una sincronización cada hora o por la noche en su propia base de datos, con una indicación de "última actualización" en la página, es más sencilla y fiable.
Si las API le resultan nuevas, qué es una API y qué es una base de datos explican lo básico.
Elija el gráfico adecuado
- Una sola cifra con su variación ("42.000 €, sube un 8 % frente al mes anterior"): una tarjeta KPI. Es el elemento más útil de la mayoría de los dashboards.
- Tendencia en el tiempo: un gráfico de líneas. Use barras solo para un número pequeño de periodos.
- Comparar categorías: barras horizontales, ordenadas por valor.
- Parte de un todo: barras apiladas. Los gráficos de tarta solo funcionan con dos o tres porciones.
- Detalle y excepciones: una tabla con ordenación, búsqueda y filtros. A menudo es más útil que cualquier gráfico.
Mantenga los colores coherentes: un color para "este periodo", uno apagado para la "comparación" y rojo solo para lo que necesita atención.
Quién ve qué
Decida los accesos antes de construir:
- Interno, todos ven todo: lo más sencillo. Aun así necesita inicio de sesión si contiene datos de negocio.
- Por roles: ventas ve las cifras de ventas, finanzas ve los márgenes, los responsables ven a su propio equipo.
- Orientado al cliente: cada cliente ve solo sus propios datos. Cada consulta debe filtrar por la cuenta del cliente en el servidor. Compruébelo entrando como dos clientes distintos.
Un dashboard con datos de ingresos o de clientes en una URL pública y sin inicio de sesión es una fuga de datos esperando a ser descubierta.
Un primer prompt que funciona
Construye un dashboard de ventas para una empresa de software B2B de 10 personas. Público: los fundadores y el responsable de ventas, que lo revisan cada lunes. Vista general: tarjetas KPI para el MRR nuevo de este mes, el MRR total, los clientes nuevos de este mes, los clientes perdidos de este mes y el valor del pipeline, cada una con la variación respecto al mes anterior; un gráfico de líneas del MRR de los últimos 12 meses; un gráfico de barras de negocios nuevos por origen. Una página de Negocios con una tabla con búsqueda y ordenación (empresa, responsable, importe, fase, fecha de cierre) y filtros por responsable y fase. Definiciones de métricas: el MRR es la suma de los importes mensuales de las suscripciones activas, dividiendo entre 12 los planes anuales; el abandono cuenta los clientes cuya suscripción terminó este mes. Usa datos de muestra realistas en una base de datos por ahora; conectaremos Stripe más tarde. Muestra una hora de "última actualización". Inicio de sesión obligatorio. Navegación lateral limpia.
Pasos de construcción
- Maquetación con datos de muestra. Acuerde las métricas y los gráficos mientras los datos son ficticios y fáciles de cambiar.
- Conecte una fuente real. Compruebe cada cifra a mano contra el sistema de origen. Si el MRR no coincide con lo que muestra Stripe, averigüe por qué antes de seguir.
- Añada el resto de fuentes, una a una, comprobando cada una.
- Actualización programada o consultas al cargar, con una etiqueta de "última actualización".
- Filtros: primero el rango de fechas y después uno o dos más que la gente pida.
- Inicio de sesión y roles.
- Estados vacíos y de error: qué muestra la página cuando una fuente no responde o un filtro no devuelve nada.
- Compártalo con el público previsto y elimine después lo que nadie mire durante un mes.
Que vaya rápido
Un dashboard lento se consulta menos. Precalcule los totales que son costosos (una tabla de resumen diario en lugar de recorrer cada pedido), pagine las tablas grandes y cargue primero las tarjetas principales para que la página sea útil antes de que terminen los gráficos. Si una cifra tarda mucho en calcularse, muestre cuándo se calculó por última vez en lugar de recalcularla en cada visita.
Errores habituales
- Demasiados gráficos. Si todo está destacado, nada lo está.
- Métricas sin definir. Dos personas que lean el mismo dashboard deben llegar a la misma conclusión.
- No comprobar nunca las cifras con el origen. Una cifra equivocada y la gente deja de confiar en todo el dashboard.
- Consultar cada API en cada carga de página. Lento, frágil y a veces caro.
- Sin contexto de fechas. Muestre siempre el periodo y la comparación.
- Secretos en el frontend. Una clave de API visible en el navegador puede ser copiada por cualquiera que abra la página.
Cuándo es mejor una herramienta de BI
Si sus datos ya están en una base de datos o en un almacén, y los usuarios principales son analistas que quieren explorarlos, segmentarlos y crear sus propios gráficos, una herramienta de BI como Looker Studio, Power BI, Metabase y otras les servirá mejor que un desarrollo a medida. Muchas herramientas SaaS también tienen buenos informes integrados; revíselos antes de rehacerlos. Un dashboard a medida gana cuando es para clientes o para usuarios no analistas, necesita una lógica o unos permisos que la herramienta de BI no puede expresar, combina fuentes de una forma específica de su negocio o forma parte de un producto que ya tiene.
Si el trabajo consiste menos en ver cifras y más en modificar registros, le conviene un panel de administración o una herramienta interna; consulte cómo crear una herramienta interna. Y si sus cifras viven hoy en una hoja de cálculo, cómo convertir una hoja de cálculo en una aplicación es una buena siguiente lectura.
Construirlo con Mythex
En Mythex describe el dashboard y el agente construye las páginas y los gráficos en una vista previa en vivo, empezando con datos de muestra realistas y pasando a una base de datos Postgres dedicada cuando las cifras necesiten persistir. El caso de uso de dashboard de la documentación tiene un prompt inicial. Si sus datos están en una herramienta como Google Sheets, puede conectar la cuenta mediante Conectores y pedir al agente que los lea y cree un dashboard con ellos.
No hay conectores de almacén integrados para la propia aplicación: para BigQuery, Snowflake, Stripe y similares, la aplicación llama a sus API con claves que guarda como secretos del proyecto. Los accesos y los roles de las personas que ven el dashboard forman parte de la aplicación que construye. Para empezar desde un prompt, consulte las plantillas de dashboard, como el dashboard de métricas.
Preguntas
¿Cómo creo un dashboard?
Decida para quién es el dashboard y qué preguntas debe responder, elija unas pocas métricas con definiciones exactas, conecte las fuentes de datos y después escoja un gráfico para cada métrica. Un creador de aplicaciones con IA puede generar las páginas y los gráficos a partir de una descripción una vez que tenga claras esas decisiones.
¿Cuántos KPI debe tener un dashboard?
Los suficientes para que alguien los asimile de un vistazo: normalmente de cinco a siete en la vista principal. El detalle va en páginas aparte que la gente abre cuando una cifra principal parece incorrecta.
¿Debo crear un dashboard a medida o usar una herramienta de BI?
Use una herramienta de BI como Looker Studio, Power BI o Metabase cuando sus datos ya estén en una base de datos o almacén compatible y los analistas vayan a explorarlos. Cree un dashboard a medida cuando sea para clientes o para usuarios no analistas, cuando necesite su propia lógica o sus propios permisos, o cuando vaya dentro de una aplicación que ya tiene.
¿Puede un dashboard mostrar datos en tiempo real?
Sí, si lee datos de una base de datos o una API al cargar la página o con un intervalo de actualización. Para muchos dashboards empresariales basta con datos actualizados cada hora o cada día, que son más sencillos y baratos de mantener.