Consent state propagation across channels

Most marketing stacks have consent. They just don't have it consistently. The consent management platform holds one version. The CDP holds another, refreshed nightly. The ESP holds a third, refreshed by the latest list upload. The ad platforms hold whatever was true at the last audience push. Each of these systems makes activation decisions against its own local copy. When the copies diverge, the activations diverge with them.

The visible failure is a customer who withdrew consent on Tuesday continuing to receive marketing emails on Friday, or being included in a Custom Audience pushed to Meta the following Monday. The invisible failure is more dangerous: the team can't answer, when asked by a regulator or an auditor, where the canonical consent record lives. Each system shows its own version. Each version is partially correct. None is authoritative.

The recipe addresses this by establishing a single source of truth for consent and a mechanical propagation path from that source to every system that activates against it. The system of record holds the consent state. The downstream systems either receive push updates or perform checks against the source at activation time. The audit trail records every decision and the consent state under which it was made. This is the architecture that makes compliance defensible rather than aspirational.

A canonical consent record per user, owned by a single system, with a deterministic propagation path to every downstream system that activates against it. Send-time and activation-time consent checks at every channel, with per-decision audit evidence retained for the regulator-required period. Cross-jurisdictional routing where the consent regime applied is the one current at the moment of activation, not the one current at the moment of collection. Latency between consent change and downstream propagation low enough that the failure window doesn't span a typical campaign cycle. Most stacks running this recipe target propagation under one hour for standard channels and under fifteen minutes for high-frequency channels like behavioral email and real-time bidding.

A consent management platform for collection: OneTrust, Cookiebot, Didomi, Sourcepoint, or a self-built equivalent for organizations large enough to justify the engineering investment. A system of record for the consent state, which may be the CMP itself or, more commonly for sophisticated stacks, a dedicated consent table in the CDP or warehouse that the CMP writes into. An event bus, webhook system, or replication layer that propagates consent changes to downstream systems. Each downstream channel needs a way to receive and apply the updates: ESP APIs for email eligibility, ad-platform APIs for audience and bid eligibility, decisioning-engine inputs for activation logic. An audit log infrastructure with enough retention to cover the longest applicable regulatory window, typically two to seven years depending on jurisdiction and processing type.

The architectural decision that drives everything else is which system holds the source of truth. There are three viable answers: the consent management platform itself, a CDP or warehouse table populated by the CMP, or a purpose-built consent service. CMP-as-source-of-truth works for smaller organizations with simpler stacks; the CMP API is the authoritative read, and downstream systems either poll or subscribe to webhook updates. CDP-or-warehouse-as-source-of-truth works for larger organizations with established CDP investments; the CMP writes to the CDP, and downstream systems read from the CDP. Purpose-built consent service is for organizations large enough to justify the engineering investment and complex enough to need consent governance independent of any vendor relationship.

Whichever choice gets made, the rule is one source. Multiple sources is the failure mode that creates the divergence problem in the first place. If consent can be set in multiple places (e.g., customers can update their preferences in the CMP cookie banner, in the email preference center, and in their account profile), the multiple collection points must write back to a single canonical record. Local copies in downstream systems are caches, not authorities, and they refresh from the canonical record on a defined cadence.

The propagation mechanism is the second decision. Push-based propagation has the source-of-truth system actively notify downstream channels when consent changes, via webhooks or event bus messages. This has lower latency but more failure modes (failed webhooks, retry logic, dead-letter queues, channel-specific rate limits). Pull-based propagation has downstream channels check the source at activation time. This has higher latency tolerance but adds load to the consent service and creates a hard dependency on its availability. Most production setups use a hybrid: push for state changes that affect immediate eligibility (consent withdrawal, jurisdictional change), pull for periodic refresh of slower-moving state.

The audit trail records every consent check at every channel. The schema includes the user identifier, the channel performing the check, the timestamp, the consent state read, the activation decision made, and the source of the consent state read (which system, which version of the record). Audit retention follows the longest applicable regulatory window. The audit trail is the primary evidence in any regulatory inquiry or breach response.

Jurisdictional routing is the layer most teams underestimate. A user consents to behavioral advertising while in the EU under GDPR. They travel to the US and interact with the brand from a California IP. The question is what regime applies to the next activation. There's no universal answer, but there are three defensible postures: user-level (the regime at consent collection sticks for that user forever), session-level (the regime current at activation applies, even if it differs from collection), and most-protective (whichever regime is most restrictive at any point applies always). The first is simplest. The third is safest. The second is cheapest in compliance overhead but most expensive in legal interpretation. Pick one explicitly and document the choice.