Es la pregunta fundacional y la que peor está respondida en la mayoría de las cuentas. Sin los eventos correctos no hay journey posible: podés tener la mejor plataforma y la mejor estrategia, y no vas a poder disparar nada en el momento que importa.
La regla que evita el catálogo inflado
Cada evento tiene que tener un journey o un análisis que lo justifique. Si no podés nombrar para qué lo vas a usar, no lo trackees. Un catálogo de doscientos eventos que nadie mira cuesta plata y esconde los veinte que importan.
El set mínimo para una fintech
Agrupados por el momento del ciclo de vida al que sirven. Los nombres son ilustrativos: lo importante es que sean consistentes, no que se llamen igual que acá.
Alta y verificación
| Evento | Propiedades que no pueden faltar | Para qué |
|---|---|---|
registro_iniciado | canal, origen, dispositivo | Denominador de todo el funnel de alta |
registro_completado | tiempo desde inicio | Cierra el primer escalón |
verificacion_iniciada | tipo de documento | Arranque del KYC |
verificacion_abandonada | paso exacto, motivo si existe | El evento más valioso del set: sin el paso, el recordatorio es genérico e inútil |
verificacion_completada | tiempo total, intentos | Cierra el escalón más caro |
verificacion_rechazada | motivo | Journey distinto: no es lo mismo abandonar que ser rechazado |
Producto y primera operación
| Evento | Propiedades | Para qué |
|---|---|---|
producto_aprobado | tipo, límite o monto disponible | Dispara el journey de aprobado que no usa |
primera_operacion | tipo, monto, canal | Define activación real, no registro |
operacion_realizada | tipo, monto, canal, moneda | Base de frecuencia, recencia y valor |
fondos_ingresados | monto, medio, origen | Clave en wallets y neobancos |
feature_usada | nombre de la feature | Adopción de producto y señal de profundidad |
Pagos, mora y riesgo
| Evento | Propiedades | Para qué |
|---|---|---|
cuota_por_vencer | monto, fecha, cuota número | El recordatorio preventivo, el de mejor retorno |
pago_realizado | monto, medio, puntual o tardío | Cierra journeys y actualiza estado |
pago_fallido | motivo, medio, reintentos | Sin el motivo no sabés si es fondos o tarjeta vencida, que son dos mensajes distintos |
mora_iniciada | días, monto, producto | Entrada a la escalera de recupero |
mora_regularizada | días que estuvo, cómo se resolvió | Salida del journey y entrada al de reconstrucción |
Estado y ciclo de vida
Además de eventos, tu perfil necesita atributos de estado: si está verificado, si tiene producto activo, en qué escalón de mora está, cuál es su segmento de valor. Los eventos cuentan lo que pasó; los atributos cuentan cómo está ahora, y las condiciones de los journeys se escriben sobre los dos.
Los cuatro errores que rompen todo
- Nombres inconsistentes.
pago_ok,PagoExitosoypayment_successconviviendo. Elegí una convención y documentala antes de emitir el primer evento. - Eventos sin propiedades. Saber que hubo una operación sin saber el monto ni el tipo sirve para contar y para nada más.
- El evento de abandono sin el paso. Es el error más caro del set: convierte un recordatorio quirúrgico en uno genérico.
- Trackear la pantalla en vez del hecho.
vio_pantalla_pagoes analítica de producto;pago_fallidoes lo que dispara un journey. Necesitás los dos, pero no son lo mismo.
Por dónde empezar si no tenés nada
- Escribí los cinco journeys que más plata muevenNo los que te gustaría tener: los cinco que sabés que faltan.
- Para cada uno, anotá qué lo dispara y con qué datosAhí aparece tu lista real de eventos y propiedades, y suele ser mucho más corta de lo esperado.
- Documentá la convención antes de emitirNombres, tiempos verbales, formato de propiedades. Renombrar después es carísimo.
- Emitir, verificar y recién después construirUn journey armado sobre un evento que no llega bien es peor que no tenerlo.
Esto es el paso 1 del Ciclo Kunko, y el que más veces encontramos sin hacer.
Preguntas frecuentes
¿Cuántos eventos hay que trackear en una app fintech?
Menos de los que la gente cree. Entre veinte y treinta eventos bien definidos cubren casi todos los journeys de una fintech. El problema nunca es la cantidad: es que falten las propiedades que permiten segmentar, o que el mismo evento se llame de tres formas distintas.
¿Conviene trackear todo por las dudas?
No. Un catálogo inflado de eventos que nadie usa cuesta plata, ensucia el análisis y hace más difícil encontrar los que importan. La regla es al revés: cada evento tiene que tener un journey o un análisis que lo justifique.
¿Qué diferencia hay entre evento y propiedad?
El evento es lo que pasó; la propiedad es el detalle de lo que pasó. 'Préstamo solicitado' es el evento; monto, plazo, producto y canal son propiedades. Sin propiedades podés disparar un journey pero no podés personalizarlo ni segmentarlo.
¿Quién define la taxonomía, marketing o producto?
Los dos, y por eso suele quedar sin dueño. Producto sabe qué emite el sistema y marketing sabe qué necesita para comunicar. La taxonomía que funciona se escribe entre ambos y se documenta en un solo lugar.
Un evento suelto no dice nada. Lo que sirve es la secuencia: qué hizo antes, cuánto tardó, qué dejó a medias.
¿Tu taxonomía aguanta los journeys que necesitás?
Media hora para revisarla. Es el trabajo que hay que hacer antes que ningún otro.
Agendá un diagnóstico de 30 min →