Enviar eventos

Los pageviews te dicen que la gente llegó. Los eventos personalizados te dicen qué hizo. Esta página cubre cómo enviarlos.

La llamada básica

lp.track('ticket_purchased', { ticket_type: 'vip', seats: 2 });

El primer argumento es el nombre del evento. El segundo es un objeto opcional de propiedades. Esa es toda la API de eventos — para el resto del tracker mira la referencia del SDK.

El evento sale de inmediato. No lo esperas con await, y una request fallida nunca rompe tu página.

Nombres de evento

El prefijo $ está reservado para eventos integrados. Si llamas lp.track('$algo'), el tracker se niega a enviarlo y avisa en la consola.

Hay exactamente dos eventos integrados:

• $pageview — se dispara al inicializar y otra vez en cada navegación SPA.
• $identify — lo dispara identify().

Todo lo demás en tus datos es algo que enviaste a propósito.

Propiedades

Las propiedades son los detalles que hacen que un evento se pueda responder después: qué plan, cuántos asientos, qué variante. Aparecen en el detalle de fila del log de eventos.

El colector aplica límites duros. Violar cualquiera de ellos rechaza el evento completo, no solo la propiedad culpable. El evento se descarta, así que conviene quedarse bien adentro de los márgenes.

En la práctica nunca te vas a acercar a estos límites con un evento sensato. Si estás chocando contra el techo de 8 KB, seguramente estás mandando una respuesta de API entera como propiedad — manda mejor los tres campos por los que realmente vas a filtrar.

Claves de propiedad reservadas con $

$revenue y $currency son las únicas claves con prefijo $ permitidas. Cualquier otra clave con $ rechaza el evento completo.

lp.track('order_completed', { $revenue: 49.00, $currency: 'USD' });

Los ingresos tienen su propia página — mira tracking de ingresos.

Buenas prácticas

Estos son los hábitos que separan los datos en los que confías de los datos con los que discutes.

Dispara los eventos de conversión solo cuando la acción realmente tuvo éxito

No en el clic del botón. No en el submit del formulario. Después de que la cuenta efectivamente se creó.

// Mal — cuenta gente cuyo registro falló
form.addEventListener('submit', () => {
  lp.track('account_created');
});

// Bien — cuenta gente que tiene una cuenta
const res = await createAccount(payload);
if (res.ok) {
  lp.track('account_created');
}

Un número de conversión inflado es peor que no tener número. Esconde justo la falla —un registro roto— que más necesitas ver, porque el gráfico se sigue viendo sano mientras nadie logra entrar.

Para el primer valor, mejor desde tu backend

Primer valor significa que el usuario obtuvo algo real. Tu backend es donde eso se sabe con certeza: el proyecto se creó, la exportación terminó, la invitación fue aceptada. Dispáralo desde ahí, después de que la operación se completa, con la API del servidor.

Los eventos de primer valor en el cliente se disparan cuando la interfaz cree que algo funcionó. Los del backend se disparan cuando funcionó.

Nunca envíes información personal

Ni emails, ni nombres, ni teléfonos, ni direcciones — ni en las propiedades de eventos ni en identify(). Usa un id interno de usuario.

// No hagas esto
lp.track('plan_upgraded', { email: 'ana@example.com' });

// Haz esto
lp.track('plan_upgraded', { user_id: 'u_8813', plan: 'pro' });

Un id interno responde todas las preguntas que respondería un email, y mantiene los datos personales afuera de un sistema que no los necesita. Mira seguridad para saber qué guarda y qué no guarda LaunchPulse.

Sé consistente, y trata los nombres como permanentes

Elige snake_case y quédate ahí. account_created, no accountCreated en un lado y Account Created en otro — para cualquier herramienta de analítica son tres eventos distintos, y tu embudo se parte en tres.

Un nombre es para siempre, o necesita un alias. Renombrar un evento en tu código parte tu historial en el momento del deploy: los datos viejos bajo el nombre viejo, los nuevos bajo el nuevo. Eso tiene arreglo — los alias de eventos mapean el nombre entrante a tu nombre configurado en tiempo de consulta, sobre todos los datos pasados y futuros — pero el camino más limpio es elegir bien el nombre la primera vez.

Un chequeo rápido antes de fijar un nombre: ¿lo entenderías dentro de seis meses, en un desplegable, sin contexto? Si no, renómbralo ahora que es gratis.

Rastrea los pocos eventos que cambian decisiones

Tienes un tope de 12 eventos rastreados extra en la configuración del proyecto, y eso es una virtud. La mayoría de los productos tiene un puñado de momentos que importan: registro, primer uso real, upgrade, cancelación. Instrumenta esos bien en vez de instrumentar todo mal.

Hacer que los eventos cuenten

Enviar un evento no es lo mismo que medirlo. Cuando tu app ya está mandando un nombre, anda a Ajustes → Tracking y dale un trabajo: conversión, primer valor o uno de los eventos rastreados extra.

El panel Eventos detectados de ahí lista los nombres que tu sitio está enviando y que todavía no están mapeados a nada, con botones de un clic para asignarlos. Es la forma más rápida de cerrar el círculo después de un deploy. Mira alias de eventos para entender cómo funciona ese panel.

Como todo eso es configuración de lectura, puedes enviar eventos ahora y decidir después qué significan. No se pierde nada mientras te decides.

Qué sigue

• Conversiones y activación — convertir un evento en tu métrica de éxito
• Alias de eventos — reconciliar nombres que no coinciden
• Tracking de ingresos — $revenue y $currency
• Referencia del SDK — todos los métodos del tracker
• Log de eventos — ver qué llegó