> ## Documentation Index > Fetch the complete documentation index at: https://developers.argosidentity.com/llms.txt > Use this file to discover all available pages before exploring further. # Recorrido de sesión > Rastrea cronológicamente todo el proceso por el que pasa un envío en el formulario en vivo e interpreta por qué un usuario se encontró con un resultado o error específico. ## Qué es el Recorrido de sesión El Recorrido de sesión (Session Journey) es una función del panel que **reúne todos los eventos ocurridos desde el momento en que un usuario entra en el formulario en vivo hasta el resultado final (aprobado, rechazado o en espera), agrupándolos cronológicamente como una sola unidad de envío**. Cada evento se recopila tanto en el frontend (la acción observada en la pantalla del usuario) como en el backend (la verificación y la decisión ejecutadas en el servidor). Esto permite rastrear "**por qué** este usuario se bloqueó en este paso" y "cuál fue el motivo del rechazo o de la espera". A diferencia del [registro de eventos](/dashboard/es/event), que rastrea la actividad de los administradores y el historial de eliminaciones, el Recorrido de sesión se centra en **el avance de la verificación de un solo envío**. ## Estado de la sesión En la lista del Recorrido de sesión, cada envío muestra de un vistazo su grado de avance mediante su **estado de la sesión**. Este estado es un valor distinto de la decisión final de KYC (aprobado, rechazado o en espera); indica hasta dónde ha avanzado el recorrido. | Estado | Significado | | ------------- | -------------------------------------------------------------------------------------------------------------------- | | `IN_PROGRESS` | En curso — aún no ha llegado al resultado final | | `COMPLETED` | Completado — el usuario terminó el recorrido hasta el final (el resultado puede ser aprobado, rechazado o en espera) | | `DROPPED` | Abandono — el usuario se marchó sin completar el recorrido (no llegó a la página de resultado final) | | `ERROR` | Error — salió del flujo normal, por ejemplo a través de una página de error | `COMPLETED` solo significa "completó el recorrido hasta el final"; no significa "fue aprobado". Confirma siempre el estado final de aprobado, rechazado o en espera con los eventos de decisión del BE (`APPROVED`, `REJECTED`, `PENDING`). ## Precauciones clave al interpretar **Los eventos se enumeran cronológicamente, pero en realidad muchas verificaciones se ejecutan de forma simultánea.** Que los eventos aparezcan de arriba abajo en la pantalla no significa que "el evento anterior sea la causa del posterior". Por ejemplo, el reconocimiento del documento de identidad, la prueba de vida y la verificación de edad se ejecutan casi al mismo tiempo, y el orden de visualización solo refleja pequeñas diferencias en el momento del registro. **Juzga la relación causal a partir del valor de resultado y del impacto en el usuario de cada evento, no del orden.** ## Eventos del frontend (FE) y del backend (BE) Los eventos del Recorrido de sesión se dividen en dos tipos según su origen. | Origen | Significado | Ejemplos | | ----------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | **FE (frontend)** | Señales observadas sobre las pantallas y acciones que vio el usuario | Entrada a la pantalla, activación de la cámara, entrada a la página de error | | **BE (backend)** | Verificación, decisión y finalización reales ejecutadas en el servidor | Reconocimiento del documento de identidad, comparación de rostros, aprobación/rechazo final | **El criterio real de bloqueo o rechazo son siempre los eventos del BE.** Los eventos del FE (por ejemplo, `ERROR_PAGE_VIEWED`, `FINAL_PAGE_VIEW`) son solo una observación de que el usuario llegó a esa pantalla; el resultado final debe confirmarse con los eventos de decisión del BE (`APPROVED`, `REJECTED`, `PENDING`) del mismo envío. El FE y el BE a veces registran la misma acción como un par. Por ejemplo: `FRONT_SESSION_START` (FE) ↔ `SESSION_CREATED` (BE), `CREATE_FLOW` (una llamada a la API desde una pantalla del FE) ↔ `FLOW_ID_ISSUED` (resultado del procesamiento del BE). El FE muestra "qué hizo la pantalla", mientras que el BE muestra "cómo decidió el servidor". ## Etapas del recorrido El Recorrido de sesión fluye a grandes rasgos a través de tres segmentos: **Verificaciones previas → Principal → Posterior**. Es la etapa de control (Guard) previa a la verificación principal, que incluye la creación de la sesión y las comprobaciones de token, duplicados, IP y dispositivo. Si un usuario se detiene en este segmento, no puede entrar en la captura del documento de identidad y queda bloqueado (BLOCKED). Las verificaciones relacionadas con el documento de identidad se ejecutan de forma simultánea: captura del documento, reconocimiento OCR, prueba de vida, edad, caducidad, lista negra, etc. Si se superan, se crea un envío (Submission). Solo ocurre en los proyectos que requieren verificación basada en la cuenta, como las transferencias de 1 won o la consulta del nombre del titular de la cuenta. Las verificaciones relacionadas con el rostro se ejecutan de forma simultánea: prueba de vida del selfie, comparación de rostros, duplicados, verificación de autenticidad gubernamental, políticas personalizadas, etc. Se agregan todos los resultados de las verificaciones para finalizar el envío como aprobado, rechazado o en espera, y el resultado se notifica por webhook y correo electrónico. El usuario llega a la página de resultado y el recorrido finaliza. ## Las tres decisiones finales Cuando termina el segmento principal, el envío siempre se finaliza como una de las tres opciones siguientes. Superó todas las verificaciones y se aprobó automáticamente. Sin motivo aparte. Rechazado por fallo de verificación/política o por superar el límite de reintentos. El motivo se distingue mediante el valor `reason`. Se suspende el juicio automático y se requiere una revisión manual. El motivo se distingue mediante el valor `reason`. Para los códigos de motivo concretos de rechazo y espera, consulta la tabla "Motivos de la decisión final" en la [referencia de eventos del Recorrido de sesión](/dashboard/es/session-journey/event-reference). ## Interpretar las causas de los errores Cada evento muestra un **impacto en el usuario (User Impact)**. Este valor indica qué impacto experimentó realmente el usuario, por lo que es lo primero que se debe comprobar al interpretar un error. | Impacto en el usuario | Significado | | --------------------- | ------------------------------------------------ | | `NONE` | Sin impacto (avance normal o evento de registro) | | `BLOCKED` | Bloqueado — el flujo normal se interrumpió | | `RETAKE` | Solicita repetir la captura o reintentar | | `PENDING` | En espera — a la espera de revisión manual | | `REJECTED` | Rechazado — finalizado como rechazo final | | `APPROVED` | Aprobado | | `COMPLETED` | El paso correspondiente se ha completado | El orden para interpretar los errores: **① Comprueba primero los eventos de decisión final (`APPROVED`, `REJECTED`, `PENDING`) y su `reason` → ② Encuentra los eventos de verificación del BE que provocaron un impacto `BLOCKED` o `RETAKE` en el mismo paso → ③ Usa los eventos de observación del FE para confirmar de forma complementaria la pantalla que vio el usuario.** No los leas de arriba abajo en el orden mostrado. Para la lista completa de eventos y sus significados, consulta la [referencia de eventos del Recorrido de sesión](/dashboard/es/session-journey/event-reference).