Every ad platform invented its own way to hear about consent. Google wants Consent Mode signals. Meta has no GDPR parameter at all, so the only compliant move is withholding the event. TikTok wants limited_data_use. Get one dialect wrong and you're either leaking data or losing attribution.
HeySignal speaks all of them, automatically, from one verified consent state.
Your events arrive once, in one common shape. Built-in per-platform mappings do the rest.
limited_data_use translation.Adding a platform is a destination, not a project. No new tags, no new container, no re-instrumenting.
One consent state from your CMP becomes, automatically:
gcd and ad_user_data / ad_personalization for Google surfaceslimited_data_use for TikTok, data_use for Snapchat, opt_out_type for Pinterestasc signalIn sGTM setups this is a per-tag checkbox exercise where one forgotten box means non-consented data on a US server. Here it is not configurable enough to get wrong.
GOOGLE gcd · ad_user_data · ad_personalization
META event withheld + Limited Data Use
TIKTOK limited_data_use
SNAPCHAT data_use
PINTEREST opt_out_type
MICROSOFT asc
Each destination gets its own privacy settings, per field: strip, hash, or pass, for email, phone, names, IP, user agent and more. Defaults are strip. A capability registry knows what each platform legally and technically accepts, and coerces illegal combinations to the safe option. Fields a platform can't take are never sent at all.
No. Destinations are fed by the HeySignal SDK or your existing dataLayer. If you want to keep GTM, use the first-party proxy alongside.
The SDK intercepts your existing pixel calls and shares event IDs, so Meta's CAPI dedup matches server and browser events correctly.
You see it: real status codes in the delivery log, dead-lettered payloads you can inspect and replay. No black holes.
Yes, the webhook destination signs payloads with HMAC so your endpoint can verify they're really from your pipeline.