Talently
Talently
Data Analyst / BI

Data Analyst / BI

Convierte datos en respuestas concretas que permiten al negocio tomar mejores decisiones con evidencia en lugar de intuición.

Un Data Analyst es responsable de extraer, limpiar, analizar e interpretar datos para responder preguntas de negocio específicas y generar insights accionables. Su trabajo abarca desde la construcción de queries SQL y la exploración de datasets hasta la creación de visualizaciones y la comunicación de hallazgos a audiencias no técnicas. No solo describe lo que pasó: investiga por qué pasó y qué implica para las decisiones del negocio. Trabaja en estrecha colaboración con product managers, equipos de marketing, operaciones y liderazgo para traducir preguntas de negocio en análisis rigurosos y resultados comprensibles.

SQLPythonTableauPower BIEstadísticaGoogle Analytics

Recluta al mejor Data Analyst / BI aquí

Empieza ahora

Responsabilidades Principales

  • •Extraer y transformar datos desde múltiples fuentes usando SQL y herramientas de análisis para responder preguntas específicas del negocio.
  • •Limpiar y validar los datos antes del análisis para garantizar que los resultados son fiables y reproducibles.
  • •Identificar tendencias, patrones y anomalías en los datos que generan insights accionables para los equipos de negocio.
  • •Construir y mantener dashboards y reportes que permiten a los equipos monitorear sus KPIs de forma autónoma.
  • •Diseñar y analizar experimentos A/B en colaboración con los equipos de producto y marketing.
  • •Comunicar los resultados del análisis con claridad y honestidad sobre las limitaciones y los supuestos utilizados.

Habilidades Clave

Technical Skills

  • SQL avanzado para extracción, transformación y análisis de datos: window functions, CTEs, subqueries y optimización de queries
  • Python o R para análisis estadístico, manipulación de datos con pandas y visualización con matplotlib o seaborn
  • Herramientas de visualización y BI: Tableau, Power BI, Looker o equivalentes para construcción de dashboards accionables
  • Estadística aplicada: distribuciones, tests de hipótesis, intervalos de confianza y correlación para análisis rigurosos
  • Herramientas de analytics de producto: Google Analytics 4, Mixpanel, Amplitude para análisis de comportamiento de usuarios
  • Conocimiento de data warehouses: Snowflake, BigQuery o Redshift para trabajar con grandes volúmenes de datos de forma eficiente

Soft Skills

  • Pensamiento analítico para descomponer preguntas de negocio complejas en análisis manejables y rigurosos
  • Escepticismo saludable para cuestionar los datos antes de sacar conclusiones y verificar la calidad antes de presentar resultados
  • Comunicación efectiva para presentar hallazgos complejos con visualizaciones claras y narrativas accesibles para no técnicos
  • Curiosidad para explorar los datos más allá de la pregunta original y descubrir insights no anticipados
  • Honestidad intelectual para reportar los resultados negativos o ambiguos con la misma claridad que los positivos
  • Capacidad de priorizar cuándo un análisis simple responde mejor la pregunta que uno complejo y costoso en tiempo

Casos de uso reales

Contexto

Entender cómo los usuarios navegan por el producto y dónde abandonan permite al equipo de producto priorizar las mejoras con mayor impacto en las métricas clave.

Ejemplos reales

  • Análisis del funnel de registro identificando los pasos con mayor drop-off y sus causas
  • Segmentación de usuarios por comportamiento para identificar patrones de los que convierten mejor
  • Análisis de cohorts de retención para entender cuándo y por qué los usuarios dejan de usar el producto
  • Identificación de las features con mayor correlación con la retención a largo plazo

Contexto

Los equipos de negocio necesitan visibilidad sobre sus métricas clave para tomar decisiones operacionales. El analista construye los sistemas de reporting que proveen esa visibilidad de forma confiable.

Ejemplos reales

  • Dashboards semanales de ventas con comparativa contra períodos anteriores y objetivos
  • Reportes de rendimiento de campañas de marketing con atribución por canal
  • Análisis de la calidad del pipeline de ventas por etapa y por representante
  • Monitoreo de métricas operacionales con alertas automáticas ante desviaciones significativas

Contexto

Las decisiones de producto y marketing basadas en experimentos bien diseñados tienen mayor probabilidad de generar el impacto esperado que las basadas en opiniones o en datos correlacionales.

Ejemplos reales

  • Cálculo del tamaño muestral y la duración mínima de un test A/B antes de lanzarlo
  • Análisis de los resultados con los tests estadísticos apropiados y corrección por múltiples comparaciones
  • Diagnóstico de por qué un experimento produjo resultados contraintuitivos
  • Evaluación de la significancia práctica además de la estadística para decisiones de negocio

Contexto

No todas las preguntas de negocio están bien definidas. El análisis exploratorio descubre patrones y oportunidades que los equipos no sabían que existían.

Ejemplos reales

  • Análisis de los clientes con mayor LTV para identificar características comunes que guíen la adquisición
  • Exploración de los productos con mayor tasa de devolución para identificar problemas de calidad o de expectativas
  • Análisis geográfico de las ventas para identificar regiones sub-penetradas con potencial
  • Identificación de segmentos de usuarios con comportamientos anómalos que merecen investigación cualitativa

Contexto

Las iniciativas estratégicas (expansión a nuevos mercados, cambios de pricing, lanzamiento de nuevos productos) requieren análisis de datos para evaluar la oportunidad y medir el impacto post-implementación.

Ejemplos reales

  • Análisis de viabilidad de expansión a un nuevo mercado con datos de demanda y competencia
  • Evaluación del impacto de un cambio de precios en el volumen de ventas y el revenue
  • Análisis post-lanzamiento de un nuevo producto comparando su adopción con la de productos anteriores
  • Modelado de escenarios para evaluar el impacto de distintas estrategias de retención

Preguntas básicas

Verificar la calidad de los datos fuente: registros duplicados, valores nulos en campos críticos, rangos de fechas completos y consistencia con otras fuentes conocidas. Validar la lógica del análisis con un subset pequeño donde el resultado esperado es conocido. Confirmar que las métricas calculadas coinciden con los valores reportados por otros sistemas (cruce contra el sistema de facturación, contra GA, o contra reportes anteriores). Documentar los supuestos y las limitaciones del análisis junto con los resultados. Presentar a la dirección un análisis con datos de calidad cuestionable es más perjudicial que retrasar la entrega para verificarlo.
Explicar con un ejemplo concreto del propio negocio: 'los usuarios que usan esta feature tienen un 40% más de retención, pero eso no significa que activarla para todos aumentará la retención un 40%. Puede que los usuarios más comprometidos sean los que naturalmente la usan'. Para afirmar causalidad necesitamos un experimento aleatorio controlado donde asignamos la feature aleatoriamente. La correlación es una pista de dónde mirar, no una garantía de que la intervención funcionará. Esta distinción es fundamental antes de que el negocio tome decisiones de inversión basadas en el análisis.
Evaluar cada solicitud con tres criterios: urgencia (¿hay una decisión esperando este análisis?), impacto (¿cuánto valor puede generar la decisión que habilitará el análisis?), y esfuerzo estimado (¿cuánto trabajo requiere?). Comunicar las prioridades a los solicitantes con transparencia para que puedan re-evaluar su urgencia o simplificar el alcance. Para solicitudes urgentes pero de bajo impacto, ofrecer un análisis rápido y menos exhaustivo que responda la pregunta esencial sin el rigor completo. El tiempo del analista es escaso; la priorización transparente es más valiosa que intentar satisfacer todas las solicitudes superficialmente.
Presentar los resultados con honestidad, independientemente de las expectativas. Primero verificar que el análisis es correcto revisando la metodología y los datos con un colega antes de la presentación. Al comunicar el resultado inesperado, proveer el contexto: qué explica la diferencia con la hipótesis inicial, qué otras variables podrían estar influyendo, y qué análisis adicional podría clarificar la situación. Un analista que ajusta sus conclusiones para confirmar las expectativas del stakeholder destruye el valor del análisis como herramienta de toma de decisiones.
Un dashboard útil responde preguntas específicas de los usuarios que lo van a ver, no exhibe todos los datos disponibles. Definir las tres o cinco decisiones que el usuario debe poder tomar con el dashboard antes de diseñarlo. Priorizar las métricas que indican si algo requiere acción inmediata sobre las que son interesantes pero no accionables. Diseñar con una jerarquía visual clara: el estado general primero, el detalle al profundizar. Incluir comparativas de referencia (vs período anterior, vs objetivo) para que los números tengan contexto. Un número sin contexto no permite tomar ninguna decisión.
Una métrica de vanidad es aquella que puede crecer sin que el negocio mejore realmente: visitas totales al sitio sin tener en cuenta la calidad, número de registros sin tener en cuenta los activos, o número de features lanzadas sin medir su adopción. Se identifica preguntando: ¿puede esta métrica crecer mientras el negocio empeora? ¿puede el equipo manipularla artificialmente sin mejorar el resultado real? Si la respuesta es sí en ambos casos, es una métrica de vanidad. Las métricas accionables son aquellas cuyo movimiento implica necesariamente una mejora real en el valor entregado al usuario o en el resultado del negocio.
Antes de comunicar un pico como un insight real, verificar: ¿coincide con algún evento conocido (campaña de marketing, falla de tracking, cambio de definición de la métrica)? ¿el pico aparece en todas las fuentes de datos o solo en una? ¿el pico afecta a todos los segmentos de usuarios o solo a uno específico? ¿hay anomalías en los datos crudos como valores duplicados o timestamps fuera de rango? Un pico real debería verse consistentemente en múltiples fuentes y segmentos. Un artefacto de datos típicamente aparece en una sola fuente o en un segmento muy específico sin explicación de negocio.
La media es la suma de todos los valores dividida por el número de observaciones: sensible a los valores extremos (outliers). La mediana es el valor central cuando los datos se ordenan: robusta ante outliers. Para datos con distribuciones simétricas y sin outliers significativos, ambas son similares y la media es más informativa. Para datos con outliers o distribuciones sesgadas (ingresos, tiempo de respuesta de sistemas, precios de inmuebles), la mediana representa mejor al usuario o caso típico. Ejemplo: si el tiempo de carga promedio es 2 segundos pero la mediana es 0.8 segundos, unos pocos usuarios con conexiones muy lentas están inflando la media sin representar la experiencia de la mayoría.

Preguntas técnicas

Crear una tabla de cohortes identificando para cada usuario la semana de su primer evento (registro o primera acción relevante). Para cada cohorte, contar los usuarios activos en cada semana posterior dividido entre el total de la cohorte. Usar una CTE para calcular la semana de primer uso por usuario, otra para generar todas las combinaciones usuario-semana donde el usuario estuvo activo, y finalmente un JOIN para calcular el porcentaje de retención por cohorte y semana. Las window functions (FIRST_VALUE o MIN con OVER PARTITION BY user_id) son útiles para identificar la semana de entrada de cada usuario. El resultado es una matriz de cohorte vs semana con la tasa de retención en cada celda.
Primero identificar visualmente con boxplots e histogramas la distribución de las variables clave. Para detección estadística: el método IQR (valores fuera de Q1 - 1.5×IQR o Q3 + 1.5×IQR) para distribuciones moderadamente simétricas, o Z-score para distribuciones aproximadamente normales. Antes de tratar los outliers, investigar su origen: ¿son errores de datos (un precio de -100 euros), eventos excepcionales legítimos (ventas de Black Friday), o simplemente la cola larga de la distribución natural? Los errores se corrigen o eliminan. Los eventos excepcionales pueden excluirse del análisis de tendencias normales pero documentarse. Los valores de la cola natural generalmente se conservan y se menciona su efecto en la interpretación.
Verificar que se alcanzó el tamaño muestral pre-calculado antes de hacer el análisis: el early stopping es una de las causas más frecuentes de falsos positivos. Calcular el p-value con el test apropiado según el tipo de métrica (chi-squared para tasas de conversión, t-test para métricas continuas). Verificar que el poder estadístico fue suficiente (80% o mayor) para detectar el efecto mínimo esperado. Evaluar la significancia práctica además de la estadística: un p-value de 0.001 con un lift del 0.1% puede no justificar el coste de implementar el cambio. Revisar las métricas de guardia (métricas que no deberían moverse) para detectar efectos no deseados del tratamiento.
Usar una window function con RANGE BETWEEN para calcular el acumulado móvil, o una CTE que genera la serie de meses y luego hace un JOIN con los datos de ventas. La forma más limpia: generar una serie de fechas con GENERATE_SERIES o una tabla de calendario, hacer un JOIN con los eventos de ventas filtrando por los 12 meses anteriores a cada fecha, y agrupar por mes. Otra opción es usar SUM con OVER (ORDER BY month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW) para una ventana de 12 meses deslizante. Ambos enfoques son más mantenibles y eficientes que 12 subqueries unidas con UNION ALL.
Definir las variables de segmentación relevantes para el negocio: frecuencia de compra, valor monetario, recencia de la última compra (framework RFM), tipo de producto preferido, o canal de adquisición. Para la segmentación descriptiva, usar quintiles por cada variable para crear grupos discretos manejables. Para segmentación más sofisticada, k-means clustering sobre las variables normalizadas. Validar que los segmentos tienen diferencias accionables: no basta con que sean estadísticamente distintos, deben justificar estrategias distintas de marketing, producto o servicio. Nombrar los segmentos en términos de negocio (campeones, en riesgo, hibernantes) para facilitar la adopción por los equipos que actuarán sobre ellos.
Metodología de drill-down sistemático. Primero acotar el problema: ¿la caída afecta a todos los canales de adquisición o solo a alguno? ¿a todos los dispositivos o solo mobile? ¿a todos los países o regiones? ¿a todos los tipos de usuario o a un segmento específico? Cada segmentación que produce una caída concentrada en un subgrupo es un indicio de la causa. Paralelamente, revisar el timeline de cambios: deployments, campañas lanzadas o pausadas, cambios en precios o en el flujo de checkout, cambios técnicos que podrían haber roto parte del tracking. Cruzar los cambios de timeline con los segmentos donde se concentra la caída para identificar la hipótesis más probable antes de profundizar.
Estructurar la presentación en tres partes: el contexto en 2 minutos (cuál era la pregunta y por qué importa), el hallazgo principal en 5 minutos (qué encontramos, con una visualización clara y el nivel de confianza en el resultado), y la recomendación en 3 minutos (qué debería hacer el negocio y cuál es el impacto esperado). Empezar con la conclusión, no con la metodología: los directivos necesitan saber qué hacer, no cómo se hizo el análisis. Preparar el detalle metodológico como un apéndice para quien lo pida. Una visualización bien elegida comunica más en 30 segundos que tres slides de tablas de datos.
Para un forecast simple pero robusto: descomposición de la serie temporal en tendencia, estacionalidad y residuo. Calcular la tendencia con una regresión lineal sobre los datos históricos. Calcular los índices estacionales como el ratio entre las ventas de cada mes y el promedio anual de los últimos dos o tres años. El forecast es la proyección de la tendencia multiplicada por el índice estacional del mes correspondiente. Añadir un intervalo de confianza basado en la variabilidad histórica de los residuos. Este método es transparente, explicable al negocio, y suficientemente preciso para la mayoría de los casos sin la complejidad de modelos de ML que requieren más datos y más mantenimiento.

Preguntas avanzadas

La cultura de datos se construye con victorias pequeñas y visibles, no con presentaciones sobre la importancia de los datos. Identificar un equipo con un líder receptivo y un problema de negocio concreto donde los datos pueden generar una mejora measurable. Ejecutar el análisis, mostrar el resultado, y hacer seguimiento del impacto de la decisión basada en datos. Repetir con otro equipo y otro problema. Construir herramientas de self-service que permitan a los equipos responder sus propias preguntas sin esperar al analista. La cultura de datos emerge cuando los líderes ven que sus pares toman mejores decisiones con datos y quieren lo mismo para su equipo.
En etapa temprana, evitar la trampa de medir todo. Focalizarse en los indicadores de retención que demuestran que el producto resuelve un problema real: la curva de retención de cohortes debe estabilizarse y no caer a cero. La pregunta de Sean Ellis como encuesta periódica ('¿cuánto te decepcionaría no poder usar el producto?') con el umbral del 40% de 'muy decepcionado'. El NPS cualitativo con las razones específicas de promotores y detractores. La frecuencia de uso de los usuarios más activos como proxy del valor percibido. Medir pocas métricas con alta frecuencia y alta fidelidad es más útil en esta etapa que muchas métricas con baja confianza.
Los métodos quasi-experimentales permiten estimar el impacto causal cuando no hay RCT. Diferencias en diferencias: comparar la evolución de un grupo tratado versus un grupo de control comparable antes y después de la intervención. Regresión discontinua: si hay un umbral (por ejemplo, usuarios con más de X días de antigüedad recibieron la intervención) se puede comparar los usuarios en los bordes del umbral. Propensity score matching: emparejar usuarios tratados con no tratados similares en las variables observables y comparar sus resultados. Cada método requiere supuestos que deben documentarse y cuestionarse honestamente. Los resultados de estos métodos deben presentarse con sus limitaciones explícitas, no como equivalentes a un RCT.
Implementar un repositorio centralizado de análisis con control de versiones (Notion + GitHub, o una plataforma como Hex o Mode) donde cada análisis es reproducible y consultable por otros analistas. Establecer una biblioteca de métricas compartidas con definiciones estandarizadas para evitar que el mismo KPI se calcule de formas distintas por distintos analistas. Sesiones semanales de revisión de análisis donde los analistas presentan su trabajo al equipo para recibir feedback metodológico. Plantillas de análisis que estandarizan la estructura de documentación: pregunta, metodología, limitaciones y hallazgos. Los silos producen análisis inconsistentes que generan desconfianza cuando los stakeholders obtienen números distintos para la misma pregunta.
Entrevistar a los usuarios de cada dashboard con dos preguntas: ¿cuál fue la última decisión que tomaste basándote en este dashboard? ¿qué acción tomarías si la métrica principal bajara un 20%? Si no pueden responder la primera pregunta con un ejemplo concreto reciente, el dashboard es decorativo. Si no pueden responder la segunda, las métricas mostradas no son accionables. Auditar también el uso real: ¿cuántos usuarios abren el dashboard semanalmente? ¿cuánto tiempo pasan en él? Un dashboard con 2 usuarios activos de los 20 que supuestamente lo necesitan está fallando en su propósito. El resultado de la auditoría debe producir un plan de simplificación, no un plan de añadir más métricas.
Comunicar la limitación proactivamente al stakeholder antes de invertir tiempo en un análisis que producirá resultados poco confiables. Presentar las opciones disponibles: un análisis con los datos existentes que produce una estimación con intervalos de confianza amplios y supuestos explícitos, la identificación de qué datos adicionales reducirían la incertidumbre y cómo obtenerlos, o el diseño de un experimento que generaría los datos necesarios en el futuro. En algunos casos, la respuesta correcta es 'no tenemos los datos para responder esta pregunta con suficiente confianza para tomar esta decisión'. Esa honestidad es más valiosa que un análisis que aparenta mayor certeza de la que los datos soportan.

Errores comunes en entrevistas

Decir 'los usuarios que usan la feature X tienen 40% más retención, por lo tanto debemos forzar su adopción' es un error conceptual grave que puede llevar a decisiones de producto costosas e inefectivas. Los entrevistadores de empresas con cultura analítica madura hacen preguntas directas sobre causalidad y esperan que el analista sepa dónde están los límites de la inferencia.
Un análisis construido sobre datos incorrectos produce conclusiones incorrectas con una apariencia de rigor que las hace más peligrosas. Los entrevistadores preguntan específicamente cómo el candidato verifica la calidad de los datos antes de usarlos. No mencionar este paso es una señal de experiencia limitada con datos reales de producción que frecuentemente tienen problemas.
Construir dashboards es un medio, no un fin. Un analista que describe su trabajo principalmente en términos de los dashboards que construyó sin poder articular qué decisiones habilitaron esos dashboards demuestra que mide su impacto en outputs y no en outcomes. Los entrevistadores de empresas con equipos de datos orientados al impacto preguntan qué decisiones cambió el análisis.
Un analista que presenta resultados sin poder explicar por qué eligió esa técnica estadística, qué supuestos hace y cuáles son las limitaciones del método produce análisis que no son reproducibles ni cuestionables. Los entrevistadores técnicos piden al candidato que explique paso a paso cómo haría un análisis específico.
Un análisis que funciona bien para un científico de datos puede ser incomprensible o irrelevante para un director de ventas. La capacidad de adaptar la comunicación al nivel técnico y a los intereses de cada audiencia es una competencia central del rol. Los entrevistadores evalúan específicamente cómo el candidato comunica resultados a audiencias no técnicas.
Reportar que la tasa de conversión subió un 0.1% con significancia estadística sin mencionar que ese cambio equivale a tres ventas adicionales al mes demuestra falta de criterio de negocio. Los números tienen contexto y escala: lo que es estadísticamente significativo no siempre es prácticamente relevante para el negocio.

Las mejores oportunidades de trabajo para Data Analyst / BI

Todas las ofertas de internet en un solo lugar

Great American Insurance
Great American Insurancehace 2 semanas

Analista de Datos

Si eres Data Analyst, esta oferta es para ti. Se requiere conocimientos en Java, Spring framework, Oracle DB, SQL, Angular.js, Tableau.

$1,000 - $1,500/mes Presencial Inglés intermedio