Consent management

1) Terms and limits of responsibility

Consent: voluntary, informed, specific and unambiguous expression of will; may be revoked.
Legal basis: consent is only one of the options (contract, legal basis, legitimate interest, etc.). The model must store both the base and the target.
Purpose: atomic reason: analytics, personalization, ads, email_marketing, data_sharing_vendor_X.
Granularity: consents are stored by goals, channels, vendors, regions, data categories.
Subject profile: person, device, household, child account (special rules for minors).

2) Consent lifecycle

1. Collection: banner/CIW, settings in the profile, API/SDK, offline channel (contact center).
2. Validation: age, region, availability of alternatives (without "dark patterns").
3. Register to create an opt-in event and current snapshot for targets.
4. Distribution: publishing events to the bus, updating caches on edge, synchronizing with vendors.
5. Implementation: application in real-time (gateways/pixels/SDK), in batch (ETL/analytics), in ML-pipelines.
6. Change/revocation: immediate ban on new collection/activation, subsequent "cleansing" of historical policy data.
7. Audit/reporting: provability of consent at the time of processing (who, when, what version of the text).

3) Architectural components

CMP (Consent Management Platform): UI/SDK + API formatting consent options for UX/jurisdictions; source of truth by texts and versions.
Consent Registry: a reliable repository of consent states and events (append-only journal + current projection).
Consent PDP/PEP: Policy Decision/Enforcement Point. PDP decides "is it possible? "PEP applies the solution to the API gateway, ETL, SDK, etc.
Edge cache of consents: low latency for perimeter checking.
Partner/GPP/IAB gateway: translation of local targets into partner signals and vice versa.
Data Lineage & Tagging: marking data with consent/base flags throughout the chain.

4) Data model (diagrams)

json
{
"subject_id": "usr_123",
"subject_scope": "user",
"region": "EU",
"legal_basis": {
"analytics": "consent",
"personalization": "consent",
"security": "legitimate_interest",
"contract_core": "contract"
},
"purposes": {
"analytics": {"status": "granted", "version": "v5", "updated_at": "2025-10-31T13:20:10Z"},
"personalization": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"ads": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"email_marketing": {"status": "granted", "channel":"email","updated_at":"2025-10-31T13:22:05Z"}
},
"text_bundle": {"locale":"uk-UA","policy_version":"2025-09"},
"evidence": {"capture_ip":"203. 0. 113. 5","capture_ua":"Chrome/142"}
}

json
{
"event_id": "cse_987",
"subject_id": "usr_123",
"purpose": "personalization",
"previous": "denied",
"current": "granted",
"legal_basis": "consent",
"policy_version": "2025-09",
"captured_at": "2025-10-31T13:21:31Z",
"channel": "web",
"evidence": {
"banner_id": "cmp_v3",
"text_hash": "sha256:...",
"ip": "203. 0. 113. 5",
"ua": "Chrome/142",
"locale": "uk-UA"
}
}

5) Signal protocols and distribution

Web/App/SDK: cookie/local storage/secure storage + signature/integrity check; auto-resink at login.
Server-side: headers' X-Consent-Token '/' X-Purposes', bidirectional exchange with SSR/edge rendering.
Partners/vendors: translation into their formats (for example, target vector, general signal "GPP/TCF"); in case of failure - zero signal/restricted mode.
Offline channel: recording of audio consent/checkbox by the operator with subsequent verification and binding to 'subject _ id'.

6) Execution: where and how traffic is "cut"

• Block endpoints/fields without consent (/profile/enrich ,/ads/,/events/track).
• Mutate response/request: cut trackers, personalization fields, identifiers.
• Assign consent context to the backend request (JWT stamps or individual headers).

• The event transformer removes/masks fields by consent flags.
• Dataset marking: 'dataset. consent_scope=analytics:granted; ads:denied`.
• In ML-pipeline, records without appropriate consents are excluded; disables training/activation for prohibited purposes.

7) Pseudocode: Gateway Solution

python def enforce_consent(request, consent_snapshot):
purpose = map_endpoint_to_purpose(request. path) # /ads/ -> "ads"
basis  = consent_snapshot. legal_basis. get(purpose)
status = consent_snapshot. purposes. get(purpose, {}). get("status", "denied")

if basis! = "consent": # e.g. security/contract - allowed without return ALLOW banner

if status!= "granted":
return DENY # or ALLOW with redaction if degradation is allowed

return ALLOW

8) Versioning and provability

Consent text version: keep 'policy _ version', 'text _ hash', 'banner _ id'.
Locale and region: what text and in what language is shown.
Snapshot at the time of processing: the opportunity to answer "why was the ad shown 2025-10-15 at 09:03? ».
Immutable log: WORM/append-only with crypto event signature.

9) Special cases

Minors: validation of age, parental consent, individual goals and deadlines.
Guest → login: merging anonymous token with account; rules in a conflict (the strictest wins).
Multi-device: consistent resync; when revoking - push-disabled tokens on all devices.
Regional modes: "strict" (EU) vs "opt-out" (some markets) - switching CMP presets.
A/B tests: data experiments are a separate goal of experimentation; without it - only functional tests without personal data.
Right to delete: A recall can trigger the deletion/anonymization of historical target data ("purge on revoke" policy).

10) Anti-patterns

One "common" checkbox for everything.
Lack of text versions and provability of the show.
Store only the cookie flag without the server registry.
Applying consent only in UI, not in ETL/ML/exports.
Conflicting sources of truth (SDK ≠ backend).
Dark patterns, imposing consent: legal and reputational risks.

11) Observability and metrics

Coverage: the proportion of traffic with a valid consent token.
Latency PDP: Perimeter decision time.
Drift: mismatch between SDK and server snapshot.
Revoke SLA: revocation time → full deactivation/clear time.
Vendor Compliance - percentage of partner calls with the correct signal.
Incidents: attempts to process without consent, blocked calls.

Dashboards: "consent funnels," map of regions/channels, thermal failure maps.

12) Testing and verification

PDP/PEP contract tests: truth table by goal/region combinations.
Chaos/Drift tests: non-synchronous SDK states ↔ server; TTL cache expiration.
CMP releases: A/B validation of texts and UX neutrality (no dark patterns).
E2E tracing: user-revoke event → no sending to partner pixels and pipelines.

13) Interrelated abilities

Anonymization/pseudonymization: execution of failures before and after depersonalization.
Encryption and KMS Token/Log Protection.
Geo-routing: selection of regional texts/rules.
Observability: private dashboards without personal data; correlation by tokens only.
Data Lineage: in each dataset - the imprint of consents.

14) Mini recipes

yaml purposes:
analytics:
legal_basis: consent enforcement: redact_fields: [ad_id, gaid, idfa]
personalization:
legal_basis: consent enforcement: deny_endpoints: [/recs/, /profile/enrich]
security:
legal_basis: legitimate_interest enforcement: allow email_marketing:
legal_basis: consent channel: email

event. meta. consent. analytics = granted    denied event. meta. consent. ads    = denied event. meta. legal_basis    = consent    contract    li

on user_revoke(purpose):
mark subject_id + purpose as "purge_pending"
schedule purge jobs over datasets with lineage(purpose)
emit audit_event("purge_started", scope=purpose)

15) Architect checklist

1. Is there a single registry and an unchangeable consent journal?
2. Are the goals set atomically and versionally everywhere?
3. Is there execution on the perimeter, in streams, in analytics and in ML?
4. Feedback and historical data cleanup policy implemented?
5. Are the UI/SDK/server snapshots and resync mechanisms consistent?
6. Configured Coverage/Drift/Revoke SLA metrics and reporting?
7. Is there a runbook on incidents (violations, complaints, regulator)?
8. Are special regimes supported (children, regions, B2B partners)?

Conclusion

Consent management is not a modal window, but an end-to-end architectural function: from declaring goals and versioning texts to machine execution of decisions in real time and subsequent reporting. A strict data model, a single registry, PDP/PEP on all layers, full telemetry and cleaning procedures turn compliance into a competitive advantage - a trusted platform.