Ir al contenido

Compatible con WP Consent API y CMPs

SignalRelay está construido bajo el estándar Privacy by Design: ningún evento sale de tu sitio si la puerta de consentimiento no lo permite, y esa puerta cubre tanto el píxel del navegador como el canal server-side.


En Ajustes → SignalRelay → Settings → Consent, la opción Default gate define qué pasa cuando ningún plugin de consentimiento se pronunció:

  • Permissive (por defecto): los eventos se envían salvo que un plugin de consentimiento o el filtro signalrelay_consent diga que no.
  • Deny by default: no se envía nada hasta que la herramienta de consentimiento del visitante otorgue el consentimiento de marketing.

SignalRelay implementa la WP Consent API oficial. Si utilizás cualquiera de los siguientes plugins de CMP (Consent Management Platform):

  • Complianz GDPR/CCPA
  • CookieYes
  • Cookiebot
  • Real Cookie Banner

SignalRelay consulta únicamente la categoría marketing. Cuando el CMP definió un tipo de consentimiento, manda la decisión de marketing de cada visitante, en cualquiera de las dos posturas:

  • El píxel del navegador no consulta una sola vez: espera y dispara cuando se otorga el consentimiento, así que un visitante que acepta a mitad de la visita empieza a medirse desde ese momento. Una regla de scroll cuya profundidad el visitante ya alcanzó se dispara apenas llega el consentimiento.
  • El servidor revisa el mismo estado de consentimiento antes de cada entrega.
  • Si la verificación de la herramienta de consentimiento lanza un error en el navegador, SignalRelay lo cuenta como falta de consentimiento.

No hace falta configurar nada del lado de SignalRelay.


Para desarrolladores o sitios sin plugins CMP estándar, podés controlar el consentimiento server-side mediante el siguiente filtro en tu functions.php. Tiene la última palabra en el servidor:

add_filter('signalrelay_consent', function (bool $granted, string $category): bool {
// Ejemplo: bloquear el envío server-side salvo que el visitante haya consentido
return mi_funcion_verificar_consentimiento_usuario();
}, 10, 2);

El segundo argumento es la categoría de consentimiento (SignalRelay consulta marketing), no una plataforma.

Ese filtro gobierna el servidor. No puede gobernar el navegador, y tenés que conectar el navegador vos mismo. Es obligatorio, no opcional.

El filtro responde por visitante, pero el HTML de la página por el que tendría que viajar su respuesta está en caché y se sirve a todos. Por eso, en cuanto SignalRelay detecta un hook en ese filtro, el lado del navegador falla cerrado: sin píxel, sin cookies _fbp/_fbc, sin ID first-party y sin eventos de página, para todos los visitantes, incluidos los que aceptaron. Es deliberado: adivinar en silencio sobre una página en caché es lo único que una puerta de consentimiento nunca debe hacer.

Avisale al navegador cuando el visitante acepta, desde el callback de “aceptado” de tu CMP, una vez por página:

if (window.signalRelay && typeof window.signalRelay.grantConsent === 'function') {
window.signalRelay.grantConsent();
}

Cuando el visitante retire más tarde su consentimiento, llamá a revokeConsent() desde el callback de “rechazado” o “retirado” de tu CMP:

if (window.signalRelay && typeof window.signalRelay.revokeConsent === 'function') {
window.signalRelay.revokeConsent();
}

revokeConsent() impide que SignalRelay envíe más eventos en esa página. No elimina las cookies que ya están guardadas, y volver a llamar a grantConsent() reactiva el seguimiento. La lista completa de salvedades está en la referencia de la API de JavaScript.

Si tu CMP habla la WP Consent API, no necesitás estas llamadas: SignalRelay ya escucha wp_listen_for_consent_change y lee el tipo de consentimiento compartido. El hook y las dos llamadas son para un CMP que no la habla.


El botón Send test event de una tarjeta de plataforma se salta la puerta de consentimiento. Es una herramienta de administración para verificar credenciales, envía un evento sintético sobre vos y nunca se registra en el registro de actividad.