Actualización de «Conversiones mejoradas» de Google de 2026: la mayoría de las agencias aún no han comprobado si la suya funciona

En junio de 2026, Google Ads cambió el funcionamiento de «Conversiones mejoradas». Los dos productos independientes, «Conversiones mejoradas para web» y «Conversiones mejoradas para clientes potenciales», cada uno con su propia pantalla de configuración y método de implementación, se fusionaron en un único botón para activarlas o desactivarlas.

Google lo presentó como una simplificación, y lo es. Pero la actualización también hace algo menos obvio: elimina el recordatorio visible de que «Conversiones mejoradas» es un sistema activo con componentes dinámicos, no un interruptor que activas una vez y te olvidas. Si lo configuraste hace tiempo y no lo has vuelto a mirar desde entonces, es muy probable que ya no esté haciendo nada.

Una gran parte de las configuraciones de «Conversiones mejoradas» parecen estar activas en Google Ads, aunque envían pocos datos útiles o ninguno. El interruptor está en «activado». La acción de conversión muestra actividad. Pero los datos de usuario cifrados que hacen que toda la función funcione nunca llegan realmente a Google en un formato útil. Nadie se da cuenta, porque nada en la interfaz indica claramente que algo no funciona bien.

Aquí te cuento qué cambió realmente en junio de 2026, por qué fallan las configuraciones de «Conversiones mejoradas» de Google sin que aparezca ningún error visible, cómo comprobar si la tuya es una de ellas y por qué, para empezar, pasar la configuración por GTM server-side elimina la mayoría de los puntos de fallo.

¿Qué hacen realmente las «conversiones mejoradas» de Google?

Las conversiones mejoradas existen porque el seguimiento de conversiones basado en cookies tiene una laguna. Normalmente, Google Ads atribuye una conversión mediante un GCLID, un identificador de clics que se guarda en una cookie del navegador. Cuando esa cookie no está (porque está bloqueada, se ha borrado o el usuario ha realizado la conversión en otro dispositivo), la conversión sigue produciéndose, pero Google no puede vincularla al anuncio que la ha generado.

Las «conversiones mejoradas» cubren parte de esa brecha con un segundo identificador. Cuando un usuario realiza una conversión, tu sitio web recoge datos propios (normalmente una dirección de correo electrónico) y los codifica con SHA-256 antes de enviarlos a Google. Google compara ese hash con los hash derivados de los datos de sus propias cuentas con sesión iniciada. Si coinciden, la conversión se atribuye incluso sin un GCLID válido.

Ese es todo el proceso: hash, enviar, comparar. El proceso de hash es unidireccional, así que Google nunca recibe una dirección de correo legible, solo una huella digital de la misma.

Para ver el desglose completo, que incluye las «Conversiones mejoradas» para web frente a los «clientes potenciales», cómo funciona la tasa de coincidencia y las instrucciones de configuración para cada método de implementación, echa un vistazo a nuestra guía completa sobre las «Conversiones mejoradas» de Google.

Actualización de «Conversiones mejoradas» de Google de junio de 2026: qué ha cambiado

Antes de junio de 2026, «Conversiones mejoradas para la web» y «Conversiones mejoradas para clientes potenciales» eran funciones independientes. Cada una tenía su propia pantalla de configuración, y los anunciantes tenían que elegir un método de implementación (la etiqueta de Google, GTM o la API) por cada acción de conversión.

A partir de abril de 2026, Google empezó a aceptar datos proporcionados por los usuarios a través de etiquetas en sitios web, Data Manager y conexiones API al mismo tiempo, en lugar de imponer un único método. A partir de junio de 2026, esa flexibilidad se convirtió en la opción por defecto: los dos productos se fusionaron en una sola función con un único botón para activarla o desactivarla, y la pantalla de selección de método desapareció por completo de la interfaz.

Para las agencias que gestionan varias cuentas, hay tres cosas que conviene comprobar tras la fusión.

Las configuraciones existentes se migraron automáticamente, pero solo en el caso de las cuentas que ya habían aceptado las condiciones de Google sobre datos de clientes. Si una cuenta de cliente nunca aceptó explícitamente esas condiciones (algo habitual cuando una agencia anterior o un equipo interno activó las «Conversiones mejoradas» sin completar toda la configuración), la migración no se realiza correctamente y es posible que la cuenta muestre las «Conversiones mejoradas» como disponibles pero inactivas.

El cambio en la interfaz ha ocultado algunas de las pistas de diagnóstico que había antes. Cuando se veía la selección de métodos, al menos podías confirmar qué ruta de implementación se suponía que debía usar una acción de conversión. Ahora que ya no está esa pantalla, comprobar la configuración depende más de los diagnósticos y menos de que la página de ajustes coincida con lo que esperas.

La opción de exclusión sigue existiendo a nivel de la acción de conversión, y nada de lo relacionado con la fusión cambia el requisito subyacente de las Condiciones de tratamiento de datos. Google sigue esperando que los anunciantes hayan aceptado esas condiciones y que gestionen los datos facilitados por los usuarios de acuerdo con la política. El botón de activación/desactivación se ha simplificado, pero la obligación de cumplir con la normativa sigue siendo la misma.

Las configuraciones que funcionan, siguen funcionando. Pero este es un buen momento para revisar las cuentas que se configuraron hace tiempo y que nunca se han vuelto a revisar, porque la fusión es precisamente el tipo de cambio que saca a la luz problemas que nadie esperaba.

Por qué falla «Enhanced Conversions» sin avisar y cómo detectarlo

Las conversiones mejoradas de Google tienen un tipo de fallo específico que pasa fácilmente desapercibido. La etiqueta de conversión puede activarse correctamente, la conversión se registra de todos modos y Google Ads puede mostrar la acción de conversión como activa, mientras que los datos mejorados en sí nunca llegan realmente a Google en un estado utilizable.

El propio informe de diagnóstico de Google define varios estados precisamente por este motivo. «Registrando conversiones mejoradas» significa que realmente está funcionando. «A la espera de recibir datos de conversiones mejoradas» puede significar que aún es pronto, ya que el estado puede tardar hasta 48 horas en actualizarse. Pero «Se han detectado problemas de configuración» y, en el caso de los clientes potenciales, un estado «Urgente», indican que la configuración parece estar activa pero no está generando nada útil. La brecha entre esos estados es donde la mayoría de las configuraciones defectuosas se quedan durante meses, sin que nadie les haga caso, mientras a nadie se le ocurre echar un vistazo.

Las causas más comunes no son nada del otro mundo. Son pequeños detalles de configuración que no dan ningún error:

• El campo «user_data» está ahí, pero está vacío. La etiqueta se activa, el contenedor llega a Google, pero el campo con el correo electrónico o el número de teléfono en forma de hash que hay dentro está en blanco. Google registra el ping como recibido y sigue adelante. No señala que «no había nada útil ahí». Normalmente se trata de una variable de GTM que nunca se asignó a la clave correcta de dataLayer, y es la causa más habitual de que una configuración que parece estar bien no aporte ninguna señal.
• Doble hash. Algunos equipos aplican ellos mismos el hash a la dirección de correo electrónico antes de enviarla a dataLayer; luego, GTM o la etiqueta de Google le aplican otro hash antes de enviarla. Al final, Google compara un hash de un hash con su propia base de datos de hashes individuales. Nunca coincide nada y no aparece ningún error que indique la causa. La solución es enviar siempre el valor sin procesar y dejar que GTM o gtag.js se encarguen del hash.
• Activar el interruptor sin tocar la etiqueta. Al activar las conversiones mejoradas en la interfaz de Google Ads, tu etiqueta de GTM no se reconfigura automáticamente. Si nunca se han configurado los campos «user_data» en la etiqueta de conversión, activar el interruptor a nivel de cuenta no tiene ningún efecto, salvo que la configuración parezca activa.
• Los selectores CSS han dejado de funcionar tras el rediseño de la web. Si la configuración original captaba el campo de correo electrónico mediante un selector CSS en la página de confirmación, un rediseño que cambie los ID de los elementos o los nombres de las clases hace que el selector deje de funcionar sin que nadie se dé cuenta. La etiqueta sigue activándose, pero ya no encuentra nada que procesar. Las variables de la capa de datos no tienen este problema, y esa es una de las razones por las que son la opción más duradera.
• Un sistema de consentimiento que parece una variación normal. Cuando se deniega el consentimiento para «ad_user_data», «Enhanced Conversions» simplemente no envía los datos con hash de ese usuario. Es el comportamiento correcto, no un error, pero eso significa que la tasa de coincidencia baja de forma natural en las regiones donde el consentimiento es muy exigente. El truco está en distinguir entre la variación esperada debida al consentimiento y un fallo técnico real, algo difícil de hacer sin comprobar las cifras directamente.

Para diagnosticar cualquiera de estos problemas, empieza por estas dos comprobaciones: abre el modo de vista previa de GTM y confirma que el objeto «user_data» de la etiqueta de conversión contiene realmente valores con hash, y no un objeto vacío. A continuación, comprueba si la propia solicitud de red incluye el parámetro «em». Si no está, significa que la etiqueta no está configurada para enviarlo. Si está presente pero dice algo así como «tv.1~em.» sin nada detrás, el campo se está activando vacío. En cualquier caso, la solución está en GTM, no en la pantalla de configuración de Google Ads.

Cómo el GTM server-side hace que las conversiones mejoradas de Google sean más fiables

La mayoría de los puntos de fallo mencionados tienen algo en común: se producen en el navegador, donde la etiqueta depende del DOM de la página, de que el dataLayer se haya rellenado correctamente y de que nada intercepte la solicitud antes de que salga. Trasladar la configuración a GTM server-side no elimina todos los modos de fallo, pero sí elimina varios de ellos al cambiar el lugar donde se lleva a cabo el proceso.

Con un contenedor de servidor, la tarea del navegador se reduce. Este envía el evento (con los datos sin procesar del usuario) a tu propio punto final de primera parte. El contenedor de servidor, y no una etiqueta del navegador, crea el objeto `user_data`, aplica el hash y reenvía la solicitud a Google. Ese único cambio elimina por completo el problema del doble hash, ya que la lógica de hash se encuentra en un solo lugar en lugar de estar dividida entre la página y la etiqueta.

Además, elimina el riesgo de los bloqueadores de anuncios. Una etiqueta de «Conversiones mejoradas» del lado del navegador envía su solicitud desde el navegador del usuario, lo que significa que un bloqueador de anuncios o una función de protección contra el rastreo puede interceptarla o descartarla antes de que Google la vea. La etiqueta puede estar perfectamente configurada y, aun así, perder datos por algo que está totalmente fuera de tu control. Una solicitud de servidor a servidor desde tu contenedor a la API de Google no corre ese riesgo, porque no hay nada en el navegador que un bloqueador pueda interceptar.

Vale la pena tener en cuenta que el salto server-side solo sirve de algo si el tramo del navegador al servidor ya es de por sí resistente. Asegúrate de ejecutar el script de seguimiento mejorado de TAGGRS para que esa solicitud inicial sea totalmente invisible para los bloqueadores de anuncios; de lo contrario, el mismo riesgo de interceptación simplemente se adelanta un paso en la cadena.

Nada de esto sustituye la necesidad de configurar las cosas correctamente. Una configuración server-side con un campo «user_data» vacío sigue siendo un campo «user_data» vacío. Pero sí que significa que hay menos puntos en los que una configuración que funciona puede dejar de hacerlo sin que aparezca ningún error, que es precisamente el tipo de fallo que cuesta detectar si no lo buscas activamente. Para las agencias que gestionan varias cuentas de clientes, esa diferencia en la fiabilidad se acumula rápidamente: menos fallos silenciosos significan menos auditorías, menos lagunas en los datos de atribución y menos conversaciones para explicar a los clientes por qué sus cifras de conversión no se corresponden con la realidad.

• Para ver la guía de configuración completa, incluida la configuración a nivel de campo para Google Ads a través de GTM del lado del servidor, echa un vistazo a la documentación sobre la configuración de «Conversiones mejoradas» y a la descripción general del seguimiento server-side de Google Ads.
• Si además gestionas conversiones offline desde un CRM junto con «Conversiones mejoradas para clientes potenciales», la documentación sobre la etiqueta de conversión offline explica esa configuración concreta, y este artículo sobre cómo demostrar el ROAS real de las conversiones offline explica por qué esos datos son importantes para la elaboración de informes, más allá de «Smart Bidding».

Las conversiones mejoradas de Google y el RGPD: lo que deben saber las agencias de la UE

«Enhanced Conversions» envía datos personales, y el uso de hash no cambia esa clasificación según el RGPD. Un hash SHA-256 de una dirección de correo electrónico son datos seudonimizados, no datos anonimizados, porque Google (la parte que los recibe) puede compararlos con los datos que ya tiene y volver a identificar a la persona que hay detrás. La distinción es importante: los datos seudonimizados siguen estando totalmente sujetos al RGPD, con las mismas obligaciones en cuanto a la base legal, el consentimiento y los derechos de los interesados.

En la práctica, esto significa que «Google Enhanced Conversions» necesita que se conceda la señal de consentimiento «ad_user_data» del «Consent Mode V2» antes de activarse. Si un usuario deniega ese consentimiento, la etiqueta de Google no incluirá en absoluto los datos con hash en el registro de conversión. Esto es así por diseño, no es un error, y es el comportamiento correcto y conforme a la normativa. El modelo de conversión agregada sigue aplicándose a los usuarios que no dan su consentimiento.

Para las agencias de la UE, el riesgo real no suele ser el programa «Enhanced Conversions» en sí mismo. El problema son aquellas configuraciones en las que se concede el permiso «ad_storage», pero nunca se ha configurado explícitamente «ad_user_data», por lo que el banner de consentimiento funciona técnicamente, mientras que la señal subyacente que Google comprueba realmente para «Enhanced Conversions» nunca se ha activado. La etiqueta se activa, los datos se envían y no hay ningún registro de consentimiento que lo respalde. Esa es una brecha de cumplimiento que no aparecerá en un informe de tasa de coincidencia, porque, desde el punto de vista de Google, todo parece funcionar correctamente. Es el tipo de cosa que solo descubres si la buscas, y que resulta muy complicado de explicar a posteriori.

El GTM server-side no elimina el requisito del consentimiento, ni debería hacerlo. Lo que hace es centralizar el lugar donde se comprueba el consentimiento. En lugar de depender de varias etiquetas server-side para que cada una respete correctamente el estado del consentimiento, el contenedor del servidor puede filtrar toda la carga de datos del usuario en un solo lugar antes de que se envíe nada a Google, Meta o cualquier otra plataforma.

Para tener una visión completa sobre las señales de consentimiento y el seguimiento server-side, echa un vistazo a la guía sobre el RGPD y el seguimiento server-side.

Dónde encaja TAGGRS

Revisar las conversiones mejoradas en todas las cuentas de los clientes cada vez que Google hace una actualización no es un proceso viable para la mayoría de las agencias. Nadie tiene tiempo de abrir el modo de vista previa de GTM en cincuenta cuentas cada vez que Google cambia algo.

TAGGRS ejecuta las «conversiones mejoradas» a través del mismo contenedor de GTM server-side que se encarga del resto del seguimiento de una cuenta. Como el hash y la construcción de «user_data» se realizan en el lado server-side, en lugar de a través de un batiburrillo de etiquetas del navegador, hay menos puntos en los que pueda colarse un error silencioso —como una carga útil vacía o un campo con doble hash— sin que nadie se dé cuenta.

El control de consentimientos también se gestiona desde un único lugar. En lugar de comprobar si cada etiqueta server-side en la web de un cliente respeta correctamente el parámetro `ad_user_data`, el contenedor del servidor se encarga de garantizarlo de forma centralizada, antes de que cualquier dato de usuario se envíe a Google, Meta u otra plataforma.

Para los equipos que ya utilizan el seguimiento de Google Ads a través de TAGGRS, las «conversiones mejoradas» forman parte del mismo proceso que cualquier otro evento de conversión, y se pueden supervisar en los paneles de análisis centralizados de la cuenta de TAGGRS.

Conclusión

La actualización de junio de 2026 hizo que las «Conversiones mejoradas» fueran más fáciles de activar y más fáciles de pasar por alto. Ese es el riesgo que se esconde tras una simplificación: tener menos ajustes que gestionar también significa menos recordatorios visibles para comprobar si lo que configuraste hace meses sigue funcionando como es debido.

Una configuración que parezca activa en Google Ads puede que, aun así, no esté enviando nada útil. La única forma de saberlo es comprobar el informe de diagnóstico y la solicitud de red real, no solo el interruptor. Y si el objetivo es reducir los puntos en los que puede producirse ese fallo, trasladar la configuración server-side elimina la mayoría de los puntos dependientes del navegador en los que suele fallar.

Hacer un seguimiento de las conversiones mejoradas en todas las cuentas de tus clientes es justo el tipo de trabajo que una configuración server-side está pensada para ahorrarte. Puedes crear una cuenta gratuita en TAGGRS para empezar, o echar un vistazo a las guías de configuración si prefieres ver primero cómo funciona.

Preguntas frecuentes

¿Qué ha cambiado con la actualización «Enhanced Conversions» de junio de 2026?

Google ha fusionado «Conversiones mejoradas para web» y «Conversiones mejoradas para clientes potenciales» en un único botón de activación/desactivación y ha eliminado la pantalla en la que los anunciantes elegían el método de implementación. Las cuentas existentes que ya habían aceptado las condiciones de Google sobre datos de clientes se han migrado automáticamente. El mecanismo subyacente de hash y coincidencia no ha cambiado.

¿Por qué las «Conversiones mejoradas» parecen estar activas pero en realidad no funcionan?

Porque la etiqueta de conversión y los datos ampliados son dos cosas distintas. La etiqueta puede activarse y la conversión puede registrarse con normalidad aunque el campo «user_data» que contiene esté vacío, tenga un doble hash o ni siquiera aparezca. Google Ads muestra la acción de conversión como activa en cualquier caso, ya que la conversión básica sigue registrándose correctamente.

¿Cómo puedo comprobar si mi configuración de «Conversiones mejoradas» está enviando datos útiles?

Abre el modo de vista previa de GTM, realiza una conversión de prueba y comprueba que el objeto «user_data» contenga valores hash en lugar de estar vacío. A continuación, comprueba si la solicitud de red incluye el parámetro «em». Si falta o está vacío, los datos mejorados no llegan a Google, aunque se realice el seguimiento de la conversión básica.

¿El GTM server-side soluciona todos los problemas relacionados con las conversiones mejoradas?

No. Un campo mal configurado sigue estando mal configurado, independientemente de dónde se realice el hash. Lo que elimina el GTM server-side son los puntos de fallo que dependen del navegador: los bloqueadores de anuncios que interceptan la solicitud, los selectores CSS que dejan de funcionar tras un rediseño y el doble hash causado por la división de la lógica entre la página y la etiqueta.

¿Las conversiones mejoradas siguen cumpliendo con el RGPD tras la actualización?

Sí, y el requisito no ha cambiado. «Enhanced Conversions» sigue necesitando que se conceda el consentimiento para «ad_user_data» a través del «Consent Mode V2» antes de poder enviar datos con hash. El hash no convierte los datos en anónimos según el RGPD, ya que Google sigue pudiendo relacionarlos con los datos de la cuenta que tiene almacenados.

¿Tengo que volver a configurar las «Conversiones mejoradas» por la fusión?

No necesariamente. Si tu cuenta ya había aceptado las condiciones sobre los datos de los clientes, la migración se ha realizado automáticamente. Aun así, vale la pena echar un vistazo al informe de diagnóstico, ya que la fusión es una buena ocasión para detectar alguna configuración que ya fallaba antes de la actualización, pero que nadie había notado.