Concepto clave

En el modelado de datos para casos de negocio reales, el objetivo principal es transformar datos crudos en modelos analíticos que respondan preguntas de negocio especificas. Piensa en esto como construir una casa: los datos crudos son los materiales de construccion (ladrillos, cemento, madera), y los modelos son las habitaciones funcionales (cocina, dormitorio, sala) que satisfacen necesidades concretas.

Un caso de negocio real en analytics engineering implica identificar metricas clave, definir dimensiones relevantes, y estructurar los datos para facilitar analisis. Por ejemplo, para un e-commerce, necesitaras modelos que muestren ventas por producto, comportamiento de clientes, y tendencias temporales. La clave esta en entender que datos de entrada tienes y que preguntas de negocio debes responder.

Como funciona en la practica

Vamos a desarrollar modelos para un caso de negocio de ventas online. Paso a paso:

Identifica las fuentes de datos: tablas de pedidos, productos, clientes, y pagos en tu warehouse.
Define las metricas clave: ingresos totales, unidades vendidas, tasa de conversion.
Crea modelos base que limpien y estandaricen los datos crudos.
Construye modelos intermedios que combinen tablas relacionadas.
Desarrolla modelos finales (marts) optimizados para consultas analiticas.

Por ejemplo, para analizar ventas por categoria de producto, necesitaras unir datos de pedidos con informacion de productos, luego agrupar por categoria y calcular metricas.

Codigo en accion

Modelo base para limpiar datos de pedidos:

-- models/staging/ecommerce/stg_orders.sql
{{ config(materialized='view') }}

WITH raw_orders AS (
    SELECT
        order_id,
        customer_id,
        order_date,
        status,
        amount,
        -- Limpieza de datos: estandarizar estados
        CASE
            WHEN status IN ('completed', 'shipped') THEN 'completed'
            WHEN status IN ('pending', 'processing') THEN 'in_progress'
            ELSE 'cancelled'
        END AS order_status_clean,
        -- Validar montos positivos
        CASE
            WHEN amount < 0 THEN 0
            ELSE amount
        END AS amount_clean
    FROM {{ source('ecommerce_raw', 'orders') }}
    WHERE order_date >= '2023-01-01'  -- Filtro temporal
)

SELECT *
FROM raw_orders

Modelo intermedio para ventas por producto:

-- models/marts/ecommerce/fct_sales.sql
{{ config(
    materialized='table',
    unique_key='sale_id'
) }}

WITH orders_cleaned AS (
    SELECT * FROM {{ ref('stg_orders') }}
    WHERE order_status_clean = 'completed'
),

order_items AS (
    SELECT * FROM {{ ref('stg_order_items') }}
),

products AS (
    SELECT * FROM {{ ref('stg_products') }}
)

SELECT
    oi.order_item_id AS sale_id,
    o.order_id,
    o.customer_id,
    p.product_id,
    p.category,
    o.order_date,
    oi.quantity,
    oi.price,
    (oi.quantity * oi.price) AS revenue,
    CURRENT_TIMESTAMP AS loaded_at
FROM orders_cleaned o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id

Errores comunes

No definir granularidad correcta: Crear modelos con nivel de detalle inconsistente (ej., mezclar datos diarios y mensuales). Solucion: Documenta explicitamente la granularidad de cada modelo en un archivo YAML.
Ignorar el rendimiento: Usar JOINs innecesarios que ralentizan consultas. Solucion: Usa modelos incrementales y particiones para datos grandes.
Falta de documentacion de negocio: Modelos sin descripcion de que metricas representan. Solucion: Anade descripciones en los archivos de configuracion de dbt.
No considerar historico: Sobrescribir datos sin mantener trazabilidad. Solucion: Implementa SCD Type 2 para dimensiones cambiantes.
Testing insuficiente: Solo probar unicidad, no relaciones de negocio. Solucion: Anade tests personalizados para reglas de dominio.

Checklist de dominio

¿Los modelos responden preguntas de negocio especificas identificadas al inicio?
¿Cada modelo tiene una unica responsabilidad y granularidad definida?
¿Se implementaron tests para validar integridad referencial y reglas de negocio?
¿La documentacion incluye descripciones de metricas y ejemplos de uso?
¿Los nombres de columnas y modelos siguen convenciones consistentes?
¿Se optimizo el rendimiento con materializaciones apropiadas?
¿Se versionaron los cambios y se mantiene historico donde es necesario?

Construye un modelo de analisis de retencion de clientes

Para un caso de negocio de e-commerce, desarrolla un modelo que calcule la tasa de retencion de clientes mensual. Sigue estos pasos:

Crea un modelo base stg_customers que limpie la tabla de clientes, estandarizando fechas de registro y paises.
Desarrolla un modelo intermedio int_customer_activity que identifique en que meses cada cliente realizo al menos una compra.
Construye el modelo final fct_customer_retention que calcule:
- Mes de cohorte (primer mes de compra de cada cliente)
- Clientes activos por mes desde su cohorte
- Tasa de retencion mensual por cohorte
Anade tests para validar que:
- No hay clientes duplicados
- Las fechas de actividad son posteriores a las de registro
- Las tasas de retencion estan entre 0 y 1
Documenta cada modelo explicando su proposito y metricas calculadas.

Pistas

Usa funciones de ventana como LAG() para comparar actividad entre meses.
Considera usar un CTE para calcular la cohorte inicial de cada cliente.
Recuerda que la tasa de retencion se calcula como (clientes activos este mes / clientes en cohorte inicial) * 100.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Desarrollar Modelos para un Caso de Negocio Real