Nivel 8 · Desafío final: el paquete de KPI heredado

Los informes heredados rara vez tienen un solo fallo. Este desafío final te da tres consultas del mismo paquete. Cada una se ejecuta, cada una devuelve una tabla ordenada, y cada una le dice algo falso a la junta.

Paso 1: ingresos mensuales y envío

Dos fallos de este capítulo. El join con order_items repite el shipping_fee de cada pedido una vez por línea, así que el envío está inflado en todos los meses: enero muestra $1,223.15 en lugar de $752.17. Y BETWEEN '2025-01-01' AND '2025-12-31' se detiene a medianoche del 31 de diciembre, así que diciembre tiene 623 pedidos en lugar de 634.

Arregla primero la multiplicación de filas sumando las líneas por pedido en una CTE. Luego cambia a un rango semiabierto. El conteo de pedidos, los ingresos y el total de envío deberían coincidir después con el sistema de pedidos.

Paso 2: tasa de cancelación por canal

El starter devuelve 12 filas para 3 canales. GROUP BY channel, status divide cada canal en una fila por estado, así que la fila de cancelados muestra 100% y todas las demás 0%. Es un fallo de grano: la columna extra hace el agrupamiento más fino que la pregunta.

Arregla el agrupamiento y aparece un segundo fallo: // es división entera, así que la tasa de app se lee 6 en lugar de 6.23. Usa 100.0 * y divide con /.

Paso 3: tasa de recompra por segmento

Una tasa de recompra de exactamente 100% en ambos segmentos es imposible. El HAVING COUNT(*) >= 2 dentro de la CTE elimina a los compradores de una sola vez antes de que la consulta externa cuente compradores, así que numerador y denominador son el mismo grupo. Es la lección de WHERE frente a HAVING en otra forma: un filtro aplicado en el paso equivocado cambia lo que significa el agregado.

Quita el HAVING. El FILTER (WHERE b.orders >= 2) externo ya restringe el numerador. Empresas tiene 253 compradores y 188 recurrentes, consumidores 1,194 y 690.

Cómo trabajar un paquete roto

1. Para cada consulta, di en una frase qué debería ser una fila de salida. Compáralo con el conteo de filas.
2. Reconstruye un número desde la consulta más simple posible: el envío solo desde orders, el conteo de diciembre con un rango semiabierto, los compradores con un simple COUNT(DISTINCT customer_id).
3. Arregla un fallo, vuelve a ejecutar, compara otra vez. Un segundo fallo suele esconderse detrás del primero.

Errores comunes

• Tratar el COUNT(DISTINCT o.order_id) del paso 1 como prueba de que la consulta no tiene multiplicación de filas. Protege el conteo, no las sumas.
• Arreglar la división del paso 2 pero no su agrupamiento: las filas de 0% y 100% siguen mal.
• Mover el HAVING del paso 3 a la consulta externa: eso filtra segmentos, no clientes.

En SQL Server

T-SQL no tiene cláusula FILTER. Escribe los conteos condicionales con CASE, que también funciona en DuckDB:

SUM(CASE WHEN status = 'cancelled' THEN 1 ELSE 0 END) AS cancelled_orders,
ROUND(100.0 * SUM(CASE WHEN status = 'cancelled' THEN 1 ELSE 0 END) / COUNT(*), 2)

En el trabajo

Anota qué estaba mal en cada consulta cuando devuelvas el paquete. La junta preguntará por qué cambiaron los números del trimestre pasado, y “el envío se contaba una vez por línea” es una respuesta que pueden aceptar.