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 categorisation, 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 and enforcement points.
- 05
In AEP, a DULE matrix covering restriction, label, policy, marketing action and blocking test, as scoped.
- 06
Testing by consent state and operating documentation.
- 07
Technical retention and deletion configuration based on requirements supplied by the client.
Related experience and reasoning
-
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, categorised 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 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 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 centre, 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 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 personalisation stays, and without that check the candidate list is worthless.
- Data Lifecycle
- Query Service
- Retention
- Identity
Explore more work in my career history →
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.
Explore this decision
- Seeing data does not permit every use
Who can see data, what it may be used for and what a person accepts. Compare access controls, DULE and consent in AEP.