Esta tabla contiene registros de los trackings implementados en los Bots, existiendo únicamente después de la implementación durante el desarrollo del contacto inteligente para la generación de los datos.
Normalmente, los trackings se registran en los enrutadores, pero para clientes que no tienen un contexto de router activo, los datos se generan en cada subbot. Recomendamos activar el contexto de enrutador en caso de que aún no se esté utilizando.
Latencia nominal: 5 minutos
Latencia máxima: 15 minutos
Objeto: clients_trustedzone.deltashare_core.eventtracks
Retención: 3 días (D-0, D-1, D-2)
Carga histórica inicial (en objeto separado): 360 días
La carga histórica debe combinarse con Blip para su disponibilidad; el objeto permanece disponible durante 7 días para su ingestión.
Utilizando eventtracks para análisis
Cálculo en Eventos o en Usuarios Únicos:
Para construir métricas, es importante comprender la diferencia entre contabilizar eventos y contabilizar por usuarios únicos.
Las métricas por U.U. generalmente se utilizan para comprender la expansión de la base; sin embargo, para entender el recorrido del contacto inteligente, recomendamos calcular en base a eventos. Analicemos un ejemplo para que quede más claro:
Supongamos que un usuario haya accedido al bot cuatro veces en un día, intentando contactar con un agente y logrando hacerlo solo una vez.
Si calculamos la tasa de desvío (transfer) por usuario, tendremos:
Tasa de desvío = (1 usuario desviado) / (1 usuario que inició la conversación) = 100%
Es fácil notar cómo esta forma de cálculo representa una métrica de vanidad, donde el resultado parece espectacular, pero no refleja la verdadera dificultad del usuario para ser atendido.
La mejor manera de construir esta métrica es considerar los eventos, resultando en:
Tasa de desvío = (1 desvío efectivo) / (4 conversaciones iniciadas) = 25%
Definiendo el inicio de una conversación/jornada
Esta definición ocurrirá de acuerdo con la regla de su contacto inteligente. Algunas prácticas comunes son: la suma de los eventos que marcan el inicio de conversaciones (menús principales, onboarding, entradas, etc.), DAUs (usuarios únicos por día).
En algunos casos se definen puntos del flujo donde se genera un nuevo código que marca una nueva sesión; este dato puede registrarse como un extra de los eventos, permitiendo así contar las conversaciones iniciadas.
Análisis en el roadmap de la documentación
Embudo de Jornada: debe desarrollarse a partir de las categorías implementadas, realizando una correspondencia (mapping) de los puntos macro de los flujos.
Utilizar los extras de los trackings como filtros globales de jornada.
Entradas inesperadas en el menú: asociación con messages para identificar mensajes no comprendidos.
Abandono: desarrollado a partir de trackings, deben observarse los puntos donde el usuario interrumpe la jornada.
Para obtener más información, acceda a la discusión sobre el tema en nuestra comunidad o los videos en nuestro canal. 😃