Reportes personalizados

Esta página explica cómo armar reportes propios dentro de Metabase. Da por sentado que sabés de bases de datos (SQL, joins, agregaciones). Lo que probablemente no conozcas todavía es cómo están organizados los datos de CDC — eso está en Modelo de datos, y es la lectura que más tiempo te va a ahorrar.

Qué es Metabase y cómo se accede

Metabase es la herramienta de reportes de CDC. Corre en su propia instancia y está conectada solo a la base de datos de CDC, que dentro de Metabase aparece como MySQLCDC.

Para armar reportes hace falta una cuenta; se pide acceso (ver Reportes). Los roles habituales son lectura (ver y usar los tableros) y editor (crear preguntas y tableros propios y guardarlos en una colección).

Dos formas de armar una pregunta

Metabase llama “pregunta” a cada consulta guardada.

  1. Editor visual. Elegís una tabla y agregás agrupaciones y filtros desde la interfaz. No requiere SQL. Es lo mejor para explorar y para tablas dinámicas (pivots).
  2. SQL nativo. Escribís la consulta a mano. Es lo más flexible (joins, subconsultas) y lo mejor para versionar el reporte. Casi todos los reportes “de verdad” de CDC son SQL nativo.

Pivots: editor visual; joins u orden puntual: SQL + tabla

La visualización de pivot de Metabase reordena sus encabezados por su cuenta e ignora el ORDER BY de la consulta. Si necesitás una tabla dinámica, armala con el editor visual; si necesitás joins o un orden específico, usá SQL y mostralo como tabla.

Trabajar sobre las tablas centrales

La base es un WordPress multisitio: históricamente cada casa tenía sus propias tablas (wp_3_posts, wp_10_postmeta, …). No trabajes contra esas tablas por sitio. CDC guarda todo lo que hace falta para reportar en tablas centrales, justamente para que un reporte no tenga que unir catorce tablas por casa y para esquivar problemas de collation entre ellas.

Casi todos los reportes salen de cuatro tablas: wp_cdc_registrations (inscripciones), wp_users (cuentas), wp_usermeta (datos del usuario, entre ellos el documento) y wp_cdc_notes (notas). El detalle está en Modelo de datos.

Cómo se filtra por casa

El tablero principal tiene un filtro Sitio conectado a cada carta. En el dato, la casa se identifica por wp_cdc_registrations.site_slug (por ejemplo elcascosv, lagranjasf). Para elegir varias casas a la vez desde el tablero, en SQL nativo se implementa como field filter:

WHERE 1 = 1
  [[AND {{site_slug}}]]

Se expande a wp_cdc_registrations.site_slug IN (...). Como nombra la tabla por su nombre real, la consulta no debe ponerle alias a wp_cdc_registrations (un alias la rompe con Unknown column ‘wp_cdc_registrations.site_slug’).

Los paneles que ya existen (para copiar ideas)

El tablero “Reportes CDC” está embebido en el panel y hoy tiene tres solapas:

  • Globales — Registraciones por sitio, año y mes: inscripciones por casa y período, agrupando por site_slug y por el mes de created_at (cuándo se hizo la reserva).
  • Listado actividades — una fila por actividad con vendidas, por pagar, lista de espera, canceladas, staff, capacidad de la casa, capacidad ociosa y un precio estimado. Sale solo de tablas centrales. Buen ejemplo de cuánto se puede reportar sin tocar las tablas por sitio.
  • Personas — inscripciones por año: una fila por persona, una columna por año, cada celda la cantidad de inscripciones.

Además hay una consulta de ingresos por casa ya escrita (todavía sin tablero) y varias consultas sobre la calidad del documento de los usuarios (duplicados, formatos).

Buenas prácticas al armar un reporte

  1. Preferí las tablas centrales. Si te encontrás uniendo tablas wp_N_* por sitio, casi seguro el dato ya está en wp_cdc_registrations o en un espejo central. Preguntá antes de armar un UNION de catorce tablas.
  2. Distinguí NULL de 0. Varias columnas pueden ser NULL = desconocido. No lo colapses a 0 sin querer: cambia el número.
  3. Cuidado con el fan-out. Unir a wp_usermeta sin pre-agrupar duplica filas e infla todos los SUM/COUNT. Uní una subconsulta ya agrupada por usuario.
  4. Contá “Vendidas” por exclusión, no listando los estados “buenos”: hubo estados que se retiraron y siguen vivos en filas históricas (ver Modelo de datos).
  5. Guardá el reporte en una colección con un nombre claro. Si va a terminar embebido en la app, además se versiona el SQL — coordiná ese paso con el equipo técnico.
  6. Probá el filtro de verdad. Un reporte puede devolver un total plausible y aun así estar ignorando el filtro de Sitio. Verificá que la cantidad de filas cambie al elegir una casa.

Siguiente paso

Leé el Modelo de datos: las cuatro tablas, cómo se vincula una inscripción con la persona que la hizo (por documento, con respaldo en el nombre), los criterios de tipo de actividad y una batería de consultas de ejemplo listas para adaptar.