Experiencia

Qué construí aquí

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

  Arquitectura · AEP

  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.

• Resolución de identidades con Data Prep y Query Service

  Data Prep · 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%.

• Consentimiento del bus de eventos al perfil y la activación

  Kafka · AEP

  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.

• Runbook semanal de salud de identidades, con baselines

  Query Service · Identidades

  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.

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

  Data Lifecycle · Query Service

  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.

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

  Data Lifecycle · Query Service

  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.

• Personalización en app con estado operativo recuperable

  AJO · Estado operativo

  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 de campañas, dentro de AJO y sin bucles

  Journey Optimizer · Kafka

  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.

Qué construí aquí

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

  OneTrust · 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.

• Arquitectura AEP para varias líneas de negocio

  XDM · Identidades

  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.

• El canal en AJO, con Pega intacto como decisor

  AJO · Pega

  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ó.

• Experience Decisioning de Journey Optimizer en banca

  Experience Decisioning · Journey Optimizer

  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.

• Atributos de perfil o de contexto: de dónde sale cada dato

  Journey Optimizer · Personalización

  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.

• Retargeting con las ofertas vistas guardadas en el navegador

  Decisioning · GTM

  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.

Qué construí aquí

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

  Data layer · Web 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.

• Walmeric y Glassbox integrados en la capa de medición

  Walmeric · Glassbox

  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.

• El mapa de riesgo del gestor de etiquetas

  Tealium iQ · Auditoría

  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.

• Cambiar el gestor de etiquetas de un banco sin apagar la medición

  Tealium iQ · Capa de datos

  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.

• Dos perfiles de Tealium dentro de una misma marca

  Tealium iQ · Adobe Analytics

  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.

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

  Adobe Analytics · Atribución

  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.

• Tracking server-side y atribución de paid media

  EventStream · Server-side GTM

  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 con Didomi, de cero

  Didomi · CMP

  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.

• Medición congelada hasta que el usuario decide en el banner

  Consentimiento · Tealium

  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.

• Componente promocional medido dentro del área privada

  Adobe Analytics · Área privada

  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.

• Lo que el session replay tiene permiso para grabar

  Glassbox · Privacidad

  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.

• Adobe Target como destino del CDP, con las audiencias gobernadas

  Adobe Target · Real-Time CDP

  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.

• Una sola recogida, sobre Adobe Web SDK

  Adobe Web SDK · alloy.js

  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.

• Migración de Adobe Analytics a Customer Journey Analytics

  Adobe Analytics · CJA

  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.

Qué construí aquí

• Contenedores plantilla de medición, reutilizados por cuenta

  Adobe Launch · GTM

  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.

• Migración temprana de Universal Analytics a GA4

  GA4 · Universal Analytics

  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.

• SDKs de analítica en iOS y Android, e integraciones híbridas

  iOS · Android

  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.

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

  Google Cloud · Python

  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 que configuran analítica en lote y cierran el ticket

  Python · Management API

  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.

• Tagging server-side con clientes propios, cuando sGTM acababa de salir

  Server-side GTM · Clientes propios

  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.

• Cuadros de mando por mercado, con el acceso gobernado

  Reporting · Gobierno

  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.