Skip to main content
Adrià García
← All services

Service

Architecture and implementation audit

I assess an existing MarTech implementation and turn the observed problems into prioritised findings and a remediation plan.

What is included

  1. 01

    A map of data flows, integrations, dependencies, owners, and control points.

  2. 02

    A review of collection, quality, identity, and activation as scoped.

  3. 03

    Consent and DULE review: restrictions, labels, policies, marketing actions and blocking tests as scoped.

  4. 04

    A review of monitoring, data freshness, owners and recovery procedures.

  5. 05

    Each finding with its impact and its estimated effort.

  6. 06

    An ordered remediation plan.

Optional

  • As a separate engagement: implement checks, alerts and recovery procedures, or execute prioritised remediation.

Related experience and reasoning

  1. 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
  2. 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
  3. 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
  4. 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

Explore more work in my career history →

Frequently asked questions

Do you need access to our platforms?

Read access, and only where it is needed and authorised. 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 afterwards?

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.

Discuss the scope

Explore this decision