Data strength en Google Ads y WooCommerce: datos first-party y GTM del lado del servidor

En otoño de 2026 Google colocó los datos first-party en el centro de la medición de Google Ads. El 10 de septiembre anunció la métrica Data Strength Uplift y un Data Manager ampliado (blog Google Ads and Commerce), y la página de ayuda Data Strength Best Practices se lee ahora como una guía de implantación paso a paso. La dirección es clara: pegar un píxel de JavaScript en la cabecera de una tienda online ya no basta. Ante las exigencias regulatorias europeas, las restricciones de privacidad de navegadores como Safari ITP y el empleo generalizado de bloqueadores de publicidad, la rentabilidad de las inversiones de comercio electrónico depende ahora de la calidad de los datos propios (first-party data) y de sistemas de medición procesados en el servidor.

Para los responsables de tiendas WooCommerce e ingenieros de WordPress, este contexto obliga a sustituir extensiones genéricas por infraestructuras de datos diseñadas con exactitud. Un negocio digital que remite información parcial o discontinua a las plataformas publicitarias lo paga: los algoritmos de puja automatizada (Smart Bidding) pierden precisión de atribución y el coste por adquisición de clientes (CPA) sube.

En esta guía técnica explicamos qué abarca Data Strength, qué señales pide Google, los requisitos de ingeniería de las conversiones mejoradas (Enhanced Conversions) y cómo desplegar Google tag gateway y Server-Side Google Tag Manager (sGTM) en el dominio de la propia tienda.

#Qué es data strength en Google Ads y por qué condiciona los costes de campaña

Data Strength es el término genérico con el que Google designa la configuración de medición basada en datos first-party que alimenta Google Ads. La página de ayuda la divide en cuatro pasos: conectar las fuentes de datos, maximizar las señales, activar la IA de Google (Smart Bidding, AI Max for Search, Demand Gen, Performance Max) y demostrar el retorno con experimentos de incrementalidad y el modelo de marketing mix Meridian. Estos datos son una variable de entrada esencial para los modelos de aprendizaje automático que pujan en las campañas de Performance Max, Demand Gen y la red de búsqueda, así que las lagunas en los datos se convierten en lagunas en la puja.

Dos puntos de Google Ads lo traducen a cifras. La nueva métrica Data Strength Uplift, según el anuncio de Google, calcula las conversiones adicionales recuperadas por la configuración de datos first-party. Las calificaciones de calidad proceden de los diagnósticos: los diagnósticos de datos sin conexión etiquetan los datos importados como Excellent (al menos el 90% de los eventos con formato correcto), Good (entre el 70 y el 90% aproximadamente), Needs attention (menos del 70%) o No recent data (ningún evento en los últimos 28 días). Las conversiones mejoradas tienen su propio informe de diagnóstico.

En una tienda WooCommerce, la configuración que describe Google se reduce a cuatro condiciones técnicas:

1. Exactitud de los atributos de compra: Cada transacción transmitida debe aportar el importe íntegro, el código de divisa normalizado según ISO 4217 y un identificador único de pedido (Transaction ID) que imposibilite duplicidades.
2. Volumen de identificadores first-party con hash: Envío de correos electrónicos, números de teléfono y direcciones físicas estandarizados y hasheados, permitiendo a Google enlazar las compras con cuentas de Google con sesión iniciada.
3. Implantación conforme de Consent Mode v2: Emisión correcta de las directivas ad_user_data y ad_personalization en sincronía con la voluntad manifestada por el usuario en el gestor de consentimiento (CMP). La página de ayuda de Google no incluye el consentimiento como paso de Data Strength, pero en la UE no se puede enviar ningún identificador sin él.
4. Continuidad del flujo de datos: Erradicación de lagunas en la recepción de datos provocadas por caídas de pasarelas de pago externas, bloqueos perimetrales o cortes de red.

Cuando faltan datos, el motor Smart Bidding se ve forzado a operar con incertidumbre. Ve menos conversiones de las que registra la tienda, valora los clics con menos evidencia, y el retorno sobre el gasto publicitario (ROAS) y el coste por conversión evolucionan en la dirección equivocada.

#Qué señales pide la guía de data strength de Google a los anunciantes

El paso “maximizar las señales” de la página Data Strength Best Practices enumera los identificadores que Google quiere recibir con cada conversión:

• Datos del cliente: correo electrónico o teléfono con hash, que las conversiones mejoradas comparan con los datos de usuarios de Google con sesión iniciada para recuperar conversiones no observadas.
• Dirección IP: se envía en las importaciones mediante Data Manager. Google indica hasta un 3% más de conversiones observadas en la Búsqueda y más de un 10% en YouTube en una simulación sin conexión.
• Transaction ID: el número de pedido o de lead que conecta el clic en el frontend con la venta en el backend.
• GCLID: el identificador de clic que indica a Google qué campaña generó la venta.
• Atributos de sesión: ID de campaña, URL completa de la página de destino, marca temporal de la sesión, navegador y sistema operativo.
• GBRAID y WBRAID: parámetros de URL que recuperan la atribución de conversiones en iOS y en navegación privada.

De ahí salen dos reglas. Google recomienda enviar al menos 3 identificadores por evento, priorizando el GCLID y la IP junto con los datos del cliente con hash, y enviar todos los eventos de conversión en lugar de solo una parte.

En WooCommerce la mayoría de estos valores ya están en el pedido. $order->get_order_number() es el ID de transacción, $order->get_customer_ip_address() devuelve la IP registrada en el checkout y los campos de facturación contienen los datos del cliente. El GCLID, el GBRAID y el WBRAID solo aparecen como parámetros en la URL de la página de destino, así que una tienda que quiera subir conversiones desde el servidor tiene que capturarlos en la primera visita y guardarlos con el pedido.

Google respalda la página con cifras propias, cada una con su base declarada:

Son mediciones internas de Google, no estudios independientes. Tómelas como la dirección del efecto y mida su propia tienda antes y después.

#Por qué los píxeles tradicionales en el navegador pierden conversiones

Durante más de dos décadas, los sistemas de analítica digital dependieron de código procesado en el navegador del usuario (client-side tracking). Al culminar una compra, un fragmento de JavaScript leía los datos del Document Object Model (DOM) de la página de confirmación y remitía peticiones HTTP a servidores publicitarios externos. En 2026, este enfoque adolece de una fragilidad estructural crítica.

#Cómo los bloqueadores de anuncios y Safari ITP acortan la vida de las cookies

Existen tres factores técnicos que provocan pérdidas sistemáticas de información en las arquitecturas de rastreo basadas en el navegador:

Si un cliente completa el pago a través de un TPV virtual bancario o pasarela y prescinde de regresar a la pantalla de confirmación de la tienda, las etiquetas tradicionales de JavaScript no se disparan. El pedido queda asentado en la base de datos de WooCommerce, pero Google Ads carece de conocimiento sobre esa conversión.

#Por qué Smart Bidding en Google Ads necesita datos first-party

Los motores de puja inteligente proyectan la probabilidad de conversión de un usuario antes de entrar en la subasta publicitaria. Cuantos más elementos de identidad comprobables logre relacionar el algoritmo con una impresión de anuncio, más riguroso será el cálculo del valor económico esperado.

En ausencia de datos first-party, el algoritmo contempla únicamente una sesión anónima y un clic aislado. Con un correo electrónico con hash, Google hace coincidir la conversión con una cuenta de Google con sesión iniciada y puede atribuirla a la interacción con el anuncio que la precedió (Ayuda de Google Ads). Más conversiones atribuidas dan al modelo de puja más ejemplos de qué clics terminan en pedido.

#Cómo funcionan las conversiones mejoradas (Enhanced Conversions) en WooCommerce

Las conversiones mejoradas completan los avisos de compra habituales mediante la inclusión de identificadores recopilados durante el proceso de pago, previamente transformados con una función hash irreversible. Desde abril de 2026 las conversiones mejoradas para la web y para leads son un único ajuste de activar o desactivar en Google Ads, y los usuarios existentes se migraron automáticamente.

#Qué datos del cliente se deben hashear con SHA-256 antes del envío

La guía de Google sobre conversiones mejoradas exige normalizar los datos personales y aplicarles hash SHA-256 en hexadecimal, y enviar cada valor como cadena de texto:

• Correo electrónico: Supresión de espacios en blanco al inicio y final del texto, conversión obligatoria a letras minúsculas y aplicación de la función hash SHA-256. A partir de [email protected] se obtiene la cadena de entrada [email protected]. En direcciones gmail.com y googlemail.com se eliminan además los puntos antes de la @.
• Teléfono: Eliminación de espacios, guiones y paréntesis, adaptación a la norma E.164, de 11 a 15 dígitos con el signo más y el prefijo del país (por ejemplo, +34600123456), y hash con SHA-256.
• Nombre y apellidos: Letras en minúscula sin caracteres de puntuación ni espaciados superfluos.
• Código postal y territorio: Código postal libre de caracteres sobrantes y código internacional de país en dos letras bajo la norma ISO 3166-1 alpha-2 (como ES o MX). La coincidencia por dirección necesita nombre, apellidos, código postal y país a la vez.

#Código PHP completo para woocommerce_thankyou y el dataLayer

El código que figura a continuación se integra en el archivo functions.php del tema hijo o en un plugin del sitio. Se encarga de alimentar el objeto dataLayer en la pantalla de pedido completado mediante valores SHA-256 calculados directamente en PHP:

<?php
/**
 * Implementación de dataLayer para Google Ads Enhanced Conversions en WooCommerce
 */
add_action('woocommerce_thankyou', 'wppoland_inject_enhanced_conversions_datalayer', 20);

function wppoland_inject_enhanced_conversions_datalayer($order_id) {
    if (!$order_id) {
        return;
    }

    $order = wc_get_order($order_id);
    if (!$order || $order->has_status('failed')) {
        return;
    }

    // Normalización y cifrado del correo electrónico
    $raw_email = strtolower(trim($order->get_billing_email()));
    // gmail.com y googlemail.com: eliminar los puntos antes de la @
    if (preg_match('/^([^@]+)@(gmail|googlemail)\.com$/', $raw_email, $m)) {
        $raw_email = str_replace('.', '', $m[1]) . '@' . $m[2] . '.com';
    }
    $hashed_email = hash('sha256', $raw_email);

    // Normalización y cifrado del teléfono (formato E.164)
    $raw_phone = preg_replace('/[^0-9+]/', '', $order->get_billing_phone());
    if (strpos($raw_phone, '+') !== 0 && strlen($raw_phone) === 9) {
        $raw_phone = '+34' . $raw_phone; // Prefijo estándar para España
    }
    $hashed_phone = hash('sha256', $raw_phone);

    // Tratamiento de nombre y datos postales
    $raw_first_name = strtolower(trim($order->get_billing_first_name()));
    $raw_last_name  = strtolower(trim($order->get_billing_last_name()));
    $hashed_first_name = hash('sha256', $raw_first_name);
    $hashed_last_name  = hash('sha256', $raw_last_name);

    $postal_code = trim($order->get_billing_postcode());
    $country_code = strtoupper(trim($order->get_billing_country()));

    // Desglose de artículos adquiridos
    $items = [];
    foreach ($order->get_items() as $item) {
        $product = $item->get_product();
        if ($product) {
            $items[] = [
                'item_id'   => (string) $product->get_id(),
                'item_name' => $item->get_name(),
                'price'     => (float) $order->get_item_total($item, false, false),
                'quantity'  => (int) $item->get_quantity(),
            ];
        }
    }

    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
        event: 'purchase',
        ecommerce: {
            transaction_id: '<?php echo esc_js($order->get_order_number()); ?>',
            value: <?php echo (float) $order->get_total(); ?>,
            tax: <?php echo (float) $order->get_total_tax(); ?>,
            shipping: <?php echo (float) $order->get_shipping_total(); ?>,
            currency: '<?php echo esc_js($order->get_currency()); ?>',
            items: <?php echo json_encode($items); ?>
        },
        user_data: {
            sha256_email_address: '<?php echo esc_js($hashed_email); ?>',
            sha256_phone_number: '<?php echo esc_js($hashed_phone); ?>',
            address: {
                sha256_first_name: '<?php echo esc_js($hashed_first_name); ?>',
                sha256_last_name: '<?php echo esc_js($hashed_last_name); ?>',
                postal_code: '<?php echo esc_js($postal_code); ?>',
                country: '<?php echo esc_js($country_code); ?>'
            }
        }
    });
    </script>
    <?php
}

Al calcular los valores hash de SHA-256 directamente en el servidor mediante PHP, los datos personales legibles no se exponen a variables de JavaScript en el navegador del usuario, lo que refuerza la privacidad y el cumplimiento normativo.

#Cómo comprobar que las conversiones mejoradas funcionan en WooCommerce

Google indica tres comprobaciones, todas en el mismo artículo de ayuda:

1. Petición de red en la página de agradecimiento: haga un pedido de prueba, abra Chrome DevTools, vaya a la pestaña Network y localice la petición de conversión. Debe llevar un parámetro em: el correo aparece como tv.1~em seguido de un hash y el teléfono como tv.1~pn. Un prefijo sin hash significa que el campo estaba vacío cuando se disparó la etiqueta, lo que en WooCommerce suele indicar que la etiqueta se dispara antes del push al dataLayer.
2. Informe de diagnóstico: Google Ads muestra el diagnóstico de las conversiones mejoradas unas 48 horas después de la implantación.
3. Impacto: el efecto sobre las conversiones registradas se hace visible al cabo de unos 30 días.

Dos ajustes bloquean la recogida sin ningún aviso. Los datos no se recogen hasta aceptar las condiciones sobre datos de clientes en Google Ads o Google Analytics, y en la etiqueta de Google tiene que estar activada la opción Allow user-provided data capabilities. Cuando el fragmento de código y la detección automática aportan datos a la vez, Google da siempre prioridad al fragmento de código.

#Cómo implementar Server-Side Google Tag Manager en un subdominio propio

Disponer de una estructura adecuada en el dataLayer no resulta suficiente si las llamadas HTTP son canceladas por bloqueadores de contenido. Aquí entra un contenedor de Server-Side Google Tag Manager (sGTM).

#Por qué server-side GTM en el dominio propio es más difícil de bloquear

En el rastreo tradicional, el navegador se conecta de forma directa a dominios como googleadservices.com. Los bloqueadores de publicidad mantienen registros de estos servidores y cortan las peticiones en el propio dispositivo.

Con una arquitectura Server-Side GTM, el punto de recogida funciona en el dominio de la propia tienda, por ejemplo en un subdominio:

https://metricas.tu-tienda.es

La guía de Google sobre dominio propio describe tres opciones:

Para el navegador, las peticiones de las dos primeras opciones pertenecen al dominio de la tienda (contexto first-party), así que las listas de bloqueo dirigidas a los dominios de Google no las detectan. El subdominio tiene una salvedad: desde Safari 14, WebKit detecta el encubrimiento CNAME de terceros y limita a 7 días las cookies establecidas en esas respuestas (blog de WebKit). Un subdominio que sea un CNAME al dominio de un proveedor de alojamiento puede caer en esa regla, otro motivo para preferir el mismo origen.

En el entorno del servidor, el contenedor sGTM:

1. Centraliza un paquete consolidado de eventos procedente del cliente.
2. Sanea las cabeceras y elimina atributos innecesarios o potencialmente lesivos.
3. Establece cookies en la respuesta HTTP del dominio de la propia tienda en lugar de hacerlo con JavaScript.
4. Transfiere las llamadas de forma simultánea a Google Ads, Meta Conversions API (CAPI) y Google Analytics 4.

#Cuánto cuesta mantener server-side GTM en Cloud Run

La guía de Google para Cloud Run da cifras de dimensionamiento que conviene conocer antes de apostar por sGTM:

• Cada servidor de etiquetado es una instancia de Cloud Run con 1 vCPU y 0,5 GB de memoria, facturada en el modelo de CPU siempre asignada. Google estima unos 45 USD por servidor al mes.
• Google recomienda un mínimo de 2 instancias en producción para reducir el riesgo de pérdida de datos durante una caída.
• El autoescalado entre 2 y 10 servidores debería atender de 35 a 350 peticiones por segundo, según el número de etiquetas.
• El valor de max-instances marca el peor escenario de gasto, así que fíjelo con criterio y añada una alerta de facturación.
• El servidor de vista previa, que da servicio al modo de vista previa de Tag Manager, se aprovisiona por separado.
• Para un público global, Google sugiere desplegar en varias regiones detrás de un balanceador de carga.

App Engine y una configuración manual en cualquier plataforma figuran como alternativas documentadas. En una tienda WooCommerce pequeña, dos instancias funcionando todo el mes son un gasto mensual fijo que hay que comparar con las conversiones recuperadas.

#Cómo trasladar los scripts de análisis al servidor acelera la tienda online

Muchas tiendas de WooCommerce cargan en el cliente infinidad de librerías externas: píxel de Meta, scripts de Google Ads, TikTok, Pinterest y grabadores de sesiones. Cada uno de estos ficheros consume ciclos de procesamiento en el móvil del comprador, deteriorando las métricas de Core Web Vitals, muy especialmente Interaction to Next Paint (INP).

La transición hacia el servidor unifica esos procesos en una única etiqueta de recopilación ligera. El navegador expide un flujo de datos conciso, mientras que las adaptaciones de formato y el consumo de APIs externas se ejecutan en el servidor de etiquetado y no en el móvil del cliente. Google incluye la mejora del rendimiento de la página entre las ventajas del etiquetado en servidor (Google for Developers).

#En qué se diferencia Google tag gateway de server-side GTM

Google tag gateway for advertisers es la opción más ligera, y Google la menciona en el primer paso de la guía de Data Strength. Permite desplegar una etiqueta de Google en su propia infraestructura, servida desde el dominio del sitio (Google for Developers). El gateway funciona en una CDN, un balanceador de carga o un servidor web que ya tenga. Sirve la etiqueta de Google y sus peticiones de medición desde su dominio, pero no procesa ni redistribuye eventos como lo hace un contenedor sGTM.

Con Cloudflare, la configuración se hace en la propia etiqueta de Google (Ayuda de Google Ads):

1. En la configuración de la etiqueta de Google, abra Admin y seleccione Google tag gateway.
2. Inicie sesión en Cloudflare. La cuenta necesita el rol Super Administrator, Administrator o Zaraz Admin.
3. Seleccione los dominios que quiere activar y haga clic en Complete setup. Después, los dominios deben mostrar el estado Active.

El gateway usa una ruta de medición en su dominio, por defecto cuatro caracteres aleatorios, que se puede cambiar (por ejemplo a /metrics). Google pide revisar antes la configuración de consentimiento, porque activarlo cambia la forma en que se dispara la etiqueta de Google.

Las dos soluciones se complementan. Google tag gateway lleva las etiquetas de Google a su dominio con poca infraestructura. Server-side GTM añade una capa de procesamiento que también alimenta Meta CAPI, GA4 y otros destinos. Google recomienda completar ambas para lograr la configuración de etiquetado más duradera.

#Cómo coordinar Consent Mode v2 con el RGPD y las directivas de privacidad

Gestionar datos de primera parte en la Unión Europea impone el respeto riguroso al Reglamento General de Protección de Datos (RGPD) y la directiva ePrivacy. Google Consent Mode v2 articula el enlace técnico entre la decisión del comprador en el banner de consentimiento (CMP) y el comportamiento de las herramientas de medición. La documentación de Google deja claro que la responsabilidad de obtener el consentimiento sigue siendo del titular del sitio.

Consent Mode v2 trabaja con cuatro tipos de consentimiento:

// Configuración predeterminada antes de la respuesta del usuario
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

• ad_storage: Habilita o restringe el almacenamiento de cookies comerciales.
• analytics_storage: Controla el uso de cookies analíticas y estadísticas.
• ad_user_data: Determina si los datos personales con hash pueden transmitirse a Google para fines de atribución publicitaria.
• ad_personalization: Autoriza o veta la inclusión del perfil del usuario en listas de remarketing dinámico.

En el modo básico, las etiquetas de Google no se cargan hasta que el usuario interactúa con el banner, y si rechaza el consentimiento no se envía nada. En el modo avanzado (Advanced Consent Mode), las etiquetas se cargan con denegación por defecto y, si el comprador rechaza el uso de cookies, emiten señales sin cookies (cookieless pings) hacia Google. Estas comunicaciones contienen información sobre la interacción sin identificadores persistentes, y Google las usa para modelar conversiones cuando la etiqueta alcanza un umbral de datos recogidos (Google for Developers).

#Cómo construir data strength en WooCommerce paso a paso

Construir Data Strength en una tienda WooCommerce funciona mejor como una secuencia fija. El esquema siguiente define las fases del proyecto:

+-------------------------------------------------------------------+
|               PLAN DE OPTIMIZACIÓN DE DATA STRENGTH               |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ PASO 1: Auditar el evento de compra en el dataLayer ]
                 (Validar Transaction ID, importes y artículos)
                                  |
                                  v
        [ PASO 2: Aplicar hash SHA-256 en el servidor PHP ]
               (Procesar correo, teléfono y dirección en origen)
                                  |
                                  v
       [ PASO 3: Configurar Consent Mode v2 en la CMP ]
               (Asegurar la actualización dinámica de ad_user_data)
                                  |
                                  v
      [ PASO 4: Activar tag gateway y Server-Side GTM ]
               (Ruta en el mismo origen o subdominio, Cloud Run)
                                  |
                                  v
         [ PASO 5: Mapear conversiones mejoradas en sGTM ]
               (Enlazar user_data con la etiqueta de Google Ads)
                                  |
                                  v
       [ PASO 6: Enviar pedidos sin página de agradecimiento ]
               (Desde el servidor vía Google Ads API o Data Manager API)

1. Revisión del evento de compra: Verifique que el evento purchase aporte invariablemente referencias únicas de pedido, importes e impuestos.
2. Hash previo en el servidor: Implante la estandarización de campos de texto y la creación de valores SHA-256 en PHP, previniendo la exposición de datos personales en el entorno del navegador.
3. Conexión de CMP homologada: Integre un gestor de consentimiento compatible con Consent Mode v2 que renueve de forma dinámica los estados de autorización.
4. Despliegue de tag gateway y sGTM: Sirva la etiqueta de Google desde su dominio y encamine los eventos por un servidor de etiquetado en una ruta del mismo origen o en un subdominio.
5. Configuración de etiquetas en sGTM: Habilite las conversiones mejoradas en la etiqueta de Google Ads dentro del contenedor de servidor y asocie las propiedades user_data pertinentes.
6. Envío de los pedidos que faltan desde el servidor: En compras abonadas mediante pasarelas externas en las que el usuario no retorna a la tienda, use el hook woocommerce_order_status_completed para enviar la conversión, con el ID de transacción y el GCLID guardado, a Google Ads mediante la API de Google Ads o la Data Manager API.

#Conclusiones prácticas para responsables de e-commerce y especialistas en PPC

Mejorar Data Strength en Google Ads es una labor de ingeniería de datos cuyo resultado se puede comprobar en la cuenta.

La convergencia de conversiones mejoradas limpias, la protección de la identidad del usuario con SHA-256 y el paso de los eventos por Google tag gateway y Server-Side GTM aporta a la tienda:

• Las conversiones que pierde una etiqueta solo en el navegador (peticiones bloqueadas, páginas de agradecimiento cerradas) llegan a Google Ads, y la métrica Data Strength Uplift muestra cuántas son.
• Al menos 3 identificadores por pedido (ID de transacción, correo con hash, IP, GCLID cuando se ha guardado), tal como pide la guía de Google.
• Menos scripts de terceros en el navegador del cliente, lo que ayuda a las Core Web Vitals en móvil.
• Una configuración de consentimiento acorde con Consent Mode v2 y el marco legal europeo de protección de datos.

Para contrastar el cumplimiento técnico de su tienda online con las exigencias comunitarias, consulte nuestra evaluación de preparación de WooCommerce para la UE.

Una arquitectura de medición del lado del servidor y respetuosa con la privacidad mantiene la medición publicitaria en funcionamiento ante futuros cambios en los navegadores.