¿Qué hace un analista de datos? El día real

Son las nueve y tres minutos de un lunes. Un mensaje aparece en el chat de la empresa: "oye, ¿por qué han bajado las ventas la semana pasada?". Parece una pregunta sencilla. No lo es. ¿Bajado respecto a qué semana? ¿En unidades vendidas o en dinero facturado? ¿En toda la empresa o en una tienda concreta? ¿Y quién pregunta de verdad: la persona que ha escrito el mensaje, o su jefa, que se lo ha pedido a ella hace cinco minutos y quiere una respuesta antes de la reunión de las cuatro? Esa frase de nueve palabras es el trabajo entero, comprimido. El resto del día consiste en desenredarla.

La imagen que mucha gente tiene de este oficio es la de alguien tecleando consultas todo el día, rodeado de números en una pantalla oscura. Hay consultas, sí, pero el tiempo que se pasa escribiéndolas es sorprendentemente corto comparado con el que se pasa entendiendo qué pregunta hay detrás de la pregunta, y comprobando que el número que va a enseñar no está mal calculado. Se parece más al trabajo de un médico de cabecera que al de quien instala las cañerías de un edificio: alguien llega diciendo "me duele todo" y la primera tarea, antes de recetar nada, es averiguar qué le duele exactamente.

### Un lunes cualquiera, hora por hora

No hay dos días iguales, pero el patrón se repite tanto que merece la pena contarlo como si fuera uno solo. Este es un lunes compuesto con las tareas más habituales de la profesión, ensambladas para que se vea el reparto real del tiempo:

1. 01.9:00 — Repasas el dashboard (el cuadro de mando, la pantalla con los gráficos que se actualiza sola cada noche) antes del café. Una línea que suele ser plana esta semana tiene un escalón hacia abajo.
2. 02.9:15 — Llega el mensaje sobre las ventas. En vez de ponerte a escribir una consulta, respondes con otra pregunta: "¿bajado respecto a la semana pasada o al mismo lunes del año anterior? ¿Hablamos de toda la tienda online o solo de la app?".
3. 03.9:40 — Con la pregunta ya acotada, escribes la consulta que compara ambas semanas por categoría de producto. El primer resultado dice que las ventas han caído un 18%, lo cual es una barbaridad para una semana normal.
4. 04.10:15 — Antes de enseñarle ese 18% a nadie, lo comparas contra otra fuente: el resumen que genera la pasarela de pago. No coincide. Empiezas a tirar del hilo.
5. 05.11:00 — Encuentras la causa: alguien cambió el criterio de un campo hace diez días, y ahora un pedido cancelado se cuenta como si nunca hubiera existido en vez de contarse y luego restarse. El 18% real, corregido, es un 4%. Sigue siendo una caída, pero una completamente distinta a la que ibas a anunciar.
6. 06.12:00 — Preparas tres frases claras con el número correcto, la causa probable y una comparación con el mismo periodo del año anterior, para la reunión de las dos.
7. 07.14:00 — Reunión con el equipo comercial. Enseñas el 4% y el motivo. Alguien pregunta: "¿seguro que es así? A mí no me sale eso". Explicas cómo lo has calculado y de dónde viene el dato, sin ponerte a la defensiva.
8. 08.16:30 — Dejas anotado, en el mismo sitio donde vive la consulta, qué campo cambió y cuándo, para que la próxima persona que tropiece con ese número no tenga que descubrirlo otra vez desde cero.

Conviene fijar dónde está la frontera entre las tres, porque no está donde parece. "Entender" es todo lo que pasa antes de tocar un dato: acotar la pregunta y averiguar quién la hace de verdad. "Contar" es lo que pasa cuando el número ya está y hay que sostenerlo delante de alguien.

Y en medio, "consultar" es más ancho de lo que suena: no es sólo escribir la consulta, también es comprobar que el número que ha salido es cierto. Contrastar contra otra fuente o revisar el panel por la mañana son tareas de consultar, aunque no se escriba una línea. De hecho, la mayor parte de ese 50% no es teclear: es comprobar.

### Lo que ocupa el tiempo de verdad

Escribir la consulta que compara dos semanas se hace en veinte minutos, con algo de práctica. Lo que se lleva las horas es lo de antes y lo de después: acotar qué se pregunta de verdad, y comprobar que el número no miente antes de firmarlo con tu nombre. Quienes llevan años en este oficio cuentan casi todos la misma historia de novato, con variaciones: la vez que enseñaron un crecimiento espectacular en una reunión, alguien preguntó de dónde salía, y la respuesta honesta era que salía de un cambio en cómo se medía la cosa, no de que de verdad hubiera crecido nada. El dato no mentía técnicamente. Pero contaba una historia falsa, y quien lo presentó fue quien quedó mal delante de todo el comité.

De esa clase de sustos sale la regla que más se repite en este trabajo: el dato dice esto, pero mira de dónde sale. No es desconfianza gratuita, es el hábito de preguntarse siempre quién produjo ese número, con qué criterio, y si ese criterio ha cambiado hace poco sin que nadie te avisara. Un número sin ese contexto no es un hecho: es una cifra suelta esperando a que alguien la crea sin comprobarla.

### Tres oficios que se confunden todo el rato

En las ofertas de empleo, y en las conversaciones de pasillo, los nombres "analista de datos", "ingeniero de datos" y "científico de datos" se mezclan constantemente, como si fueran sinónimos con distinto acento. No lo son, y la manera más clara de distinguirlos no es por el título, sino por el tipo de pregunta que cada uno responde. Un analista responde "¿qué ha pasado, y cuánto?", con datos que ya existen y que alguien ha dejado en condiciones de consultar. Un ingeniero de datos se asegura de que esos datos lleguen limpios, completos y a tiempo hasta el sitio donde el analista los va a consultar; su pregunta es "¿cómo hago que este dato exista aquí, todos los días, sin que nadie tenga que rezar?". Un científico de datos responde "¿qué va a pasar, por qué, y con cuánta seguridad?", casi siempre construyendo un modelo o diseñando un experimento en lugar de contar lo que ya ocurrió.

Un ejemplo concreto ayuda más que la definición. Imagina que una empresa de suscripciones nota que algunos clientes dejan de pagar cada mes: a eso se le llama churn, la proporción de clientes que se dan de baja en un periodo. Contar cuántos se han ido este mes y desde cuándo empezó a subir esa cifra es trabajo de análisis. Que esa cifra de bajas llegue cada noche a la tabla correcta, sin duplicar a nadie que se dio de baja dos veces por error, es trabajo de ingeniería de datos. Construir un modelo que calcule, cliente por cliente, la probabilidad de que se vaya el mes que viene para poder llamarle antes, es trabajo de ciencia de datos. Las tres preguntas parten del mismo problema de negocio y ninguna sustituye a las otras dos.

### El panorama de herramientas: qué vas a aprender aquí y qué no

La caja de herramientas de este oficio tiene, en la práctica, cuatro compartimentos, y conviene saber desde el primer día cuáles vas a llenar en esta plataforma y cuáles no. El primero es la hoja de cálculo, y merece más respeto del que suele recibir: lleva más de cuarenta años siendo la herramienta con la que más gente responde preguntas con números en una oficina — entre el 78% y el 94% de los profesionales la usan (la primera, VisiCalc, salió en 1979 para un ordenador —la computadora— Apple II, y el parecido con lo que hoy abres en tu ordenador o en el navegador es asombroso). Para una pregunta puntual, con pocos datos y sin necesidad de repetirla cada semana, sigue siendo, muchas veces, la respuesta correcta. El segundo es SQL, el lenguaje con el que se le habla a una base de datos; cuando los datos ya no caben cómodamente en una hoja, o cuando la misma pregunta hay que responderla una y otra vez sobre datos que cambian cada día, SQL hace en segundos lo que a una hoja de cálculo le costaría minutos o directamente no podría hacer. El tercero es Python, un lenguaje de programación de propósito general que, en este oficio, sirve sobre todo para automatizar lo repetitivo y para ir un paso más allá de lo que una consulta puede contar por sí sola. El cuarto compartimento son las herramientas de business intelligence (BI): programas dedicados a convertir tablas en gráficos y paneles que cualquier persona de la empresa puede mirar sin escribir una sola línea de código.

• ▹Hoja de cálculo: la herramienta de la respuesta rápida y del análisis puntual. Aquí aprenderás a usarla en serio, no como sustituto barato de las otras tres.
• ▹SQL: el lenguaje que hablarás casi todos los días para consultar cualquier fuente de datos de tamaño serio. Es el núcleo de esta profesión.
• ▹Python: el complemento para automatizar, limpiar en profundidad y hacer cálculos que SQL por sí solo no cubre bien.
• ▹Herramientas de BI: aquí no se enseñan. Son un oficio con entidad propia, con sus propias plataformas y su propia curva de aprendizaje, y mezclarlas con lo anterior diluiría las dos cosas. Si te interesan, esta plataforma las trata en su propio sitio.

### Cuando el número no cuadra

Vuelve un momento al 18% del lunes. Ese es el escenario que se repite más veces de las que gustaría: un número sale de la consulta, es llamativo, y la tentación de enseñarlo tal cual es enorme porque encaja con lo que todo el mundo ya sospechaba. La costumbre que separa a quien lleva un año en esto de quien lleva diez no es escribir consultas más rápido, es desconfiar sistemáticamente del número bonito antes de que lo vea nadie más. Comparar contra otra fuente, mirar si algún criterio cambió hace poco, preguntarse si ese resultado tendría sentido si te lo contara un compañero. La mayoría de las veces el número resiste la comprobación. Las pocas veces que no la resiste son las que evitan quedar mal en una reunión, o algo peor: que la empresa tome una decisión cara basada en un error que nadie se paró a mirar dos veces.

De ese instinto, y de la pregunta bien planteada del principio, sale casi todo lo que vas a construir a continuación en este módulo: cómo convertir una frase vaga como "¿por qué han bajado las ventas?" en algo que se pueda medir de verdad, y cómo decidir qué merece la pena calcular y qué es ruido que no le importa a nadie.