Opt-outs stuck in cookies; orchestration synced to Salesforce and Marketo with send?time checks for email/push

Overview

Website consent was captured in a Consent Management Platform (CMP) but wasn’t synchronized to downstream systems, so customers who opted out still received marketing emails and push messages. Consent lived in cookies and form submissions, while CRM and messaging tools held their own preference flags. Intelligex introduced an API layer that normalized consent states and purposes, synchronized updates across CRM, ESP, CDP, and data warehouse, and enforced send?time checks. Every change wrote to an audit log with timestamps and source, and Legal approved purpose and vendor changes under change control. Marketing respected preferences across channels and complaints dropped, while the CMP and existing tools stayed in place.

Client Profile

• Industry: Digital services and commerce
• Company size (range): Multi?region operations with centralized Legal & Compliance and distributed marketing teams
• Stage: CMP deployed on web; preferences tracked separately in CRM and ESP; batch ETL to CDP; no unified consent model; inconsistent suppression in email, SMS, and push
• Department owner: Legal & Compliance (Privacy Office and Legal Operations)
• Other stakeholders: Marketing/Growth, CRM Operations, Product/Engineering, Data/Analytics, Customer Support, Security/Identity, Internal Audit

The Challenge

Consent was collected in one place and acted on in another. The website’s CMP stored consent in cookies and a web log, but CRM and messaging platforms used their own flags. Revocations on the site did not reach email and push in time, and opt?outs captured in email campaigns did not flow back to the website or app. Different teams used different names for purposes—marketing, analytics, personalization—so preferences were mapped loosely or not at all.

Channels drifted out of sync. Email campaigns pulled lists from the CRM, push notifications used app preferences, and data enrichment vendors had their own acceptance fields. Batch updates landed late or failed silently, so suppression lists lagged. When customers complained, support teams had to reconcile various systems to prove what the customer chose and when. Legal needed dependable lineage to answer regulator inquiries and to manage changes in lawful basis or regional rules.

There was no single source of truth. Consent events from the CMP, the email unsubscribe page, and in?app settings lived in different places. Audit logs varied by system, and identity resolution was inconsistent across web IDs, app IDs, and CRM contacts. Downstream tools trusted their local state and sent communications even when another channel had an opt?out.

Why It Was Happening

Consent management ended at the browser. The CMP set cookies and captured preferences but did not push normalized events to back?office systems. Integrations were one?way and batch?based, so changes were delayed or dropped. The organization lacked a canonical consent model that tied a person’s identity to purposes, channels, and jurisdictions.

Policy lived in documents, not in the path of work. The privacy policy and playbooks described purposes and requirements under GDPR and state laws, but tools used arbitrary fields. Without standardized purpose codes, consistent states, and send?time checks, each system interpreted consent differently. There was no governed process to log changes, review vendor mappings, or prove consent and revocation with timestamps.

The Solution

Intelligex implemented a consent orchestration layer that normalized preferences, synchronized them across systems, and enforced send?time checks. CMP events and other capture points posted to an API that wrote a canonical consent record with identity resolution, purpose codes, channel flags, jurisdiction, lawful basis, and timestamps. Downstream systems subscribed to updates, and the email/SMS/push pipelines checked suppression before sending. All changes wrote to an immutable audit log, and Legal approved updates to purpose definitions and vendor mappings. Guidance aligned to recognized frameworks, including the IAB Europe Transparency and Consent Framework and the European Data Protection Board’s Guidelines on consent.

• Integrations: CMP (for example, OneTrust or TrustArc) for web capture; CRM (for example, Salesforce) for contact preferences; ESP/marketing automation (for example, Marketo or Salesforce Marketing Cloud) for email; mobile push provider (for example, Braze) for app messaging; CDP (for example, Segment or Adobe Experience Platform) for audience sync; data warehouse for reporting; identity/SSO for access.
• Consent data model: Canonical record with person identity keys, purposes, channels, jurisdiction, lawful basis, and state transitions (opt?in, opt?out, objection, withdrawal); effective and collected timestamps; source and evidence links.
• API and eventing: Webhooks from CMP and email unsubscribe pages; in?app settings handlers; publish/subscribe updates to CRM, ESP, CDP, and data warehouse; retries and dead?letter queues for resiliency.
• Enforcement gates: Send?time suppression in email/SMS/push; audience sync checks in CDP; guardrails to prevent sends when state is unknown; quarantine for records with identity conflicts.
• Preference center: Unified UI surfaced in web and app; mapped to canonical purposes and channels; regional variants and language; double?opt?in and confirmation where required.
• Audit and lineage: Immutable logs with user, time, source, and previous state; evidence of consent or revocation; exportable receipts for regulator inquiries and customer requests.
• Governance and change control: Legal approval for purpose changes, vendor mappings, and regional variants; release notes and effective dates; periodic reviews of mappings and false sends.
• Dashboards: Opt?in/opt?out trends by channel and region; sync health and error queues; unresolved identity conflicts; complaint patterns and remediation tracking.

Implementation

• Discovery: Mapped current consent capture points (web CMP, email unsubscribe, in?app settings); inventoried CRM and ESP fields; reviewed CDP audiences and data warehouse schemas; sampled complaints and regulator inquiries; gathered Legal, Marketing, Engineering, and Support requirements for lineage and enforcement.
• Design: Authored the canonical consent model and purpose taxonomy; defined identity resolution rules; designed the API and webhook patterns; specified send?time gates and suppression checks; planned preference center UI updates; outlined dashboards and audit exports; established change control for purpose definitions and vendor mappings.
• Build: Implemented the API layer and event bus; connected CMP and unsubscribe endpoints; integrated CRM/ESP/CDP updates and send?time suppression; built the audit log with evidence links; updated the preference center to read/write canonical states; instrumented dashboards and alerting.
• Testing/QA: Ran in shadow mode to compare canonical states to system flags; validated double?opt?in and revocation flows; exercised failure and retry paths; tested regional variants; piloted with one brand and channel; tuned mappings, retry intervals, and enforcement messages from user feedback.
• Rollout: Enabled read?only sync first; turned on send?time gates for email, then SMS and push; migrated CDP audiences to canonical states; retired batch scripts after stable cycles; maintained a monitored fallback for high?priority campaigns early on.
• Training/hand?off: Delivered playbooks for marketing ops on purpose selection and suppression; trained Legal on change control, audit exports, and dashboards; briefed Support on consent receipts for complaints; updated SOPs and escalations; transferred ownership of purpose taxonomy, mappings, and dashboards to the Privacy Office under change control.
• Human?in?the?loop review: Established monthly reviews of purpose definitions, vendor mappings, sync failures, and complaints; recorded decisions with rationale and effective dates; updated taxonomy, UI labels, and enforcement rules accordingly.

Results

Preferences stayed synchronized across channels. Consent captured on the website, in email, or in the app flowed to a single record and propagated to CRM, ESP, and push providers. Send?time checks prevented messages when state was missing or revoked, and audience syncs respected objections and opt?outs. Marketing teams worked with a clear purpose list and saw suppression applied consistently.

Lineage became auditable. Each change carried a timestamp, source, and evidence link, and Legal exported receipts for complaints and regulator inquiries without assembling a narrative from multiple tools. Purpose changes and vendor mappings moved under change control, eliminating confusing variants and mismatched fields. Existing systems remained; the new layer provided normalization, synchronization, enforcement, and governance between them.

What Changed for the Team

• Before: CMP preferences and CRM flags drifted apart. After: A canonical consent record synchronized states across CRM, ESP, CDP, and push.
• Before: Sends relied on local flags. After: Send?time gates checked canonical consent and suppressed messages when required.
• Before: Purposes were named differently by tool. After: Standard purpose codes and labels drove consistent capture and enforcement.
• Before: Complaints required system?by?system checks. After: Audit receipts showed who consented or revoked, when, and how.
• Before: Changes to purposes were informal. After: Legal approved purpose and vendor mapping updates with release notes.
• Before: Batch jobs failed silently. After: Event?driven sync with retries and dashboards surfaced issues for quick remediation.

Key Takeaways

• Create a single source of truth; normalize consent into a canonical model tied to identity.
• Push and pull; sync changes from all capture points and enforce at send?time across channels.
• Standardize purposes; use a governed taxonomy so tools don’t invent their own fields.
• Prove lineage; log each change with source, timestamp, and evidence for audit and complaints.
• Run under change control; treat purpose and vendor mapping updates as governed releases.
• Integrate, don’t replace; keep the CMP, CRM, ESP, and CDP—add orchestration, enforcement, and audit between them.

FAQ

What tools did this integrate with? The CMP captured website consent and posted events to the API layer. CRM (for example, Salesforce), ESP/marketing automation (for example, Marketo or Salesforce Marketing Cloud), and mobile push (for example, Braze) subscribed to updates and enforced suppression. The CDP (for example, Segment or Adobe Experience Platform) synced audiences, and the data warehouse stored consent history for reporting. Purpose mapping aligned to frameworks such as the IAB Europe Transparency and Consent Framework, and consent guidance referenced the EDPB’s Guidelines on consent.

How did you handle quality control and governance? Purpose definitions, vendor mappings, and regional variants lived under Privacy Office change control with owners and effective dates. Every state change wrote to an immutable log with source and evidence links. Legal approved updates to purposes and mappings, and dashboards surfaced sync failures, identity conflicts, and complaint patterns for remediation.

How did you roll this out without disruption? Sync ran in shadow mode first to compare canonical states with tool flags. Send?time gates started as advisory checks on email, then moved to enforcement, followed by SMS and push. CDP audiences migrated to canonical states in phases. Batch scripts remained as monitored fallbacks until accuracy and adoption stabilized.

How did you manage multi?channel and regional differences? The canonical model separated purposes from channels and included jurisdiction and lawful basis fields. Regional variants mapped to the same core purposes with localized labels, and the preference center displayed the correct options by region. Channel?specific enforcement ensured an opt?out applied consistently across email, SMS, and push.

How do you prove consent and handle revocations? Each event captured a timestamp, source, identity keys, and evidence such as CMP transaction IDs or unsubscribe confirmations. The audit log maintained the full state history, and exports provided receipts for regulators and customer support. Revocations updated the canonical record immediately and triggered suppression across subscribed systems.