Tres Errores de Agregación de Datos en Sistemas BI

Por qué los sistemas BI mienten: Tres errores fatales de agregación de datos

Las métricas en las herramientas BI suelen mostrar una precisión ilusoria. En la práctica, tan pronto como los datos pasan de transacciones crudas a marts preagregados, surgen distorsiones sistemáticas, a veces de decenas de por ciento. Esto no es un fallo; es un compromiso arquitectónico entre velocidad y precisión. Vamos a desglosar tres trampas matemáticas clave que hacen que el análisis sea peligroso para la toma de decisiones.

Error Uno: Promediar promedios — Una catástrofe matemática

Ticket medio, tiempo promedio de procesamiento de solicitudes, costo promedio de pedido: estas métricas no son aditivas. No puedes simplemente promediar valores ya promediados. Ejemplo clásico: Un sistema BI toma los tickets medios por tienda para enero, febrero y marzo, los suma y divide por tres para obtener la cifra trimestral. La fórmula se ve así:

SELECT 
    region_name,
    EXTRACT(QUARTER FROM year_month) AS quarter,
    AVG(avg_receipt_amount) AS total_average_check
FROM dwh.store_monthly_aggregated
WHERE EXTRACT(QUARTER FROM year_month) = 1
GROUP BY region_name, EXTRACT(QUARTER FROM year_month);

El problema es que A/B + C/D ≠ (A+B)/(C+D). Un hipermercado con 10.000 tickets al día tiene el mismo peso en el cálculo que un quiosco con 50 tickets. Un mes con ventas pico se equipara con uno 'muerto'. En datos reales, esto lleva a desviaciones de -6% a +7%. En el retail, donde cada punto porcentual de aumento en el ticket medio significa millones de rublos, tales distorsiones son inaceptables. Lo peor de todo, cuando una coincidencia de denominadores produce accidentalmente el resultado correcto, el error se cementa en el DWH como 'correcto'.

Error Dos: Count Distinct al cambiar el contexto de filtro

Contar objetos únicos —clientes, tickets, productos— se rompe al cambiar el nivel de detalle. Imagina tres transacciones:

• Ticket #101 | Comestibles
• Ticket #101 | Bebidas
• Ticket #102 | Bebidas

Número real de tickets únicos: 2. Pero si los datos están preagregados por categorías:

• Comestibles: 1 ticket (#101)
• Bebidas: 2 tickets (#101, #102)

Entonces, al colapsar la jerarquía en Power BI o un motor SQL, DAX realiza una suma simple: 1 + 2 = 3. Se pierde la unicidad. El sistema contó doble el ticket #101. Este error distorsiona instantáneamente el ticket medio, conversión, LTV: todo lo que depende del conteo de entidades únicas. El usuario ni siquiera se da cuenta de que ha cambiado la vista y termina con números falsos.

Error Tres: Medidas semi-aditivas y calendarios rígidos

Saldos de inventario, saldos de cuentas, número de usuarios activos: estas son métricas de instantáneas. Se pueden sumar a lo largo del espacio (tiendas, regiones), pero no del tiempo. Para sortear esto, los desarrolladores usan funciones como LASTNONBLANK en DAX o NonEmpty en MDX:

Balance on konets perioda = 
CALCULATE (SUM('Inventory'[Balance]),
    LASTNONBLANK ('Calendar'[Date], 
        CALCULATE(SUM('Inventory'[Balance]))
    ))

Esto crea tres problemas:

• Rendimiento: El motor itera sobre todas las fechas de la jerarquía en cada cambio de filtro. Con volúmenes grandes, se congela.
• Fallos en la vida real: Si el día 30 la caja registradora falla al transmitir datos, el sistema muestra saldo cero el 31. Los bienes 'desaparecen' por valor de cientos de miles de rublos.
• Complejidad del código: El usuario debe ser desarrollador. Con múltiples calendarios de negocio, las fórmulas se vuelven ilegibles y frágiles.

Lo que importa

• La agregación mata la precisión. Precomprimir datos por velocidad es un compromiso aceptado implícitamente sin captar las consecuencias.
• Métricas no aditivas requieren datos crudos. Cualquier promedio, mediana, conteo único debe calcularse al vuelo desde el conjunto de datos completo.
• Métricas de instantáneas no toleran límites temporales rígidos. El sistema debe encontrar de forma flexible el valor actual, no seguir ciegamente el calendario.
• Los usuarios de BI no deberían escribir DAX/MDX. La arquitectura debe ocultar la complejidad, no volcarla sobre el analista.
• Nuevas plataformas eliminan las preagregaciones. El enlace dinámico de fuentes crudas al vuelo es el único camino hacia un análisis matemáticamente preciso.

Cambio de paradigma: Análisis sin compromisos

Los sistemas BI clásicos se construyen sobre una ilusión: podemos precalcular todo lo que el negocio necesita. En realidad, el negocio cambia constantemente sus preguntas. En vez de escribir workarounds en DAX, las plataformas modernas trabajan directamente con datos crudos. Por ejemplo, calcular 'Cobertura de stock' —la relación de inventario a ventas— puede combinar dos fuentes distintas: miles de millones de filas de inventario y miles de millones de filas de tickets. En lugar de construir un mart rígido en el DWH, el sistema enlaza dinámicamente las fuentes en cada clic del usuario, recalculando la métrica con precisión matemática. El núcleo mismo determina las ventanas temporales, encuentra los niveles actuales de inventario y carga en memoria solo los datos necesarios. Esto no es 'más rápido'; es 'correcto'. Cuando los directivos de un banco vieron por primera vez el tiempo real de procesamiento de solicitudes —sin distorsiones de promediar promedios— empezaron a plantear las preguntas adecuadas. La cadena de retail ya no quiere sacrificar sentido por un límite de 5 millones de filas. El análisis debería ser un archivo RAW, no un JPEG. Solo así se preservan los detalles y la capacidad de afinar los insights. La tecnología existe; ahora toca repensar nuestra arquitectura mental.

— Editorial Team