How to Build a Compliance-First CDP Architecture: A Technical Blueprint

The Wrong Question Most Companies Ask When Buying a CDP

When procurement teams evaluate a Customer Data Platform, the first questions are typically about activation capabilities: Which advertising platforms does it connect to? How fast does it resolve identity? Can it run real-time personalization?

These are not wrong questions. But they're the second questions. The first question — the one that determines whether your CDP creates legal liability the moment you go live — is: where does the data go and who consented to what?

Compliance is not a feature you add to a CDP post-deployment. It's a structural property of the architecture. The following six-layer blueprint describes how to build a CDP where GDPR Article 17, KVKK Article 11, and UAE PDPL transfer controls are not bolt-ons, but foundations.

---

Layer 1 — Consent Collection

Every data flow into your CDP begins with a consent signal. Without this signal, no data should enter an identifiable profile.

What this requires:

• CMP integration at all collection points: Web, mobile, in-store kiosks, call centers — every touchpoint where personal data is collected must have a CMP that produces a standardized consent output.
• Cookie category granularity: Consent must be captured at category level: necessary, analytics, marketing, personalization. A single "I accept all" checkbox is not sufficient under GDPR or KVKK if you're using data for multiple distinct purposes.
• Google Consent Mode v2 default deny: In all GTM containers targeting EEA or UK users, analytics_storage and ad_storage must default to denied. The CMP triggers the consent update signal; no data fires before that signal is received.
• Timestamped consent receipts: Every consent interaction produces a receipt with: user identifier (hashed), timestamp, channel, jurisdiction, specific categories granted, and the consent text version shown to the user.

---

Layer 2 — Data Ingestion

Events flowing into your CDP must carry consent signals embedded in the event schema itself. You cannot retroactively apply consent to events that were collected without it.

Required event schema fields:

{
  "userId": "uuid-v4-hashed",
  "eventType": "page_view",
  "consentAnalytics": true,
  "consentMarketing": false,
  "consentPersonalization": false,
  "jurisdiction": "TR",
  "timestamp": "2026-07-07T09:14:22Z",
  "source": "web_checkout",
  "consentVersion": "v2.3"
}

Events with consentAnalytics: false should be aggregated for statistical modeling but must not be linked to an identifiable profile. Events with consentMarketing: false must be suppressed from all marketing activation channels, regardless of what the channel's own settings say.

---

Layer 3 — Identity Resolution

Identity resolution is where privacy risk concentrates. Matching a pseudonymous web visitor to a known customer record is powerful for personalization — and high-risk for compliance.

Key principles:

• Data minimization (GDPR Article 5(1)(c)): Resolve identity only when there is a documented lawful basis for doing so. Don't match records speculatively.
• Probabilistic matching disclosures: If you use probabilistic identity resolution (device fingerprinting, lookalike matching), this must be disclosed in your privacy notice and, under KVKK, requires explicit consent.
• Cross-jurisdiction identity isolation: A Turkish user matched to an EU profile creates a cross-border data transfer. The CDP must track the jurisdictions involved in every identity merge event.

---

Layer 4 — Profile Storage

In a compliance-first CDP, consent is a first-class attribute — not a tag, not a note field, but a structured data type with its own schema.

Every profile must include:

{
  "profileId": "...",
  "jurisdiction": ["TR", "EU"],
  "consent_history": [
    {
      "timestamp": "2025-03-15T10:22:00Z",
      "channel": "web_banner",
      "jurisdiction": "TR",
      "marketing": true,
      "analytics": true,
      "version": "v2.1"
    },
    {
      "timestamp": "2026-01-08T14:05:00Z",
      "channel": "email_preference_center",
      "jurisdiction": "TR",
      "marketing": false,
      "analytics": true,
      "version": "v2.3"
    }
  ],
  "current_consent": {
    "marketing": false,
    "analytics": true
  }
}

The consent_history array is append-only — a full audit trail. The current_consent object is derived from the most recent entry and drives all activation decisions.

---

Layer 5 — Activation

No consent, no activation. This is the non-negotiable rule of Layer 5.

Segment definitions must include consent checks as structural constraints, not optional filters. When building an audience for an email campaign, the segment query should look like:

customers WHERE current_consent.marketing = true
AND jurisdiction IN ['TR']
AND last_active > 90_days_ago

The current_consent.marketing = true condition is not optional. It's built into the segment template as a required clause that cannot be removed by a marketing operator. Any platform integration — Meta Ads, Google Ads, Klaviyo, Salesforce Marketing Cloud — receives only profiles that pass this consent gate.

When a user revokes consent, the profile is removed from all active segments within the CDP's next sync cycle (typically under 15 minutes) and a deletion signal is sent to all integrated platforms.

---

Layer 6 — Subject Access Requests

GDPR Article 17, KVKK Article 11, and UAE PDPL all grant individuals the right to access, correct, and delete their data. The legal deadline is 30 days (KVKK) to one month (GDPR). Manual compliance at scale is not feasible.

The CDP must support:

1. Full profile export on demand: One API call returns all profile attributes, all historical events (with their consent signals), all consent history, and a log of every system the data was shared with.
2. Cascading deletion: A deletion request triggers removal from the CDP profile store, propagates deletion signals to all integrated activation systems (email platform, ad audiences, analytics tools), and logs each deletion with a timestamp.
3. Correction workflow: Data corrections in the CDP must propagate downstream to all systems that received the original data.
4. Legal hold exemptions: Data required for tax, fraud, or legal proceedings is flagged and excluded from deletion — but only the specific fields with legal basis, not the entire profile.

---

Why Vendor-Neutral Architecture Matters

The final architectural principle: avoid building your consent infrastructure on top of a single vendor's proprietary format. If your CMP produces consent signals in a format that only your current CDP vendor can read, you face a migration problem that will cost you your compliance history.

Standardized event schemas (aligned with IAB TCF 2.2 for GDPR, and supplemented with jurisdiction-specific fields for KVKK/UAE PDPL) ensure that your consent records remain portable and auditable regardless of which CDP vendor you use.

---

Mapping Your CDP Against These 6 Layers

Most companies operating a CDP today are strong on Layers 5 and 6 (activation) and weak on Layers 1–4 (consent infrastructure). The gap becomes visible only during a regulatory audit or a data breach — both of which carry serious consequences.

Mapping your CDP against these 6 layers is exactly what ONMARTECH does in our 4-Week Data Readiness Audit. We assess your current architecture layer by layer, document the compliance gaps, and deliver a concrete remediation roadmap with implementation priorities. Contact us to schedule your audit.