Retail Intelligence Pipeline

El pivote analítico

El dataset de Blinkit en Kaggle se usa comúnmente para análisis de ventas. Al cargarlo, la columna item_outlet_sales no existía — el archivo era el test set de la competición. En lugar de cambiar el dataset, reformulé la pregunta hacia posicionamiento de catálogo: qué productos reciben visibilidad en el estante, si eso es proporcional a su precio, y qué formatos de tienda encajan mejor con cada segmento. Eso produjo la métrica clave: weighted_revenue_potential = item_mrp × item_shelf_fraction.

Hallazgos principales

• Los productos Mid-Range concentran el mayor potencial de ingreso aunque los Budget los superan en cantidad — el catálogo optimiza volumen, no margen.
• El espacio en góndola y el precio no están correlacionados: productos económicos ocupan más estante que premium, señal de un planograma desalineado.
• Las tiendas Supermarket Type 1 tienen el mayor potencial individual y la mayor amplitud de catálogo — el formato ideal para lanzar productos premium.

Lo que aprendí

• dbt obliga a pensar en capas. Separar staging (renombrar y castear) de marts (lógica de negocio) hace las transformaciones legibles y testeables de forma independiente.
• Los bulk inserts no son opcionales. execute_values cargó 5,681 filas en 5 segundos; executemany habría tardado 4 minutos.
• El deploy en la nube expone lo que el testing local oculta. Encoding de archivos, resolución de hostnames y secrets son invisibles en local — se vuelven bloqueadores en el primer deploy real.

The Analytical Pivot

The Blinkit dataset on Kaggle is commonly used for sales analysis. After loading it, the `item_outlet_sales` column was missing — the file was the competition test set. Instead of finding a different dataset, I reframed the question around catalog positioning: which products are getting shelf visibility, whether that's proportional to their price, and which store formats suit premium vs. budget SKUs best. That pivot produced the key metric: `weighted_revenue_potential = item_mrp × item_shelf_fraction` — a prioritization signal derivable from a catalog alone.

Key Findings

• Mid-Range products hold the highest revenue potential despite Budget SKUs outnumbering them — the catalog optimizes for volume, not margin.
• Shelf space and price are not correlated: Budget products often occupy more shelf than Premium ones, signaling a misaligned planogram.
• Supermarket Type 1 stores have the highest potential and broadest catalog — the ideal format for premium launches.

What I Learned

• dbt enforces layer discipline. Separating staging (rename + cast) from marts (business logic) makes SQL readable and testable independently.
• Bulk inserts are not optional. `execute_values` loaded 5,681 rows in 5 seconds; `executemany` would have taken 4 minutes.
• Cloud deploys expose what local tests hide. UTF-16 file encoding, hostname resolution, and secrets management are invisible locally — they become hard blockers on first deploy.