Alias de eventos y descubrimiento
Mapear los nombres de evento que tu sitio realmente envía a los nombres que configuraste.
Tarde o temprano tu código y tu configuración no se ponen de acuerdo sobre cómo se llama algo. Tu app envía sign_up; tú configuraste account_created. Tu conteo de conversiones se queda en cero y técnicamente nada está roto.
Los alias arreglan eso sin necesidad de un deploy.
El panel de descubrimiento
Antes de que salgas a buscar un desajuste, LaunchPulse te lo muestra. En Ajustes → Tracking hay un panel Eventos detectados:
Your site is sending these, but they aren’t mapped to anything yet (last 30 days).
Lista los nombres de evento que tu sitio está enviando de verdad y que no figuran en ninguna parte de tu configuración. Concretamente, un nombre aparece acá cuando:
- no es tu evento de conversión,
- no es tu evento de primer valor,
- no está en tus eventos rastreados extra,
- no es ya un alias,
- y no es un evento integrado con prefijo
$.
Cada fila muestra el nombre del evento y cuántas veces llegó. A la derecha, botones de un clic:
| Botón | Qué hace |
|---|---|
| Conversion | Fija ese nombre como tu evento de conversión |
| Primer valor | Fija ese nombre como tu evento de primer valor |
| Track | Lo agrega a tus eventos rastreados extra |
| Alias a… | Lo mapea a un nombre que ya tienes configurado |
El desplegable Alias a… ofrece tu evento de conversión, tu evento de primer valor y tus eventos rastreados — los nombres que ya significan algo en tu proyecto.
Cuando todo está contemplado, el panel dice:
Nada sin mapear — todo lo que envía tu sitio está contemplado.
Ese es el estado que quieres después de la configuración inicial. También es algo útil para mirar de reojo después de un deploy: un nombre nuevo acá significa que alguien lanzó un evento que todavía nadie está midiendo.
Qué hace un alias
Un alias mapea un nombre entrante → tu nombre configurado. El nombre entrante es lo que envía tu código; el configurado es lo que pusiste en ajustes.
Los alias se aplican en tiempo de consulta. Ese es todo el truco, y tiene consecuencias que vale la pena decir sin vueltas:
- El alias funciona sobre todos los datos pasados y futuros, de inmediato. Los eventos que llegaron el mes pasado con el nombre viejo empiezan a contar en el momento en que guardas.
- No se reescribe nada en el almacén de eventos. Tus eventos crudos conservan sus nombres originales — vas a seguir viendo
sign_upen el log de eventos. - Sin reinstalar, sin reenviar, sin backfill.
Por dentro, tu nombre configurado se expande a una coincidencia con ese nombre más todos sus alias. En todos los lugares donde se cuenta el nombre configurado, los alias se cuentan también: el dashboard Pulse, las métricas de conteo de eventos en insights y el conteo de las alertas.
Esto último importa. Una alerta sobre tu evento de conversión también se dispara con los nombres aliaseados, así que no te queda un hueco silencioso de alertas mientras un renombre se abre paso por tu código.
Cuándo usar uno
Un renombre partió tu historial
Lanzaste signup durante seis meses y después lo renombraste a account_created. Ahora tu embudo tiene un precipicio en la fecha del deploy.
signup → account_created
Un alias y el historial vuelve a estar entero. Es la razón más común por la que se recurre a un alias, y es donde el comportamiento en tiempo de consulta más se luce: el arreglo es instantáneo y retroactivo.
Varias plataformas usan nombres distintos
Tu app de iOS envía ios_purchase, tu web envía web_purchase y quieres un solo número.
ios_purchase → purchase_completed
web_purchase → purchase_completed
Los dos apuntan al mismo nombre configurado. Tu conteo de conversiones es la suma, y todavía puedes separar las plataformas en el log de eventos porque los nombres crudos quedan intactos.
Una herramienta de terceros nombra a su manera
Alguna herramienta de tu stack dispara eventos que no puedes renombrar: un widget de checkout, un constructor de formularios, un SDK móvil. Aliasea su nombre al tuyo y deja de pensar en eso.
Administrar los alias
El panel lista cada alias activo como entrante → destino, con un botón Remove.
| Regla | Valor |
|---|---|
| Máx. alias por proyecto | 24 |
| Eliminar un alias | Selecciona un destino vacío |
Veinticuatro alcanza de sobra para los casos honestos: renombres, separación por plataforma, nombres de terceros. Si estás rozando ese techo, el problema real probablemente sea la disciplina de nombres en el código, no que te falte un lugar de alias. Los alias son para reconciliar historial que no puedes cambiar; de acá en adelante, nombra los eventos de forma consistente y no los vas a necesitar.
¿Alias o renombre?
Si puedes cambiar el código, cambiarlo es más limpio: un solo nombre, sin indirección, nada que la próxima persona tenga que descubrir. Pero parte tu historial en el deploy, así que normalmente vas a querer hacer las dos cosas: renombrar en el código de acá en adelante, y aliasear el nombre viejo al nuevo para que el pasado siga contando.
Si no puedes cambiar el código —herramienta de terceros, una versión de tu app móvil todavía dando vueltas, un cliente que no controlas— el alias es la respuesta completa.
Ten en cuenta que las versiones viejas de tu app móvil van a seguir enviando el nombre viejo mientras la gente las use. El alias sigue funcionando todo ese tiempo, sin que tengas que coordinar tu calendario de releases con tu analítica.
Qué sigue
- Conversiones y activación — los nombres a los que apuntan los alias
- Enviar eventos — nombrar eventos para necesitar menos alias
- Ajustes del proyecto — el resto de la pestaña Tracking
- Log de eventos — ver los nombres crudos, sin aliasear