Eventos de producto.
Las acciones que el usuario ejecuta dentro de tu aplicación, medidas una a una. La analítica de web se apaga en el registro: a partir de ahí, sin eventos instrumentados no hay activación, no hay cohortes y no hay nada que dirigir.
Los eventos de producto son las acciones que un usuario ejecuta dentro de una aplicación —crear el primer proyecto, invitar a un compañero, exportar un informe— registradas una a una con su instante y sus propiedades. De ellas, y solo de ellas, salen la activación, la adopción por funcionalidad y las cohortes de retención.
También: product events · eventos in-app · instrumentación de producto
Agencia Snowball, Barcelona · Revisado el
Qué hace el usuario dentro del producto, no qué páginas vio antes de entrar.
Un evento de producto es una acción que el usuario ejecuta dentro de tu aplicación, registrada con su hora y sus propiedades: creó el primer proyecto, invitó a un compañero, exportó un informe, volvió el día siete. Nada de esto se mide con analítica web sola.
Y ahí está el malentendido que hay que deshacer, porque cuesta caro: tener GA4 montado no es tener medido el producto. La analítica de web está construida para responder de dónde vino la visita y qué páginas recorrió, y hace ese trabajo bien. Eso es atribución. Pero se apaga exactamente en el registro, que es justo donde empieza el negocio de un producto que se paga cada mes.
Tampoco es lo mismo que un evento de conversión. Ese es uno, lo elige el negocio para contarlo como venta y es el que se le pasa a la plataforma de anuncios. Los eventos de producto son muchos, casi ninguno es una conversión y su trabajo es otro: reconstruir el uso. Son dos instrumentaciones distintas y confundirlas es la forma más común de acabar con las dos a medias.
Aquí termina su trabajo. Con esto puedes atribuir el registro a un canal y nada más: ninguno de estos dos números dice si el producto se usa.
Sin eventos instrumentados, estos dos escalones no existen. No es que salgan mal: es que no hay dato, y son los que deciden la facturación del año que viene.
El ejemplo es ilustrativo, con los ratios de referencia de un tablero de software: de 20.000 visitas salen 700 registros al 3,5%, de esos registros 245 llegan a la acción que activa y 28 acaban pagando. Los dos primeros números te los da la analítica de web. Los dos últimos no existen si nadie instrumentó nada, y son los que se convierten en facturación recurrente.
A lápiz antes que en la herramienta, y con un contrato de tres columnas.
No hay fórmula. Hay un orden, y el orden empieza fuera del código: primero el journey dibujado a mano —sin Miro y sin Lucidchart todavía—, y solo después los eventos.
Dibuja el recorrido que necesitas que siga el usuario para llegar al valor, y enséñaselo a dos o tres personas más del equipo antes de darlo por bueno. Un journey validado solo por ti es una opinión, no un modelo, y sobre un dibujo que no existe se trabajan meses. A cada etapa le pones al menos dos métricas: la conversión de ese paso y el tráfico que llega a él. Esa lista de etapas es la lista de eventos, y no al revés.
Cada evento se cierra con tres cosas escritas, no habladas: cómo se llama, en qué instante exacto se dispara y qué propiedades lleva. El instante es lo que más se escapa: “invitó a un compañero” puede querer decir que abrió el diálogo, que mandó la invitación o que la aceptaron, y son tres cifras muy distintas de la misma frase.
registro_completadolo define negocioEl alta termina y el usuario entra por primera vez.plan, origen, tamaño del equipoproyecto_creadolo define negocioSe guarda el primer proyecto con nombre, no al abrir el formulario.plantilla, número de orden del proyectocompanero_invitadolo define negocioLa invitación sale del producto, no cuando la aceptan.rol invitado, canal de envíoinforme_exportadolo define productoLa exportación termina y el fichero se descarga.formato, número de filassuscripcion_activadalo define negocioEl primer cobro se confirma.plan, importe, cicloinforme_exportado con la propiedad formato vale por los catorce eventos distintos que salen de tener uno por cada formato.Y hay una cuarta cosa que se escribe aunque no se instrumente: la base de cada ratio. En el ejemplo de arriba, 28 clientes de pago sobre 700 registros son un 4%, y los mismos 28 sobre los 245 que llegaron a la acción que activa son un 11,4%. Ninguna de las dos cifras está mal. Lo que está mal es que en la reunión cada uno diga la suya creyendo que dice la misma.
La implementación es la parte fácil y hoy más que nunca: los eventos se montan con un gestor de etiquetas o desde el propio código, y una herramienta de producto conectada desde el primer día te da el dato de comportamiento sin que construyas el pipeline. Lo que no delega ninguna herramienta es la pregunta: cuál es la acción. Si nadie en tu empresa la puede nombrar en una frase, no tienes onboarding ni esquema: tienes eventos sueltos.
El listón de que está bien montado es uno y se comprueba en diez segundos: que el embudo entero se vea dentro de la propia herramienta, no en una hoja de cálculo al lado. Y que se pueda recorrer al revés: qué pasos siguió de verdad quien terminó pagando.
Con el esquema puesto, hay tres cosas que dejan de ser opinión.
Los eventos no se miran, se usan. Tres decisiones que sin ellos se toman a ojo, y con ellos se toman con un dato delante.
Uno: cuál es la acción que activa. El aha moment se define cruzando cohortes —quién se quedó, y qué hizo distinto en la primera semana quien se quedó frente a quien no—, no en una reunión de producto. Los ejemplos clásicos ya están medidos por otros y no sirven de meta, sirven de forma de pensar: completar un pin en los primeros siete días, enviar tres mensajes en la primera semana, organizar la primera reunión en siete días, sumar siete contactos en diez. Ninguno salió de una corazonada de fundador. Con la acción elegida, la activación deja de ser una palabra y se convierte en un porcentaje que se puede subir.
Dos: qué funcionalidades no usa nadie. Es la pregunta que duele, porque mantenerlas es un despilfarro de recursos que nunca sobran. La adopción por funcionalidad solo sale de eventos, y lo que se exige no es el informe: es una decisión tomada sobre cada funcionalidad muerta, matarla o promocionarla.
Tres: leer por cohortes y no en acumulado. Los registrados acumulados desde el lanzamiento son la métrica de vanidad de manual: solo suman, nunca restan y no dirigen nada. Lo mismo le pasa a cualquier ratio leído en acumulado, y ese es un fallo de lectura, no de instrumentación.
Los tres usos van juntos, y por eso esto es la infraestructura de cualquier estrategia de PLG: cuando el producto es el canal, la única palanca que tienes es lo que pasa dentro. Sin eventos no la ves, y una palanca que no se ve no se mueve, se adivina.
Cuatro formas de instrumentar el producto y quedarte sin dato.
Instrumentar antes de dibujar el recorrido
Empezar por la herramienta acaba en trescientos eventos y ninguna pregunta contestada. El orden es a lápiz antes que en la herramienta: journey, dos métricas por etapa, y entonces sí, eventos. Y el journey validado con dos o tres personas del equipo antes de tocar nada.
Dejar que el esquema lo decida quien lo implementa
Quien escribe el código decide cómo se dispara un evento; qué acciones importan lo decide el negocio. Si esa decisión se delega, sale un esquema fiel a la arquitectura de la aplicación y ciego a las preguntas de dirección. Antes de elegir modelo de precios ya hay que tener decidido qué cohortes y qué eventos vas a poder capturar: si no, eliges a ciegas y lo descubres seis meses tarde.
Nombrar los eventos sobre la marcha
Sin convención escrita, cada persona que pasa por el producto inventa la suya y en dos años hay cuatro nombres para la misma acción. Y esto es lo que lo hace grave: un evento que no se emitió no se puede reconstruir, y renombrar parte el histórico en dos series que no se suman. El esquema mal puesto no se arregla después, se paga perdiendo el pasado.
Meterlos en el mismo saco que la conversión
El evento de conversión es uno y va hacia fuera, a las plataformas de anuncios. Los eventos de producto son muchos y van hacia dentro, a entender el uso. Mandar los cincuenta a la plataforma no le enseña nada al algoritmo, y quedarse solo con el de conversión deja el producto sin medir.
Lo que se pregunta sobre eventos de producto.
¿Qué son los eventos de producto?
Son las acciones que el usuario ejecuta dentro de la aplicación, registradas una a una con su instante y sus propiedades: creó el primer proyecto, invitó a un compañero, volvió el día siete. Nada de esto se mide con analítica web sola, que responde de qué canal vino la visita y qué páginas recorrió antes de registrarse, y se apaga justo ahí.
¿En qué se diferencian de un evento de conversión?
El evento de conversión es uno, lo elige el negocio para contarlo como venta y va hacia fuera, a las plataformas de anuncios. Los eventos de producto son muchos, casi ninguno es una conversión y van hacia dentro, a reconstruir el uso. Son dos instrumentaciones distintas: mandar cincuenta eventos de producto a la plataforma no le enseña nada al algoritmo, y quedarse solo con el de conversión deja el producto sin medir.
¿Cuántos eventos hay que instrumentar?
Los que salgan del recorrido dibujado, no los que la aplicación sea capaz de emitir. Se dibuja el journey a mano, se le ponen dos métricas a cada etapa —conversión del paso y tráfico que llega— y esa lista es la lista de eventos. Empezar por la herramienta acaba en trescientos eventos y ninguna pregunta contestada.
¿Se puede arreglar después un esquema de eventos mal puesto?
Solo hacia delante. Un evento que no se emitió no se puede reconstruir, y renombrar uno parte el histórico en dos series que no se suman: las cohortes antiguas se quedan sin el dato. Por eso qué cohortes y qué eventos vas a poder capturar se decide antes, no cuando ya hace falta el informe.
Los que hacen falta para usar este.
Saber de dónde viene cada venta y poder demostrarlo cuando alguien lo discuta.
Saber de dónde viene cada venta. Sin esto, cualquier decisión de inversión es el cuento de la vieja.
El porcentaje de registros que llega a usar el producto de verdad. En PLG, el número que manda.
La acción concreta que convierte un registro en usuario que se queda. Se fuerza pronto, no se espera.
Product-led growth: el producto se vende solo. Solo aplica si el cliente entiende el valor sin que nadie se lo explique.
Lo que el usuario te deja medir. Hoy decide qué porcentaje de tus datos existe, y ningún arreglo técnico se lo salta.
Los datos que tienes porque te los dio tu cliente. El único activo de medición que no depende de una plataforma ajena.
