El trabajo en una línea
Un Data Analyst de growth responde la pregunta que el resto del equipo no deja de intentar adivinar: ¿esto funciona, y por qué? Es responsable de las métricas, construye los informes y lee los datos como un navegante lee una carta náutica: no por el placer de hacerlo, sino para indicarle un rumbo al equipo. En un equipo de growth está al final de la cadena, después de todos los demás roles: el Growth Engineer instrumenta los eventos, y el analista convierte esos eventos en evidencia.
La retención es la métrica que lo sostiene todo
El primer trabajo del analista suele ser la curva de retención, porque la retención es la base sobre la que se apoyan todas las demás cifras. Brian Balfour y el equipo de Reforge sostienen que una retención débil limita en silencio la adquisición y la monetización, por buenas que parezcan. El analista construye la vista de cohortes —qué proporción de cada cohorte de registro sigue activa el día 1, 7 y 30— y observa si la curva se aplana. Una curva que se aplana significa que el producto tiene un núcleo de usuarios que conserva; una curva que cae hasta cero significa que todavía no hay negocio que escalar.
De los datos a las decisiones
Los eventos brutos no son insights. El analista define cada métrica con precisión —qué cuenta como activo, dónde empieza y termina el embudo, qué churn es voluntario— para que el equipo discuta sobre la decisión y no sobre la definición. Después construye el informe semanal que leen el Growth PM y el Growth Lead para fijar el roadmap: la cohorte que crece más rápido, el paso del embudo que tiene fugas, el churn que probablemente traerá el mes siguiente. El resultado no es un panel. Es una recomendación con una cifra detrás.
Señal frente a ruido
La mayoría de las métricas que se mueven no importan. Un buen analista dedica tanto tiempo a eliminar métricas de vanidad como a construir las de verdad: el total de registros da gusto verlo y no predice nada; la activación y la retención cuestan más de mover y lo predicen casi todo. La disciplina, que enseñan equipos como Amplitude y Reforge, consiste en encontrar el indicador adelantado que de verdad anticipa el resultado que te importa y luego ignorar el resto del ruido que llena un panel típico.
Cómo suele aparecer el rol
En un equipo pequeño rara vez hay un analista dedicado: el trabajo recae en quien se maneja mejor con SQL, a menudo un fundador a las 11 de la noche. En un equipo más grande es un analista de growth o un data scientist integrado en la función de growth, distinto de un analista de business intelligence que informa sobre la empresa en su conjunto. Los títulos varían; lo que no cambia es el trabajo: definir las métricas, construir los informes y separar la señal del ruido para que el equipo apueste por la evidencia.
Dónde la IA acelera el análisis
Extraer los datos y hacer los gráficos es más rápido; las definiciones y la decisión, no. En fromHello, la materia prima del analista está en un solo lugar: eventos first-party, perfiles, segmentos en tiempo real y resultados de journeys y mensajes, con embudos y analíticas integrados. A través del servidor MCP, el cliente de IA que ya usas, como Claude o Cursor, puede sacar una curva de retención por día, mostrar qué segmentos crecen o se reducen y leer el rendimiento de journeys y plantillas cuando se lo pides. Son herramientas de lectura, ninguna herramienta de IA envía mensajes y las llamadas a herramientas MCP quedan registradas en tu log de auditoría. Nada en fromHello prevé el churn ni decide qué métrica importa; ese criterio sigue siendo del analista. Para compararlo con una suite que conoces, consulta fromHello vs. HubSpot.