FC71 Shop — Pipeline ETL: 700+ SKUs normalizados sin intervención manual

1El problema

Un catálogo de dropshipping vive de datos que cambian constantemente — precios, existencia, descripciones — repartidos en fuentes externas con estructuras inconsistentes entre sí. Mantenerlo actualizado a mano no escala: cada revisión manual es una ventana de datos desactualizados, y cada categoría nueva de producto es una oportunidad de clasificarla distinto la próxima vez.

El objetivo no era "tener un scraper" — era tener un catálogo confiable sin que alguien tuviera que sentarse cada semana a revisarlo producto por producto.

2La solución diseñada

Pipeline de tres etapas, pensado para correr sin supervisión:

1. Extracción: scraper con Playwright (Chromium) contra las fuentes de producto, con opciones de user-agent para evitar bloqueos.
2. Normalización: cada producto extraído se clasifica contra un maestro de 16 categorías (más 6 "otros" para lo que no encaja), eliminando la inconsistencia de nombres/categorías entre fuentes.
3. Carga: importación a PostgreSQL, con Redis como capa de caché para las consultas que expone la API del catálogo (FastAPI + Uvicorn).

Decisión clave: detección incremental por SKU — el pipeline no reprocesa el catálogo completo cada corrida, solo identifica y procesa productos nuevos. Eso mantiene los tiempos de ejecución bajos aunque el catálogo crezca.

3El proceso de implementación

La automatización de la ejecución fue tan importante como la del scraping en sí: un script .bat dispara el pipeline completo cada lunes en Windows, sin que nadie tenga que iniciarlo manualmente. El frontend del catálogo (HTML + HTMX + Alpine.js) consume la misma API sin necesitar un framework pesado de por medio.

El obstáculo real no fue técnico sino de datos: fuentes distintas describen el mismo tipo de producto con nombres de categoría diferentes. La normalización a 16 categorías maestras es exactamente la capa que resuelve eso — sin ella, el catálogo termina con decenas de micro-categorías inconsistentes que no sirven para navegación ni para reporting.

4El stack en producción

5Resultados medibles

El resultado que de verdad importa no es el número de SKUs — es que ese número crece sin que nadie tenga que sentarse a mantenerlo. La actualización de catálogo dejó de ser una tarea recurrente en el calendario de alguien.

6Qué aprendimos

• La normalización de datos (no el scraping) es donde vive la mayoría de la complejidad real en un pipeline de catálogo — vale la pena diseñarla primero, no como un paso posterior.
• La detección incremental no es una optimización opcional: es lo que hace viable correr el pipeline sin monitoreo activo a medida que el catálogo crece.
• Automatizar la ejecución (el .bat semanal) es tan parte de la solución como el código del pipeline — sin eso, sigue siendo un script que alguien tiene que recordar correr.

7Servicios que este caso demuestra

Este proyecto combina capacidades que ofrecemos como servicio a otras empresas:

• Automatización de procesos administrativos — el mismo principio de eliminar la actualización manual de datos dispersos.
• Automatización de reportes y consolidación de datos — la misma lógica de normalización aplicada a reportes en lugar de catálogos.
• Diagnóstico operativo — todo proyecto como este empieza por identificar dónde vive realmente el trabajo manual antes de automatizarlo.