Un dashboard de conversiones en vivo dentro de WP-Admin

El tracking server-side mueve el despacho a PHP, lo cual es estupendo para la inmunidad al adblock y terrible para la visibilidad. No puedes abrir DevTools y observar un POST servidor-a-servidor. Así que Beaconry registra lo que envía en dos almacenes compactos dentro de tu propia base de datos, puntúa cada canal de 0 a 10 y te envía un correo en el momento en que el volumen de un canal se desploma o explota. El objetivo es simple: entérate de un pixel roto desde tu propio WP-Admin, no por un representante de Meta cuando la campaña lleva dos días desperdiciando dinero.

El agujero de visibilidad que abre el server-side

Con un pixel de navegador, depurar está a una pestaña Network de distancia. Haces clic en comprar, observas el request a la plataforma dispararse, lees el payload, ves volver el 200. Mueve el despacho al server-side y esa ventana se cierra. La conversión ahora abandona tu instalación de WordPress como un wp_remote_post en segundo plano con blocking => false, de modo que ni siquiera el proceso PHP que lo originó espera la respuesta. El navegador del visitante ya regresó. Nada en el navegador habló jamás con la plataforma.

Esa es exactamente la propiedad por la que pagaste con el server-side. También es la razón por la que un pixel roto puede pasar inadvertido durante días. Si un proveedor deja de aceptar tus eventos sin avisar, o un token expira, o una capa de caché se come la cookie de consentimiento de modo que el endpoint REST nunca se llama, el único síntoma visible es "las conversiones en la plataforma se fueron a cero", y eso tiendes a descubrirlo cuando alguien pregunta por qué la campaña dejó de optimizar. La respuesta de Beaconry es registrar lo que despacha, donde puedas verlo, y alertarte cuando el volumen deja de verse normal.

Qué se registra y dónde

Hay un único hook que se dispara una vez por canal, justo después de que retorna la llamada de despacho de cada canal:

do_action( 'bcnr_post_dispatch_event', $channel, $event );

Un evento que se reparte hacia GA4 y Meta dispara esto dos veces, una por canal, que es la unidad correcta: "cuántas conversiones vio Meta hoy" es una pregunta por canal. BCNR_Dashboard_Stats escucha en esa action y escribe dos estructuras en wp-options con autoload=false. Sin nueva tabla en la base de datos, dos llamadas update_option por evento despachado:

• El búfer circular reciente (bcnr_dashboard_recent): los últimos 50 eventos de todos los canales. Cada entrada guarda el timestamp, el canal, el nombre del evento tal como se envió de verdad al proveedor (de modo que un mapeo híbrido de Meta muestra ViewContent, no el nombre interno de GA4), el valor y la moneda, la moneda original si Multi-Currency la reescribió, y una cadena de contexto.
• Los contadores por canal y por día (bcnr_dashboard_counters): un conteo y una suma de valor por canal por día, conservados durante 30 días con poda al escribir, de modo que la opción nunca crece sin límite. Esta es la serie de la que leen las cards, los sparklines, el health score y el mailer de anomalías.

La cadena de contexto es lo que hace legible la tabla de conversiones recientes en lugar de un muro de "page_view". Beaconry la resuelve por orden de prioridad: gana una etiqueta de formulario (puesta por la capa de formularios), luego un número de pedido para una compra de WooCommerce / EDD / SureCart (renderizado como #1482), y en otro caso la ruta de página de la que vino el evento. De un vistazo distingues una compra en #1482 de un lead del formulario de contacto de un pageview en /pricing/.

Esto es un compromiso deliberado y documentado sobre la regla original de "sin escrituras en la BD por evento". La justificación es el perfil de tráfico: una instalación real de Beaconry se mantiene muy por debajo de mil eventos por hora, ambas options están excluidas del bundle autocargado de modo que nunca tocan una carga de página normal, y una segunda migración para una tabla de dashboard no valía el coste. Dos escrituras de opción por evento compran toda la superficie de observabilidad.

El panel de conversiones recientes

La pestaña Dashboard lee una única ruta REST solo para admins:

GET /wp-json/beaconry/v1/dashboard?range=today|7d|30d

Requiere la capability manage_options y un nonce wp_rest válido enviado como X-WP-Nonce, de modo que el snapshot nunca queda expuesto a un visitante no autenticado. El JS vanilla de la card lo consulta cada 30 segundos y se pausa en visibilitychange, de modo que una pestaña de admin en segundo plano no machaca el endpoint. Sin jQuery, sin framework, sin librería de gráficos de terceros: los sparklines son los conteos por día que el snapshot ya lleva.

El panel responde la pregunta que DevTools solía responder para el pixel de navegador: "lo que configuré, ¿está disparándose de verdad, justo ahora, con los valores que espero?" Ves una compra de prueba aterrizar en la tabla dentro de un ciclo de consulta, confirmas que el valor y la moneda son correctos, confirmas que se repartió a cada canal que activaste. Si Multi-Currency está activo ves la conversión como 92.59 EUR (USD), el valor normalizado con la moneda original anotada, de modo que puedes verificar que el tipo del BCE hizo lo que querías.

El health score de 0 a 10

Cada card de canal lleva un health score, y lo importante es entender lo que no es. No es una métrica de proveedor. Hace cero llamadas extra a la API. Se calcula por completo a partir de la misma tabla de contadores interna de WordPress, por lo que es lo bastante barato como para calcularse en cada snapshot. BCNR_Health_Score::for_channel() suma tres componentes ponderados en un entero de 0 a 10:

• Configurado (4 puntos): ¿tiene el canal credenciales conectadas? Esto lee a través de exactamente las mismas gates has_*() que usa el despachador, de modo que el score nunca puede discrepar con la visualización de configuración en vivo. Un canal sin configurar no está "roto", simplemente está sin terminar, y el score refleja que dijiste que lo querías y no has completado el setup.
• Activo en los últimos 7 días (4 puntos): al menos un evento despachado en la semana anterior. Esta es la señal más útil de todas. Un canal configurado que lleva siete días en silencio es la forma clásica de un pixel roto o de un token que el proveedor dejó de honrar sin avisar, el tipo de fallo que la sonda de salud del token no siempre detecta porque la credencial sigue pareciendo válida.
• Estable (2 puntos): el coeficiente de variación de los conteos de 7 días está por debajo de 1,0. El CoV es la desviación estándar dividida por la media. Por debajo de 1 significa que el volumen de un día a otro es razonablemente parejo; por encima de 1 significa que días sueltos dominan la serie, que es la firma de una rotura intermitente (una capa de caché que pierde eventos en los días de cache-miss, un banner de consentimiento que se dispara de forma inconsistente).

El score se clasifica en un punto de color vía tier(): de 0 a 3 es rojo (roto o sin configurar), de 4 a 7 es amarillo (funciona pero tiene problemas), de 8 a 10 es verde (sano). Un canal configurado que dispara volumen diario estable aterriza en 10. Un canal configurado que se quedó en silencio cae a 4, casi rojo, que es la advertencia que quieres antes de que la campaña pase hambre.

Hay un segundo indicador, más simple, junto al score: un punto de estado de frescura impulsado por lo viejo que es el último evento. Verde para un evento dentro de 24 horas, amarillo para 24 a 72 horas, rojo para más de 72 horas o nunca. El score responde "¿este canal está estructuralmente sano a lo largo de una semana?"; el punto de estado responde "¿llegó algo hace poco?". Son señales deliberadamente separadas, y un canal de bajo tráfico puede mostrar legítimamente un punto de estado amarillo sin un mal score.

El mailer de anomalías: caída significa roto, pico significa bots

El dashboard es pull. Tienes que abrirlo. El mailer de anomalías es push, y es la parte que se gana el sueldo, porque nadie abre el dashboard un domingo a las 7 de la mañana cuando el pixel se rompe. Un cron diario (bcnr_anomaly_check) lee los contadores por canal y juzga el día de ayer contra una baseline móvil. Sin llamadas de red; es pura aritmética sobre datos que ya están en la base de datos, por lo que plegarlo dentro de la sonda de salud del token habría sido el diseño equivocado. Token-verde más volumen-rojo es justo el patrón de pixel-roto-en-el-frontend que una sonda de token no puede ver.

Las matemáticas son deliberadamente aburridas para que sean predecibles:

• Baseline: la suma de los siete días anteriores a ayer (días 2 a 8 atrás), dividida por 7. Ayer mismo se excluye de su propia baseline, de modo que un desplome no arrastra hacia abajo la línea contra la que se mide.
• Caída: el conteo de ayer está en o por debajo del 50 % de ese promedio. Una reducción a la mitad del volumen normal. Esta es la alarma de pixel-roto: pixel bloqueado o eliminado, token expirado, tag desplegado mal.
• Pico: el conteo de ayer está en o por encima de 4x el promedio. Una cuadruplicación. Esta es la alarma de bots-o-spam: un exploit de envío de formularios mediante scripts, una oleada de bots o, de vez en cuando, un momento viral genuino (genial si lo es, y el correo lo dice).
• Baseline mínima: un canal necesita al menos 14 eventos a lo largo de la ventana de 7 días antes de ser juzgado siquiera. Esto es lo que impide que un par de conversiones de prueba disparen una falsa alarma en un canal que apenas se dispara.

Cuando un canal cruza un umbral, Beaconry envía un correo al mismo destinatario de alertas que usa el health-check del token. El correo nombra el canal, el conteo de ayer, el promedio de la baseline y el porcentaje de desviación de lo normal, luego enumera las causas probables para esa dirección (un correo de caída habla de pixeles bloqueados y tokens expirados; un correo de pico habla de bots y te dirige a la tabla de conversiones recientes para inspeccionar los tipos de evento y el contexto de origen). Una gate de transient por canal y por día (TTL de 23 horas, un pelo por debajo del intervalo diario de modo que el día siguiente nunca se bloquea) garantiza que recibes como máximo un correo por canal por día, no una tormenta.

Los tres umbrales son filtrables para usuarios avanzados: bcnr_anomaly_drop_ratio, bcnr_anomaly_spike_ratio y bcnr_anomaly_min_baseline. Una tienda de alto volumen que quiera ser alertada ante una bajada más suave del 30 % puede ajustar la drop ratio sin tocar el código del plugin.

Por qué "dos días después" es todo el punto

El modo de fallo al que apunta este diseño es la latencia del descubrimiento, no el fallo en sí. Los pixeles se rompen. Los tokens expiran. Una actualización de tema reordena el script de consentimiento y el endpoint REST deja de ser llamado. Eso ocurre sin importar qué herramienta de tracking uses. Lo que difiere es cuánto dura el hueco entre "se rompió" y "te enteraste".

Sin una señal interna, la ruta de descubrimiento es: el pixel se rompe, las conversiones dejan de llegar a la plataforma, el optimizador de la plataforma pierde lentamente su señal, la campaña deriva, y en algún momento del día dos o tres un humano nota los números y empieza a hacer preguntas. Con los contadores más el mailer, la ruta de descubrimiento es: el pixel se rompe, el conteo de hoy aterriza en cero, el cron de la mañana siguiente ve el día de ayer en cero contra una baseline sana, y recibes un correo que nombra el canal antes de que la campaña haya tenido tiempo de derivar. La misma rotura, una factura muy distinta.

Vale la pena ser honesto sobre la resolución. Esto es un cron diario que compara conteos de días enteros, así que la ventana de detección más estrecha es "la mañana siguiente". No es un buscapersonas en tiempo real. Para una pipeline de tracking que alimenta optimizadores de plataformas de anuncios, la mañana siguiente es la altitud correcta: las plataformas agregan y atribuyen a lo largo de días de todos modos, así que atrapar un día-cero antes de que se convierta en una semana-cero es lo que de verdad protege el gasto. Si quieres una confirmación en tiempo real de que un canal específico se dispara en este minuto, para eso están el panel en vivo y el botón de Test de extremo a extremo; el trabajo del mailer es la alerta temprana desatendida.

Conclusión

El tracking server-side cambia visibilidad de navegador por inmunidad al adblock, y el dashboard recompra la visibilidad sin renunciar a la inmunidad. Dos options con autoload=false registran cada despacho (un búfer circular de los últimos 50 para la tabla en vivo, 30 días de contadores por canal para todo lo demás). Un score de 0 a 10 construido a partir de Configurado, Activo-7d y Estable, sin llamadas a proveedores, te dice qué canales están estructuralmente sanos. Un cron diario te envía un correo ante una caída del 50 % (roto) o un pico de 4x (bots), medido contra los siete días anteriores a ayer, limitado a un correo por canal por día. Nada de esto es un buscapersonas en tiempo real, y no pretende serlo. Es la capa de alerta temprana que convierte "nos enteramos dos días después por la plataforma" en "Beaconry nos envió un correo a la mañana siguiente".