WP Consent API & CMP Support

SignalRelay is built following strict Privacy by Design principles: no event leaves your site unless the consent gate allows it, and the gate covers both the browser pixel and the server-side channel.

---

Default Gate

In Settings → SignalRelay → Settings → Consent, the Default gate decides what happens when no consent plugin has spoken:

• Permissive (default): events are sent unless a consent plugin or the signalrelay_consent filter says no.
• Deny by default: nothing is sent until the visitor’s consent tool grants marketing consent.

---

Native WP Consent API Support

SignalRelay implements the official WP Consent API. If you run any of the following Consent Management Plugins (CMPs):

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

SignalRelay asks for the marketing category only. When the CMP has set a consent type, the visitor’s own marketing decision governs, per visitor and in either posture:

• The browser pixel does not check just once: it waits and fires when consent is granted, so a visitor who accepts mid-visit is tracked from that moment. A scroll-depth rule that the visitor already satisfied fires as soon as consent arrives.
• The server checks the same consent state before every delivery.
• If the consent tool’s own check throws an error in the browser, SignalRelay counts it as no consent.

No configuration is needed on SignalRelay’s side.

---

PHP Filter signalrelay_consent

For custom setups or non-standard CMPs, developers can control dispatch logic using the signalrelay_consent filter in functions.php. It has the final say on the server:

add_filter('signalrelay_consent', function (bool $granted, string $category): bool {
    // Example: deny server-side tracking unless the visitor has consented
    return my_custom_consent_check();
}, 10, 2);

The second argument is the consent category (SignalRelay asks for marketing), not a platform.

The filter does not govern the browser

That filter governs the server. It cannot govern the browser, and you have to wire the browser yourself. This is required, not optional.

The filter answers per visitor, but the page HTML it would have to travel in is cached and served to everyone. So the moment SignalRelay sees a hook on that filter, the browser side fails closed: no pixel, no _fbp/_fbc cookies, no first-party ID and no page events, for every visitor, including the ones who accepted. That is deliberate: silently guessing on a cached page is the one thing a consent gate must never do.

Tell the browser when the visitor accepts, from your CMP’s “accepted” callback, once per page:

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

When the visitor later withdraws consent, call revokeConsent() from your CMP’s “declined” or “withdrawn” callback:

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

revokeConsent() stops SignalRelay from sending any further events on this page. It does not remove cookies that are already set, and calling grantConsent() again turns tracking back on. The full list of caveats is in the JavaScript API reference.

If your CMP speaks the WP Consent API, you do not need these calls: SignalRelay already listens for wp_listen_for_consent_change and reads the shared consent type. The hook and the two calls are for a CMP that does not.

---

One Exception

The Send test event button on a platform card bypasses the consent gate. It is an admin tool for verifying credentials, it sends a synthetic event about you, and it is never recorded in the activity log.