Más de ocho años en consultoría, cinco de ellos trabajando a diario con Customer Data Platforms. Los proyectos realizados para clientes de mis anteriores empleadores se presentan de forma anónima.
Empecé en desarrollo e integración de sistemas. Después pasé por analítica, tag management y consentimiento antes de centrarme en Adobe Experience Platform, Real-Time CDP, AJO y CJA.
Ese recorrido me ayuda a tratar identidad, activación y medición como partes de una arquitectura, no como configuraciones separadas.
Un CDP de seguros desde cero: arquitectura, identidad y consentimiento, con procedimientos de operación para el equipo que recibe el traspaso.
Qué construí aquí
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.
Los eventos y cargas de sistemas legacy generaban perfiles duplicados. Las identidades se resolvieron en la ingesta con Data Prep y se reconciliaron después mediante consultas programadas en Query Service. Los duplicados bajaron alrededor de un 30% y los emails sin mapear se redujeron a menos de la mitad.
Pipeline de consentimientos desde Kafka hasta AEP, con una carga separada para el estado histórico que ya existía. Las dos cadencias importan: el consentimiento que llega en streaming y el que entra por detrás en una carga masiva tienen que acabar significando lo mismo.
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.
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.
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.
Patrones de personalización en Adobe Journey Optimizer para la app, con la reconciliación necesaria para que el estado operativo fuera auditable, recuperable y transferible. Sin eso, el journey funciona hasta el primer fallo y nadie sabe cómo dejarlo como estaba.
El gestor anterior devolvía en milisegundos qué incentivo aplicaba a cada cotización. Al desmontarlo quedó claro que era un motor de reglas, no de recomendación, así que Decisioning no era la respuesta para el primer alcance. Lo difícil era calcular N incentivos para N primas sin bucles en el editor de expresiones.
Arquitecturas AEP para banca y educación digital. En banca, el canal migró manteniendo el sistema de decisión. En educación, definí el origen de los datos para personalizar.
Qué construí aquí
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.
Modelo XDM, identidades, Web SDK y decisioning de ofertas para líneas de negocio distintas sobre una misma instancia. La primera línea nunca es el problema. El problema es que la segunda no obligue a rehacer el modelo de la primera.
Coordiné la migración del canal a Adobe Journey Optimizer sin tocar el sistema de decisión, integrando Pega con AEP y AJO, y consolidando más de 30 campañas de email. Cambiar el canal y el decisor a la vez es la forma más rápida de no poder aislar qué se rompió.
Trabajo sobre Experience Decisioning, la capacidad de decisión actual de Adobe Journey Optimizer, no el Decision Management heredado del offer decisioning anterior. La diferencia cambia dónde vive la oferta, cómo se pide y qué puede decidir el canal en el momento.
Personalizar un envío tiene dos fuentes, y elegir mal cuesta caro. Lo que el CDP ya sabe del cliente sale del perfil. Lo que solo se sabe en el momento de disparar, y por tanto no se puede anticipar, viaja como atributo de contexto en la propia llamada. Definí cuál de las dos alimenta cada dato.
Retargetizar ofertas sin montar un backend. Las últimas que el usuario ha visto se guardan en el navegador, en una cola corta que alimenta el evento de selección de las tarjetas. Vuelven en la siguiente petición de decisioning, para que la respuesta no repita lo mismo.
Mi responsabilidad pasó del etiquetado al contrato de datos de todo el catálogo del banco y las reglas de ejecución de scripts.
Qué construí aquí
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.
La captación de leads telefónicos del área privada iba por Walmeric. Integré el formulario y su envío, y llevé el identificador de visitante de Walmeric a la capa de datos, que es lo que ata la llamada con la sesión que la originó. Sobre Glassbox, mejoré su integración con Adobe Analytics.
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.
Lo heredé de otro proveedor y no era de fiar, así que hubo que rehacerlo casi entero: la capa de datos, las reglas de carga, las extensiones y los propios tags. Todo con el sitio en producción y sin ventana de parada, lo que obliga a ir por partes y a demostrar que lo nuevo dice lo mismo que lo viejo antes de apagar nada.
Una marca, pero dos mundos. El sitio comercial y el transaccional no comparten etiquetas, ni reglas de consentimiento, ni riesgo. Mantuve un perfil para cada uno, con Adobe Analytics y Target en los dos, y el grueso de las etiquetas publicitarias solo en el comercial.
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.
Píxeles de paid media desplegados client-side y server-side, con el enrutado sobre Tealium EventStream y GTM server-side. Los identificadores salían hasheados desde el navegador, validados antes de hashear y solo si el consentimiento lo permitía. La plataforma procesaba decenas de millones de eventos al mes.
Consentimiento cross-domain: una decisión tomada en un dominio tenía que valer en los demás y no romperse al saltar. Preproducción y producción, web y webview de la app, finalidades categorizadas y banners a medida. Y que esa decisión llegue entera a todos: API de TCF para los vendors, Consent Mode v2 para las etiquetas de Google.
La primera vista ocurre antes de que nadie haya aceptado nada. Mientras el banner está abierto la página queda cubierta, y esa vista se guarda en vez de perderse o de enviarse igualmente: se reproduce después, según las categorías aceptadas. Sin consentimiento no sale nada, y con él no se pierde la entrada a la sesión.
Una pieza promocional dentro del área autenticada, con su emplazamiento y su clic medidos como variables propias y no como una navegación más. Cada hueco se identifica por su slot, que es lo que permite compararlos entre sí y decidir con dato propio qué se mantiene y qué se retira.
Una herramienta de repetición de sesión ve la pantalla del usuario, y en el área privada de un banco eso es su dinero. En vez de confiar en el enmascarado por defecto, la lista de lo que puede capturar se declara: fuera de ella, no graba. Instalarla es fácil. Decidir qué tiene derecho a ver es el trabajo.
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.
Pasar de librerías heredadas por superficie a una sola recogida sobre Web SDK. Es la pieza que hace posible todo lo que viene después: sin una recogida única, ni el server-side, ni el perfil unificado, ni la migración a CJA se sostienen, porque heredan las divergencias que venían a resolver.
Con el SDR mantenido a mano durante años, sus eVars, props y eventos, y el control de calidad del dato que sostenía los informes. La migración no fue copiar el modelo antiguo, sino decidir qué parte de él seguía sirviendo para decidir.
Ecosistemas de medición estandarizados para varias cuentas corporativas, y las herramientas propias para mantenerlos sin rehacerlos cada vez.
Qué construí aquí
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.
Para una cuenta de moda, con la plataforma recién salida y sin las guías que hay hoy. Las dos propiedades convivieron en el mismo contenedor durante la transición, que es lo que permite comparar cifras y explicar las diferencias antes de apagar la antigua.
Implementación de los SDKs nativos y resolución de las integraciones híbridas entre la capa nativa y la web embebida. Es donde se pierden las sesiones y las identidades, y no se mira hasta que los números dejan de cuadrar.
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.
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.
Un contenedor server-side con clientes propios, no solo los de serie. Uno para la recogida heredada, otro para la nueva y otro de plataforma publicitaria, más peticiones salientes a una API propia. El contenedor está exportado en marzo de 2021, con la herramienta recién salida.
Una marca de gran consumo con filial en varios mercados europeos, y un cuadro de mando para cada uno. Construirlos no costaba. Lo que costaba era decidir quién ve qué, así que cada mercado llevaba declarado su destinatario y su nivel de acceso. Un informe compartido de más es una fuga y uno compartido de menos no se usa.
Plataformas y capacidades organizadas según mi experiencia práctica y el trabajo realizado.
Ingeniería Informática, especialidad de Computación. Universitat Autònoma de Barcelona, 2012 a 2017.
Castellano y catalán nativos. Inglés, nivel profesional de trabajo.
En las fichas encontrarás el detalle técnico: el problema, el trabajo realizado y el resultado.