Service
Technical consent implementation
I implement the technical consent and governance layer so preferences travel from collection to the systems that enforce them.
What is included
- 01
Technical configuration of OneTrust, Didomi, or Cookiebot.
- 02
Technical categorization, tag blocking, and a banner adapted to the agreed design.
- 03
Integration with Consent Mode v2, tag management, Adobe Web SDK, or AEP as scoped.
- 04
Preference-flow design, usage policies, and enforcement points.
- 05
Testing by consent state and operating documentation.
- 06
Technical retention and deletion configuration based on requirements supplied by the client.
Related experience and reasoning
-
Built 2025–2026
Consent from the event bus to profile and activation
A consent pipeline from Kafka into AEP, with a separate load for the historical state that already existed. Both cadences matter: consent arriving as streaming and consent entering through a bulk load have to end up meaning the same thing.
- Kafka
- AEP
- Consent
- Historical load
-
Built 2025–2026
Who not to delete: the hard part of a profile purge
Batch deletion of around 250,000 identities through Data Lifecycle work orders, until the licensed volume was back in range. The hard part is not deleting: it is choosing who not to delete. A candidate with an active policy or live personalization stays, and without that check the candidate list is worthless.
- Data Lifecycle
- Query Service
- Retention
- Identity
-
Built 2025–2026
Proving the purge happened, which is not the same as requesting it
Requesting deletion with full scope is not enough: the reconciliation dataset was not purged with it, and the nightly chain brought the profiles back every morning. Three independent queries surfaced that, and a second bug: the snapshot stores identity keys lowercase while events send them camelCase, so the checks returned false zeros.
- Data Lifecycle
- Query Service
- Reconciliation
- Verification
-
Built 2024–2025
OneTrust consent into AEP, by connector and by event forwarding
The official OneTrust connector ingests consent and preferences only, not cookies, and each run brings only what came after the previous one. It covers the preference center, not the consent that travels with a web event. I built both routes: the connector for identified data and event forwarding for the rest.
- OneTrust
- Event Forwarding
- AEP
- Consent
-
Built 2021–2024
Cross-domain consent with Didomi, from scratch
Cross-domain consent: a decision taken on one domain had to hold on the others and survive the jump. Pre-production and production, web and app webview, categorized purposes, custom banners. And that decision reaching everything: the TCF API for vendors, Consent Mode v2 for Google tags.
- Didomi
- CMP
- Cross-domain
- Consent Mode v2
-
Built 2021–2024
Measurement held until the user decides in the banner
The first page view happens before anyone has accepted anything. While the banner is open the page sits behind a cover, and that view is stored rather than lost or sent regardless: it is replayed afterward, following the accepted categories. Without consent nothing leaves, and with it the entry to the session survives.
- Consent
- Tealium
- Data layer
-
Built 2021–2024
What session replay is allowed to record
A session replay tool sees the user screen, and inside a bank logged-in area that screen is their money. Rather than trusting default masking, what it may capture is declared in a list: outside it, nothing is recorded. Installing the tool is easy. Deciding what it has a right to see is the work.
- Glassbox
- Privacy
- Logged-in area
- Governance
Frequently asked questions
Does this replace legal advice?
No, and it is worth being clear about that up front. Legal bases, purposes, and wording are decided by your legal team. My work starts after that: making sure the decision is actually applied in tags, CDP, and destinations.
We already have a CMP installed. Why this?
Having a CMP is not the same as having consent applied. The usual pattern is that the banner works and the preference stays in the browser, never reaching the CDP or the destinations. That is where the real problems show up.
Which consent platform do you work with?
I have implemented with Didomi and with OneTrust, including environments, categories, and custom banners. The technical layer underneath is the same with any CMP: what changes is the integration, not the problem of making the preference travel intact to the destination.
How do you verify that it works?
By testing per category and per destination, not by looking at the banner. You check what fires and what does not for each combination of preferences, and what arrives at the end of the chain. A screenshot of the banner proves nothing.
Does this fit your problem?
Send me the context and I will tell you whether this scope fits or a different starting point makes more sense.