> For the complete documentation index, see [llms.txt](https://academy.gopersonal.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.gopersonal.ai/guia-de-usuario/analytics/journeys/cambios-en-el-analisis-de-journeys-septiembre-2026.md).

# Cambios en el análisis de journeys (Septiembre 2026)

A partir de septiembre de 2026, el análisis de user journeys se actualiza para brindar una visión más precisa y accionable del rendimiento de cada flujo. La nueva versión corrige limitaciones históricas en la forma de determinar el estado de las ejecuciones, incorpora el detalle de las notificaciones por canal y suma una atribución de compras configurable, alineada con la del resto de los módulos de Analytics.

Esta evolución permite entender no solo cuántas ejecuciones se iniciaron, sino cómo terminaron, qué pasó con cada mensaje enviado y qué compras se le pueden atribuir al journey bajo distintos criterios.

### Nueva forma de determinar el estado de las ejecuciones

Este es el cambio más importante, y el que explica por qué los números pueden diferir de los del dashboard anterior.

**Antes de septiembre de 2026:**

* El estado de una ejecución se leía de un único campo que guardaba **el último valor escrito**.
* En journeys con caminos paralelos —A/B testing o condiciones con varias ramas— todas las ramas escribían sobre ese mismo campo, por lo que el estado final dependía de cuál terminaba último.
* Una rama que terminaba sin pasar por un componente **Terminar** quedaba marcada como en ejecución de forma permanente.
* Los estados no cerraban entre sí: las cantidades de iniciados, completados y cancelados no eran comparables.

**A partir de septiembre de 2026:**

* El estado se deriva de los **pasos efectivamente ejecutados**, y no de un campo de estado.
* Los contadores **reconcilian**: Completados + Cancelados + En curso = Iniciados.
* Todas las métricas de estado se calculan sobre las ejecuciones **iniciadas dentro del período**, siguiendo su desenlace aunque ocurra después del final del rango. Responden a la pregunta "de las que entraron en el período, cuántas terminaron".
* Las ejecuciones abandonadas porque el cliente volvió a entrar al mismo journey se excluyen de todas las métricas, evitando que inflen los conteos.

{% hint style="warning" %}
Como consecuencia de este cambio, las cantidades de completados y cancelados pueden diferir respecto de lo que mostraba el dashboard anterior para un mismo período. La medición nueva es la correcta: la anterior sobrecontaba o subcontaba según la estructura de cada journey.
{% endhint %}

### Nuevas métricas de ejecución

* **En curso:** ejecuciones que arrancaron en el período y todavía no llegaron ni a Terminar ni a Cancelar. Antes no era posible distinguirlas.
* **Tasa de completitud:** porcentaje de completados sobre iniciados, disponible tanto en el total como por journey.

### Análisis de notificaciones

**Antes de septiembre de 2026:** solo se contaba el total de notificaciones enviadas, sin desglose por canal ni por resultado del envío.

**A partir de septiembre de 2026:**

* Métricas de rendimiento: **Enviadas**, **Tasa de entrega**, **Tasa de apertura**, **Tasa de clicks** y **CTOR**.
* **Filtro por canal** —Email, App Push, Web Push— aplicado a las métricas y a su evolución en el tiempo.
* Distinción entre **Descartadas** —no se intentaron enviar por frequency capping, opt-out, rebote previo, reclamo de spam o falta de canal— y **Errores** por fallas técnicas. Antes ambos casos eran indistinguibles.
* Evolución diaria de enviadas, aperturas, clicks, descartadas y errores.

### Atribución de compras configurable

**Antes de septiembre de 2026:**

* El revenue se calculaba con una ventana fija de una semana posterior a la finalización del journey.
* La única métrica comercial era el revenue, acompañado de una tasa de conversión.
* No era posible elegir el criterio de atribución.

**A partir de septiembre de 2026:**

* **Tres tipos de atribución:** journey completado, apertura de notificación y click en notificación.
* **Cuatro ventanas de atribución:** mismo día, 1 día, 7 días y 14 días.
* Nuevas métricas de compras: **Compras**, **Productos**, **UPT**, **Revenue**, **AOV** y **AIV**, con su evolución en el tiempo.
* Cada compra se cuenta **una sola vez** y se atribuye al último evento dentro de la ventana, de modo que dejan de duplicarse compras entre journeys o entre notificaciones del mismo flujo.
* El criterio aplicado se muestra siempre en pantalla, para evitar comparar lecturas hechas con configuraciones distintas.

### Nuevas vistas

* **Listado de journeys:** todos los journeys con al menos una ejecución iniciada en el período, ordenables por cualquier métrica, para compararlos entre sí y filtrar el dashboard por uno en particular.
* **Embudo del journey:** los conteos del período pintados sobre cada nodo del workflow, con el detalle de envíos, aperturas y clicks en los componentes de notificación. Permite ver en qué punto del flujo se caen las ejecuciones.
* **Ficha del journey:** estado, autoría y accesos directos al embudo y a la edición del flujo.

### Otras mejoras

* Los datos se calculan con la **zona horaria configurada en el proyecto**.
* Persistencia del rango de fechas entre pantallas de análisis.
* Mejoras de performance en la carga de las métricas.
* El dashboard anterior sigue disponible desde el menú **Acciones**, en la opción **Analytics (deprecado)**.

{% hint style="warning" %}
Las notificaciones enviadas **antes** de que se comenzara a registrar el resultado del envío no pueden clasificarse como enviadas ni descartadas. Se incluyen en el total, pero no en las métricas que dependen del resultado, por lo que la tasa de entrega de períodos anteriores a este cambio puede aparecer más baja de lo real.

El resto de las métricas mantiene compatibilidad con los datos históricos.
{% endhint %}