Saltearse al contenido
SignalRelay

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 envía la solicitud a la API de Conversiones.
  4. Deduplicación Exitosa: Meta, TikTok o Pinterest reciben ambos paquetes con el mismo event_id y fusionan los datos para maximizar el Event Match Quality (EMQ).