Docs / Build Workflow

Dashboards

Un dashboard, una pregunta

La mayoría de las herramientas BI te empujan a un dashboard gigante que trata de responder todo a la vez. El resultado es una pantalla llena de charts que nadie lee. Looky se construye alrededor del principio opuesto: un dashboard enfocado por pregunta de negocio.

Un dashboard que responde "¿Dónde está perdiendo revenue este quarter?" es útil. Un dashboard que muestra todas las métricas para todas las dimensions para todos los períodos es una pantalla de loading con charts. Construye chico, agudo y publicable.

Dos layout modes soportan distintos casos de uso. layout_mode es requerido; los únicos valores permitidos son:

  • fluid_grid: canvas interactivo y responsive. Los charts se sientan lado a lado y se cross-filtran entre sí cuando los usuarios clickean. Mejor para exploración y monitoreo operacional.
  • document: orden de lectura fijo top-to-bottom. Diseñado para ser leído, compartido y exportado a PDF. Mejor para reportes, briefings y deliveries scheduleados.

Cualquier otro valor es rechazado por el validator.

Dashboard fluid grid con control de layout

Usa width en los items para controlar cuánto de la fila ocupa cada visualization. El grid piensa en tercios: width 1 = un tercio, 2 = dos tercios, 3 = fila completa. Existen dos tokens de span extra para filas de KPIs: 4 = un cuarto de la fila y 6 = media fila. Omite width para dejar que el layout planner dimensione los items por tipo (las tablas ocupan la fila; un chart seguido de uno o dos KPIs se compone automático).

Un item también puede setear height (una altura mínima en pixels) y title_override (un título de display que reemplaza el propio de la viz solo para este dashboard).

id: ec_order_fulfillment_dashboard
title: "How Is Fulfillment Performing?"
description: "Track created orders, shipment progress, delivery completion, and where leakage happens in fulfillment."
layout_mode: fluid_grid
published: true
tags: ["ecommerce", "fulfillment", "funnel", "dashboard"]
filters:
  - id: global_period
    type: cutoff_date
    granularity: year
    label: Period
    default: "{{today}}"
items:
  - visualization: ec_fulfillment_created_kpi
    width: 6
  - visualization: ec_fulfillment_shipped_rate_kpi
    width: 6
  - visualization: ec_fulfillment_delivered_rate_kpi
    width: 6
  - visualization: ec_fulfillment_return_rate_kpi
    width: 6
  - visualization: ec_fulfillment_funnel
    width: 2
  - visualization: ec_fulfillment_leakage_grid
    width: 1

Dashboard document para reportes y exports

El modo document renderiza en un layout fijo de una columna. Es la elección correcta cuando el dashboard se va a compartir vía PDF export o cuando el orden de lectura tiene significado.

id: ec_business_overview
title: What Is Happening In The Business?
layout_mode: document
published: true
filters:
  - id: global_period
    type: cutoff_date
    granularity: year
    param: cutoff_date    # lets a scheduled export inject the date by this name
    label: Period
    default: "{{today}}"
items:
  - visualization: ec_revenue_kpi
  - visualization: ec_orders_kpi
  - visualization: ec_aov_kpi
  - visualization: ec_revenue_over_time_line
  - visualization: ec_category_brands_matrix
  - visualization: ec_orders_by_status_bar

Los dashboards document se pueden exportar a PDF en un schedule — el params.cutoff_date del export se bindea a través del param declarado arriba. Mira Scheduled Exports.

Qué NO es un campo del YAML de dashboard

Las relaciones de cross-filter no se declaran a nivel dashboard. No hay bloque cross_filter en el dashboard. El cross-filter es un toggle por viz y un comportamiento runtime automático dashboard-wide — mira Cross-filtering.

Similar, el shape de las entries en items[] es chico: visualization (requerido — un id de viz, no un file path) más los opcionales width, height y title_override. No hay position, row ni col; el fluid grid acomoda los items en orden de declaración y el layout document es de una columna. La prosa entre charts en un dashboard document tampoco es un campo del dashboard — autorala como una viz text y referenciala desde items.

Paginación dentro de un dashboard

Los items grid y report_matrix dentro de un dashboard paginan server-side; cambiar de página re-corre la query subyacente con los nuevos parámetros de página. El comportamiento es idéntico para sources de BigQuery, Postgres y MySQL. Las características de costo difieren — mira Diferencias entre adapters de source.

Tipos de filter

Los filtros declarados en un dashboard aplican a cada viz que el dashboard contiene. La referencia completa por tipo vive en Filters; los dos shapes más comunes para dashboards se muestran abajo.

cutoff_date — selección de período de tiempo

El filtro de dashboard más común. El usuario elige una sola fecha y Looky manda dos parámetros a cada query: date_from y date_to. El lower bound depende de granularity.

filters:
  - id: global_period
    type: cutoff_date
    granularity: month     # day | month (default) | quarter | year
    label: Period
    default: "{{today}}"

Valores de granularity soportados — respetados tanto a nivel dashboard como a nivel visualization:

  • day: date_from = date_to = la fecha elegida. Una ventana de un solo día.
  • month (default): date_from = primer día del mes de la fecha elegida, date_to = la fecha elegida. Útil para dashboards month-to-date.
  • quarter: date_from = primer día del quarter de la fecha elegida, date_to = la fecha elegida.
  • year: date_from = 1 de enero del año de la fecha elegida, date_to = la fecha elegida. Útil para dashboards year-to-date.

Default tokens: {{today}}, {{yesterday}}, {{start_of_week}}, {{end_of_week}}, {{start_of_month}}, {{end_of_month}}. Cualquier otra cosa se trata como un string literal de fecha ISO.

select — filtro de dimension desde una query de Malloy

Pobla un dropdown desde una query live. Usa cuando los usuarios necesitan filtrar por un valor de dimension (región, categoría, marca) en vez de por tiempo.

filters:
  - id: category
    type: select
    label: Category
    param: category
    options_query: "models/ec_revenue.malloy::category_options"
    default: all

options_query apunta a una query de Malloy que devuelve filas con al menos las columnas id y label (o uno de los aliases reconocidos — mira select). El parámetro del model declarado como p_category recibe el valor (el prefix p_ se strippea para el nombre externo; el filtro manda category).

Cross-filtering en fluid grid

En dashboards fluid_grid, clickear una barra, punto o celda en cualquier chart interactivo filtra todos los otros charts del dashboard a esa selección. Esto funciona automático — no requiere configuración.

Para deshabilitar el cross-filtering en una visualization específica (por ejemplo un KPI summary que no debería cambiar cuando se filtran otros charts), setea cross_filter: false en el bloque chart de la visualization:

# in the visualization YAML, not the dashboard
chart:
  cross_filter: false

El cross-filtering no está disponible en modo document. Los dashboards document están diseñados para lectura, no exploración.

El mecanismo completo — pills, whitelist de supported-params, reglas emit/consume por viz — vive en Cross-filtering.

Checklist de composición

  • Cada items[].visualization referencia un id de visualization publicada existente.
  • layout_mode se elige deliberadamente: fluid_grid para exploración, document para reportes.
  • El título del dashboard es una pregunta, no una etiqueta de categoría.
  • El param del filtro matchea el nombre del parámetro declarado en el model de Malloy.
  • granularity matchea la resolución temporal de los datos subyacentes.
looky validate
looky list dashboards