Arquitectura & Deduplicación Cache-Safe

El problema del tracking tradicional

En una configuración típica de WordPress con caché de página completa (Full-Page Cache):

1. Caché HTML Estática: El servidor genera el HTML una vez y lo guarda en disco o memoria (WP Rocket, LiteSpeed, Cloudflare).
2. Colisión de IDs: Si un plugin genera el event_id en el servidor PHP durante la carga de la página, ese mismo ID queda grabado en el HTML cacheado. Todos los visitantes posteriores reciben el mismo event_id.
3. Pérdida de Conversiones: Cuando dos visitantes distintos realizan una acción, Meta ve el mismo event_id y descarta la segunda conversión creyendo que es un duplicado.

[ Visitante A ] ──▶ Carga página cacheada (event_id: "xyz-123") ──▶ Envía Formulario ──▶ Meta registra Lead
[ Visitante B ] ──▶ Carga página cacheada (event_id: "xyz-123") ──▶ Envía Formulario ──▶ Meta DESCARTA (Duplicado) ❌

---

La Solución de SignalRelay: event_id en el Navegador

SignalRelay desacopla la generación del ID de la renderización del servidor:

[ Visitante A ] ──▶ JS genera event_id único "sr_a98f..." ──▶ Servidor despacha CAPI con "sr_a98f..." ──▶ Meta Acepta ✅
[ Visitante B ] ──▶ JS genera event_id único "sr_b44c..." ──▶ Servidor despacha CAPI con "sr_b44c..." ──▶ Meta Acepta ✅

1. Generación Client-Side: El script tracking.js genera un UUID v4 criptográfico único para cada evento en el momento exacto en que ocurre la acción.
2. Sincronización Dual: El mismo event_id se pasa tanto al pixel del navegador (fbq('track', 'Lead', {...}, {eventID: id})) como al endpoint REST local de SignalRelay (/wp-json/signalrelay/v1/event).
3. Despacho Server-to-Server: El servidor de WordPress recibe el payload, aplica las reglas de consentimiento, hashea la información personal (PII) con SHA-256 y encola la conversión. Luego un proceso en segundo plano la envía a la API oficial (ver Cola de entrega).
4. Deduplicación Exitosa: Meta recibe ambos paquetes con el mismo event_id y fusiona los datos para maximizar el Event Match Quality (EMQ).

---

Cola de entrega

El visitante nunca espera a una plataforma publicitaria. Cada conversión entra en una cola de Action Scheduler en tu servidor y un proceso en segundo plano la envía, normalmente en menos de un minuto. Una entrega que falla por un motivo que un reintento puede resolver (un error de red o un error temporal de la plataforma, como un 5xx o un límite de tasa) se reintenta hasta tres veces más en unos 20 minutos.

El registro de actividad solo lista eventos que ya terminaron de procesarse, así que una cola trabada parecería un sitio sin tráfico. Por eso SignalRelay te avisa, en la pestaña Overview del panel y en Herramientas → Salud del sitio, cuando:

• una conversión lleva más de 10 minutos esperando en la cola, o
• hubo conversiones cuya entrega falló de forma definitiva en los últimos 7 días. Una entrega fallida no se reintenta, y el error figura en Herramientas → Scheduled Actions.

La causa habitual de una cola detenida es un sitio que no ejecuta las tareas programadas de WordPress. Si DISABLE_WP_CRON está definido en wp-config.php, quitalo o agregá un cron del servidor que solicite wp-cron.php cada minuto. No se pierde nada mientras la cola espera: las conversiones se envían apenas vuelve a ejecutarse.