Solución de problemas

Busca tu síntoma, lee la causa, aplica la solución. Casi todo lo que parece un error es una de unas diez cosas.

No aparecen datos

“No veo ningún dato”

Recorre esta lista en orden: está ordenada más o menos por qué tan seguido es la respuesta.

¿El proyecto sigue en configuración? Los eventos no se guardan hasta que presionas Go Live. En estado de configuración, el collector acepta tus eventos, los muestra en la pantalla de prueba del onboarding y los descarta. Nada llega a los reportes. Revisa la pantalla de prueba: si los eventos aparecen ahí pero en ningún otro lado, esa es tu respuesta. Mira Salir en vivo.

¿Estás probando desde localhost? El modo debug se activa automáticamente en hosts locales, y los eventos en debug nunca se cuentan:

• localhost
• 127.*
• 10.*
• 192.168.*
• 172.16.* hasta 172.31.*
• *.local
• 0.0.0.0

Despliega a un dominio real, o mira la pantalla de prueba del onboarding, que muestra el tráfico de depuración en vivo.

¿El snippet está realmente en la página? Abre las herramientas de desarrollo, ve a la pestaña Network y recarga. Busca una petición a /e en el collector. Si no hay petición, el snippet no se está ejecutando: verifica que esté en el HTML desplegado, que no lo bloquee una CSP y que tu build no lo haya eliminado.

No tomes un 2xx como prueba de que tu clave es válida. Las claves desconocidas o revocadas devuelven a propósito la misma respuesta 2xx que las válidas, para que la API no sirva para adivinar qué claves existen. Una petición exitosa te dice que el camino de red funciona, nada más. Vuelve a copiar tu clave pública desde Configuración → Instalación y compárala carácter por carácter con la de tu página.

¿El proyecto está pausado? Los proyectos pausados aceptan los eventos y los descartan. Revisa el estado de tu proyecto.

“No puedo salir en vivo”

Go Live requiere todo esto:

• Un correo verificado. Revisa tu bandeja, o reenvía desde el aviso en la configuración de tu cuenta.
• Una suscripción activa o una prueba vigente. Mira Cuenta y facturación.
• Que tu almacén analítico haya terminado de aprovisionarse. Justo después de crear un proyecto esto toma un momento y se muestra como “configurando analytics”. Se resuelve solo: espera y recarga.

Atribución y fuentes

“Faltan mis datos de fuente o dicen sin atribuir”

Causa: el dominio desde el que sirves no está en Configuración → Datos → Dominios.

Esa lista es una lista blanca de orígenes. Los eventos de un origen que no está en ella igual se aceptan —no pierdes el tráfico— pero se marcan como sin atribuir, y se descartan sus campos de referencia, UTM y atribución.

Solución: agrega todos los dominios desde los que sirves. Tanto tuproducto.com como app.tuproducto.com si tienes un sitio de marketing y una app. El dominio raíz y los subdominios son entradas distintas.

Arreglar la lista no repara retroactivamente los eventos a los que ya se les quitaron esos campos: nunca se guardaron. De ahí en adelante, la atribución funciona.

Mira Dominios y referencias.

“Stripe o Google aparecen como fuente de tráfico”

Causa: tu visitante salió de tu sitio hacia un proveedor de pagos o de OAuth y volvió, así que ese proveedor queda como referencia en el regreso. Es real, pero no es adquisición.

Solución: agrega esos hosts a Configuración → Datos → Referencias ignoradas.

Conversiones y eventos

“Mi conteo de conversiones es cero”

Causa 1 — el nombre no coincide. Compara el nombre exacto del evento en Configuración → Tracking contra lo que aparece de verdad en el registro de eventos. sign_up y signup son eventos distintos. Signup y signup también.

Solución: cambia lo que envías, o agrega un alias que mapee el nombre entrante a tu nombre configurado. Los alias se aplican de forma retroactiva, así que un error de tipeo que llevas enviando un mes queda corregido en el momento en que agregas el alias. Mira Alias de eventos.

Causa 2 — configuraste una conversión por página y la ruta no coincide. Las conversiones por página son una coincidencia por prefijo de la ruta. /welcome coincide con /welcome y con /welcome/step-2. No coincide con /app/welcome.

Causa 3 — disparas el evento demasiado pronto. Dispara el evento de conversión solo cuando la acción realmente se completó, no al hacer clic en el botón. Un formulario que falla la validación no debería contar.

“Las vistas de página se ven infladas o muy bajas en mi SPA”

Causa: el SDK engancha pushState y replaceState y deduplica por ruta + query. Eso cubre la mayoría de los routers. No cubre el ruteo por hash, ni un router propio que cambia la vista sin tocar el historial.

Solución: llama a lp.track_pageview() manualmente en tu cambio de ruta. Mira Referencia del SDK.

Si en cambio las vistas se ven infladas, busca un router que dispare tanto pushState como un track_pageview() manual para la misma navegación, o un componente que se reinicialice en cada render.

“Los ingresos muestran 0”

Causa: nunca enviaste $revenue, así que esa columna no existe en tu proyecto. Las columnas vacías se eliminan.

Esto no es un error. Envía ingresos y la columna aparece. Mira Seguimiento de ingresos.

Paneles e insights

“Una tarjeta de insight está vacía”

Causa: la desglosaste por una dimensión que tu sitio nunca envía. Si ningún evento llevó nunca una campaña UTM, esa columna no existe en tu proyecto y no hay nada por lo que agrupar.

Solución: empieza a enviar ese dato —etiqueta los enlaces de tus campañas con parámetros UTM, por ejemplo— o desglosa por una dimensión que sí tengas. Mira Insights y Modelo de datos.

“Las horas se ven corridas”

Causa: el selector Local/UTC cambia solo la visualización. Los buckets siempre se calculan en UTC.

Cambiar a Local reetiqueta el eje sin recalcular qué eventos caen en qué bucket, así que en una zona horaria distinta de UTC las etiquetas aparecen corridas respecto de los límites reales de cada bucket. Es lo esperado. Si necesitas que etiquetas y límites coincidan exactamente, mira en UTC.

Alertas y webhooks

“Mi alerta nunca se dispara”

Causa 1 — el intervalo mínimo. Una regla no se vuelve a consultar más rápido que max(60 segundos, ventana ÷ 4). Por eso una ventana de 24 horas se revisa como mucho cada ~6 horas. Si acabas de crear la regla, puede que simplemente todavía no haya corrido.

Causa 2 — ya está disparada. Las alertas son por flanco: una notificación cuando la condición empieza a cumplirse, y otra cuando se recupera. No hay repeticiones mientras sigue disparada. Si esperas una segunda notificación, no llegará hasta que se recupere y vuelva a saltar.

“Mi alerta se dispara demasiado”

Causa: una ventana muy corta en un sitio de poco tráfico. Una ventana de 5 minutos va a saltar en cualquier período tranquilo normal: noches, fines de semana, un martes lento. Es la regla funcionando tal como está escrita.

Solución: amplía la ventana hasta que refleje un problema real y no la variación de siempre.

Mira Alertas.

“Mi webhook no entrega”

Revisa cada requisito:

Solución: usa Enviar prueba para forzar una entrega, y revisa Actividad reciente para ver la marca de entrega fallida.

Las causas más comunes son un túnel que caducó, un endpoint que devuelve 3xx esperando que se siga la redirección, y un handler que hace trabajo lento en línea en vez de encolarlo y devolver 200 de inmediato.

Mira Webhooks de alertas.

¿Sigues atascado?

Dos cosas resuelven casi todo lo que queda:

1. Abre el registro de eventos y mira el evento crudo. Lo que hay realmente en event_name, path, user_id y properties suele zanjar la duda de inmediato.
2. Vuelve a leer Modelo de datos. Los números que se ven mal muchas veces son correctos bajo una definición que no esperabas: actores contra visitantes es la típica.