Reglas de captura

Para qué sirve#

Una regla de captura dice: "cuando llegue un pedido que cumpla estas condiciones, creá un evento de negocio con estos datos". Un evento de negocio es el registro de algo que pasó en tu operación: un turno reservado, un pago rechazado, una cancelación.

Con esto armás eventos a partir de lo que tu sistema ya hace, sin pedirle a nadie que programe. Los eventos aparecen en los dashboards y en Explorar.

La pantalla es Reglas de captura (menú Configuración, sección Datos).

Cuándo usarlo#

• Tu sistema no manda un evento para algo que querés contar (por ejemplo, el pago de un turno).
• Querés resaltar situaciones malas, como un pago rechazado.
• Querés que Lymen arme solo las métricas de negocio (ventas, reservas, cancelaciones) a partir de esos eventos.

Probar, crear, editar, pausar y activar reglas pueden los roles Administración y Sistemas. Borrar una regla, solo Administración. El resto la ve en modo lectura.

La pantalla#

La pantalla tiene dos vistas (el selector aparece si podés editar):

• Reglas: las reglas que creaste. Una fila por regla con Evento, Cuándo, Estado y Últimas 24 h (cuántos eventos creó y su evolución).
• Eventos que ya llegan: los eventos que ya manda el código de tu sistema (no salen de reglas), en los últimos 7 días. Ahí le decís a Lymen qué significa cada uno (una venta, una reserva, una cancelación) y cuál de sus datos es el monto, la moneda o el canal. Con eso Lymen arma las métricas de negocio y los atajos de "Empezar rápido" al agregar un gráfico a un dashboard. Podés confirmar una sugerencia con un clic, Guardar significado o Quitar significado.

Al tocar una fila se abre el detalle: cuántos eventos en las últimas 24 h, cuándo fue el último, qué significa, cuándo se crea y qué guarda. Desde ahí podés Editar, Pausar o Activar, Duplicar, Ver la regla completa y Borrar (con confirmación).

Estados de una regla#

Las reglas con error se muestran primero, después las activas y al final las pausadas.

Cómo se configura, paso a paso#

Tocá Nueva regla. El editor tiene cinco pasos.

1. Evento#

1. Nombre técnico: cómo se llama el evento adentro, con formato entidad.accion en minúsculas (por ejemplo pago.rechazado).
2. Cómo se muestra: el nombre que ves en pantalla (por ejemplo "Pago rechazado").
3. Evento negativo: marcalo si es algo malo; se resalta en los paneles de eventos de los dashboards.
4. Qué significa este evento: elegí una de las opciones (ver tabla de campos). Con esto Lymen arma solas las métricas de negocio.
5. Descripción para tu equipo (opcional): por ejemplo "el banco rechazó el pago del turno".

2. Cuándo#

Armá las condiciones que tiene que cumplir un pedido para generar el evento. Tienen que cumplirse todas. Podés elegir una de las "Rutas que ya están llegando" para no tipear.

3. Campos a guardar#

Elegí qué datos del pedido se guardan dentro del evento. Cada campo tiene un nombre dentro del evento, de dónde sale, una clave y, si querés, un significado (monto, moneda, canal o sesión). Podés tocar los datos disponibles para agregarlos. Sin campos, el evento igual se guarda con la hora, el servicio y el link a lo que pasó.

4. Probar#

Tocá probar. Te dice cuántos eventos hubiera creado la regla en las últimas 24 horas y muestra hasta 10 ejemplos, con un link "Ver qué pasó" a cada pedido. No se puede guardar sin probar, y si cambiás la regla hay que probar otra vez.

5. Guardar#

Opcionalmente marcá Aplicar también a los últimos 7 días para crear los eventos que hubieran coincidido en el pasado. Después tocá Guardar y activar (o Guardar cambios si estás editando). Las reglas se activan en unos segundos.

Tabla de campos#

Evento#

Significados disponibles:

Cuándo (condiciones)#

Hasta 8 condiciones por regla, sin repetir ninguna. Por defecto una regla nueva arranca con "Ruta es (vacío)" y "Método es POST".

Impacto: condiciones muy amplias (por ejemplo, solo Método es GET) crean muchísimos eventos. Si la prueba estima más de 200.000 eventos, aparece un aviso: sumá condiciones para quedarte con lo que importa. Más eventos significa más almacenamiento y más ruido en los dashboards.

Campos a guardar#

Hasta 20 campos por regla.

Protecciones:

• Los headers de credenciales nunca se guardan: authorization, proxy-authorization, cookie, set-cookie, x-api-key y x-auth-token.
• Si Privacidad borra un campo (por ejemplo, con una regla "No guardar"), ese campo aparece tachado y no se puede usar acá, con un link para habilitarlo en Privacidad.
• Los campos del body solo están disponibles si tu sistema los manda junto con el pedido. Si no, pedile a quien programa la app que los agregue como datos del pedido.
• Los datos que sí se guardan pasan por las reglas de Privacidad.

Guardar#

Topes generales#

Qué pasa cuando activás una regla#

• Lymen mira las trazas guardadas cada 30 segundos y crea un evento por cada pedido que cumple la regla. Un pedido genera un solo evento por regla.
• Además, la regla le avisa al agente de tu red que guarde siempre las trazas que coinciden. Así se ve el 100 % de esos pedidos y no solo la muestra (ver Muestreo).
• Costo: guardar siempre esas trazas suma almacenamiento. Si la regla es muy amplia, cuesta más. Cuidá las condiciones.
• Hasta que el agente confirme el cambio (estado Activándose), solo se capturan los pedidos cuyas trazas ya se guardaban.
• Los cambios valen desde que guardás. Los eventos ya capturados no cambian, salvo que marques la carga de los últimos 7 días.
• Pausar una regla la deja de ejecutar sin perder la configuración ni los eventos creados. Los eventos de una regla pausada siguen contados en las métricas.
• Borrar una regla es definitivo y solo lo hace el rol Administración. También se quita el significado que le habías dado al evento. Si la necesitás de nuevo, hay que crearla otra vez.

Ejemplos#

Pago rechazado (el banco rechazó el pago de un turno):

• Nombre técnico: pago.rechazado
• Cómo se muestra: Pago rechazado, marcado como evento negativo
• Significa: Venta rechazada
• Cuándo: Método es POST, Ruta es /api/pagos, Respuesta es 402
• Campos: monto (del dato del pedido, significa Monto), canal (del header x-canal, significa Canal)

Reserva de turno:

• Nombre técnico: turno.reservado, significa Reserva confirmada
• Cuándo: Método es POST, Ruta empieza con /api/turnos, Respuesta está entre 200 y 299
• Campo: especialidad (parámetro de la URL)

Errores de un servicio: Servicio es turnos-api y Terminó con error es sí, para contar cuántos pedidos fallan.

Problemas comunes#

• "Primero probá la regla". El botón de guardar se habilita después de probar. Si cambiás algo, probá de nuevo.
• La prueba dice que no hubo pedidos. Revisá la ruta, el método y el status. Elegí una de las "Rutas que ya están llegando".
• "Tu sistema ya manda ese evento". Ese nombre ya existe en el código de tu sistema. Elegí otro para no contarlo dos veces.
• "Ya hay otra regla que crea ese evento". El nombre técnico no se puede repetir entre reglas.
• "Como mucho 30 reglas". Llegaste al tope. Borrá o juntá reglas.
• La prueba dice que los ejemplos salen de lo guardado. La prueba cuenta sobre las trazas que se guardaron, que no son todas. Desde que activás la regla se guardan todas las que coinciden.
• Un campo no vino en ningún ejemplo. Revisá de dónde sale.
• Un campo aparece tachado. Privacidad no deja guardarlo. Habilitalo en Privacidad.
• Esperá un minuto antes de volver a probar. La prueba tiene un límite de uso por minuto.
• Estado Error con el agente de tu red. El cambio no llegó al agente. Los eventos se crean igual, pero con menos cobertura. Verificá que el agente esté conectado y volvé a guardar.
• No veo el botón Nueva regla. Tu rol no tiene permiso. Pedíselo a alguien con rol Administración.
• Los eventos no aparecen enseguida. Se leen cada 30 segundos y hay una demora corta para esperar que lleguen las trazas completas.

Para ver cómo se transforman los datos antes de guardarse, mirá Procesamiento; para el costo de guardar, Almacenamiento.