Resumen ejecutivo

• El Analytics Engineer transforma, testea, documenta y versiona datos en el warehouse para que el negocio se autosirva con números confiables.

• El Data Analyst interpreta esos datos, responde preguntas de negocio y comunica insights; no suele ser dueño de la capa de modelos reutilizables.

• El stack típico del AE incluye SQL, dbt, Git/CI, un warehouse (BigQuery, Snowflake, Redshift) y tests de calidad.

• La transición desde analyst se logra con proyectos: un modelo dbt documentado, tests y un “contrato” de métricas con stakeholders.

Si ya armás reportes y te pedís “otra vez la misma tabla limpia”, probablemente estás rozando el trabajo de un Analytics Engineer. El rol nació para romper el cuello de botella entre analistas que necesitan datos listos y data engineers saturados de tickets de pipelines. ¿Por qué ahora? Porque las empresas adoptaron warehouses en la nube y herramientas de self-service, y sin una capa de transformación confiable aparecen dos dashboards con el mismo KPI… y números distintos. Para anclar el contraste con el rol clásico, partí de qué es y qué hace un Data Analyst.

Qué hace un Analytics Engineer

Según dbt Labs, el analytics engineer entrega datasets limpios, modelados, testeados y documentados, aplicando prácticas de software (control de versiones y CI) al código analítico. En la práctica, tu día se parece más a iTerm + Git + SQL que a Excel + un dashboard improvisado.

Responsabilidades frecuentes:

• Explorar datos ya ingeridos y entender el dominio de negocio.

• Limpiar y transformar tablas crudas en modelos reutilizables (staging → marts).

• Definir tests de calidad (nulos, unicidad, relaciones) y alertar antes de que se rompa un chart.

• Documentar columnas, owners y definiciones de métricas para self-service.

• Colaborar con stakeholders sin meter cada pedido en la cola de data engineering.

Analytics Engineer vs Data Analyst (y vs Data Engineer)

La comparación de dbt Labs entre analytics engineer, analyst y data engineer resume el corte así:

• Data Engineer: infraestructura e ingestión; pipelines, arquitectura, disponibilidad del dato crudo.

• Analytics Engineer: capa de transformación en el warehouse; productos de datos listos para análisis.

• Data Analyst: insights, reportes, visualización y storytelling con el negocio.

En una frase: el AE hace que el dato sea usable y confiable; el analyst lo vuelve accionable. Si te interesa el extremo más de infraestructura, mirá también qué hace un Data Engineer.

Señales de que tu trabajo ya es “AE” aunque tu título diga Analyst

• Mantenés SQL versionado y reusado por varios equipos.

• Te preocupa el naming de tablas y la definición única de “ingreso” o “usuario activo”.

• Querés enterarte de un dato roto antes de que lo vea un VP en Looker/Power BI.

• Documentás para que otros se autosirvan sin pedirte el export.

Stack y entregables que demuestran el rol

• SQL sólido (CTEs, ventanas, modelado dimensional básico).

• dbt (models, tests, docs, sources).

• Git + CI (PRs, review, deploy de modelos).

• Warehouse: BigQuery, Snowflake o Redshift.

• Ingesta liviana (conocer Fivetran/Stitch ayuda a hablar con DE).

• BI consumer: entender cómo se consumen tus marts en Looker, Power BI, Metabase, etc.

Portfolio mínimo creíble: un repo público o privado bien documentado con 3–5 modelos dbt, tests, un diagrama de linaje y un README que explique qué pregunta de negocio responde cada mart.

Ruta de transición desde Data Analyst

1. Elegí un dominio que ya conozcas (marketing, finanzas, producto).

2. Reemplazá un Excel recurrente por un modelo en el warehouse.

3. Sumá tests y documentación; pedí review como si fuera código de producto.

4. Acordá con el negocio un “contrato” de métricas (definición, owner, SLA de refresco).

5. Medí impacto: menos tickets ad hoc, menos discrepancias entre reportes, menos tiempo de limpieza.

dbt Labs destaca que muchos analysts ya traen contexto de negocio; lo que falta suele ser transformación con Git/CI y mindset de producto de datos. No hace falta volverte data engineer de infra para dar el salto.

Un día típico (para aterrizar el rol)

Mañana: revisás fallos de tests de dbt en CI y un modelo que rompió unicidad en orders. Media mañana: reunión con marketing para acordar la definición de “lead calificado” y documentarla en el repo. Tarde: abrís un PR que agrega un mart de retención con tests y descripción de columnas; pedís review a otro AE o a un DE. Cierre: actualizás el catálogo para que Finance deje de pedir el CSV semanal.

Si tu semana es 80% Excel ad hoc y 20% SQL suelto sin Git, todavía estás más cerca de analyst clásico. El salto al AE es tratar los modelos como producto con dueño, versión y SLA.

Errores comunes al intentar el cambio

• Renombrar el LinkedIn a “Analytics Engineer” sin un solo modelo testeado.

• Copiar transformers enormes sin tests ni docs (deuda instantánea).

• Ignorar el dominio: un modelo “bonito” que nadie entiende no se usa.

• Pelear con Data Engineering en vez de acordar contratos de datos (sources, frescura, ownership).

Curso recomendado de Coderhouse

Para fortalecer SQL, análisis y visualización antes (o mientras) pegás el salto a modelado, el Curso de Data Analytics y la Carrera de Data Analytics te dan base práctica para hablar el idioma del warehouse y del negocio.

CTA: esta semana tomá un reporte que armes a mano, escribí el SQL en un repo Git, agregá 3 tests de calidad y documentá la definición de la métrica principal. Ese entregable ya habla el idioma de un Analytics Engineer.

Preguntas frecuentes

¿Necesito saber Python para ser Analytics Engineer? SQL es el core. Python ayuda (automatización, análisis puntual), pero muchas vacantes priorizan dbt + Git + modelado.

¿Es un rol junior o mid? Hay juniors, pero el mercado suele pedir experiencia previa como analyst o en SQL de producción. Un portfolio con dbt acelera.

¿En qué se diferencia de BI Developer? BI Developer suele vivir en la herramienta de visualización; el AE vive en el warehouse y entrega modelos que alimentan BI y self-service.

¿Puedo llegar sin título de sistemas? Sí, si demostrás modelos testeados, documentación clara y impacto en confiabilidad de métricas. El título ayuda menos que el repo y los casos.