La historia detrás de otra extensión que nadie me pidió

Llevo años peleándome con GTM server-side. Desde que Google lo lanzó, ha sido una montaña rusa de emociones: primero el subidón —"¡wow, esto es el futuro!"—, después la realidad de la implementación —ese momento en que te preguntas si no estarías mejor con tu huertecito allá lejos, en la montaña—, y finalmente la aceptación de que algunas cosas podrían ser más simples.

Y ese último punto es el que me llevó a crear sGTM PreviewEZ. Porque, seamos sinceros, el flujo de trabajo para depurar implementaciones server-side es un auténtico dolor de muelas.

El problema: la realidad del modo vista previa en sGTM

Antes de sumergirme en la solución, hablemos de cómo se depura normalmente GTM server-side. Existen dos métodos principales:

Método 1: El clásico modo de vista previa de GTM

El método oficial de Google funciona así:

1. Abres la interfaz de GTM

2. Seleccionas el contenedor server-side

3. Pulsas "Preview"

4. Se abre una nueva ventana con el depurador

   

5. Navegas a tu sitio web en la misma sesión del navegador e interactúas con él siguiendo el flujo que quieras revisar

6. Las solicitudes que pasan por tu servidor GTM aparecen en la ventana de depuración

   

Como explica Optimize Smart en su guía, este método tiene algunas limitaciones importantes:

• Restricción a una misma sesión: Solo funciona si navegas directamente desde la ventana de vista previa

• Problemas con iframes y redirecciones: Muchas veces se pierde la conexión con el depurador

• No detecta todas las peticiones: Especialmente las que utilizan sendBeacon o se envían desde código de servidor

• Cookies de terceros: Con las restricciones actuales, el modo preview puede fallar en navegadores que bloquean cookies de terceros

• Limitación a un solo navegador: No puedes depurar en dispositivos móviles u otros navegadores simultáneamente

Método 2: La técnica del token manual (X-Gtm-Server-Preview)

Para casos más complejos, como documenta detalladamente Julius Fedorovicius en Analytics Mania, existe una técnica alternativa usando un header HTTP especial:

1. Inicias el modo vista previa desde la interfaz de GTM

   

2. Clicas en los tres puntos que se ven en la esquina superior derecha y selecciona “Send Requests manually“

   

3. Se te abrirá un pop-up con la cabecera mágica X-Gtm-Server-Preview:

   

4. Utiliza este valor codificado como valor de cabecera en tus peticiones

5. Envía la petición directamente al endpoint de tu servidor GTM

6. Las solicitudes que pasen por tu servidor GTM aparecerán de nuevo en la ventana de depuración

   

Esta técnica te permite:

• Depurar peticiones desde cualquier dispositivo o herramienta (Postman, cURL, etc.)

• Evitar las limitaciones de cookies y sesiones del navegador

• Probar directamente contra el endpoint sin necesidad de navegar por el sitio web

• Enviar datos de prueba incluso cuando el sitio no está disponible

Sin embargo, como señala Julius, este proceso es tedioso y propenso a errores:

• Necesitas reconstruir manualmente el token cada vez

• El formato debe ser exactamente correcto

• Cada vez que expira el preview (cada hora) debes generar un nuevo token

• Tienes que modificar manualmente cada petición que quieras depurar

Por satisfacer la curiosidad de muchos, este token no es más que la combinación del valor de tres cookies —disponibles en la vista previa de GTM server-side—:

1. El parámetro gtm_preview, que suele ser algo como env-XX

2. El parámetro gtm_auth compuesto por un código alfanumérico

3. El parámetro gtm_debug, que no es más que otro código alfanumérico

Bajo el formato: btoa(“env-XX|gtm_auth_token|gtm_debug_token”) (codificado en Base64, vaya)

La solución: automatizar el token sin perder el depurador oficial

sGTM PreviewEZ automatiza precisamente este segundo método. Hace todo el trabajo pesado:

1. Genera automáticamente el token de preview con el formato correcto

2. Lo codifica en Base64

3. Lo inyecta en todas las peticiones que coinciden con tu patrón configurado

4. Renueva el token automáticamente cuando expira

5. Funciona incluso con peticiones sendBeacon que normalmente son difíciles de interceptar

Esto significa que puedes disfrutar de todos los beneficios del método manual, sin ninguno de sus inconvenientes:

• Depurar peticiones directas a tu endpoint sin navegación previa

• Probar eventos enviados con sendBeacon (sobre todo si has montado algún tipo de proxy o middleware)

• Mantener el token activo sin tener que renovarlo manualmente (en el peor de los casos, es hacer un simple clic)

• Interceptar y modificar las peticiones en tiempo real

• Trabajar con múltiples pestañas y contextos simultáneamente

Cómo funciona realmente (para los curiosos)

Para los que quieran entender el funcionamiento interno, la extensión hace lo siguiente:

1. Autenticación con Google: Usa las cookies existentes de Chrome para autenticarse con la API de GTM (sin almacenar tus credenciales)

2. Generación de preview: Solicita un token de preview a través de las APIs oficiales de GTM (las mismas que usa la interfaz web)

3. Construcción del token X-Gtm-Server-Preview: Formatea y codifica en Base64 los parámetros necesarios

4. Interceptación de solicitudes: Utiliza las capacidades de Chrome para interceptar solicitudes antes de que salgan del navegador

5. Inyección de headers: Añade el header X-Gtm-Server-Preview a las solicitudes que coinciden con tu patrón

6. Monitorización en tiempo real: Mantiene un ojo en tus solicitudes para asegurarse de que todo funciona correctamente

Y para los que trabajáis con cuerpos de petición JSON —¿quién no hoy en día?—, también puede inyectar el token directamente en el payload, con tres modos diferentes de inyección para adaptarse a cualquier estructura de datos.

Seguridad: la paranoia como filosofía

"Esto suena genial, pero... ¿qué pasa con mis datos?" —dice el experto en privacidad que todos llevamos dentro.

Aquí va mi respuesta: la extensión NO almacena credenciales, NO envía datos a servidores externos, y NO accede a nada más allá de lo estrictamente necesario para funcionar. Todo se procesa localmente en tu navegador.

El código está diseñado para ser lo más transparente posible.

Cómo empezar a usarla

1. Instala la extensión desde la Chrome Web Store

2. Haz clic en el icono de la extensión y fíjala en tu navegador

   

3. Introduce tu ID de cuenta GTM (ese primer número que aparece en la URL

   https://tagmanager.google.com/#/container/accounts/123456789/containers/987654321/workspaces/4) o también lo puedes consultar en la sección “Administrador/Cuenta/Configuración de la cuenta” de GTM:

   

4. Selecciona tu contenedor server-side:

   

   Si no tuvieras acceso a la cuenta, saldrá un mensaje de error como este:

   

5. Selecciona el contenedor GTM server-side

   

   Si esta cuenta no tiene contenedor GTM server-side, verás un mensaje de error como este:

   

6. Elige el workspace que quieres depurar:

   

7. Configura el patrón de dominio (ej: *.midominio.com)

   

8. ¡Activa y disfruta!

La extensión abrirá automáticamente el depurador oficial de GTM Server-Side para que puedas ver los resultados como lo harías normalmente, pero sin tener que lidiar con la gestión manual del token.

Recuerda activar la opción de “Permitir acceso a URL de archivo” para que funcione correctamente todo:

Funcionalidades adicionales que facilitan tu vida

• Renovación automática de tokens: Olvídate de la frustración de los tokens caducados (los tokens siguen caducando a la hora, pero tan solo tienes que recargar tu página para que se actualice la cabecera)

• Inyección en payload: Para APIs que no admiten cabeceras personalizadas

• Compatibilidad con sendBeacon: Captura eventos que el modo preview tradicional podría perder

• Modo middleware: Perfecto para quienes trabajan con arquitecturas API más complejas

• Modo debug GA4: Activa automáticamente el modo debug de GA4 para una depuración aún más detallada (en fase de pruebas, así que es posible que no esté todavía habilitado correctamente)

Si clicas en “Open Configuration” podrás ver más información sobre la propiedad GTM server-side, así como diferentes funcionalidades:

Bonus Track: Vista mejorada para GA4, Meta y MixPanel

Como si automatizar los tokens no fuera suficiente, he añadido una funcionalidad extra que hace la vida aún más fácil: un visor mejorado de peticiones, al estilo Omnibug, para las llamadas más comunes.

Cuando trabajas con implementaciones de GA4, Meta (Facebook) o MixPanel a través de GTM server-side, ahora podrás ver los datos en un formato mucho más comprensible y estructurado. En lugar de tener que descifrar el JSON crudo de las peticiones, la extensión te presenta los parámetros importantes de forma clara y organizada.

Por ejemplo, para las llamadas a Meta (Facebook), podrás ver fácilmente:

• El tipo de evento (PageView, Purchase, etc.)

• La fuente de la acción

• Timestamp del evento

• Datos de usuario

• Toda la información técnica relevante

Esto es especialmente útil cuando estás depurando conversiones o eventos complejos y necesitas confirmar rápidamente que todos los parámetros se están enviando correctamente.

Esta visualización mejorada funciona de forma automática: cuando la extensión detecta una llamada a uno de estos servicios, reorganiza la información para que puedas encontrar lo que buscas sin tener que navegar por montañas de código JSON.

Considéralo un pequeño regalo adicional para hacer tu experiencia de depuración aún más agradable 😉.

Esta sección está todavía en fase beta —justo estoy trabajando ya corrigiendo algunas cosas en GA4—, por lo que si ves algo extraño o que no cuadra, te agradecría un montón que me contactaras y me dijeras qué has visto raruno.

Y como suelen decir que una imagen vale más que mil palabras, aquí dejo un vídeo (está difuminado a propósito, no te has pasado con el alcohol ni te está dando un ictus, tranquilo):

Conclusión: el poder está en los detalles

Esta extensión no pretende sustituir las herramientas oficiales de Google. Su objetivo es simplemente hacer que el proceso de depuración sea más fluido y menos tedioso, para que puedas centrarte en lo importante: solucionar problemas reales.

Échale un vistazo y si tienes cualquier duda o detectas algún bug, házmelo saber.

Deja un comentario

En los artículos anteriores, hemos explorado cómo implementar una solución basada en proxies para proteger nuestras herramientas analíticas y de consentimiento. Pero seamos honestos: no hemos inventado la rueda. Si bien nuestra solución es robusta y está bien estructurada, sigue siendo vulnerable a bloqueadores más sofisticados. Hoy vamos a hablar de estas limitaciones y cómo podemos fortalecer nuestra defensa.

El talón de Aquiles: El CMP como punto único de fallo

Los bloqueadores de anuncios se han vuelto más inteligentes. Muchos, en lugar de intentar bloquear todas las herramientas analíticas una por una, han identificado un punto débil crítico: el CMP y han puesto todo de su parte por bloquearlo sí o sí. Aquí en Europa la lógica es simple y efectiva: si bloquean el gestor de consentimiento, indirectamente bloquean toda la analítica que depende de él. Es como cortar el agua en la entrada del edificio en lugar de cerrar todos los grifos uno por uno.

Justo ahora es cuando la cosa se pone interesante: las extensiones modernas y muchos navegadores no se limitan a bloquear solicitudes HTTP. También manipulan el DOM e interfieren con los objetos JavaScript que nuestro CMP y nuestras herramientas de analítica generan —como ya hablamos en los anteriores artículos—. Pueden:

• Ocultar o eliminar el banner de consentimiento

• Manipular las funciones del objeto JS de nuestro CMP

• Simular interacciones de usuario para rechazar automáticamente las cookies

• Modificar el almacenamiento local y las cookies

• Notificar a las herramientas de analítica sobre el rechazo del consentimiento

Y para muestra un botón:

Aquí os comparto un enlace de Ghostery con más información al respecto.

Read more

En el primer artículo de esta serie, exploramos cómo funcionan los sistemas de bloqueo de publicidad y recopilación de datos, y establecimos las bases teóricas para superar estas restricciones utilizando proxies y personalizaciones técnicas. En este segundo artículo, profundizaremos en la implementación práctica de una solución robusta basada en el framework Flask —ay, mi querido Python—, diseñada para garantizar que herramientas críticas como la plataforma de consentimiento —Cookiebot en este caso—, Google Tag Manager y Google Analytics 4 funcionen sin interrupciones, incluso en entornos con bloqueadores activos. Y para muestra, un botón:

El desafío técnico de mantener la funcionalidad

Los bloqueadores de anuncios y navegadores centrados en la privacidad —como Ghostery o Brave— han evolucionado significativamente en los últimos años. Sus técnicas de bloqueo, basadas en patrones regex, manipulación del DOM y limitaciones en las APIs de extensiones, hacen que herramientas como CMPs, GTM y GA4 sean vulnerables a interrupciones. Sin embargo, con una arquitectura bien diseñada, podemos garantizar que estas herramientas sigan funcionando correctamente, siempre respetando el consentimiento del usuario y cumpliendo con normativas como el GDPR y el CCPA.

En este artículo, detallaré cómo he implementado una solución basada en proxies en Flask para gestionar las librerías de Cookiebot , GTM y GA4 , asegurando un flujo continuo de datos incluso en entornos bloqueados.

Read more

En este primer artículo de la serie, exploraremos cómo funcionan los sistemas de bloqueo de publicidad y recopilación de datos, y estableceremos las bases para entender cómo superarlos utilizando proxies y personalizaciones técnicas. Antes de entrar en detalles, es esencial comprender los principios detrás de las herramientas que bloquean estas peticiones, ya sean extensiones como Adblock Plus o navegadores como Brave. Curiosamente, aunque difieren en implementación, todos se basan en principios similares.

¿Cómo funcionan los sistemas de bloqueo de peticiones?

Antes de meternos en harina, vamos a hacer un repaso sobre las principales técnicas utilizadas por extensiones y navegadores para bloquear —con bastante éxito, todo sea dicho— las plataformas de consentimiento, herramientas de analítica y de terceros en general más conocidas del mercado.

1. Bloqueo de requests basado en patrones (Regex)

Uno de los enfoques más comunes que utilizan las herramientas de bloqueo es escuchar todas las solicitudes salientes (requests) realizadas por el navegador. Luego, comparan estas solicitudes contra una lista de patrones definidos con expresiones regulares (regex) o reglas específicas. Si una URL coincide con un proveedor de anuncios o analítica conocido, la request se bloquea antes de que se realice.

Ejemplo práctico:

• URL: https://www.google-analytics.com/collect

• Regex: .*google-analytics\.com.*

Esto ocurre directamente desde el navegador, interceptando las solicitudes HTTP/HTTPS antes de que lleguen al servidor. Este mecanismo permite bloquear librerías como las de Google Analytics, OneTrust, o cualquier herramienta de marketing fácilmente identificable.

2. Interacción con objetos JavaScript en el DOM

Otra estrategia clave es monitorizar —o últimamente tan solo interactuar con— los objetos JavaScript que se crean en el Document Object Model (DOM). Estas herramientas pueden identificar y manipular dichos objetos para evitar que envíen datos al servidor, para bloquear el acceso a información sensible o simplemente interactuar con ellos para simular determinados comportamientos.

Ejemplo práctico para Cookiebot:

const CMPFunctions = {
    async detectCmp() {
        return await !!window.Cookiebot;
    },
    async detectPopup() {
        return !window.Cookiebot.hasResponse && window.Cookiebot.dialog?.visible === true;
    },
    async optOut() {
        await this.wait(500);
        let res = await window.Cookiebot.withdraw() || true; // withdraw
        await this.wait(500); // prevent race conditions
        res = res && (await window.Cookiebot.hide() || true); // hide
        return res;
    }
};

Este código que he compartido con vosotros, es una “ligera” adaptación de lo que hace la extensión del fantasma —que no quiero líos— para rechazar cookies en el caso específico de Cookiebot, activándolo previamente desde su interfaz

3. Manipulación del DOM para bloquear interacciones

El tercer enfoque común se centra en interactuar directamente con los elementos del DOM generados por la página. Las herramientas de bloqueo pueden:

• Identificar banners o botones del CMP.

• Simular clics para seleccionar automáticamente configuraciones restrictivas (ej., "Denegar todo").

• Ocultar o eliminar elementos visuales relacionados con anuncios o consentimientos.

Ejemplo práctico también para Cookiebot:

 async optIn() {
        if (this.elementExists('#dtcookie-container')) {
            return this.click('.h-dtcookie-accept');
        }

        this.click('.CybotCookiebotDialogBodyLevelButton:not(:checked):enabled', true);
        this.click('#CybotCookiebotDialogBodyLevelButtonAccept');
        this.click('#CybotCookiebotDialogBodyButtonAccept');
        return true;
    }

En este ejemplo, vemos como se puede simular un clic en “Aceptar” dentro del banner de Cookiebot. También de nuestro amigo el fantasma.

Manifest V3 de Google y su impacto en los ad blockers

Lo mismo ahora, después de ver lo que una extensión puede llegar a hacer, te preguntas sobre la legalidad de todo esto, y si se están tomando medidas al respecto para controlar todo esto. La respuesta es sí. En el caso específico de Google, con la actualización del manifest de sus extensiones a la versión 3.

Gracias al Manifest V3 (MV3), Google ha dado un paso significativo para reformar el ecosistema de las extensiones en Chrome. Este cambio afecta directamente a los ad blockers y, en consecuencia, a las soluciones que buscan superar sus restricciones. Pero, ¿qué implica realmente el Manifest V3?

1. Limitaciones técnicas para extensiones:

   • Con el MV3, Google ha reemplazado la API webRequest, ampliamente utilizada por bloqueadores de anuncios para interceptar y modificar solicitudes de red, por la API declarativeNetRequest. Esta nueva API tiene restricciones importantes:

     • Un límite de 30.000 reglas por extensión, lo que puede ser insuficiente para bloquear todos los scripts relacionados con analítica y publicidad en sitios web complejos.

     • Menor flexibilidad para aplicar bloqueos dinámicos o personalizados.

2. Privacidad y rendimiento como justificación:

   • Según Google, el MV3 mejora la privacidad y seguridad al limitar el acceso de las extensiones a datos sensibles y, al mismo tiempo, optimiza el rendimiento del navegador al reducir la carga de procesamiento de reglas.

3. Impacto en ad blockers:

   • Los desarrolladores de extensiones de bloqueo han adaptado sus herramientas a las nuevas limitaciones, pero no sin críticas. Herramientas como uBlock Origin han expresado preocupación por la pérdida de funcionalidades avanzadas que permitían un bloqueo más preciso y dinámico.

4. ¿Un cambio estratégico de Google?

   • Algunos críticos ven el MV3 como una estrategia de Google para proteger su modelo publicitario. Al limitar la capacidad de los bloqueadores de anuncios, más anuncios (y scripts analíticos) pueden atravesar las barreras y llegar al usuario.

Read more

Cuando navegamos por una página, nos enfrentamos a un flujo constante de solicitudes y respuestas que hacen posible todo: desde cargar imágenes hasta obtener datos dinámicos de una API. Y es que internet es como una gran carretera… Si trabajas en data collection, analítica digital o simplemente quieres entender mejor cómo funciona la web, aprender a capturar estas peticiones es una habilidad esencial.

Hoy te cuento cómo funciona este sistema, qué tipos de solicitudes puedes encontrar y, por supuesto, cómo interceptarlas de manera práctica con ejemplos que uso habitualmente.

¿Cómo funciona la web? Una historia de solicitudes y respuestas

En esencia, cada vez que cargas una página o interactúas con ella, tu navegador envía una solicitud (request) a un servidor. El servidor procesa esa solicitud y envía una respuesta (response) con los datos necesarios: HTML, JSON, imágenes, etc.

Los tipos de solicitudes más comunes:

• GET: Pide datos al servidor. Ejemplo: cargar una página o buscar productos.

• POST: Envía datos al servidor. Ejemplo: enviar un formulario o guardar una compra.

• AJAX: Solicitudes dinámicas sin recargar la página. Ejemplo: actualizar solo parte de una página en una SPA.

¿Qué es una API? (Explicado para mortales)

Una API (Application Programming Interface) es, básicamente, un conjunto de reglas que permite a diferentes sistemas hablar entre sí. Piensa en ella como un camarero que lleva tus pedidos (solicitudes) a la cocina (el servidor) y te trae la comida (respuesta) —este es, sin duda, mi símil favorito para explicar a la gente cómo funciona internet—.

Un ejemplo:

• Petición: "Quiero los productos más vendidos en esta categoría."

• Respuesta: Una lista en formato JSON con esos productos.

Entender cómo las APIs envían y reciben datos es clave para capturar información útil para tu estrategia de datos. Y esto no lo digo yo; según un estudio de CA Technologies, en 2016, más del 70% de las empresas ya utilizaban APIs para desarrollar aplicaciones; así que imagínate ahora…

Cómo capturar peticiones en la práctica

Ya es hora de pasar a la acción. Aquí tienes dos técnicas clave para interceptar solicitudes: DevTools —la forma manual que se suele utilizar para auditar sitios web o para comprobar si una implementación se ha realizado correctamente— y código JavaScript —mi favorita, donde puedes hacer auténtica magia—.

Capturar peticiones con DevTools

Cuando se trata de auditar sitios web, el navegador es tu mejor aliado. En el panel de red puedes ver todas las solicitudes realizadas por una página.

Cómo hacerlo:

1. Abre las herramientas de desarrollo (F12 en la mayoría de navegadores).

2. Ve a la pestaña "Network" o "Red".

3. Realiza una acción en la página (como un clic o recarga).

4. Observa las solicitudes en tiempo real.

¿Quieres saber qué datos viajan en esas solicitudes? Haz clic en una de ellas y revisa el apartado "Payload" (lo que el navegador envía) o "Response" (lo que el servidor devuelve).

Capturar peticiones con fetch, XMLHttpRequest y sendBeacon

Si quieres automatizar el análisis o capturar datos en tiempo real, puedes interceptar solicitudes usando JavaScript. Para ello se utilizan distintos métodos, cada uno con sus propias características y ventajas… A continuación, te explico los tres más conocidos —y utilizados—.

Importante: Si intentas interceptar cualquier petición a través de un TMS client-side, ten en cuenta que este código se ejecutará en tu página después de que se haya cargado tu gestor de etiquetas, por lo que solo podrás capturar solicitudes a partir de ese momento. Si quieres capturar lo que ha ocurrido anteriormente, te aconsejo utilizar la API performance con su método getEntries():

const entries = performance.getEntries();
entries.forEach(entry => {
    console.debug(`Solicitud capturada: ${entry.name}, tipo: ${entry.initiatorType}`);
});

Interceptando fetch

El método fetch es el estándar moderno para realizar solicitudes basadas en promesas —sí, sí, como lees—, por lo que funciona bastante bien con peticiones asíncronas. La elección moderna y flexible para la mayoría de solicitudes.

Aquí te muestro cómo capturarlas:

// Guardamos el método fetch original
const originalFetch = window.fetch;

// Reemplazamos fetch con nuestra versión personalizada
window.fetch = function (...args) {
    console.debug('Interceptando solicitud a:', args[0]); // URL de la solicitud

    // Continuamos con la solicitud original
    return originalFetch.apply(this, args).then(response => {
        console.debug('Respuesta interceptada:', response);
        return response;
    });
};

Esto te permitirá ver cada solicitud que se realiza con fetch, además de analizar las respuestas. Cuando trabajaba en consultoría, este era uno de mis códigos de cabecera cuando no podía contar con el equipo de desarrollo del cliente. De esta forma, podía interceptar cualquier llamada que se realizara y así crear mis propios triggers o incluso modificar la respuesta de alguna petición antes de que se llegara a ejecutar.

Interceptando XMLHttpRequest

Aunque cada vez menos común, XMLHttpRequest se sigue utilizando en muchas páginas —es el padre del fetch, por mucho que nos pese—. Si necesitas compatibilidad con navegadores antiguos, este es tu método.

Así puedes capturarlo:

// Guardamos el método open original
const originalOpen = XMLHttpRequest.prototype.open;

// Reemplazamos open con nuestra versión personalizada
XMLHttpRequest.prototype.open = function (...args) {
    console.debug('Interceptando XHR a:', args[1]); // URL de la solicitud
    return originalOpen.apply(this, args);
};

Si bien es cierto que cada vez más frameworks lo han reemplazado por fetch, muchas páginas web siguen utilizándolo, por lo que no está de más saber cómo interceptarlo, ¿no?

Sin ir más lejos, en Angular 17.3 se ha producido un cambio importante: el HttpClient ahora usa fetch por defecto en lugar de XMLHttpRequest. Este cambio está relacionado con cómo Angular ahora maneja internamente las peticiones HTTP usando su propio sistema de transformación antes de que lleguen al nivel de fetch, lo que hace que las técnicas tradicionales de interceptación a nivel de cliente no funcionen como antes; por lo que si te enfrentas a este problema y se ha cambiado a withFetch(), llevas las de perder desde cliente, ya que la única forma "oficial" de interceptar estas peticiones ahora sería: utilizar los interceptores HTTP de Angular o revertir a withXhrBackend().

Interceptando sendBeacon

La API sendBeacon está diseñada para enviar datos al servidor de forma asíncrona y sin bloquear el hilo principal, lo que la convierte en una excelente opción para data collection. Es especialmente útil cuando necesitas garantizar que los datos se envían incluso si el usuario cierra la pestaña o navega fuera de la página. En este caso, la mejor forma de interceptarlo es así:

// Guardamos el método original de sendBeacon
const originalSendBeacon = navigator.sendBeacon;

// Reemplazamos sendBeacon con nuestra versión personalizada
navigator.sendBeacon = function (url, data) {
    console.debug('Interceptando sendBeacon:');
    console.debug('URL:', url);
    console.debug('Datos enviados:', data);

    // Puedes analizar o modificar los datos antes de enviarlos
    if (url.includes('/analytics') && typeof data === 'string') {
        const modifiedData = data.replace('session_end', 'modified_session_end');
        console.debug('Datos modificados:', modifiedData);
        return originalSendBeacon.call(this, url, modifiedData); // Enviamos los datos modificados
    }

    // Continuamos con el envío original si no hay cambios
    return originalSendBeacon.call(this, url, data);
};

Aunque sendBeacon es una excelente opción, resulta clave conocer sus limitaciones:

1. Tamaño máximo: Los navegadores tienen límites en el tamaño de datos que puedes enviar. Chrome y Firefox permiten hasta 64KB, mientras Safari tiene un límite de 2MB. Esto significa que debes ser cuidadoso con la cantidad de datos que intentas enviar en una sola llamada.

2. Soporte de navegadores: Si bien la adopción es bastante buena (más del 97% según Can I Use), hay que tener en cuenta que Internet Explorer no lo soporta en absoluto. Es recomendable implementar un fallback siempre que se pueda :

   const enviarDatos = (url, datos) => {
       if (navigator.sendBeacon) {
           return navigator.sendBeacon(url, datos);
       } else {
           // Fallback a fetch
           return fetch(url, {
               method: 'POST',
               body: datos,
               keepalive: true // Importante para garantizar el envío
           });
       }
   };

3. Sin respuesta del servidor: sendBeacon está diseñado para ser fire-and-forget. No devuelve ninguna información sobre si la petición fue exitosa o falló, lo cual puede ser un problema si necesitas confirmar la recepción de datos.

4. Método POST únicamente: sendBeacon solo puede realizar peticiones POST. Si necesitas otro tipo de método HTTP, deberás usar fetch o XMLHttpRequest.

5. No puedes establecer headers personalizados: A diferencia de fetch, no puedes configurar headers específicos, lo que puede ser limitante para algunas implementaciones.

Reconozco que soy muy fan de sendBeacon —el hecho de que sea asíncrono y no tengas que esperar a la respuesta del servidor para garantizar su envío me parece un plus para cualquier herramienta de analítica—. De hecho, lo mismo en algún artículo futuro cuento cómo hago yo para sustituir todas las request de los clásicos collect de GA4 a sendBeacon. Esto para mí resulta clave, sobre todo si quieres trabajar con GTM server-side.

Casos prácticos en data collection

Lo mismo te estás preguntado para qué sirve todo esto, ¿no? Aquí tienes algunos ejemplos reales:

• Auditar datos enviados a terceros:

Identifica qué datos está enviando tu sitio y asegúrate de que cumplen con la normativa (GDPR, por ejemplo) o que los datos llegan correctamente a su destino.

Vale, sí, tal vez sea un carca y me digas que para eso tenemos extensiones —Omnibug sin duda es mi favorita—. Pero muchas veces tenemos que identificar determinadas requests ad-hoc y, lamentablemente, no suele haber extensiones para ello (aunque siempre puedes crear tu propia extensión, amigo mío).

• Recuperar identificadores únicos:

Usa las respuestas para capturar datos como userId o sessionId y enviarlos al dataLayer.

window.dataLayer = window.dataLayer || [];
fetch('/api/user-info').then(response => response.json()).then(data => {
    window.dataLayer.push({ userId: data.id });
    console.debug('Usuario capturado:', data.id);
});

Este es un trabajo que, en teoría, se debería de haber implementado en el código fuente de la página; pero, lamentablemente, no siempre es así. Y es que muchas veces surgen problemas de última hora —implementaciones de la nada, cambio repentino de proveedores…

• Redirigir o bloquear solicitudes:

Cambia endpoints obsoletos o bloquea solicitudes a endpoints no deseados.

// Guardamos el método original de sendBeacon
const originalSendBeacon = navigator.sendBeacon;

// Reemplazamos sendBeacon con una versión personalizada
navigator.sendBeacon = function (url, data) {
    console.debug('Interceptando sendBeacon:');
    console.debug('URL original:', url);
    console.debug('Datos enviados:', data);

    // Redirigir solicitudes a un nuevo endpoint
    if (url.includes('/old-endpoint')) {
        const newUrl = url.replace('/old-endpoint', '/new-endpoint');
        console.log('Redirigiendo solicitud a:', newUrl);
        return originalSendBeacon.call(this, newUrl, data);
    }

    // Bloquear solicitudes no deseadas
    if (url.includes('/blocked-endpoint')) {
        console.warn('Bloqueando solicitud a endpoint no deseado:', url);
        return false; // Indicamos que no se realizó la solicitud
    }

    // Continuar con la solicitud original si no cumple las condiciones anteriores
    return originalSendBeacon.call(this, url, data);
};

Importante: esto que te indico no es la forma recomendable —aunque haya veces que sea la única opción disponible, la verdad—.

Optimiza tu estrategia de datos

La captura de peticiones no es solo una habilidad técnica; es una herramienta clave para auditar, enriquecer y controlar los datos que fluyen en tus proyectos. Y créeme cuando te digo que no todos entienden de qué se trata, ni mucho menos saben cómo hacerlo correctamente.

👉 Si quieres llevar tu estrategia de datos al siguiente nivel, ¡empieza a explorar estas técnicas hoy mismo!

Oye, ¿y eso de los Proxies?

Si has llegado hasta aquí y quieres llevar tu conocimiento al siguiente nivel, déjame preguntarte algo: ¿te interesa que hablemos de los Proxies en JavaScript?

Los Proxies permiten interceptar no solo solicitudes, sino también cualquier operación sobre objetos. Son una herramienta avanzada que podría cambiar la forma en que manejas tu estrategia de datos.

📩 Déjame un comentario si te interesa este tema, y prometo dedicarle un artículo completo.

Deja un comentario

Una de las bases de cualquier implementación técnica en el mundo digital es sin duda la interacción con el DOM (Document Object Model). Ya sea para capturar interacciones, construir una capa de datos dinámica o simplemente manipular elementos, entender cómo acceder al DOM y usarlo correctamente puede marcar la diferencia entre una solución robusta y un caos lleno de race conditions. Para interactuar con el DOM, lo primero es identificar correctamente los elementos que necesitas manipular. Y aquí es donde entran en juego los IDs y las clases.

¿Qué son los IDs y las clases en el DOM?

Antes de meternos en harina con los métodos para acceder al DOM, es importante entender dos conceptos clave: ID y class. Son atributos fundamentales en HTML que sirven para identificar y agrupar elementos dentro de una página.

ID: Un identificador único

El atributo id se utiliza para identificar de manera única un elemento en una página. Cada id debe ser único dentro del DOM, lo que significa que no puede repetirse en otros elementos.

Ejemplo en HTML:

<div id="header">Este es el encabezado</div>
<p id="intro">Este es el párrafo de introducción</p>

Cómo seleccionarlo en JavaScript:

• Usando getElementById:

const header = document.getElementById('header');
console.log(header.textContent); // Salida: Este es el encabezado

• Usando querySelector:

const header = document.querySelector('#header');
console.log(header.textContent); // Salida: Este es el encabezado

Nota: En querySelector, los IDs siempre se seleccionan con # antes del nombre del ID.

Class: Agrupando elementos

El atributo class se utiliza para agrupar elementos que comparten características similares. A diferencia de los IDs, las clases pueden repetirse en múltiples elementos.

Ejemplo en HTML:

<div class="item">Elemento 1</div>
<div class="item highlighted">Elemento 2</div>
<div class="item">Elemento 3</div>

Cómo seleccionarlo en JavaScript:

• Usando getElementsByClassName:

const items = document.getElementsByClassName('item');
console.log(items.length); // Salida: 3

• Usando querySelector o querySelectorAll:

const firstItem = document.querySelector('.item'); // Selecciona el primer elemento con la clase "item"
const allItems = document.querySelectorAll('.item'); // Selecciona todos los elementos con la clase "item"
console.log(allItems.length); // Salida: 3

Nota: En querySelector y querySelectorAll, las clases se seleccionan con un . antes del nombre de la clase.

Clases combinadas y espacios en selectores

A veces los elementos tienen múltiples clases. En esos casos:

• Los espacios entre clases en el HTML se traducen a . en los selectores CSS.

Ejemplo en HTML:

<div class="item highlighted">Elemento destacado</div>

Cómo seleccionarlo en JavaScript:

• Para seleccionar un elemento que tiene ambas clases:

const highlightedItem = document.querySelector('.item.highlighted');
console.log(highlightedItem.textContent); // Salida: Elemento destacado

Nota importante: Si solo pones una de las clases (.item o .highlighted), seleccionará cualquier elemento que tenga esa clase, sin importar si tiene otras.

Resumiendo: ¿Cuándo usar ID o class?

• ID: Para identificar elementos únicos en la página, como un encabezado, un formulario o un botón específico.

• Class: Para agrupar elementos similares o aplicar estilos y comportamientos repetidos, como botones de navegación, listas de productos, etc.

Métodos básicos para acceder al DOM

Y ahora sí, estos son los métodos más conocidos —y, en mi opinión, imprescindibles si quieres trabajar en data collection— para acceder y capturar elementos del DOM.

getElementById

El clásico de los clásicos. Accede a un único elemento por su ID.
Ejemplo:

// Selecciona el elemento con el ID "header" y cambia su texto
const header = document.getElementById('header');
header.textContent = 'Nuevo título';

Pros:

• Muy rápido, ideal si sabes que el ID es único y constante.

Contras:

• Limitado a IDs, sin soporte para selectores más complejos.

Mi recomendación es asegurarse de que el ID sea único. De lo contrario, la puedes liar —ya que te devolverá un null en caso de que no encuentre el elemento que le indicas—.

getElementsByClassName y getElementsByTagName

Recuperan listas de elementos por clase o etiqueta.
Ejemplos:

// Selecciona todos los elementos con la clase "item" y cambia su color de fondo
const items = document.getElementsByClassName('item');
for (let i = 0; i < items.length; i++) {
    items[i].style.backgroundColor = 'lightblue';
}

// Selecciona todos los elementos `<p>` y los oculta
const paragraphs = document.getElementsByTagName('p');
for (let i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.display = 'none';
}

Pros:

• Más flexible que getElementById.

Contras:

• Devuelven una colección HTML (no un array), lo que puede ser menos práctico para trabajar.

Personalmente, no soy muy partidario de este método y prefiero trabajar con querySelector y —sobre todo— querySelectoAll ya que, aunque a nivel de rendimiento puede ser peor, es mucho más cómodo y sencillo de trabajar.

querySelector y querySelectorAll

Los reyes de la versatilidad, permiten usar selectores CSS para encontrar elementos. La principal diferencia es que con querySelector accedes al primer elemento, mientras que con querySelectorAll puedes acceder a todos los elementos de la selección.
Ejemplos:

// Selecciona el primer elemento con el selector CSS ".menu-item" y cambia su texto
const menuItem = document.querySelector('.menu-item');
menuItem.textContent = 'Primer ítem actualizado';

// Selecciona todos los elementos con el selector CSS ".menu-item" y los resalta
const menuItems = document.querySelectorAll('.menu-item');
menuItems.forEach(item => {
    item.style.color = 'red';
});

Pros:

• Compatibles con cualquier selector CSS.

• querySelectorAll devuelve un NodeList, iterable fácilmente con Array.from.

Contras:

• Menor rendimiento que los métodos anteriores si la estructura del DOM es masiva.

Los reyes en esto de capturar elementos si lugar a dudas, pero no los únicos que hay ni mucho menos… En páginas con muchas etiquetas —o SPAs interminables—, se puede convertir en una auténica odisea, ya que ralentiza mucho la recuperación de datos y puede afectar al rendimiento del site.

Métodos avanzados para situaciones especiales

Si conoces estos métodos —y los has utilizado alguna vez—, mi más sincera enhorabuena; significa que te has tenido que pegar mucho con el DOM y ya dispones de muchas más herramientas para acceder e interactuar con las páginas web.

closest()

Encuentra el ancestro más cercano de un elemento que coincida con un selector.
Ejemplo:

const button = document.querySelector('button'); 
const form = button.closest('form');

Perfecto para navegar hacia arriba en el DOM y mantener tus selectores limpios. Lo más importante aquí es identificar al elemento “padre” para luego buscar lo que quieres.

MutationObserver

Cuando trabajas con páginas dinámicas, este método te salva la vida. Permite "escuchar" cambios en el DOM y reaccionar a ellos en tiempo real.

Ejemplo básico:

const observer = new MutationObserver((mutations) => {
    mutations.forEach((mutation) => {
        console.log(mutation);
    });
});

observer.observe(document.body, { childList: true, subtree: true });

El rey de las SPA. Muy socorrido, además de para acceder a elementos específicos, como trigger para accionar eventos y escuchar qué ocurre en tu página. Si trabajas con Angular, Node, Astro…, sin duda es tu mejor aliado.

document.evaluate (XPath)

Una opción muy poco conocida para seleccionar nodos mediante expresiones XPath.
Pros:

• Preciso, ideal para estructuras complejas donde los selectores CSS no son suficientes.

Contras:

• Sintaxis más compleja, menos intuitiva que los selectores CSS.

const xpathExpression = '//div[@data-role="admin" and contains(text(), "Panel")]';
const result = document.evaluate(
    xpathExpression,
    document,
    null,
    XPathResult.FIRST_ORDERED_NODE_TYPE,
    null
);
console.log(result.singleNodeValue);

Xpath es un lenguaje diseñado específicamente para localizar nodos en documentos XML, pero también funciona perfectamente en HTML gracias a su estructura basada en nodos. Y justo por esa naturaleza, muchas veces resulta mejor solución que los selectores CSS (en los que se apoyan querySelector y querySelectorAll), limitados a una estructura descendente.

De esta forma, con Xpath podrás:

• Navegar hacia abajo, seleccionando hijos y ascendentes.

• Navegar hacia arriba, seleccionando padres o ancestros.

• Navegar hacia los lados, seleccionando nodos hermanos.

Además, podrás definir condiciones avanzadas y seleccionar otro tipo de nodos, como atributos, nodos de texto y comentarios. Más info aquí.

matches()

Comprueba si un elemento coincide con un selector, ideal para condicionales rápidas.
Ejemplo:

const element = document.querySelector('div');
if (element.matches('.active')) {
    console.log('Element is active');
}

Sin más, la verdad. Como digo, te puede servir para lanzar condiciones rápidas —detectar si un determinado elemento tiene una clase específica, por ejmplo—.

Problemas comunes y cómo evitarlos

Creo que esta parte puede ser la más útil de todo el artículo, la verdad. Aquí te explico los típicos problemas que pueden surgir a la hora de recoger elementos del DOM, y las posibles soluciones que puedes utilizar para lograrlo.

IDs y clases dinámicos (ejemplo: Salesforce)

Hay veces que las clases e IDs cambian constantemente. En estos casos, usar selectores únicos como data-attributes —mis queridos datasets— o posiciones relativas (nth-child) es clave.

Ejemplo:

// Seleccionar todos los productos
const products = document.querySelectorAll('.product');

// Filtrar productos de la categoría "electronics" usando `dataset`
products.forEach(product => {
    if (product.dataset.category === 'electronics') {
        console.log(`Producto encontrado: ${product.querySelector('h3').textContent}`);
    }
});

Mi truco:

Una función que utilizo para buscar elementos en entornos complejos como estos, prescindiendo de datasets y posiciones relativas es esta:

function getElementsByTextfromTag (tags, text, attribute) {
    var regex = new RegExp(text, 'i');
    var matchingElements = [];

    function getElementsByTextfromTagInternal(tag) {
        return Array.prototype.slice.call(document.getElementsByTagName(tag)).filter(function (el) {
            if (attribute) {
                return el.getAttribute(attribute) && el.getAttribute(attribute).match(regex);
            } else {
                return el.outerHTML.match(regex);
            }
        });
    }

    for (var i = 0; i < tags.length; i++) {
        var tag = tags[i];
        var elements = getElementsByTextfromTagInternal(tag);
        if (elements.length > 0) {
            matchingElements = matchingElements.concat(elements);
        }
    }

    return matchingElements;
}

//Se utilizaría así: getElementsByTextfromTag(['div'], 'er$', 'data-role'); 

Después de mucho pegarme con este tipo de páginas, me di cuenta de una cosa: lo que no suele cambiar suelen ser los textos de estos elementos. Y así se me oucrrió este script. Básicamente, itero por todas las etiquetas buscando un texto específico (al que además puedo añadir regex para hacerlo todavía más potente) dentro de algún dataset o atributo específico, en caso de que lo sepa (si lo dejas vacío, iterará por todo el elemento en sí). La sintaxis es antigua, lo sé, pero está hecho a drede para que funcione perfectamente dentro de Google Tag Manager.

Race conditions

Siempre que trabajes con el DOM, asegúrate de que esté listo antes de manipularlo. Usa eventos como DOMContentLoaded o load para evitar sorpresas desagradables.

document.addEventListener('DOMContentLoaded', () => {
    console.log('DOM fully loaded and parsed');
});

En este artículo, hablo largo y tendido sobre las Race Conditions:

Shadow DOM

Si trabajas con componentes modernos como Web Components, deberás lidiar con el encapsulamiento. Usa el shadowRoot para acceder a los nodos dentro de un Shadow DOM.

Ejemplo:

const shadowRoot = document.querySelector('custom-element').shadowRoot;
if (shadowRoot) {
    const button = shadowRoot.querySelector('button');
    console.log(button);
} else {
    console.log('Shadow root is closed or not accessible');
}

Nota importante: Si el shadow DOM está definido como closed, no podrás acceder a él de ninguna forma

Elige sabiamente

El DOM es un mundo lleno de posibilidades, pero cada método tiene su lugar. En páginas estáticas, opta por soluciones rápidas y específicas como getElementById. Para estructuras complejas o dinámicas, herramientas como querySelector, MutationObserver, y mis funciones personalizadas serán tus mejores aliadas.

Y recuerda: un buen acceso al DOM no solo mejora el rendimiento, también asegura que tu implementación sea escalable y mantenible. Y si estás lidiando con Salesforce o plataformas similares, ¡prueba mi función! Te ahorrará horas de frustración.

¿Te ha resultado útil esta guía? Si tienes dudas o quieres compartir algún truco propio para trabajar con el DOM, ¡déjalo en los comentarios o escríbeme! Me encantaría saber tu opinión.

Deja un comentario

Hablar de atribución en herramientas de analítica digital implica aceptar ciertas limitaciones, sobre todo cuando dependemos exclusivamente del cliente. Navegadores que bloquean cookies, document.referrer restringidos, single-page applications, redirecciones interminables o sistemas operativos que prácticamente ocultan cualquier atisbo de rastreo, hacen que atribuir correctamente las campañas sea muchas veces todo un reto.

En el mundo del marketing digital, la precisión en la atribución de campañas es esencial. Sin embargo, con las crecientes preocupaciones por la privacidad, los navegadores y sistemas operativos están implementando medidas que complican este proceso. Un ejemplo claro puede ser la introducción de la Protección de Rastreo de Enlaces en iOS 17 de Apple del pasado 2023, que eliminaba automáticamente ciertos parámetros de seguimiento en las URL para proteger la privacidad del usuario (Adsmurai).

Estas medidas, aunque beneficiosas para la privacidad, presentan desafíos significativos para los profesionales del marketing que dependen de estos parámetros para la atribución precisa de campañas. La eliminación de parámetros como utm_source o gclid dificulta la identificación de la fuente de tráfico y la evaluación del rendimiento de las campañas.

Ya he leído estas últimas semanas a muchas personas quejándose y diciendo: «si se ha hecho así, será para algo» en lo que respecta a la privacidad y buscar soluciones dentro de la legalidad para capturar el máximo de datos. Yo no voy a entrar en debates sobre si está bien o no querer saber de dónde provienen las ventas de tu ecommerce, o en qué medios se deben invertir para mejorar el rendimiento de tus campañas, solo ofrezco una alternativa legal.

El problema: dependencia del cliente

Tradicionalmente, la atribución en Google Analytics 4 (GA4) se basa en parámetros de URL y el document.referrer. Sin embargo, con las nuevas protecciones de privacidad:

• En dispositivos móviles: iOS y Android presentan problemas al gestionar cookies y referrer, especialmente al navegar entre aplicaciones o cuando se utilizan navegadores como Safari. La eliminación automática de parámetros de seguimiento en Safari y otras aplicaciones complica aún más la identificación de la fuente de tráfico (Adsmurai).

• Limitaciones del cliente: Dependemos de variables que pueden no estar disponibles o ser manipuladas por extensiones, navegadores o configuraciones de privacidad.

El resultado: Atribuciones incorrectas y campañas subestimadas. Esto lo hemos visto claramente reflejado en la reacción de la comunidad frente al cambio de políticas de Apple con iOS 17 y las restricciones a los parámetros de seguimiento. Como se analiza en el artículo de Branch.io, estas medidas dificultan aún más la atribución precisa en entornos móviles.

Una posible solución: implementación en el servidor

Para superar estas limitaciones, hemos trasladado la lógica de atribución al pre-render del servidor. Esto nos permite acceder a las cabeceras HTTP de las peticiones de origen, obteniendo datos más precisos antes de que el navegador aplique sus restricciones.

Ventajas de este enfoque:

• Acceso directo a las cabeceras HTTP: Podemos analizar el Referer y otros encabezados para determinar la fuente de tráfico sin depender del cliente, como el User-Agent.

• Eliminación de dependencias del navegador: No estamos sujetos a las restricciones o manipulaciones que los navegadores puedan aplicar en el lado del cliente.

• Datos más fiables: Al trabajar con información directa del servidor, reducimos la posibilidad de errores o datos incompletos.

Desventajas:

• Conocimientos técnicos: Necesitas trabajar en el código fuente del back en el que esté montado tu sitio web, por lo que no está al alcance de todo el mundo —aunque siempre puedes tirar del equipo de desarrollo—.

• Dependencia del stock tecnológico: No todos los sitios web cuentan con un prerrenderizado, por lo que lo primero es saber sobre su viabilidad —si en algún momento has escuchado a los desarrolladores hablar de la hidratación del sitio web, no es que el pobre se muriera de sed… Pregunta que es probable que puedas hacerlo—.

• Mantenimiento y escalabilidad: Al ser una solución ad-hoc, necesitará un mantenimiento mínimo, así como una actualización continúa del listado de proveedores… La clave aquí está en el orden y limpieza del código.

Artículos relacionados:

• Merkle en este artículo destaca cómo los modelos de atribución de GA4 pueden complicarse sin un manejo adecuado de las fuentes de tráfico.

• Como destaca Adjust en su análisis sobre iOS 14.5, las restricciones en clics han complicado la atribución basada en parámetros tradicionales.

Implementación:

En el servidor, utilizamos un script que analiza las cabeceras de cada solicitud entrante para identificar la fuente de tráfico. Basándonos en el referrer y otros parámetros, determinamos si el tráfico proviene de motores de búsqueda, redes sociales, correos electrónicos u otras fuentes. Esta información se procesa y se incluye en la capa de datos que se envía al cliente, permitiendo así tener una variable adicional donde registrar eventos con una atribución precisa y luego poder revisar con la atribución que hace tu herramienta de analítica favorita —guiño, guiño—.

Ejemplo de código en el servidor:

var Se = function() {
    this.searchEngines = ["google", "bing", "yahoo", "duckduckgo", "ask", "ecosia", "aol"...]; //listado de motores de búsqueda
    this.socialMedia = {
        Facebook: "facebook.com",
        Twitter: "twitter.com",
        LinkedIn: "linkedin.com",
        Instagram: "instagram.com",
        Reddit: "reddit.com",
        Pinterest: "pinterest.com",
        TikTok: "tiktok.com"
    };
    this.mailServices = {
        Gmail: "mail.google.com",
        YahooMail: "mail.yahoo.com",
        Outlook: "outlook.live.com"
    };
};

Se.prototype.getTrafficDetails = function(headers) {
    var referrer = headers['referer'] || headers['referrer'];
    var userAgent = headers['user-agent'];
    var source = this.getSource(referrer.toLowerCase());
    var channel = this.getChannel(source);

    return {
        channel: channel,
        source: source,
        medium: channel !== "direct" ? "organic" : "direct"
    };
};

Se.prototype.getSource = function(referrer) {
    if (!referrer) {
        return "direct";
    }

    var source = this.findInSources(referrer, this.searchEngines, this.socialMedia, this.mailServices);
    return source || "direct";
};

Se.prototype.findInSources = function(referrer, ...sources) {
    for (var i = 0; i < sources.length; i++) {
        var currentSource = sources[i];
        if (Array.isArray(currentSource)) {
            if (currentSource.some(function(domain) { return referrer.includes(domain); })) {
                return currentSource.find(function(domain) { return referrer.includes(domain); });
            }
        } else {
            for (var key in currentSource) {
                if (referrer.includes(currentSource[key])) {
                    return key;
                }
            }
        }
    }
    return null;
};

Se.prototype.getChannel = function(source) {
    if (Object.keys(this.socialMedia).includes(source)) {
        return "social";
    } else if (this.searchEngines.includes(source)) {
        return "search";
    } else if (Object.keys(this.mailServices).includes(source)) {
        return "email";
    } else {
        return "direct";
    }
};

// Uso en el servidor
function handleRequest(headers) {
    var trafficDetails = new Se().getTrafficDetails(headers);
    console.log("Detalles del tráfico:", trafficDetails);

    return trafficDetails;
}

Las claves de este código serían estas:

this.searchEngineAppAndroid = {
    "Google Discover": "android-app://com.google.android.googlequicksearchbox/" // Ejemplo
    // Otros motores de búsqueda en Android
};

this.mailAppAndroid = {
    Gmail: "android-app://com.google.android.gm/" // Ejemplo
    // Otras aplicaciones de correo en Android
};

this.socialMediaAppAndroid = {
    Twitter: "android-app://com.twitter.android/" // Ejemplo
    // Otras redes sociales en Android
};

this.socialMediaAppIOS = {
    Facebook: "FBAV" // Ejemplo
    // Otras redes sociales en iOS
};

this.aiSearchEnginesAppAndroid = {
    ChatGPT: "android-app://com.openai.chatgpt" // Ejemplo
    // Otros motores de búsqueda con IA en Android
};

this.aiSearchEnginesDesktop = {
    "Google Bard": ["bard.google.com"] // Ejemplo
    // Otros motores de búsqueda con IA en Desktop
};

this.aiSearchEnginesAppIOS = {
    "Bing Chat": "bing" // Ejemplo
    // Otros motores de búsqueda con IA en iOS
};

Primero, definimos los listados para desktop, Android e iOS de foma independiente. Lo que veis no es más que un ejemplo y los bloques pueden variar en función de la precisión y fuentes —por ejemplo, podéis añadir vuestros canales de referrals habituales—. De esta forma podemos definir nuestro «source» con bastante precisión:

 getSource(r, f, u) {
        let s;
        switch (r) {
        case "android":
            s = f.startsWith("android-app://") ? this.findInSources(f, this.mailAppAndroid, this.searchEngineAppAndroid, this.socialMediaAppAndroid, this.aiSearchEnginesAppAndroid) : this.findInSources(f, this.searchEnginesDesktop, this.socialMediaDesktop, this.aiSearchEnginesDesktop, this.mailDesktop);
            break;
        case "ios":
            s = u ? this.findInSources(u, this.searchEnginesDesktop, this.socialMediaAppIOS, this.aiSearchEnginesAppIOS) : this.findInSources(f, this.searchEnginesDesktop, this.socialMediaDesktop, this.aiSearchEnginesDesktop, this.mailDesktop);
            break;
        default:
            s = this.findInSources(f, this.searchEnginesDesktop, this.socialMediaDesktop, this.aiSearchEnginesDesktop, this.mailDesktop);
            break
        }
        return s ?? "direct"
    }

Así, sabiendo el dispositivo, fácilmente podremos iterar por las distintas casuísticas de dispositivo que haya y, luego, mapear por nuestros listados. La clave, compañero, consiste en iterar de forma independiente por cada tipo de dispositivo, para acceder a donde “está la chicha”; en el caso de Android, tienes su propio listado con la clásica cabecera de referrers de sus apps android-app://, mientras que en iOS nos centramos en su userAgent para sacar el máximo provecho de lo que haya disponible. Y siempre, siempre, dejamos como default la clásica cabecera de document.referrer de desktop, para así poder “rascar” algo más (incluso en Android e iOS).

Es importante tener definido previamente el dispositivo —aquí sí que se puede utilizar el userAgent sin ningún problema—.

Si queremos hacerlo más redondo si cabe, podemos identificar en la propia URL si proviene de algún tipo de campaña utilizando el mismo ejemplo anterior de los listados:

var Pt = {
    googleAds: ["gclid"],
    bingAds: ["msclkid"],
    criteo: ["criteo_uid"],
    facebookAds: ["fbclid"]
    //Incluye más proveedores
};

De esta manera, podremos crear un par de variables indicando si existe campaña y el proveedor en cuestión.

Integración con GA4:

Una vez que la información de la fuente de tráfico se ha procesado en el servidor, se incluye en la capa de datos que se envía al cliente. Podremos entonces utilizar esta información para atribuir correctamente las conversiones y otros eventos al origen adecuado.

Beneficios adicionales:

• Cumplimiento con las políticas de privacidad: Al manejar la atribución en el servidor, respetamos las configuraciones de privacidad del usuario y las políticas de los navegadores.

• Resiliencia ante cambios futuros: Este enfoque nos prepara para adaptarnos a futuras actualizaciones de privacidad en navegadores y sistemas operativos.

• Datos para comparar: Ahora contamos con variables adicionales que nos permiten hacer doble check antes de confiar ciegamente en lo que nos dicen nuestras herramientas de analítica.

Me gustaría cerrar dando un porcentaje de mejora, pero me temo que es algo reciente todavía para aventurarme a dar cifras. Lo que sí que puedo decir es que se ha conseguido aumentar la precisión en dispositivos iOS —de nada a recoger algo, ya es un gran avance—, y hemos detectado falsos «direct» en todo tipo de dispositivos.

Sin duda, este enfoque no solo resuelve problemas inmediatos, sino que también sienta las bases para una atribución más precisa a largo plazo, mejorando la confianza en los datos.

Adaptarse o morir

En un entorno donde la privacidad del usuario es cada vez más prioritaria, es esencial adaptar nuestras estrategias de atribución. Implementar la lógica de atribución en el pre-render del servidor nos permite obtener datos precisos y fiables, superando las limitaciones del cliente y respetando las nuevas medidas de privacidad.

Si los navegadores y sistemas operativos han cambiado las reglas del juego, depende de nosotros adaptarnos y optimizar nuestras estrategias para no solo seguir en la partida, sino ganar, ¿o no estás de acuerdo?

Suscríbete ahora

¿Qué es una Race Condition?

En términos sencillos, dentro del mundo del desarrollo una race condition es una situación en la que dos o más operaciones intentan acceder o modificar los mismos recursos al mismo tiempo, sin una coordinación clara en el orden de ejecución. Esto puede resultar en comportamientos impredecibles, datos incorrectos o procesos incompletos, especialmente en entornos asincrónicos como el navegador web, donde los tiempos de carga de scripts y eventos pueden variar enormemente.

Las race conditions son particularmente problemáticas en sistemas de gestión de etiquetas (TMS) como Google Tag Manager, donde es común que múltiples etiquetas dependan de una secuencia o disponibilidad de datos específicos. Sin un control adecuado, se puede perder información crítica o, peor aún, se puede recolectar información incorrecta.

Ejemplos clásicos dentro de Data Collection

Race Condition en Thank you Page

Imaginemos que tienes una etiqueta de conversión que depende de que se haya completado una compra y que los datos relevantes estén presentes en el dataLayer. Supón que la etiqueta de conversión se dispara en la página de confirmación, pero en algunos casos, debido a la latencia de la red o al tiempo de procesamiento de otros scripts, el dataLayer aún no tiene los datos completos cuando la etiqueta intenta acceder a él, o peor, no se llega a ejecutar nunca y el usuario cierra la página. Como resultado, la conversión podría registrarse sin la información correcta o no registrarse en absoluto. Un clásico bastante más habitual de lo que uno piensa.

Race Condition en la Gestión de Consentimiento

Otro caso común de race condition se presenta en la gestión del consentimiento, donde GTM espera que el consent.update esté configurado antes de disparar etiquetas que dependen de dicho consentimiento. En algunas implementaciones, debido a la carga asincrónica de los CMP (Consent Management Platforms) o el retraso en el dataLayer, el evento consent.update puede no estar disponible inmediatamente, y la vista previa de GTM muestra un mensaje de advertencia en rojo en la vista previa, indicando que se ha intentado leer el estado del consentimiento antes de que se hubiese establecido. ¿Te suena?

Estrategias para evitarlas

Ahora que entendemos el problema —y lo hemos sufrido en nuestras propias carnes, seguro 100%—, vamos a analizar cómo podemos evitarlo utilizando diferentes estrategias de programación y herramientas disponibles en JavaScript y en los TMS.

1. Uso de dispatchEvent para coordinar eventos

Una solución efectiva para evitar que una etiqueta se ejecute antes de que el dataLayer esté listo es usar un evento personalizado (CustomEvent) que notifique cuándo los datos están disponibles.

Ejemplo:

// Función para obtener datos de una API y actualizar el dataLayer con un evento específico
function fetchDataAndUpdateDataLayer(url, eventName) {
    fetch(url)
        .then(response => response.json())
        .then(data => {
            dataLayer.push({
                'event': eventName,
                'data': data
            });
            document.dispatchEvent(new CustomEvent('apiReady'));
        })
        .catch(error => {
            console.error("Error al obtener datos de la API:", error);
        });
}

// Listener para 'apiReady' que ejecuta la lógica dependiente de los datos
document.addEventListener('apiReady', function() {
    console.log("Datos de la API disponibles en el dataLayer, ejecutando lógica dependiente.");
    // Aquí podrías disparar una etiqueta o función dependiente de estos datos
});

// Ejemplo de uso de la función
fetchDataAndUpdateDataLayer("https://api.example.com/user-data", "userDataReady");

Este enfoque modular y flexible es ideal para implementar en escenarios donde múltiples fuentes de datos pueden estar en juego y cada llamada debe estar perfectamente sincronizada con la carga de etiquetas.

Al hilo de esto, os ofrezco un desarrollo de la casa para elevar al cubo la gestión de eventos sin tener que iterar sobre múltiples eventListeners:

// Creamos un proxy para interceptar los cambios en el dataLayer
const dataLayer = new Proxy([], {
    set: function(target, property, value) {
        target[property] = value;
        // Detectamos si el evento que necesitamos está en el dataLayer
        if (value.event === 'userDataReady') {
            console.log("userDataReady detectado en el dataLayer, ejecutando lógica dependiente.");
            // Ejecutamos la lógica necesaria cuando se detecta el evento específico
            executeDependentLogic(value.data);
        }
        return true;
    }
});

// Función genérica para obtener datos de una API y actualizar el dataLayer con un evento específico
function fetchDataAndUpdateDataLayer(url, eventName) {
    fetch(url)
        .then(response => response.json())
        .then(data => {
            // Añadimos los datos necesarios al dataLayer tras la respuesta de la API
            dataLayer.push({
                'event': eventName,
                'data': data
            });
        })
        .catch(error => {
            console.error("Error al obtener datos de la API:", error);
        });
}

// Función que se ejecuta cuando el evento 'userDataReady' es detectado en el dataLayer
function executeDependentLogic(data) {
    // Aquí podrías disparar una etiqueta, enviar datos adicionales, o cualquier otra lógica
    console.log("Lógica dependiente ejecutada con los datos:", data);
}

// Ejemplo de uso: Llamada a la API y especificación de un evento único
fetchDataAndUpdateDataLayer("https://api.example.com/user-data", "userDataReady");

En esta implementación, usamos un proxy para monitorear el dataLayer y ejecutar automáticamente una lógica específica cuando se detecta un evento particular, en este caso, userDataReady. Al definir el dataLayer como un proxy, podemos interceptar cada vez que se realiza un push en él. Cuando el proxy detecta que el evento agregado es userDataReady, activa la función executeDependentLogic y le pasa los datos asociados a este evento.

Este enfoque elimina la necesidad de configurar listeners explícitos cada vez que queremos ejecutar una acción dependiente de un evento en el dataLayer. En lugar de eso, el proxy se encarga de observar todos los cambios en el dataLayer y de activar la lógica dependiente de forma automática cuando encuentra un evento que coincide con userDataReady.

La función executeDependentLogic se convierte en el punto donde centralizamos la lógica específica para este evento. Por ejemplo, en lugar de esperar manualmente con listeners o eventos personalizados, el proxy ejecuta cualquier acción necesaria, como disparar una etiqueta o procesar datos, en el momento en que detecta el evento.

Este enfoque hace que la gestión de múltiples eventos en el dataLayer sea más eficiente y reduce la necesidad de listeners repetitivos, permitiendo una implementación más limpia y adaptada a entornos de data collection complejos. Vamos, una fumada muy guapa.

2. Uso de callbacks() para garantizar el orden de ejecución

Un callback es una función que se ejecuta una vez que otra función ha terminado su tarea. Esto asegura un orden de ejecución cuando hay dependencias directas entre tareas.

Ejemplo de callback para la ejecución secuencial:

function loadConversionData(callback) {
    // Simulamos la carga de datos del servidor o dataLayer
    setTimeout(() => {
        dataLayer.push({ 'event': 'conversion', 'transactionId': '67890', 'value': 200 });
        console.log("Datos de conversión cargados.");
        callback(); // Llamamos al callback cuando los datos están listos
    }, 1000); // Simulamos un retraso de 1 segundo
}

function executeConversionTag() {
    console.log("Ejecutando etiqueta de conversión.");
}

// Ejecutamos loadConversionData y pasamos executeConversionTag como callback
loadConversionData(executeConversionTag);

En este ejemplo, executeConversionTag solo se ejecutará después de que loadConversionData haya completado la carga de datos.

Dentro de Google Tag Manager, tenemos una opción similar, especialmente útil para coordinar el flujo de eventos: el método eventCallback. Este método permite asociar una función que se ejecutará después de que se complete el dataLayer.push(). De esta forma, podemos asegurarnos de que cualquier acción dependiente de los datos en el dataLayer ocurra solo después de que estos se hayan procesado.

El uso de eventCallback es particularmente útil en casos donde queremos que una acción, como una redirección, se ejecute solo después de que los datos de un evento, como un clic en un producto, se hayan enviado al dataLayer. A continuación, te mostramos un ejemplo práctico de su implementación:

Ejemplo de Uso de eventCallback en un Evento de Clic en Producto:

dataLayer.push({
    'event': 'newsletterSubscription',
    'subscription': {
        'email': subscriberObj.email,
        'firstName': subscriberObj.firstName,
        'source': 'Homepage Signup Form'
    },
    'eventCallback': function() {
        // Redirige a la página de agradecimiento solo después de procesar el evento
        window.location.href = '/thank-you';
    }
});

Para asegurar que los datos de una suscripción se registren en el dataLayer antes de redirigir al usuario, usamos eventCallback. Este método permite ejecutar una acción (como una redirección) solo después de que el evento haya sido procesado.

3. Implementación de Promises y async/await para la sincronización de tareas asíncronas

Para casos en los que tienes múltiples dependencias que deben completarse antes de continuar, las Promises o async/await pueden ofrecer un control robusto. Esto es especialmente útil si manejas llamadas a APIs o recursos externos.

Ejemplo usando Promises:

function fetchData() {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            dataLayer.push({ 'event': 'fetchComplete', 'data': 'sample data' });
            resolve("Datos cargados exitosamente.");
        }, 1500); // Retraso de 1.5 segundos
    });
}

fetchData().then((message) => {
    console.log(message); // "Datos cargados exitosamente."
    console.log("Ejecutando lógica después de fetchData");
}).catch((error) => {
    console.error("Error cargando datos: ", error);
});

Con async/await:

async function executeDataFlow() {
    await fetchData();
    console.log("Datos listos, ejecutando lógica dependiente.");
}

executeDataFlow();

Este método garantiza que executeDataFlow se ejecute solo después de que fetchData haya completado su tarea, ayudando a evitar conflictos de sincronización.

Poco más que decir. ¿Dime si has visto algo más limpio? El único pero es que async/await no funciona en todos los TMS —no miro a nadie, GTM—, por lo que si decides inyectar algo de esto, tendrás que probar con una promesa…

4. Uso de MutationObserver para monitorizar cambios en el DOM

Si tu etiqueta depende de la existencia de elementos específicos en el DOM (como cuando usas un TMS que necesita detectar cambios en el contenido de la página), el MutationObserver es una herramienta muy potente. Permite escuchar cambios en el DOM y responder a ellos solo cuando ciertos elementos están disponibles.

Ejemplo de MutationObserver:

const observer = new MutationObserver((mutations) => {
    mutations.forEach((mutation) => {
        if (document.querySelector('#conversionElement')) {
            console.log('Elemento de conversión detectado en el DOM.');
            // Ejecuta la lógica dependiente
            observer.disconnect(); // Detenemos la observación después de detectarlo
        }
    });
});

// Observamos el cuerpo del documento en busca de cambios
observer.observe(document.body, { childList: true, subtree: true });

Este enfoque permite que tu código reaccione a la aparición de elementos específicos en el DOM, eliminando las race conditions que pueden surgir por la carga asíncrona de contenido. En SPA, te vas a hartar de utilizar mutationObserver, créeme.

5. Implementación de estrategias de reintentos (Retries)

Cuando no puedes garantizar el orden de carga o necesitas intentar varias veces para obtener un recurso, implementar un sistema de reintentos con límite es una solución efectiva. Esto es útil en situaciones donde la disponibilidad de los datos puede variar.

Ejemplo de retry con setTimeout:

function tryLoadData(attempts = 5) {
    if (checkDataLayerData()) {
        console.log("Datos listos, ejecutando etiqueta.");
    } else if (attempts > 0) {
        setTimeout(() => tryLoadData(attempts - 1), 500); // Intento cada 500ms
    } else {
        console.log("Límite de intentos alcanzado, abortando.");
    }
}

function checkDataLayerData() {
    return dataLayer.some(item => item.event === 'purchase');
}

tryLoadData(); // Iniciamos la función de reintento

Esta función intenta obtener los datos necesarios hasta cinco veces antes de abortar, aumentando las probabilidades de éxito en entornos asíncronos.

Personalmente, he utilizado más veces de las que pensaba este tipo de funciones… Es una solución bastante útil, pero tenemos que ajustar muy bien los intentos para no afectar en el rendimieto del sitio web y, lo que es más importante, que funcione correctamente un alto porcentaje de las veces.

Conclusión

Las race conditions son un desafío común en nuestro campo, especialmente en entornos de TMS como GTM. Afortunadamente, existen múltiples estrategias y herramientas en JavaScript para minimizar su impacto y asegurar que las etiquetas y scripts se ejecuten en el orden correcto, con los datos completos y precisos. Desde el uso de eventos personalizados y callbacks hasta herramientas avanzadas como MutationObserver, dominar estas técnicas te permitirá asegurar la calidad y confiabilidad de tus datos.

Espero que este artículo te haya sido útil para abordar las race conditions en tus implementaciones y mejore la precisión de tus resultados en data collection. ¡Me cuentas!

Deja un comentario

Cuando hablamos de persistencia del dato en aplicaciones web, inmediatamente pensamos en nuestras amigas las cookies, ¿o no? Sin embargo, existen otras herramientas esenciales para mantener la información disponible durante la navegación del usuario, más allá de estas. En este artículo, exploraremos cómo utilizar sessionStorage, localStorage, indexedDB y las APIs propias para que los datos persistan, y cómo podemos valernos de otros recursos, como postMessage o broadcastChannel, para comunicarnos de forma más efectiva y ofrecer así una mejor experiencia de usuario. Con esta guía, intentaré mostrarte los matices, pros y contras de cada método y cómo se implementan en un contexto de eCommerce y de interacción en tiempo real.

SessionStorage y LocalStorage: persistencia clásica en el cliente

sessionStorage y localStorage son APIs de almacenamiento web que ofrecen diferentes niveles de persistencia en el cliente. Disponibles en cualquier navegador, ambos métodos son extremadamente útiles, no solo en el contexto de la capa de datos, sino para el propio funcionamiento del sitio web, permitiéndote gestionar el estado de la aplicación a medida que el usuario interactúa con el sitio.

SessionStorage

sessionStorage almacena datos que solo deben persistir durante la sesión del usuario y desaparecen al cerrar la pestaña. Este almacenamiento es perfecto para manejar datos temporales como el estado de un carrito de compras o las preferencias de visualización, por ejemplo.

Ejemplo práctico: Almacenamiento temporal de estado de carrito en JavaScript

// Guardar el estado del carrito en sessionStorage sessionStorage.setItem("cartItems", JSON.stringify(cartItems));
  
// Recuperar datos del carrito al cambiar de página en la misma sesión const cartData = JSON.parse(sessionStorage.getItem("cartItems")); console.log("Datos del carrito:", cartData);   

LocalStorage

localStorage, en cambio, permite que los datos persistan incluso después de que el usuario cierre el navegador, ideal para almacenar configuraciones a largo plazo como temas de usuario o tokens de autenticación.

Ejemplo práctico: Guardar la preferencia de tema de usuario en JavaScript

// Almacenar la preferencia de tema localStorage.setItem("theme", "dark"); 

// Recuperar el tema seleccionado al cargar la página const userTheme = localStorage.getItem("theme");document.body.classList.add(userTheme);

Consideraciones de seguridad: Ambos métodos pueden ser susceptibles a ataques XSS. Evita almacenar datos sensibles y utiliza solo scripts de fuentes confiables.

IndexedDB: persistencia avanzada

indexedDB es una API de bajo nivel —esto quiere decir que proporciona acceso directo a todos los recursos, pero requiere de un conocimiento profundo sobre la API en cuestión para sacarle el máximo provecho— que ofrece acceso a una base de datos no relacional en el navegador, permitiéndote almacenar grandes volúmenes de datos en formato JSON. Es ideal para aplicaciones complejas y de alto rendimiento, como aquellas en el ámbito del eCommerce y la analítica, donde almacenar localmente el estado completo de objetos (por ejemplo, un producto o el carrito de compras) puede optimizar la experiencia del usuario y reducir la dependencia del servidor, ya que no bloquea el comportamiento del sitio web.

¿Cómo funciona IndexedDB?

IndexedDB ofrece acceso tanto síncrono como asíncrono, aunque yo siempre que lo he utilizado ha sido con su API asíncrona. Funciona mediante una interfaz basada en eventos, con una API predominantemente asíncrona para que las operaciones de lectura y escritura no bloqueen la interfaz de usuario. Si bien no es nativamente una API de promesas, es posible envolver sus operaciones en promesas para aprovechar una sintaxis más moderna y limpia, compatible con async y await.

Este sistema de base de datos maneja transacciones y objetos clave-valor, permitiendo estructuras de datos complejas y multitabla. Además, IndexedDB permite establecer índices para realizar búsquedas optimizadas, lo que facilita consultas avanzadas dentro de la base de datos. Sin embargo, esta API es compleja y tiene ciertas limitaciones, como su dependencia en el almacenamiento local del navegador y la falta de sincronización entre dispositivos (aunque puedes combinarlo con otros métodos para conseguir cosas muy chulas).

Ejemplo práctico: Almacenamiento y recuperación de datos en IndexedDB

Aquí te muestro un ejemplo básico en JavaScript que utiliza promesas para gestionar una base de datos de productos en IndexedDB. Este ejemplo crea o abre una base de datos, añade un producto y lo recupera para mostrarlo en la consola.

// Función para abrir la base de datos
function openDatabase() {
    return new Promise((resolve, reject) => {
        const request = indexedDB.open("ecommerceDB", 1);
        request.onupgradeneeded = (event) => {
            const db = event.target.result;
            db.createObjectStore("products", { keyPath: "productId" });
        };
        request.onsuccess = (event) => resolve(event.target.result);
        request.onerror = (event) => reject("Error al abrir la base de datos");
    });
}

// Función para añadir un producto
function addProduct(db, product) {
    return new Promise((resolve, reject) => {
        const transaction = db.transaction("products", "readwrite");
        const store = transaction.objectStore("products");
        const request = store.put(product);
        request.onsuccess = () => resolve("Producto añadido con éxito");
        request.onerror = () => reject("Error al añadir el producto");
    });
}

// Función para recuperar un producto por ID
function getProduct(db, productId) {
    return new Promise((resolve, reject) => {
        const transaction = db.transaction("products", "readonly");
        const store = transaction.objectStore("products");
        const request = store.get(productId);
        request.onsuccess = () => resolve(request.result);
        request.onerror = () => reject("Error al recuperar el producto");
    });
}

Este código ilustra cómo utilizar promesas para hacer que las operaciones en IndexedDB sean más intuitivas y sencillas de leer. La API permite ejecutar operaciones de transacción y lectura/escritura de manera asíncrona, optimizando el rendimiento de aplicaciones con grandes cantidades de datos.

Ventajas y limitaciones de IndexedDB

• Ventajas: IndexedDB permite almacenar grandes volúmenes de datos y realizar consultas complejas de forma local, siendo ideal para aplicaciones que manejan estructuras de datos complejas en el lado del cliente.

• Limitaciones: Al tratarse de una API de bajo nivel, su uso requiere una mayor inversión en desarrollo y conocimiento técnico. Además, es limitada en cuanto a sincronización entre dispositivos y puede tener lagunas técnicas al compararla con bases de datos de servidor.

Consejo avanzado: Herramientas como notificaciones push se apoyan en IndexedDB para almacenar datos del usuario de forma local, asegurando que las notificaciones sean relevantes sin tener que hacer llamadas al servidor en cada carga de página.

Personalmente, la he utilizado para mantener la persistencia del producto en formato array de objeto —vamos, el clásico formato items de GA4 con todas sus variables y casi media docena de variables custom— desde que se añadía el producto al carrito hasta que finalizaba su compra; con toda la lógica de añadir más unidades, eliminarlas, así como eliminar el producto de forma definitiva si finalizaba la compra. Además, gracias a su persistencia entre sesiones y su capacidad de almacenamiento (que varía entre navegadores, pero para que te hagas una idea, en Chrome tienes hasta 500 MB de espacio), te permite incluso recuperar carritos al iniciar sesión… Ahí es nada ;)

function getIndexedDBItem() {
    var openRequest = indexedDB.open("XXX", 1);

    openRequest.onsuccess = function() {
        var db = openRequest.result;
        var products = [];
        var oldItems = google_tag_manager["GTM-XXXXX"].dataLayer.get("cdl_cart_products");

        if (oldItems && oldItems.length > 1) {
            var transaction = db.transaction(["Products"], "readonly");
            var store = transaction.objectStore("Products");

            oldItems.forEach(function(oldItem) {
                var request = store.get(oldItem.sku);
                request.onsuccess = function(e) {
                    var productData = e.target.result;

                    if (productData) {
                        products.push({
                            'item_id': productData.product_id || productData.sku,
                            'item_name': productData.name || productData.product_name,
                            'item_brand': productData.brand || "N/A",
                            'item_category': productData.category1 || 'not_set',
                            'item_category2': productData.category2 || '',
                            'item_category3': productData.category3 || '',
                            'quantity': oldItem.quantity,
                            'price': parseFloat(oldItem.unitprice_ati * oldItem.quantity),
                            'discount': parseFloat(productData.discount) ? parseFloat(productData.discount * oldItem.quantity) : 0,
                            'deliveryHomeAvailability': productData.dimension148,
                            'deliverySFSAvailability': productData.dimension149,
                            'deliveryStoreAvailability': productData.dimension150,
                            'productRating': productData.rating || undefined,
                            'productNumReviews': productData.number_reviews || undefined,
                            'item_list_id': productData.zone_id || undefined,
                            'item_list_name': productData.zone_name || undefined
                        });
                    }
                };
            });

            transaction.oncomplete = function() {
                dataLayer.push({
                    'event': 'funnelEcommerceGA4',
                    'funnelItemsGA4': products
                });
            };
        }
    };

    openRequest.onerror = function() {
        console.error("Error al abrir la base de datos:", openRequest.error);
    };
}

getIndexedDBItem();

APIs Propias: persistencia en el servidor

Además de los métodos de persistencia en el cliente, el uso de APIs propias ofrece una forma de persistencia en el servidor, conectándose a bases de datos alojadas en la nube, por ejemplo. Este enfoque asegura que los datos persistan de manera segura y puedan compartirse entre dispositivos y sesiones, ideal para casos de uso donde se necesita centralizar y gestionar grandes volúmenes de datos.

Las APIs propias son especialmente útiles en contextos de analítica avanzada o personalización. Si nos abstraemos un poco, hasta sistemas como GTM Server-Side pueden actuar como sistemas de persistencia de datos al hacer de intermediarios entre el cliente y la base de datos, facilitando el almacenamiento en tiempo real sin afectar el rendimiento del sitio. Esto permite recopilar información en el servidor y procesarla de manera centralizada, minimizando la carga en el cliente y ofreciendo persistencia multidispositivo.

Ejemplo práctico: Persistencia con API en Firestore y TMS Server-Side

Imaginemos que queremos almacenar y recuperar los datos de usuario en tiempo real:

1. Recopilación en el cliente: El cliente dispara un evento, enviando datos a nuestro sistema de tagging Server-Side.

2. Almacenamiento en Firestore: Nuestro TMS procesa y guarda los datos en Firestore.

3. Recuperación a través de la API: Otra API en el servidor consulta los datos en tiempo real, permitiendo su uso en analítica o personalización de la experiencia del usuario.

Código ilustrativo en python FastAPI para acceder a datos en Firestore:

from fastapi import FastAPI
from google.cloud import firestore

app = FastAPI()
db = firestore.Client()

@app.get("/get_user_data/{user_id}")
async def get_user_data(user_id: str):
    doc_ref = db.collection("users").document(user_id)
    doc = doc_ref.get()
    if doc.exists:
        return doc.to_dict()
    else:
        return {"error": "User data not found"}

Con esta API, los datos de usuario se almacenan en Firestore y se acceden en tiempo real, permitiendo persistencia multidispositivo y sincronización entre sesiones. Imagínate la de posibilidades que se te abren con una solución que funcione en el lado servidor…

Comunicación en tiempo real: BroadcastChannel y postMessage

Además de los métodos de almacenamiento, existen alternativas potentes para “persistencia temporal” y comunicación entre diferentes contextos de navegación: broadcastChannel y postMessage. Aunque no se trata de APIs y métodos desarrollados para persistir dato, sí se pueden utilizar y combinar con los métodos mencionados anteriormente de persistencia bajo determinadas circunstancias…

BroadcastChannel: Comunicación entre pestañas del mismo dominio

broadcastChannel es una API que permite que diferentes pestañas de una misma aplicación compartan información en tiempo real. Es ideal para sincronizar el estado de autenticación o los datos del carrito en distintas pestañas. Esto resulta clave en experiencias de usuario que requieren que las acciones en una pestaña se reflejen en otra.

Ejemplo práctico: Sincronización de autenticación entre pestañas en JavaScript

// Crear un canal para la autenticación
const authChannel = new BroadcastChannel("authChannel");

// Enviar un mensaje de autenticación desde una pestaña
authChannel.postMessage({ event: "login", userId: "12345" });

// Escuchar el mensaje en otra pestaña
authChannel.onmessage = (event) => {
  if (event.data.event === "login") {
    console.log("Usuario autenticado en otra pestaña:", event.data.userId);
    // Actualizar el estado de la sesión o capa de datos
  }
};

Yo lo he utilizado en aquellos eCommerce que, debido a la lógica de programación del sitio web, se abrían pestañas nuevas de otras páginas para continuar el proceso de compra. De esta manera, era capaz de registrar las transacciones en el propio eCommerce padre, aunque el usuario lo hiciera desde otra página (incluso con dominio diferente). La magia de la persistencia una vez más en acción.

//Canal para recibir mensajes de pestañas
const transactionChannel = new BroadcastChannel("transactionChannel");

transactionChannel.onmessage = (event) => {
    if (event.data.event === "transactionComplete") {
        const transactionData = event.data.transactionDetails;
        console.log("Transacción completada recibida:", transactionData);

        dataLayer.push({
            'event': 'purchase',
            'transactionDetails': transactionData
        });
    }
};

//Enviar mensajes al dominio padre
const transactionChannel = new BroadcastChannel("transactionChannel");

function completeTransaction(transactionDetails) {
    // Envía los datos de la transacción al canal
    transactionChannel.postMessage({
        'event': 'transactionComplete',
        'transactionDetails': transactionDetails
    });
    console.log("Transacción completada y enviada al canal");
}


const transactionDetails = {
    'transaction_id': '12345ABC',
    'value': 100.50,
    'currency': 'USD',
    'items': [
        {
            'item_id': '001',
            'item_name': 'Producto A',
            'quantity': 1,
            'price': 50.25
        },
        {
            'item_id': '002',
            'item_name': 'Producto B',
            'quantity': 1,
            'price': 50.25
        }
    ]
};

completeTransaction(transactionDetails);

PostMessage: Comunicación entre ventanas y iframes

El método postMessage permite la transferencia segura de datos entre ventanas o iframes de distintos dominios, lo cual es invaluable cuando integras servicios externos como pasarelas de pago. Este método facilita que el estado de transacciones y otras interacciones dentro de un iframe se comuniquen con la ventana principal.

Ejemplo práctico: Enviar el estado de la transacción desde un iframe de pago en JavaScript

// Enviar un mensaje desde el iframe al sitio principal
iframe.contentWindow.postMessage({ event: "paymentSuccess", transactionId: "abc123" }, "*");

// Escuchar y procesar el mensaje en el sitio principal
window.addEventListener("message", (event) => {
  if (event.origin === "https://trusted-payment.com") {
    console.log("Estado de la transacción recibido:", event.data.transactionId);
    // Lógica para actualizar la capa de datos o registrar el evento
  }
});

Nota de seguridad: Siempre valida event.origin para asegurarte de que los datos provienen de una fuente confiable antes de procesarlos. Más vale prevenir que curar, créeme.

Mi solución de cabecera para comunicarme con pasarelas de pago desde el DOM y almacenar información en la capa de datos de forma cómoda y —sobre todo— segura.

window.addEventListener("message", function (event) {
  if (event.origin === "https://js.stripe.com") {
    try {
      var data = JSON.parse(event.data);

      if (
        data.message &&
        data.message.payload &&
        data.message.payload.response &&
        data.message.payload.response.object &&
        data.message.payload.response.object.status
      ) {
        
        if (
          data.message.payload.response.object.status === "requires_capture"
        ) {
          
          digitalData.events.push("postMessage-stripe_gateway");
          dataLayer.push({
            event: "gateway_confirmation",
            digitalData: digitalData,
          });
        }
      }
    } catch (error) {
      console.debug("Error procesando el mensaje de Stripe:", error);
    }
  } 
});

Comparativa de métodos de persistencia

Cada “método de persistencia” comentado aquí tiene sus características, fortalezas y limitaciones. La siguiente tabla te ayuda a identificar cuál elegir en función del tipo de dato y la duración deseada:

Adáptate a las necesidades del sitio web

La persistencia del dato es una pieza fundamental en la experiencia de usuario moderna. Al entender y aplicar estos métodos en función de la necesidad específica de tu aplicación, puedes garantizar que los datos relevantes estén disponibles cuando el usuario los necesite, mejorando tanto el rendimiento como la consistencia de la experiencia. Al combinar todos estos métodos, tienes a tu disposición un abanico completo de opciones para asegurar que el dato, al igual que la experiencia de usuario, persista de la mejor manera.

¿Y a ti, se te ocurre algún otro?

Deja un comentario