Service
Architecture and implementation audit
I assess an existing MarTech implementation and turn the observed problems into prioritized findings and a remediation plan.
What is included
- 01
A map of data flows, integrations, dependencies, owners, and control points.
- 02
A review of collection, quality, identity, and activation as scoped.
- 03
A review of data governance, consent, monitoring, and operational recovery.
- 04
Each finding with its impact and its estimated effort.
- 05
An ordered remediation plan.
Related experience and reasoning
-
Built 2025–2026
The CDP architecture, with the reason for each decision written down
The obvious architecture does not work, and you have to measure it to find out. A journey writing to the profile leaves nothing in the data lake, so any state computed inside a journey needs nightly reconciliation to exist in SQL. Everything else follows: schemas, identity, and what persists where. With the reasons written down.
- Architecture
- AEP
- Data model
- Identity
-
Built 2025–2026
Identity resolution with Data Prep and Query Service
Identities resolved at ingestion with Data Prep and reconciled afterward through scheduled Query Service jobs. Duplicate profiles dropped by around 30% and unmapped emails went from 100% to under 50%.
- Data Prep
- Query Service
- Identity
-
Built 2025–2026
Weekly identity health runbook, with baselines
Queries against the profile snapshot, run weekly and logged against a baseline: totals, identity combinations, and orphans by namespace. It is not a report, it is a threshold: if profiles carrying a single identifier climb too fast, the Data Prep mapping is wrong and you see it that week.
- Query Service
- Identity
- Data Prep
- Runbook
-
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
Shared data layer for web, logged-in area and app
Three surfaces with three separate implementations, and therefore three versions of the truth. I rebuilt the data layer on all three against one event contract, coordinating a team of 5, with functional and technical documentation kept in Confluence.
- Data layer
- Web and app
- Event contract
-
Built 2021–2024
The risk map of the tag manager
You audit what you inherit, not what you built. A tag manager can rewrite the DOM and download scripts, so I ranked by risk what each piece could do across both sites. With a cookie inventory, Adobe Analytics cross-domain tracking, and the library served through a reverse proxy on its own domain.
- Tealium iQ
- Audit
- Risk
- Cookies
-
Built 2021–2024
Custom campaign channel taxonomy in Adobe Analytics
Campaign parameters in the URL are parsed with a per-channel grammar and mapped into Adobe Analytics variables, each with a declared meaning. It replaced an earlier position-based parser that broke as soon as an agency changed its tagging format.
- Adobe Analytics
- Attribution
- Taxonomy
- Paid media
-
Built 2021–2024
Adobe Target as a CDP destination, with audiences governed
Target not as an island but as a CDP activation destination with edge personalization. Publishing audiences from analytics has a cap and takes hours to become actionable, so the rule was written the other way around: audiences are created in the CDP and never in the personalization tool.
- Adobe Target
- Real-Time CDP
- Governance
- Activation
-
Built 2018–2021
Measurement template containers, reused across accounts
Reusable GTM template containers, exported and imported into each client account: one measurement base, one for ecommerce, one per consent platform, and one for app. Standardizing retail, fashion, travel, and automotive forces you to separate the data contract from the tool that implements it.
- Adobe Launch
- GTM
- Tealium iQ
- Standardization
-
Built 2018–2021
Daily SFTP ingestion into Drive, with three update modes
A Cloud Function starts a virtual machine at the scheduled time; the machine reaches the SFTP, loads the CSV files into Drive and Sheets, and shuts itself down when finished. The machine exists because of one specific constraint: the server only accepted a fixed IP, and Cloud Functions had none.
- Google Cloud
- Python
- Drive API
- SFTP
-
Built 2018–2021
Notebooks that configure analytics in bulk and close the ticket
Python notebooks against the Google Analytics management API to create and update goals, filters, custom dimensions, and permissions in bulk across accounts, properties, and views. Every change was diffed against the live configuration first, and the Jira ticket was transitioned on completion.
- Python
- Management API
- Jira
- Governance
Frequently asked questions
Do you need access to our platforms?
Read access, and only where it is needed and authorized. If access is not possible we can work from documentation, exports, and sessions with your team, though the diagnosis will be less precise. I never ask for credentials by email.
Will you change anything in production?
No. An audit observes and documents, it changes nothing. Executing the remediation is a separate engagement, decided after seeing the findings and scoped on its own.
What if the findings question decisions already made?
They get written down anyway. A report that avoids the uncomfortable parts is useless for deciding. Every finding comes with its evidence and its impact, so the discussion is about the data and not about who proposed it back then.
Can you execute what you find afterward?
Yes, as a separate engagement and with no obligation to hire it. The audit stands on its own: the remediation plan is written so your team or your existing vendor can execute it.
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.