Los proyectos de datos que funcionan en un portfolio tienen tres características: usan datos reales y públicos, terminan en una recomendación de negocio cuantificada, y están documentados para leerse en dos minutos. Esta guía propone tres proyectos concretos —análisis de cohortes y churn, dashboard de operación comercial, y pipeline de datos automatizado—, con datasets, stack y criterios de evaluación de recruiters.

El portfolio es el diferenciador número uno para conseguir el primer trabajo en datos. También es donde más gente se traba: según lo que se observa en procesos de inserción laboral, la mayoría de los egresados de formaciones en datos no sabe qué proyectos construir ni cómo presentarlos, y termina replicando el mismo análisis de Titanic o de flores de iris que ya vieron mil veces los recruiters.

Lo que sigue son tres proyectos que sí generan entrevistas, en orden de dificultad creciente, con lo que hace falta para cada uno.

Qué mira realmente un recruiter de datos

Antes de los proyectos, conviene entender el criterio de evaluación. Un hiring manager de datos revisa un portfolio con cuatro preguntas en la cabeza:

• ¿Entendió el problema de negocio? Un análisis técnicamente impecable sobre una pregunta irrelevante no sirve.

• ¿Confío en los datos que usó? Es decir: ¿validó, limpió y documentó lo que hizo con los casos raros?

• ¿Sabe comunicar? Si necesito leer el notebook completo para entender la conclusión, falla.

• ¿Puede reproducirse? Un proyecto que no corre en otra máquina es una demo, no un proyecto.

Las cuatro se resuelven con estructura, no con complejidad técnica. Un análisis exploratorio bien contado convierte mejor que un modelo de machine learning sin explicación.

Proyecto 1: análisis de cohortes y churn de clientes

Nivel: inicial-intermedio. Tiempo estimado: dos a tres semanas.

Es el proyecto con mejor relación entre esfuerzo y valor percibido, porque el análisis de retención es una necesidad real de casi cualquier empresa con clientes recurrentes: SaaS, e-commerce, fintech, suscripciones.

Qué construir

• Segmentación de clientes por cohorte de adquisición (mes de primera compra o de registro).

• Curva de retención por cohorte, visualizada como heatmap.

• Identificación de los segmentos con mayor churn y análisis de qué los caracteriza.

• Una recomendación concreta: qué segmento atacar primero y con qué impacto estimado.

Datasets y stack

El dataset de retail online del repositorio de UCI es el clásico para esto y tiene volumen suficiente para que el análisis sea creíble. También sirven los datasets de e-commerce disponibles en Kaggle.

Stack recomendado: SQL para la agregación por cohorte, Python con pandas para el procesamiento y matplotlib o seaborn para la visualización. Si querés sumar un punto, replicá la lógica de cohortes en SQL puro: es exactamente lo que te van a pedir en una prueba técnica.

Qué evalúan acá

La correcta definición de churn. La mayoría de los candidatos usa una definición implícita y nunca la explicita. Escribir "defino churn como ausencia de compra en 90 días, porque el intervalo mediano entre compras es de 34 días" es el tipo de frase que hace que un entrevistador tome nota.

Proyecto 2: dashboard de operación comercial

Nivel: intermedio. Tiempo estimado: tres a cuatro semanas.

Este proyecto demuestra la habilidad que más se usa en el día a día de un analista: convertir datos en una herramienta que otra persona pueda usar sin ayuda.

Qué construir

• Un dashboard con cinco a ocho indicadores clave de un negocio (ingresos, ticket promedio, unidades, margen, clientes nuevos vs. recurrentes).

• Filtros funcionales por período, categoría y canal.

• Al menos una vista de comparación temporal (mes actual vs. mismo mes del año anterior).

• Una hoja de documentación que explique la definición exacta de cada métrica.

Datasets y stack

Stack recomendado: Power BI o Looker Studio si apuntás a retail, consumo masivo o banca; Python con Streamlit si apuntás a startups o empresas de producto. La elección de herramienta debería seguir al sector objetivo, no al gusto personal.

Los datos abiertos del Estado —disponibles en datos.gob.ar— permiten armar dashboards sobre comercio exterior, precios o producción que se ven más profesionales que un dataset de práctica, justamente porque nadie más los usa.

Qué evalúan acá

Dos cosas: que las métricas estén bien definidas y que el dashboard sea usable sin explicación. El error más común es el dashboard sobrecargado, con veinte gráficos y ninguna jerarquía. Menos indicadores bien elegidos comunica más criterio que muchos mal ordenados. La hoja de definiciones de métricas es lo que separa un dashboard de portfolio de uno de trabajo real.

Proyecto 3: pipeline de datos automatizado

Nivel: avanzado. Tiempo estimado: cuatro a seis semanas.

Es el proyecto que más diferencia, porque muy pocos candidatos de nivel inicial lo tienen y porque abre la puerta a roles de Analytics Engineer y Data Engineer, donde la brecha entre demanda y oferta de candidatos es mayor.

Qué construir

• Extracción automática de datos desde una API pública (clima, cotizaciones, transporte, datos deportivos).

• Carga en una base de datos o warehouse gratuito.

• Transformación con dbt, con al menos un test de calidad de dato definido.

• Orquestación programada, aunque sea con una GitHub Action que corra a diario.

• Una vista final que consuma el modelo transformado.

Stack y consideraciones

Stack recomendado: Python para la extracción, Postgres o BigQuery en capa gratuita como destino, dbt para la transformación y GitHub Actions para la programación. La documentación de dbt es suficiente para armar el modelo desde cero.

El punto clave es que corra solo. Un pipeline que hay que ejecutar a mano no demuestra lo que se quiere demostrar. Mostrar el historial de ejecuciones exitosas de las últimas semanas es la prueba más contundente que puede tener un portfolio de datos.

Qué evalúan acá

Manejo de errores y calidad de dato. Qué pasa cuando la API no responde, cómo se detecta un valor imposible, si hay reintentos. Es la diferencia entre un script y un sistema, y es lo que se está evaluando cuando alguien pregunta "¿y si el origen cambia el formato?". Si te interesa este camino, la hoja de ruta de analista a Data Engineer ordena las habilidades que faltan.

Cómo presentar los tres proyectos

El contenido importa, pero la presentación decide si alguien lo mira. Cuatro reglas:

1. Un README por proyecto, con esta estructura: problema en dos líneas, datos usados y su origen, decisiones metodológicas, hallazgo principal en negrita, recomendación, cómo reproducirlo. En ese orden.

2. Una imagen arriba. El gráfico o dashboard principal como primera cosa visible. Nadie lee un README que empieza con instrucciones de instalación.

3. Notebooks limpios. Sin celdas de prueba, sin outputs de error, con markdown que explique cada bloque. Un notebook desordenado es la señal más fuerte de falta de rigor.

4. Links vivos. El dashboard publicado, el pipeline con historial visible, el notebook renderizado. Todo lo que requiera clonar el repositorio para verse, no se ve.

Un extra que rinde mucho: escribir un post corto por proyecto explicando el hallazgo. Convierte el proyecto en contenido, genera visibilidad y demuestra la habilidad de comunicación que es exactamente la que se evalúa. Sirve de referencia el enfoque descripto en cómo armar un portfolio de Data Science.

Errores que descartan un portfolio de datos

• Datasets de tutorial. Titanic, iris y house prices comunican que no salís del material del curso.

• Análisis sin conclusión. Diez gráficos y ninguna frase que diga qué hacer con eso.

• Modelos sin evaluación honesta. Reportar sólo accuracy en un dataset desbalanceado se lee como falta de criterio, no como buen resultado.

• Cero documentación de limpieza. Si no explicás qué hiciste con los nulos y los duplicados, se asume que no los miraste.

• Repositorio sin commits intermedios. Un único commit con todo el proyecto no permite ver cómo trabajás.

Cursos y carreras recomendados de Coderhouse

Cada proyecto se apoya en un bloque de habilidades distinto:

• Curso de SQL — el nivel inicial y la base de los tres proyectos. La lógica de cohortes, las agregaciones y las funciones de ventana se resuelven acá, y es lo que se evalúa en la prueba técnica de casi cualquier búsqueda de datos.

• Curso de Data Analytics — el nivel intermedio, orientado al ciclo completo de análisis: exploración, limpieza, visualización y comunicación de resultados. Es el bloque que produce los proyectos 1 y 2.

• Curso de Power BI — específico para el proyecto de dashboard, y requisito explícito en la mayoría de las búsquedas de BI en retail, banca y consumo masivo.

• Curso de Data Engineering — el nivel avanzado, necesario para el proyecto de pipeline: modelado, transformación con dbt, orquestación y calidad de dato.

Si preferís recorrer todo el trayecto de forma integrada, la Diplomatura en Data cubre desde SQL hasta ingeniería de datos con proyectos aplicados en cada etapa.

Preguntas frecuentes

¿Cuántos proyectos necesito en un portfolio de datos?

Tres bien terminados. La combinación que mejor funciona es un análisis exploratorio con conclusión de negocio, un dashboard usable, y un proyecto que demuestre automatización o ingeniería de datos. Más de cuatro proyectos rara vez suma: nadie los revisa todos, y la calidad promedio baja.

¿Sirve usar datasets de Kaggle o los recruiters lo penalizan?

Los datasets de Kaggle sirven; lo que penaliza es usar los datasets de tutorial más conocidos con el mismo análisis que trae el notebook de ejemplo. Si tomás un dataset de Kaggle y hacés una pregunta de negocio propia, con tu propia metodología y conclusión, el origen del dato no es un problema.

¿Necesito machine learning en el portfolio para conseguir trabajo en datos?

Para roles de Data Analyst y BI Analyst, no: pesa mucho más el SQL sólido y la capacidad de comunicar hallazgos. Para roles de Data Scientist sí es esperable, pero incluso ahí un modelo simple bien evaluado y explicado vale más que uno complejo sin análisis de errores ni justificación de las métricas elegidas.

¿Cómo presento proyectos si no tengo acceso a datos reales de una empresa?

Los datos abiertos del Estado y las APIs públicas dan material más que suficiente, y tienen la ventaja de ser desordenados como los datos reales, lo que te obliga a hacer el trabajo de limpieza que sí se evalúa. Otra opción con muy buen resultado es ofrecer un análisis gratuito a una PyME o a una ONG: genera un caso real y, muchas veces, una recomendación laboral.

¿Conviene tener el portfolio en GitHub o en un sitio propio?

Las dos cosas, con GitHub como base. El repositorio es donde se revisa el código, y es lo que va a mirar un entrevistador técnico. Un sitio propio simple que liste los tres proyectos con imagen, resumen y link ayuda a la primera impresión y al recruiter no técnico. Lo que no conviene es tener sólo el sitio sin código público disponible.