Saltar al contenido principal
Adrià García
Menú
← Todos los servicios

Servicio

Auditoría de arquitectura e implementación

Analizo una implantación MarTech existente y convierto los problemas observados en hallazgos priorizados y un plan de remediación.

Qué incluye

  1. 01

    Mapa del flujo de datos, integraciones, dependencias, responsables y puntos de control.

  2. 02

    Revisión de recogida, calidad, identidades y activación según el alcance.

  3. 03

    Revisión del gobierno del dato, consentimiento, monitorización y recuperación operativa.

  4. 04

    Cada hallazgo con su impacto y su esfuerzo estimado.

  5. 05

    Plan de remediación ordenado.

Experiencia y criterio relacionados

  1. Construido 2025–2026

    La arquitectura del CDP, con el porqué de cada decisión escrito

    La arquitectura obvia no funciona, y hay que medirlo para saberlo. Un journey que escribe en el perfil no deja nada en el data lake, así que todo estado calculado dentro de un journey necesita una reconciliación nocturna para existir en SQL. De ahí sale el resto: esquemas, identidad y qué se persiste en cada sitio. Con el porqué escrito.

    • Arquitectura
    • AEP
    • Modelo de datos
    • Identidad
  2. Construido 2025–2026

    Resolución de identidades con Data Prep y Query Service

    Identidades resueltas en la ingesta con Data Prep y reconciliadas después mediante consultas programadas en Query Service. Los perfiles duplicados bajaron alrededor de un 30% y los emails sin mapear pasaron del 100% a menos del 50%.

    • Data Prep
    • Query Service
    • Identidad
  3. Construido 2025–2026

    Runbook semanal de salud de identidades, con baselines

    Consultas contra el snapshot de perfiles, lanzadas cada semana y anotadas contra un baseline: total, combinaciones de identidad y huérfanos por namespace. No es un informe, es un umbral: si los perfiles con un solo identificador suben más de la cuenta, el mapeo de Data Prep está mal y se ve esa semana.

    • Query Service
    • Identidades
    • Data Prep
    • Runbook
  4. Construido 2025–2026

    A quién no se borra: la parte difícil de una purga de perfiles

    Borrado por lotes de unas 250.000 identidades con work orders de Data Lifecycle, hasta volver al volumen contratado. La parte difícil no es borrar: es elegir a quién no. Un candidato con póliza activa o con personalización viva no se toca, y sin ese cruce previo la lista de candidatos no vale.

    • Data Lifecycle
    • Query Service
    • Retención
    • Identidades
  5. Construido 2025–2026

    Demostrar que el borrado ocurrió, que no es lo mismo que pedirlo

    Pedir el borrado con alcance total no basta. El dataset de reconciliación no se purgaba con él, y la cadena nocturna devolvía los perfiles cada mañana. Lo destapé con tres consultas independientes, junto a otro fallo: el snapshot guarda las identidades en minúscula y los eventos en camelCase, así que daban ceros falsos.

    • Data Lifecycle
    • Query Service
    • Reconciliación
    • Verificación
  6. Construido 2024–2025

    Consentimiento de OneTrust a AEP, por conector y por Event Forwarding

    El conector oficial de OneTrust solo ingiere consentimiento y preferencias, no cookies, y cada ejecución trae solo lo posterior a la anterior. Cubre el centro de preferencias, no el consentimiento que viaja con el evento web. Monté las dos vías: el conector para lo identificado y Event Forwarding para lo demás.

    • OneTrust
    • Event Forwarding
    • AEP
    • Consentimiento
  7. Construido 2021–2024

    Capa de datos común para web, área privada y app

    Tres superficies con tres implementaciones distintas, y por tanto tres verdades. Rehíce la capa de datos de las tres contra un mismo contrato de eventos, coordinando un equipo de 5, y con la documentación funcional y técnica mantenida en Confluence.

    • Data layer
    • Web y app
    • Contrato de eventos
  8. Construido 2021–2024

    El mapa de riesgo del gestor de etiquetas

    Se audita lo que se hereda, no lo que uno construye. Un gestor de etiquetas puede cambiar el DOM y descargar scripts, así que clasifiqué por riesgo qué podía hacer cada pieza en los dos sitios. Con inventario de cookies, el cross-domain de Adobe Analytics y la librería servida por proxy inverso desde el dominio propio.

    • Tealium iQ
    • Auditoría
    • Riesgo
    • Cookies
  9. Construido 2021–2024

    Taxonomía propia de canales de campaña en Adobe Analytics

    Los parámetros de campaña de la URL se trocean con una gramática propia por canal y se reparten en variables de Adobe Analytics, cada una con su significado declarado. Sustituyó a un parseo anterior por posiciones, que se rompía en cuanto una agencia cambiaba el formato de sus etiquetas.

    • Adobe Analytics
    • Atribución
    • Taxonomía
    • Paid media
  10. Construido 2021–2024

    Adobe Target como destino del CDP, con las audiencias gobernadas

    Target no como isla, sino como destino de activación del CDP con personalización en el edge. Publicar las audiencias desde la analítica tiene cupo y tarda horas en ser accionable, así que la regla se escribió al revés: las audiencias se crean en el CDP y nunca en la herramienta de personalización.

    • Adobe Target
    • Real-Time CDP
    • Gobierno
    • Activación
  11. Construido 2018–2021

    Contenedores plantilla de medición, reutilizados por cuenta

    Contenedores plantilla de GTM que se exportaban y se importaban en la cuenta de cada cliente: una base de medición, otra de ecommerce, una por cada plataforma de consentimiento y otra para app. Estandarizar retail, moda, viajes y automoción obliga a separar el contrato de datos de la herramienta que lo implementa.

    • Adobe Launch
    • GTM
    • Tealium iQ
    • Estandarización
  12. Construido 2018–2021

    Ingesta diaria de SFTP a Drive, con tres modos de actualización

    Una Cloud Function levanta una máquina virtual a la hora programada, que entra al SFTP, vuelca los CSV a Drive y Sheets y se apaga sola al terminar. La máquina existe por una restricción concreta: el servidor solo aceptaba una IP fija, y las Cloud Functions no la tenían.

    • Google Cloud
    • Python
    • Drive API
    • SFTP
  13. Construido 2018–2021

    Notebooks que configuran analítica en lote y cierran el ticket

    Notebooks en Python contra la API de gestión de Google Analytics para crear y actualizar objetivos, filtros, dimensiones personalizadas y permisos en lote sobre cuentas, propiedades y vistas. Cada cambio se comparaba antes contra la configuración vigente, y el ticket de Jira se transicionaba al terminar.

    • Python
    • Management API
    • Jira
    • Gobierno

Preguntas frecuentes

¿Necesitas acceso a nuestras plataformas?

De lectura, y solo cuando haga falta y esté autorizado. Si el acceso no es posible se puede trabajar con documentación, exportaciones y sesiones con vuestro equipo, aunque el diagnóstico será menos preciso. Nunca pido credenciales por correo.

¿Vais a tocar producción?

No. Una auditoría observa y documenta, no cambia nada. La ejecución de la remediación es un encargo distinto, que se decide después de ver los hallazgos y con el alcance acordado por separado.

¿Qué pasa si los hallazgos cuestionan decisiones ya tomadas?

Se escriben igual. Un informe que evita lo incómodo no sirve para decidir. Cada hallazgo va con su evidencia y su impacto, para que la discusión sea sobre los datos y no sobre quién lo propuso en su día.

¿Podéis ejecutar después lo que encontréis?

Sí, como encargo aparte y sin compromiso de contratarlo. La auditoría es útil por sí sola: el plan de remediación está escrito para que lo pueda ejecutar tu equipo o el proveedor que ya tengas.

¿Encaja con tu problema?

Cuéntame el contexto y te diré si este alcance es el adecuado o conviene empezar por otro sitio.

Hablar del alcance