Cómo arrancar con analítica en tu equipo: personas, procesos y tecnología

Has defendido el caso en el comité y ha salido que sí. Enhorabuena, y ahora viene la parte donde muchos equipos tropiezan: la herramienta no arranca sola.

Un arranque que sale mal no se nota el primer mes. Se nota a los seis, cuando abres la herramienta y encuentras eventos con nombres duplicados, otros que nadie sabe qué significan y cuadros de mando que nadie se atreve a tocar. A partir de ahí la gente deja de fiarse de los datos y vuelve a decidir a ojo, que es justo lo que querías evitar.

Quédate con:

Una herramienta de analítica arranca bien cuando tiene tres cosas resueltas desde la primera semana: quién se hace cargo (personas), cómo se mantiene y se usa (procesos) y qué base técnica la sostiene (tecnología). Y en ese orden. Si empiezas por la tecnología, acabas con una instalación perfecta que nadie usa.

Vamos a ver por qué fallan los arranques, qué decidir en cada uno de los tres pilares, un plan de 30, 60 y 90 días y cómo lo hace Algora, que acaba de recibir el visto bueno del comité.

Por qué fallan los arranques

Casi siempre por una de estas tres razones:

1. La herramienta no tiene dueño. Todos pueden pedir cosas, nadie decide. A los pocos meses hay diez formas de llamar al mismo evento.
2. Se instrumenta todo. Es el error del artículo 5 aplicado a la implementación: más eventos no son más respuestas, son más ruido.
3. Se confunde la instalación con el arranque. Que lleguen datos no significa que alguien los use. El arranque termina cuando una persona ajena al equipo de producto responde una pregunta suya sin ayuda.

Pilar 1: Personas

Antes de tocar nada, decide quién hace qué. Personas, procesos y tecnología son los tres pilares de este arranque. La idea no es empezar por la instalación: primero necesitas responsables con tiempo para mantenerla y usarla. Marty Cagan estructura Inspired alrededor de personas, producto, proceso y cultura, como explica en este artículo. Aquí nos centramos en cómo organizar el uso de la analítica.

Tres roles que conviene nombrar con apellidos:

• El dueño de la herramienta, y un suplente. Una persona con tiempo asignado, no quien pueda, y alguien que le cubra cuando no esté. Suele recaer en producto, o en operaciones de producto si existe. Decide los nombres de los eventos, aprueba cambios y vigila la calidad. La responsabilidad puede repartirse entre varias personas, pero cada tarea debe tener un responsable y un criterio de revisión.
• Los embajadores de cada área. Una persona de éxito del cliente, otra de marketing, quizá otra de ventas. No son usuarios más: traducen las preguntas de su equipo y empujan el uso. Son los que cumplen el plan de adopción que prometiste en el artículo 22.
• El apoyo técnico. Alguien de ingeniería o de datos con horas reservadas para instrumentar. Si no está reservado, tus eventos esperarán a que haya hueco en el ciclo de trabajo, es decir, siempre.

Y un cuarto elemento que no es un rol: la formación. Empieza por el equipo de producto y amplía al resto de la empresa por oleadas, con documentación a mano para que las instrucciones no vivan en la cabeza de una persona. Una sesión de una hora el primer día no cuenta. Es mejor una rutina corta y repetida, por ejemplo una consulta real por semana resuelta en directo con alguien que no sea de producto.

Pilar 2: Procesos

Un proceso en este contexto es lo que impide que la herramienta se degrade. Cinco piezas dan una base para empezar. La documentación de Amplitude también conecta planificación, instrumentación y revisión del dato:

1. Una taxonomía documentada. Una hoja con cada evento, su nombre, qué significa, cuándo se dispara y qué propiedades lleva. Es el diccionario que el glosario del artículo 3 daba a las personas, aplicado a los datos. Una convención sencilla, como objeto + acción en pasado (plantilla_creada, informe_compartido), ahorra muchas discusiones.
2. Un cauce para pedir eventos nuevos. Quien quiera medir algo nuevo lo pide por un único sitio, con la pregunta que quiere contestar. Si no hay pregunta, no hay evento. Esto conecta con el artículo 6.
3. Una revisión de calidad antes de publicar. Probar los eventos en un entorno de pruebas, o al menos en una cuenta interna, antes de que entren en los datos reales.
4. Un registro de datos rotos. Un lugar donde cualquiera pueda anotar este número no cuadra. Casi nunca eres el primero en notar que algo falla.
5. Una limpieza periódica. Revisar eventos y propiedades que nadie consulta antes de retirarlos: puede haber informes, integraciones o necesidades de auditoría que dependan de ellos. Reserva una revisión periódica; el intervalo depende de tu equipo, pero debe ser una fecha en el calendario y no una intención. Es el mismo principio de retirar lo que ya no sirve del artículo 17, aplicado a los datos.

Dos cosas más que también son proceso. La primera, un objetivo de adopción por cada funcionalidad que lanzas (artículo 15): así hay métricas claras que seguir y acciones claras si no se cumple. La herramienta por sí sola no da valor, lo da el hábito de mirar, analizar y ajustar. La segunda, unas reglas del juego: quién accede a qué, cómo se estructuran los informes y cómo se comprueba que se cumplen. Democratizar el dato es una ventaja, pero necesita barandillas.

Y una regla para empezar: pocos eventos, bien definidos. La guía actual de Amplitude para equipos de datos propone empezar por las cinco a diez acciones más importantes. No es un cupo universal: define solo lo necesario para responder tus primeras preguntas y añade eventos cuando una decisión los justifique.

Pilar 3: Tecnología

Aquí cae lo que casi todo el mundo cree que es lo único importante. Importa, pero va tercero.

• Instrumentación mínima. Los eventos del plan de medición del artículo 9 y los de tu North Star Metric (artículo 8). Nada más al principio.
• Identidad. Decide cómo identificas a usuarios y cuentas desde el día uno (artículo 2) y usa identificadores internos opacos, evitando datos personales innecesarios en las propiedades (artículo 11). Corregir la identidad cuando ya hay meses de datos puede exigir rehacer análisis y reconciliar históricos. Un identificador opaco no convierte por sí solo los datos en anónimos.
• Privacidad. Antes de recoger datos, revisa la base jurídica, los permisos y, cuando corresponda, el consentimiento. Deja claro dónde se procesan, quién accede a ellos, cuánto tiempo se conservan y cómo se atiende un borrado. No envíes contraseñas, datos de pago ni datos personales innecesarios. Alojar en Europa no resuelve por sí solo estas obligaciones; revisa la configuración con quien lleve privacidad.
• Conexión con tu sistema técnico. Si ya tienes un almacén de datos y una plataforma de datos de clientes (CDP), define qué sistema es la fuente de referencia y qué integraciones necesitas para no crear un silo paralelo (criterio 4 del artículo 21).
• Nombres coherentes. Convenciones de nombres desde el principio para que nada se pise ni se confunda cuando la estrategia crezca. Y aprovecha la guía que suele ofrecer el proveedor sobre cómo configurar su herramienta.
• Calidad. Un proceso de verificación (pilar 2) y alguien que lo mire (pilar 1). La tecnología sola no garantiza ni lo uno ni lo otro.

Hay un cuarto elemento que no aparece en ninguna tabla: la cultura. Instalar la herramienta y enseñársela al equipo de producto es una cosa. Conseguir que toda la empresa consulte los datos y los incorpore a cómo decide es otra, y lleva tiempo. No pierdas de vista ese horizonte mientras resuelves lo inmediato.

Un plan de 30, 60 y 90 días

• Días 1-30: nombrar y definir. Personas: dueño nombrado, embajadores por área y horas de ingeniería reservadas. Procesos: taxonomía inicial y cauce para pedir eventos. Tecnología: instrumentar los eventos clave y dejar resueltas identidad y privacidad.
• Días 31-60: acompañar. Personas: primeras consultas reales de éxito del cliente y marketing, con acompañamiento. Procesos: revisión de calidad en marcha y registro de datos rotos. Tecnología: conexión con almacén de datos y CDP, y primeros cuadros de mando.
• Días 61-90: consolidar. Personas: rutina semanal de uso y medición de la adopción real. Procesos: primera limpieza de eventos y revisión de la taxonomía. Tecnología: revisar qué falta, sin añadir por añadir.

Al final de los 90 días, pregúntate tres cosas: ¿quién fuera de producto responde ya preguntas sin pedir ayuda?, ¿qué decisiones hemos documentado con datos fiables? y ¿qué problemas de calidad hemos corregido? Retirar eventos solo tiene sentido si elimina ruido sin romper análisis útiles.

El caso de Algora: del sí del comité a los 90 días

Volvemos a Algora, el ejemplo ficticio del curso. El comité del cuarto trimestre ha aprobado la compra de PostHog Cloud EU, y Marta, la PM de Enterprise, tiene que hacer que funcione.

Lo que sigue es ilustrativo: situaciones y cifras inventadas para el ejemplo.

• Personas. Marta es la dueña de la herramienta, con un día a la semana durante los primeros 90 días tras la aprobación. Esta dedicación empieza después del comité, no en un trimestre anterior. Customer success y marketing nombran a un embajador cada uno. El equipo de datos reserva unas horas al mes para el apoyo técnico.
• Procesos. El primer mes, Marta y el equipo de datos escriben la taxonomía con los eventos de las tres iniciativas del plan de trabajo Enterprise y de la North Star Metric. Cualquier evento nuevo se pide por un único canal, con la pregunta que quiere contestar.
• Tecnología. Los eventos clave se instrumentan en la herramienta y se define su exportación a BigQuery, el almacén que Algora ya utiliza junto con dbt. Los identificadores de usuario siguen siendo opacos y la cuenta se registra como propiedad, como vimos en el artículo 2.
• Resultado a 90 días. En el ejemplo, el embajador del equipo de éxito del cliente construye por su cuenta un análisis de cuentas Enterprise que usaron plantillas de contrato en sus primeras semanas. Ya no hace falta abrir una petición al equipo de datos. Esa autonomía, junto con la calidad de los datos y las decisiones documentadas, es una señal de que el arranque funciona. El número de eventos recogidos no basta.

Tres trampas comunes

1. Empezar por la instalación y dejar lo humano para después. Sin dueño ni proceso, el mejor montaje se degrada en meses.
2. Querer medirlo todo el primer mes. Mide poco, define bien, amplía con preguntas reales.
3. No medir el uso de la propia herramienta. Si no sabes quién la abre y qué consulta, no sabrás si el caso que defendiste en el comité se está cumpliendo.

Resumen rápido

• Tesis: la herramienta arranca bien cuando están resueltos quién se hace cargo, cómo se mantiene y qué base técnica la sostiene, en ese orden.
• Personas: un dueño con tiempo asignado, embajadores en cada área, apoyo técnico reservado y formación continua.
• Procesos: taxonomía documentada, cauce único para pedir eventos, revisión de calidad, registro de datos rotos y limpieza periódica.
• Tecnología: instrumentación mínima, identidad desde el día uno, privacidad clara, conexión con tu sistema técnico y verificación de calidad.
• Plan de 90 días: nombrar y definir en el primer mes, acompañar en el segundo, consolidar en el tercero.
• Cómo saber si ha funcionado: alguien fuera de producto contesta sus preguntas sin ayuda, se documentan decisiones y se comprueba la calidad. Eliminar eventos no es un objetivo por sí mismo.

Y ahora, ¿qué?

Este es el último artículo del curso. Si has llegado hasta aquí desde el principio, ya tienes el mapa completo: qué es la analítica de producto, cómo estructurar una estrategia, cómo convertir datos en decisiones y cómo defender y arrancar la inversión.

Si has entrado por el medio, puedes volver al índice del curso y elegir el artículo que necesites. Y si te queda alguna duda sobre cómo aplicarlo en tu equipo, escríbeme.