In most tracking stacks, consent is a plain-text field riding along with the event, trusted by whoever reads it and editable by anyone who doesn't. HeySignal seals consent into the event itself. Change one bit of either and the whole thing is refused.
Our SDK reads consent from your CMP and computes an HMAC-SHA256 signature over the event data, the consent state, and a timestamp, together, as one string. At our European edge the signature is recomputed and compared in constant time. A forged event, a replayed event, or an event whose consent was altered in transit all fail identically: refused, logged, gone.
Signatures expire after five minutes, so captured requests can't be replayed later. Consent itself must be fresher than 24 hours; a stale decision is treated as no decision. Ambiguity is denial.
Only then does the gate read the consent itself. Malformed consent object? Refused. No decision made yet? Refused. Every refusal returns a 403 with a typed reason. You can see exactly why every blocked event was blocked.
403 MISSING_SIGNATURE
403 INVALID_SIGNATURE
403 CONSENT_DENIED
403 NO_CONSENT_DECISION
Consent isn't binary and the gate doesn't pretend it is. Every destination you configure declares which consent categories it requires. A visitor who granted analytics but denied marketing flows to GA4 and never touches Meta, from the same event, in the same request. The dispatcher re-checks this server-side before every single delivery.
Even our client-side tracking rules carry a consent category: a scroll-depth rule tagged marketing will not fire in a browser without marketing consent. The gate starts before the network request does.
Fail-open systems forward data when something breaks. Fail-closed systems stop. HeySignal's event pipeline is fail-closed in code, not in a policy PDF:
Every blocked event gets a receipt, and every processed event carries a consent proof ID persisted in the audit log. When someone asks "prove this conversion had consent", you have an answer with a UUID on it.
Server-side GTM hosts pass consent as Google's gcs parameter and leave enforcement to checkboxes in your tag templates. Stape's own documentation says server GTM has no consent mode like web GTM. TAGGRS's consent tooling monitors signals after the fact and says plainly that it does not replace a banner or enforce anything. If a tag is misconfigured, data flows anyway.
We built the opposite: enforcement first, configuration second. A misconfigured HeySignal site blocks traffic. That is the correct failure.
Sources and dates on the comparison pages: HeySignal vs Stape and HeySignal vs TAGGRS.
The signature stops third parties, replays, and in-transit tampering: the attacks that actually plague "consent=true" request fields. A site's own signing key lives in its SDK config, so the guarantee is integrity of the consent your CMP recorded, end to end through our pipeline.
Log the block reason, count them, and optionally feed anonymous Consent Gap statistics. We never store identifiers from denied traffic and never forward it anywhere.
Verification happens at edge nodes close to your visitors and adds milliseconds. Signing uses the browser's native Web Crypto.
CookieFirst and iubenda natively; any CMP via the custom consent hook.
BRAND