Analítica
El embudo de retención de cada recorrido, cómo se cuentan los pasos abandonados y los eventos enviados a ExyliaAnalytics.
Un recorrido existe para retener a los jugadores nuevos, así que ExyliaJourney mide lo bien que lo consigue cada uno.
El embudo
/journeyadmin stats <journey>, FUNNEL en la pantalla de un recorrido, o un clic derecho sobre él en la
lista de recorridos, abre su embudo.
La cabecera muestra el recorrido entero: cuántas veces se inició, completó, saltó y abandonó, su tasa de finalización y el tiempo medio para terminarlo. Debajo, una tarjeta por paso, en orden:
| Dato | Significado |
|---|---|
| Alcanzado | Jugadores que empezaron este paso. |
| Proporción | Alcanzado, sobre los inicios del recorrido. |
| Completado | Jugadores que lo completaron. |
| Tasa de paso | Completado, sobre alcanzado. |
| Saltado | Jugadores que lo saltaron. |
| Abandonado | Jugadores que dejaron de avanzar en él (ver abajo). |
| Tiempo medio | Cuánto se tardó en completarlo, de media. |
El paso que pierde más jugadores se muestra en rojo. Ese es el paso que hay que hacer más claro, más corto o mejor guiado.
Los contadores solo se incrementan, nunca se reescriben, así que varios servidores que comparten una base de
datos construyen juntos un mismo embudo. Cambiar el id de un paso empieza sus contadores de cero; cambiar
su título no.
Pasos abandonados
Un paso cuenta una vez como abandonado cuando pasa abandon-after (config.yml, 7 días por defecto) sin
progreso:
- el jugador se fue y nunca volvió estando en él — los jugadores desconectados se revisan una vez por hora;
- o el jugador sigue jugando pero no hace nada para completarlo.
Un paso que agota su timeout falla: el recorrido se detiene (sus disparadores pueden volver a iniciarlo,
desde el primer paso) y el paso también cuenta como abandonado, con el motivo timeout.
abandon-after: 0s desactiva el abandono por inactividad.
ExyliaAnalytics
Con ExyliaAnalytics instalado, cada recorrido envía sus eventos a la plataforma Exylia Analytics, donde se pueden graficar y convertir en embudos junto al resto de datos del servidor. Sin él no se envía nada y no hay nada que configurar.
| Evento | Cuándo | Propiedades |
|---|---|---|
journey.start | Empieza un recorrido. | journey, total_steps, cause (first_join, join, command, region_enter, npc_click, journey_complete, permission, custom o api) |
journey.step_complete | Se completa un paso. | journey, step, step_number, seconds |
journey.step_skip | Se salta un paso. | journey, step, step_number |
journey.skip | Se salta un recorrido entero. | journey, step, step_number (donde estaba) |
journey.complete | Se completa un recorrido. | journey, seconds |
journey.abandon | Un paso cuenta como abandonado. | journey, step, step_number, reason (idle o timeout) |
journey.stop | Un admin (comando o editor) u otro plugin detiene un recorrido. Agotar el timeout es un abandono, no una parada. | journey, step, step_number, reason (admin o api) |
journey.catalog | Del servidor, uno por recorrido cargado: al arrancar, tras una recarga o un cambio en el editor, y una vez al día. | journey, name (texto plano), steps (ids de los pasos en orden, separados por comas), steps_truncated (solo si los ids no cabían en 200 caracteres), total_steps, triggers (separados por comas), repeatable, skippable |
step_number cuenta desde 1. Las pruebas de un admin no envían nada.
¿Falta algo en esta página? Dínoslo en Discord