Nivel 9 · Desafío final: foto de rendimiento

Este Desafío final combina todo el capítulo: agregados sobre expresiones, agrupación, ordenamiento de resultados agrupados y filtrado de grupos.

Paso 1: productos principales por ingresos

Calcula los ingresos por línea, suma por producto y luego clasifica:

SELECT product_id,
       SUM(quantity) AS units,
       ROUND(SUM(quantity * unit_price * (1 - discount_pct / 100.0)), 2) AS net_revenue
FROM order_items
WHERE quantity > 0
GROUP BY product_id
ORDER BY net_revenue DESC, product_id
LIMIT 10;

Esto incluye todos los estados de pedido porque el estado del pedido vive en otra tabla. En el capítulo 5 harás un join con orders y contarás solo los pedidos completados, que es lo que finanzas normalmente querría. Cuando se lo entregues a Megan, di qué versión es.

Paso 2: devoluciones por motivo

Tres agregados lado a lado. Un patrón útil al presentar: el conteo, el total y el promedio juntos te dicen si un motivo es caro porque es frecuente o porque cada devolución es grande. Las devoluciones por “damaged” pueden ser menos que las de “changed_mind” pero costar más cada una, lo que apunta a un problema de embalaje en lugar de un problema de producto.

Paso 3: tasa de conversión por fuente

converted es un booleano. Para contar los valores verdaderos, conviértelo en 1 o 0 y suma:

SUM(CAST(converted AS INTEGER)) AS conversions

Esto funciona en Postgres, DuckDB y MySQL. BigQuery lo escribe CAST(converted AS INT64) o COUNTIF(converted). Postgres y DuckDB también admiten el estándar COUNT(*) FILTER (WHERE converted), y todas las bases de datos admiten SUM(CASE WHEN converted THEN 1 ELSE 0 END), que verás en el capítulo 6.

La tasa de conversión son las conversiones entre las sesiones. Multiplica por 100.0 antes de dividir, para que la división entera de Postgres no convierta cada tasa en 0. Luego HAVING COUNT(*) >= 5000 descarta las fuentes pequeñas, cuyas tasas son demasiado ruidosas para compararlas.

Los grupos pequeños mienten

¿Por qué filtrar los grupos pequeños? Una fuente con 40 sesiones y 4 conversiones muestra una tasa del 10 %, que puede verse mejor que una fuente con 20,000 sesiones al 3 %. La pequeña es sobre todo ruido. Los analistas fijan de forma rutinaria un tamaño de muestra mínimo con HAVING antes de clasificar grupos por una tasa. Menciona el umbral en tus notas para que nadie se pregunte adónde fue una fuente.

Errores comunes

• Sumar el precio en lugar del valor de la línea. SUM(unit_price) ignora cuántas unidades se vendieron. Los ingresos son SUM(quantity * unit_price * (1 - discount_pct / 100.0)).
• Restar el porcentaje como si fuera una fracción. discount_pct guarda 5 para un descuento del 5 %, así que (1 - discount_pct) da ingresos negativos. Divide primero entre 100.0.
• Dividir antes de multiplicar por 100. En Postgres, SUM(CAST(converted AS INTEGER)) / COUNT(*) * 100 divide dos enteros y devuelve 0. Escribe 100.0 * SUM(...) / COUNT(*).
• Clasificar tasas sin un tamaño mínimo. Una fuente con 40 sesiones puede quedar primera por suerte. Mantén HAVING COUNT(*) >= 5000 antes de ordenar por la tasa.

En SQL Server

El paso 1 usa SELECT TOP 10 ... ORDER BY net_revenue DESC. En el paso 3, converted sería un BIT, y SUM no acepta BIT directamente, así que conviértelo de la misma forma, y mantén 100.0 para que la tasa no se trunque:

SUM(CAST(converted AS int)) AS conversions,
ROUND(100.0 * SUM(CAST(converted AS int)) / COUNT(*), 2) AS conversion_pct