Live dashboard, alertas de anomalías y health score

Un ringbuffer por canal con los últimos 50 eventos, 30 días de contadores diarios, un health score 0-10 por canal y un email automático cuando un canal cae un 50 por ciento o se dispara 4 veces. Tres clases que comparten dos opciones autoload=false de wp. Sin nuevas tablas en la base de datos.

Tiempo de lectura: ~5 minÚltima actualización: 2026-05-09

Qué hace

El live dashboard responde a tres preguntas en las que un operador se topa la primera vez que su jefe pregunta: "¿Sigue trackeando Meta?" Tarjeta uno: sí, aquí están los últimos 12 eventos con timestamps y valores. Tarjeta dos: sí, aquí va un gráfico de 7 días por canal para que detectes una línea plana. Tarjeta tres: cada canal tiene un health score 0-10 que se pone rojo, amarillo o verde de un vistazo. Y si algún canal de pronto deja de funcionar o de pronto explota, recibes un email sin tener que mirar el dashboard.

Cómo activar

Nada que activar. El recorder se engancha a bcnr_post_dispatch_event automáticamente cuando arranca la pipeline de tracking (licencia activa, master toggle on). La tarjeta aparece en la pestaña Dashboard de Beaconry la primera vez que aterriza un evento. El cron de anomalías corre a diario en cuanto se han acumulado al menos 14 eventos en la baseline de 7 días, así los pings de prueba durante el setup no disparan alertas.

El destinatario de las alertas es el mismo alert_email que pones en la pestaña Advanced para BCNR_Health. Si quieres una bandeja separada para las anomalías, cambia ese campo y ambas alertas la siguen.

Cómo funciona (bajo el capó)

Tres clases, un storage compartido, un endpoint REST.

  1. Recorder BCNR_Dashboard_Stats. Escucha la action bcnr_post_dispatch_event por canal, dispara una vez por canal por evento después de que la llamada dispatch_* del canal haya devuelto. Escribe en dos opciones autoload=false de wp en cada evento despachado:
    • bcnr_dashboard_recent, ringbuffer de los últimos 50 eventos con channel slug, event_name, timestamp, valor, divisa. Se muestra en la lista de eventos recientes de la tarjeta.
    • bcnr_dashboard_counters, contador-por-canal-por-día + suma de valores, últimos 30 días, prune-on-write. Se muestra como gráfico de 7 o 30 días en la tarjeta.
    Dos llamadas update_option por evento despachado. Trade-off deliberado contra una nueva tabla wpdb, justificado por el perfil de tráfico de Beaconry (muy por debajo de 1k eventos por hora en un sitio cliente real).
  2. Endpoint REST. GET /wp-json/beaconry/v1/dashboard?range=today|7d|30d devuelve el snapshot para la tarjeta. La permission gate es manage_options + nonce wp_rest. El vanilla-JS de la tarjeta en el admin hace polling cada 30 segundos con pausa por visibilitychange (sin tráfico cuando la pestaña está en background). Una segunda ruta DELETE /wp-json/beaconry/v1/dashboard/recent vacía el ringbuffer (los contadores se quedan, el histórico del gráfico se preserva).
  3. Cron diario BCNR_Anomaly. Un evento WP-Cron bcnr_anomaly_check lee los contadores diarios y compara el conteo por canal de ayer contra la media móvil de 7 días de los días 2 a 8 (ayer excluido de la baseline para que una anomalía real no tire la media para abajo ella sola). Caída ≥ 50 por ciento o subida ≥ 4x dispara un email. Dos cinturones de seguridad: una baseline mínima de 14 eventos por 7 días para que los pings de prueba no disparen alertas, y un transient diario bcnr_anomaly_alert:<channel>:<date> con TTL de 23 horas para que no recibas la misma alerta dos veces.
  4. Score por canal BCNR_Health_Score. Función pura for_channel($slug) devuelve 0 a 10 desde tres componentes: Configured (4 puntos si BCNR_Forwarder::has_*() devuelve true para este canal), Active 7d (4 puntos si al menos un evento aterrizó en los últimos 7 días), Stable (2 puntos si el coeficiente de variación de los últimos 7 días es menor que 1, lo que significa volumen diario razonablemente estable). El bucketing por tier mapea a rojo (0 a 3), amarillo (4 a 7), verde (8 a 10) para el badge en cada tarjeta. Sin llamadas a APIs de vendor, todo viene de la misma tabla de contadores intra-WP que escribe el recorder.

Notas por canal

El recorder trata cada channel slug por igual (ga4|meta|tiktok|linkedin|google_ads|microsoft_ads|pinterest|reddit|snapchat|x_ads), así que aparece una tarjeta por cada canal realmente configurado. Los canales que no has configurado no salen en el dashboard, sin barras vacías en cero que ignorar. El tier del health score viene de datos puramente por canal, así que puedes tener una tarjeta de Meta verde junto a una tarjeta de TikTok roja sin que una contamine la otra.

Constantes para power-users

Ninguna. El dashboard se cablea automáticamente. Tres filtros te dejan tunear el detector de anomalías sin tocar los defaults del code:

  • bcnr_anomaly_drop_ratio, default 0.5, fracción de la baseline que dispara una alerta de "drop". Súbelo a 0.7 para alertar ya con un 30 por ciento de caída, bájalo a 0.3 para alertar solo ante un 70 por ciento de caída.
  • bcnr_anomaly_spike_ratio, default 4.0, múltiplo de la baseline que dispara una alerta de "spike". Útil cuando corres un evento de tráfico conocido (Black Friday) y quieres silenciar spikes falsos.
  • bcnr_anomaly_min_baseline, default 14 eventos por 7 días, por debajo del cual un canal se considera "demasiado silencioso para alertar". Súbelo en sitios de alto volumen para evitar alertas ruidosas en canales pequeños.

Troubleshooting

  • "La tarjeta no muestra datos": el recorder dispara con eventos despachados. Verifica que el master toggle esté on (pestaña Dashboard) y que al menos un canal esté configurado (pestaña Tracking). La pestaña Logs mostrará razones de tipo "no dispatch attempted".
  • "Borré los eventos recientes pero el gráfico aún los muestra": el gráfico lee contadores diarios, la lista de eventos recientes lee el ringbuffer. Por diseño son dos stores separados, borrar recent no borra el histórico del gráfico. Para limpiar el gráfico también, el camino que el operador debería tomar es esperar 30 días al prune-on-write natural, o borrar la opción bcnr_dashboard_counters directamente vía WP-CLI.
  • "Recibí una alerta de anomalía para un canal que acabo de desactivar": el detector funciona como se espera (comparación ayer-vs-baseline). El transient diario evita una segunda alerta para el mismo canal el mismo día, y el cron diario verá cero eventos en ese canal a partir de ahora, así que la baseline de 7 días se normaliza en una semana.
  • "Mi health score está amarillo pero el canal funciona": lo más probable es que el componente Stable (CoV < 1) haya fallado por un día atípico. El score se recupera solo según los días salgan de la ventana de 7 días. Configured + Active son los dos componentes que importan para "¿está realmente funcionando?", juntos suman como mucho 8 de 10.
← Modo híbridoMulti-divisa →