Auditoría del seguimiento de eventos en apps generadas por IA en las que puedas confiar

Por qué la analítica falla en apps generadas por IA

La analítica mala normalmente no es sutil. Verás tasas de conversión de checkout por encima del 100 %, un pico aleatorio a las 3 a.m. o un embudo donde todo el mundo “ve precios” pero casi nadie “inicia prueba”. A veces falta un paso clave por completo, así que el dashboard cuenta una historia ordenada que nunca ocurrió.

Los prototipos generados por IA a menudo se envían con tracking a medias porque el objetivo fue “que funcione” para una demo, no “que sea medible” en producción. Una herramienta de IA puede copiar un snippet de tracking en una página pero no en otras, disparar eventos desde múltiples sitios o mezclar nombres antiguos y nuevos de eventos tras un refactor. También puede disparar eventos en el momento equivocado, por ejemplo registrar "purchase" cuando se hace clic en el botón en lugar de cuando el pago realmente se completa.

Eso rompe la toma de decisiones rápidamente. Si el registro se contabiliza de más, puedes asumir que la activación está bien y gastar dinero en anuncios. Si las pruebas se cuentan de menos, puedes cambiar los precios o quitar funciones que no eran el problema. Si la atribución está enmarañada, puedes pausar una buena campaña y reforzar una mala.

La analítica de confianza es fácil de describir: la misma acción de usuario produce el mismo evento, una vez, con el mismo significado siempre. Puedes explicar dónde se dispara en el código, reproducirlo en una cuenta de prueba y verlo coincidir con lo que registran tus logs y tu base de datos.

Cuando algo parece raro, haz una comprobación rápida de la realidad. ¿El evento se disparó solo después del éxito (no en el clic)? ¿Podría estarse disparando dos veces (cliente y servidor, o dos listeners)? ¿El nombre es consistente entre páginas y entornos? ¿Los contadores coinciden con una fuente de verdad como la tabla de pedidos? ¿Los bots, reintentos o recargas de página inflan los totales?

Si heredaste una app construida por herramientas como Bolt, v0 o Replit, estos problemas son comunes. FixMyMess suele ver tracking enredado con el código de UI, manejadores duplicados y eventos que se disparan aun cuando las peticiones fallan.

Decide qué necesitas medir realmente

Antes de tocar código o dashboards, decide cómo se ve el “progreso real” en tu producto. Muchas apps generadas por IA fallan en analítica porque lo registran todo pero omiten las pocas acciones que explican crecimiento e ingresos.

Empieza con un pequeño conjunto de acciones críticas para el negocio. Para muchos productos, es alguna versión de registro (cuenta creada con éxito), activación (primera tarea con valor), compra (dinero intercambiado o inicio de plan de pago), retención (el usuario vuelve y realiza la acción clave otra vez) y a veces referido o compartir.

Define cada evento en una frase que responda a dos preguntas: cuándo se dispara y por qué te importa. Ejemplo: signup_completed se dispara después de que el usuario confirma su correo, porque ese es el primer punto en el que podemos confiar en que la cuenta es real.

Elige un estilo de nombres y mantenlo. Los nombres simples y legibles superan a los ingeniosos. Escoge un formato (como verb_noun), mantén el tiempo consistente y evita nombres que suenen a elementos de UI (por ejemplo, blueButtonClick).

Mantén las acciones de usuario separadas de los eventos del sistema. Una acción de usuario es “created project” o “started trial”. Un evento de sistema es “email sent” o “webhook received”. Cuando los mezclas, los embudos dejan de significar lo que crees.

Escribe también qué significa el éxito para cada evento. Puede ser un conteo, una tasa de conversión o un tiempo objetivo hasta la acción. Eso facilita las auditorías posteriores, especialmente si heredas código generado por IA y necesitas probar lo que los usuarios hicieron realmente.

Mapea eventos a acciones reales de usuario

La buena analítica comienza con un mapa simple: lo que hace una persona paso a paso y qué esperas registrar en cada paso. Si te saltas esto y vas directo a dashboards, acabarás midiendo clics que no significan nada.

Escribe tus flujos clave de usuario en lenguaje llano. Limítate a las acciones que importan, no a cada botón. Un conjunto típico es: primera visita, registro, inicio de sesión, tu función principal (la acción que prueba el valor) y checkout.

Para cada paso, captura tres cosas: (1) el nombre de evento esperado, (2) el momento en que debería dispararse y (3) dónde debería dispararse (cliente, servidor o ambos). Eso convierte “el tracking está roto” en algo que puedes señalar y arreglar.

Los casos límite son donde las apps generadas por IA a menudo se separan de la realidad. Un modal puede disparar un evento al abrirse y otra vez al enviar. Una redirección puede duplicar vistas de página. Un formulario multi-paso puede registrar un evento de finalización en cada paso porque el estado se reinicia.

Mientras mapeas cada flujo, anota los casos que necesitas probar: recarga o botón atrás, reintentos (doble clic, reenvío, reintento de pago), redes lentas, timeouts, conexiones inestables y diferencias móvil vs escritorio.

Ejemplo: un usuario se registra, es redirigido a un dashboard y la app restaura la sesión al cargar. Si tanto el handler de éxito del registro como el código de restauración de sesión envían signup_completed, tu embudo muestra dos registros por una sola persona.

Entiende de dónde vienen los eventos

Cuando auditas tracking, el primer trabajo es simple: encuentra la línea exacta de código que dispara cada evento. En apps generadas por IA, esa línea puede moverse rápido conforme la herramienta reescribe componentes, añade helpers o duplica lógica.

Eventos del cliente vs del servidor

Los eventos del lado del cliente (navegador o app móvil) son mejores para acciones de UI y contexto, como clics de botones, vistas de página y pasos de formularios. Capturan lo que el usuario vio y hizo, pero son más fáciles de bloquear o perder (ad blockers, errores de script, redes inestables).

Los eventos del lado del servidor (tu API, jobs backend, webhooks) son mejores para cosas en las que debes confiar, como pagos completados, cambios de suscripción o creación de cuentas. Son más difíciles de falsificar y suelen ser más fiables, pero pueden perder la intención de la UI (por ejemplo, un usuario intentó pagar y luego abandonó).

En código generado por IA, los eventos a menudo se disparan desde unos pocos lugares repetibles: handlers de UI (onClick, onSubmit), hooks y effects (useEffect), wrappers de API, gestores de estado y utilidades compartidas como una función genérica track().

Los duplicados suelen venir de código que corre más de lo que crees: rerenders que reasignan handlers, múltiples listeners adjuntos a la misma acción, logging optimista en la UI más una confirmación del servidor, o peticiones que reintentan y registran cada intento.

Los eventos faltantes tienden a ser menos dramáticos pero igual de comunes: returns tempranos antes de la llamada de tracking, excepciones que saltan la línea, scripts bloqueados por el navegador o condiciones de carrera donde la app navega antes de que el evento se envíe.

Una comprobación de cordura rápida: si “Signup Completed” se envía desde un efecto de React que depende del estado de usuario, una recarga puede dispararlo otra vez. Si se envía desde el servidor solo después de crear el registro de usuario, se disparará una vez, pero aun así querrás un Signup Started separado para entender la caída.

Paso a paso: audita un evento de extremo a extremo

Elige un flujo de usuario que te importe y mantenlo pequeño. Un buen inicio es registro, luego verificación de email (si la tienes) y después la primera acción clave (como crear un proyecto o guardar un borrador). Una vez confíes en este flujo, todo lo demás se vuelve más fácil.

Antes de probar, escribe qué esperas en palabras simples: qué evento debe dispararse, exactamente cuándo y qué debe contener. Esta es la especificación de evento más pequeña y útil.

Aquí tienes una rutina de extremo a extremo que funciona incluso en bases de código generadas por IA y desordenadas:

1. Realiza el flujo como un usuario real y observa eventos en tiempo real mientras lo haces.
2. Pausa en cada momento que debe disparar un evento y confirma que ocurre en ese instante.
3. Repite la misma acción dos veces para detectar dobles envíos. Un clic debe significar un evento.
4. Abre el payload del evento y verifica lo básico: user_id (o anonymous_id), session_id, plan o tier, source (web/app/referral), nombre de pantalla/página y cualquier estado de error.
5. Tras el procesamiento, confirma que el mismo evento aparece en los informes con los mismos conteos y segmentaciones.

Usa un escenario concreto de “falla” mientras pruebas. Si envías el formulario de registro y obtienes un error de validación, deberías ver un evento de fallo (o una propiedad de error) sin ver también un evento de éxito. Si aparecen ambos, tu embudo se verá mejor que la realidad.

Mientras pasas al siguiente flujo, lleva notas: nombre del evento, momento esperado, momento real, duplicados, propiedades que faltan y qué archivo o componente parece responsable.

Encuentra envíos duplicados y eventos faltantes

Los eventos duplicados son una de las formas más rápidas de perder confianza en tus números. Empieza comparando lo que ves en dashboards con lo que puedes reproducir en una prueba manual rápida.

Cómo detectar duplicados (y por qué ocurren)

Los duplicados suelen aparecer como el mismo nombre de evento con las mismas propiedades clave disparándose en el mismo segundo o en un par de segundos. Las vistas de página que aumentan aunque no hayas navegado son otra pista.

Señales de alerta comunes incluyen eventos idénticos repetidos, embudos donde pasos posteriores tienen más completaciones que pasos anteriores, picos súbitos que no coinciden con el tráfico y métricas que cambian mucho al refrescar.

Las causas raíz en apps generadas por IA son a menudo simples: bucles de rerender en React, tracking añadido tanto en un componente como en un handler global, listeners atados dos veces o reintentos de red que reenvían el mismo evento sin idempotencia.

Cómo detectar eventos faltantes

Los eventos faltantes aparecen como caídas que no coinciden con lo que observas al probar. Si puedes completar “Añadir al carrito” en la experiencia real pero el embudo muestra una gran brecha, probablemente tienes tracking que nunca se dispara, que lo hace solo a veces o que se dispara antes de que la acción real termine.

Los arreglos que suelen funcionar son sencillos: añade una protección para que un evento solo pueda dispararse una vez por acción, debounce en handlers de clic, mueve el tracking a una sola capa (a menudo el handler final de envío), añade una clave de idempotencia (como order_id o request_id) para que los reintentos no creen duplicados, y registra tras el éxito en lugar de en el clic (especialmente para auth y pagos).

Confirma la corrección ejecutando el mismo flujo otra vez y comparando antes vs después. También vuelve a probar en una red lenta, porque los reintentos son donde se esconden duplicados y eventos faltantes.

Verifica identidad, sesiones y atribución

Si tus gráficos parecen “más o menos correctos” pero los embudos están mal, el manejo de identidad y sesiones suele ser la razón. Las apps generadas por IA frecuentemente mezclan trackers del cliente, librerías de auth y soluciones rápidas que no concuerdan sobre quién es el usuario.

Identidad: elige una fuente de verdad

Define un único ID de usuario fiable y aplícalo en todas partes. En la mayoría de apps, eso significa trackear anónimamente hasta que el registro o login se complete y luego cambiar a un ID interno estable (no un email, no un nombre público).

Un bug común es la fusión incorrecta de usuarios anónimos y logueados. Ejemplo: un usuario visita de forma anónima, se registra, cierra sesión y luego inicia sesión de nuevo en una pestaña nueva. Si tu código reutiliza el antiguo anonymous_id, puedes fusionar a dos personas en un perfil o dividir una persona en muchas.

Cuando pruebes identidad, céntrate en unos cuantos escenarios: registrarse y luego refrescar (el ID debe seguir igual), cerrar sesión y volver a entrar (el ID logueado debe ser el mismo, el comportamiento del anonymous ID debe ser consistente), hacer la misma acción en una pestaña nueva (un usuario con dos sesiones, no dos usuarios) y comparar con una ventana de incógnito o un segundo dispositivo (no fusiones sin un login real).

Sesiones y atribución: mantenlo simple

Los límites de sesión deben coincidir con el comportamiento real: nueva sesión tras un largo intervalo, no tras cada refresco. Si tu tracker crea una nueva sesión en cada recarga, inflas “sesiones nuevas” y rompes embudos.

Para atribución, captura lo básico de forma consistente: source, campaign y referrer en la primera entrada significativa. Almacénalo una vez por sesión (o primer toque) y reutilízalo, en lugar de releer la URL en cada página. Eso evita sobrescrituras accidentales cuando los usuarios navegan, pagan o regresan desde un proveedor externo.

Revisa propiedades de eventos y seguridad de datos

Los buenos nombres de eventos son solo la mitad del trabajo. Si las propiedades son desordenadas o arriesgadas, tus gráficos mentirán y puedes crear un problema de privacidad sin darte cuenta.

Empieza escribiendo un conjunto corto y estrictamente necesario de propiedades para cada evento. Conserva solo lo que realmente usas en informes, embudos o alertas. Los campos extra parecen inofensivos, pero se convierten rápido en basura inconsistente.

Una lista de indispensables simple podría incluir:

• user_id (o anonymous_id cuando está desconectado)
• source (dónde empezó la acción, como "pricing" o "settings")
• plan o product_id (solo si lo usas)
• value (un número, la misma unidad siempre)
• environment (prod vs staging)

Luego revisa tipos y consistencia. Una app puede enviar value: "19.99" como cadena, otra value: 19.99 como número y una tercera value: null cuando la UI falla. Elige un formato, aplícalo y decide qué hacer cuando faltan datos (descartar el evento, poner un valor por defecto o marcarlo como inválido).

La seguridad de los datos no es negociable. Los eventos se registran, se reproducen en herramientas de debugging y se almacenan largo tiempo. Escanea payloads cliente y logs servidor en busca de señales de peligro como contraseñas, códigos de un solo uso, enlaces de restablecimiento, tokens de acceso, claves API, números completos de tarjeta, CVV, datos bancarios completos, cuerpos de peticiones que incluyen secretos o propiedades “debug” que replican objetos enteros.

Haz que los eventos de error sean útiles sin filtrar datos. En lugar de volcar stacks y payloads, captura lo que ayuda a arreglar el problema: dónde falló (pantalla, paso, nombre de endpoint), qué vio el usuario (mensaje corto) y un código de error seguro.

Alinea los dashboards con la verdad

Un dashboard solo es útil si cada gráfico responde una pregunta clara. Si un gráfico mezcla objetivos (como “registros y activaciones”), se vuelve difícil detectar cuándo el tracking falla. Nombra la pregunta primero y luego asegúrate de que las cuentas del gráfico coincidan con tus definiciones de evento.

Un hábito sencillo que mantiene los dashboards honestos es escribir una definición de una línea bajo cada métrica clave. Ejemplo: “Activados esta semana = usuarios que completaron onboarding Y crearon su primer proyecto.” Obliga a claridad y evita pasos de embudo “más o menos”.

Antes de confiar en los números, haz una comprobación de alineación:

• Confirma que cada gráfico usa un evento (o un conjunto definido) y una ventana de tiempo.
• Revisa filtros como environment, plataforma, país y versión de app por ocultaciones o doble conteo accidentales.
• Asegúrate de que los pasos del embudo mapeen 1:1 con tu taxonomía de eventos.
• Añade al menos una comprobación externa (conteos en BD, logs de servidor, exportes del proveedor de pagos).
• Decide cómo excluir bots y tráfico interno, y escribe la regla.

Ejemplo: tu dashboard muestra 1,200 “Nuevos registros” ayer, pero la base de datos solo tiene 900 registros nuevos. Eso suele significar que el evento de registro se dispara tanto en “cuenta creada” como en “email verificado”, o que se reintenta en un refresco. Arregla el evento para que se dispare una vez (idealmente server-side) y luego actualiza el gráfico para contar solo el evento corregido.

Ejemplo: arreglar un embudo roto de registro y checkout

Una app construida por IA muestra un 90 % de conversión en registro en el dashboard, pero los ingresos están estancados. El fundador cree que el problema es marketing. En realidad, los números mienten porque el embudo está cosido con snippets copiados y tracking cliente y servidor mezclados.

Qué encontramos en los datos

“Signup Completed” se disparaba dos veces para muchos usuarios: una al enviar el formulario y otra cuando la app redirigía a la página de bienvenida. Algunos usuarios lo activaban una tercera vez al refrescar.

Al mismo tiempo, “Payment Confirmed” faltaba para una gran parte de compras reales. El checkout usaba una pasarela de pago de terceros, pero la app nunca registró el webhook final de éxito como evento, así que el dashboard no pudo conectar registros con usuarios pagos.

El resultado fue predecible: eventos de registro inflados por disparos duplicados en cliente, éxito de pago subcontado porque el servidor no lo registró y un embudo que parecía sano mientras el negocio no lo estaba.

Cómo lo arreglamos

Movimos “Signup Completed” a un único handler que se ejecuta solo después de que el servidor confirme que el registro de usuario se creó. Luego hicimos el evento server-side “Payment Confirmed” idempotente (el mismo purchase ID solo puede contarse una vez), de modo que reintentos y reenvíos de webhook no crean ingresos duplicados.

Para validar, ejecutamos un conjunto pequeño de usuarios de prueba (navegador nuevo, navegador recurrente, red lenta) y comparamos registros reales en la base de datos vs eventos Signup Completed, cargos exitosos vs Payment Confirmed y los conteos del embudo antes y después.

Tras la corrección, la conversión de registro bajó a un número más realista y el embudo mostró la verdadera caída en el pago. Las decisiones se volvieron más sencillas: arreglar fricción en checkout, no gastar más en anuncios.

Comprobaciones rápidas y siguientes pasos

Si solo haces una cosa esta semana, audita el puñado de acciones de las que depende tu negocio (registro, activación, pago, upgrade). Pequeños errores aquí pueden hacer que cada informe parezca aleatorio.

Usa esta lista de verificación para cualquier evento clave:

• Se dispara una vez (sin doble envío por refresco, botón atrás, reintentos o cliente y servidor a la vez)
• Se dispara en el momento correcto (después de que la acción realmente tenga éxito, no al pulsar un botón)
• Tiene las propiedades correctas (plan, precio, moneda, pantalla, motivo de error) y sin valores basura
• Tiene la identidad de usuario correcta (IDs estables, sin fusiones o divisiones accidentales)
• Aparece en el dashboard como esperas (los conteos coinciden con acciones reales que puedes reproducir)

Una vez que un evento es “verdadero”, anota qué significa en lenguaje llano: nombre del evento, cuándo se dispara, propiedades obligatorias y qué nunca debe incluir (contraseñas, tokens completos, datos crudos de tarjeta). Esta nota facilita los cambios futuros, especialmente cuando el código lo editen herramientas de IA.

Para evitar que las cosas se desvíen, haz una pequeña comprobación mensual: vuelve a probar tus eventos más importantes end-to-end en un entorno de staging o cuenta de prueba, compara una muestra pequeña de sesiones reales con los totales del dashboard, revisa cambios recientes de código que tocaron tracking o auth y elimina eventos que nadie usa.

Si tu app fue generada por Lovable, Bolt, v0, Cursor o Replit, una revisión de tracking a nivel de código merece la pena. Estos proyectos suelen acabar con handlers duplicados, tracking mezclado cliente/servidor y bugs de identidad que solo aparecen con tráfico real. Si quieres una segunda opinión, FixMyMess (fixmymess.ai) puede empezar con una auditoría de código gratuita para localizar envíos duplicados, eventos faltantes y capturas de datos riesgosas antes de que escales.