En junio de 2026, Google Ads cambi\u00f3 el funcionamiento de \u00abConversiones mejoradas\u00bb. Los dos productos independientes, \u00abConversiones mejoradas para web\u00bb y \u00abConversiones mejoradas para clientes potenciales\u00bb, cada uno con su propia pantalla de configuraci\u00f3n y m\u00e9todo de implementaci\u00f3n, se fusionaron en un \u00fanico bot\u00f3n para activarlas o desactivarlas. <\/p>\n\n
Google lo present\u00f3 como una simplificaci\u00f3n, y lo es. Pero la actualizaci\u00f3n tambi\u00e9n hace algo menos obvio: elimina el recordatorio visible de que \u00abConversiones mejoradas\u00bb es un sistema activo con componentes din\u00e1micos, 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\u00e9 haciendo nada. <\/p>\n\n
Una gran parte de las configuraciones de \u00abConversiones mejoradas\u00bb parecen estar activas en Google Ads, aunque env\u00edan pocos datos \u00fatiles o ninguno. El interruptor est\u00e1 en \u00abactivado\u00bb. La acci\u00f3n de conversi\u00f3n muestra actividad. Pero los datos de usuario cifrados que hacen que toda la funci\u00f3n funcione nunca llegan realmente a Google en un formato \u00fatil. Nadie se da cuenta, porque nada en la interfaz indica claramente que algo no funciona bien. <\/p>\n\n
Aqu\u00ed te cuento qu\u00e9 cambi\u00f3 realmente en junio de 2026, por qu\u00e9 fallan las configuraciones de \u00abConversiones mejoradas\u00bb de Google sin que aparezca ning\u00fan error visible, c\u00f3mo comprobar si la tuya es una de ellas y por qu\u00e9, para empezar, pasar la configuraci\u00f3n por GTM server-side elimina la mayor\u00eda de los puntos de fallo.<\/p>\n\n
Las conversiones mejoradas existen porque el seguimiento de conversiones basado en cookies tiene una laguna. Normalmente, Google Ads atribuye una conversi\u00f3n mediante un GCLID, un identificador de clics que se guarda en una cookie del navegador. Cuando esa cookie no est\u00e1 (porque est\u00e1 bloqueada, se ha borrado o el usuario ha realizado la conversi\u00f3n en otro dispositivo), la conversi\u00f3n sigue produci\u00e9ndose, pero Google no puede vincularla al anuncio que la ha generado. <\/p>\n\n
Las \u00abconversiones mejoradas\u00bb cubren parte de esa brecha con un segundo identificador. Cuando un usuario realiza una conversi\u00f3n, tu sitio web recoge datos propios (normalmente una direcci\u00f3n de correo electr\u00f3nico) 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\u00f3n iniciada. Si coinciden, la conversi\u00f3n se atribuye incluso sin un GCLID v\u00e1lido. <\/p>\n\n
Ese es todo el proceso: hash, enviar, comparar. El proceso de hash es unidireccional, as\u00ed que Google nunca recibe una direcci\u00f3n de correo legible, solo una huella digital de la misma. <\/p>\n\n
Para ver el desglose completo, que incluye las \u00abConversiones mejoradas\u00bb para web frente a los \u00abclientes potenciales\u00bb, c\u00f3mo funciona la tasa de coincidencia y las instrucciones de configuraci\u00f3n para cada m\u00e9todo de implementaci\u00f3n, echa un vistazo a nuestra gu\u00eda completa sobre las \u00abConversiones mejoradas\u00bb de Google<\/a>.<\/p>\n\n Antes de junio de 2026, \u00abConversiones mejoradas para la web\u00bb y \u00abConversiones mejoradas para clientes potenciales\u00bb eran funciones independientes. Cada una ten\u00eda su propia pantalla de configuraci\u00f3n, y los anunciantes ten\u00edan que elegir un m\u00e9todo de implementaci\u00f3n (la etiqueta de Google, GTM o la API) por cada acci\u00f3n de conversi\u00f3n. <\/p>\n\n A partir de abril de 2026, Google empez\u00f3 a aceptar datos proporcionados por los usuarios a trav\u00e9s de etiquetas en sitios web, Data Manager y conexiones API al mismo tiempo, en lugar de imponer un \u00fanico m\u00e9todo. A partir de junio de 2026, esa flexibilidad se convirti\u00f3 en la opci\u00f3n por defecto: los dos productos se fusionaron en una sola funci\u00f3n con un \u00fanico bot\u00f3n para activarla o desactivarla<\/a>, y la pantalla de selecci\u00f3n de m\u00e9todo desapareci\u00f3 por completo de la interfaz. <\/p>\n\n Para las agencias que gestionan varias cuentas, hay tres cosas que conviene comprobar tras la fusi\u00f3n.<\/p>\n\n Las configuraciones existentes se migraron autom\u00e1ticamente, pero solo en el caso de las cuentas que ya hab\u00edan aceptado las condiciones de Google sobre datos de clientes. Si una cuenta de cliente nunca acept\u00f3 expl\u00edcitamente esas condiciones (algo habitual cuando una agencia anterior o un equipo interno activ\u00f3 las \u00abConversiones mejoradas\u00bb sin completar toda la configuraci\u00f3n), la migraci\u00f3n no se realiza correctamente y es posible que la cuenta muestre las \u00abConversiones mejoradas\u00bb como disponibles pero inactivas. <\/p>\n\n El cambio en la interfaz ha ocultado algunas de las pistas de diagn\u00f3stico que hab\u00eda antes. Cuando se ve\u00eda la selecci\u00f3n de m\u00e9todos, al menos pod\u00edas confirmar qu\u00e9 ruta de implementaci\u00f3n se supon\u00eda que deb\u00eda usar una acci\u00f3n de conversi\u00f3n. Ahora que ya no est\u00e1 esa pantalla, comprobar la configuraci\u00f3n depende m\u00e1s de los diagn\u00f3sticos y menos de que la p\u00e1gina de ajustes coincida con lo que esperas. <\/p>\n\n La opci\u00f3n de exclusi\u00f3n sigue existiendo a nivel de la acci\u00f3n de conversi\u00f3n, y nada de lo relacionado con la fusi\u00f3n 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\u00edtica. El bot\u00f3n de activaci\u00f3n\/desactivaci\u00f3n se ha simplificado, pero la obligaci\u00f3n de cumplir con la normativa sigue siendo la misma. <\/p>\n\n 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\u00f3n es precisamente el tipo de cambio que saca a la luz problemas que nadie esperaba. <\/p>\n\n Las conversiones mejoradas de Google tienen un tipo de fallo espec\u00edfico que pasa f\u00e1cilmente desapercibido. La etiqueta de conversi\u00f3n puede activarse correctamente, la conversi\u00f3n se registra de todos modos y Google Ads puede mostrar la acci\u00f3n de conversi\u00f3n como activa, mientras que los datos mejorados en s\u00ed nunca llegan realmente a Google en un estado utilizable. <\/p>\n\n El propio informe de diagn\u00f3stico de Google define varios estados precisamente por este motivo. \u00abRegistrando conversiones mejoradas\u00bb significa que realmente est\u00e1 funcionando. \u00abA la espera de recibir datos de conversiones mejoradas\u00bb puede significar que a\u00fan es pronto, ya que el estado puede tardar hasta 48 horas en actualizarse. Pero \u00abSe han detectado problemas de configuraci\u00f3n\u00bb y, en el caso de los clientes potenciales, un estado \u00abUrgente\u00bb, indican que la configuraci\u00f3n parece estar activa pero no est\u00e1 generando nada \u00fatil. La brecha entre esos estados es donde la mayor\u00eda de las configuraciones defectuosas se quedan durante meses, sin que nadie les haga caso, mientras a nadie se le ocurre echar un vistazo. <\/p>\n\n Las causas m\u00e1s comunes no son nada del otro mundo. Son peque\u00f1os detalles de configuraci\u00f3n que no dan ning\u00fan error: <\/p>\n\n Para diagnosticar cualquiera de estos problemas, empieza por estas dos comprobaciones: abre el modo de vista previa de GTM y confirma que el objeto \u00abuser_data\u00bb de la etiqueta de conversi\u00f3n contiene realmente valores con hash, y no un objeto vac\u00edo. A continuaci\u00f3n, comprueba si la propia solicitud de red incluye el par\u00e1metro \u00abem\u00bb. Si no est\u00e1, significa que la etiqueta no est\u00e1 configurada para enviarlo. Si est\u00e1 presente pero dice algo as\u00ed como \u00abtv.1~em.\u00bb<\/em> sin nada detr\u00e1s, el campo se est\u00e1 activando vac\u00edo. En cualquier caso, la soluci\u00f3n est\u00e1 en GTM, no en la pantalla de configuraci\u00f3n de Google Ads. <\/p>\n\n La mayor\u00eda de los puntos de fallo mencionados tienen algo en com\u00fan: se producen en el navegador, donde la etiqueta depende del DOM de la p\u00e1gina, de que el dataLayer se haya rellenado correctamente y de que nada intercepte la solicitud antes de que salga. Trasladar la configuraci\u00f3n a GTM server-side no elimina todos los modos de fallo, pero s\u00ed elimina varios de ellos al cambiar el lugar donde se lleva a cabo el proceso. <\/p>\n\n Con un contenedor de servidor, la tarea del navegador se reduce. Este env\u00eda 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\u00eda la solicitud a Google. Ese \u00fanico cambio elimina por completo el problema del doble hash, ya que la l\u00f3gica de hash se encuentra en un solo lugar en lugar de estar dividida entre la p\u00e1gina y la etiqueta. <\/p>\n\n Adem\u00e1s, elimina el riesgo de los bloqueadores de anuncios<\/a>. Una etiqueta de \u00abConversiones mejoradas\u00bb del lado del navegador env\u00eda su solicitud desde el navegador del usuario, lo que significa que un bloqueador de anuncios o una funci\u00f3n de protecci\u00f3n contra el rastreo puede interceptarla o descartarla antes de que Google la vea. La etiqueta puede estar perfectamente configurada y, aun as\u00ed, perder datos por algo que est\u00e1 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. <\/p>\n\n Vale la pena tener en cuenta<\/strong> que el salto server-side solo sirve de algo si el tramo del navegador al servidor ya es de por s\u00ed resistente. Aseg\u00farate de ejecutar el script de seguimiento mejorado<\/a> de TAGGRS<\/a> para que esa solicitud inicial sea totalmente invisible para los bloqueadores de anuncios; de lo contrario, el mismo riesgo de interceptaci\u00f3n simplemente se adelanta un paso en la cadena. <\/p>\n\n Nada de esto sustituye la necesidad de configurar las cosas correctamente. Una configuraci\u00f3n server-side con un campo \u00abuser_data\u00bb vac\u00edo sigue siendo un campo \u00abuser_data\u00bb vac\u00edo. Pero s\u00ed que significa que hay menos puntos en los que una configuraci\u00f3n que funciona puede dejar de hacerlo sin que aparezca ning\u00fan 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\u00e1pidamente: menos fallos silenciosos significan menos auditor\u00edas, menos lagunas en los datos de atribuci\u00f3n y menos conversaciones para explicar a los clientes por qu\u00e9 sus cifras de conversi\u00f3n no se corresponden con la realidad. <\/p>\n\n \u00abEnhanced Conversions\u00bb env\u00eda datos personales, y el uso de hash no cambia esa clasificaci\u00f3n seg\u00fan el RGPD. Un hash SHA-256 de una direcci\u00f3n de correo electr\u00f3nico 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\u00e1s. La distinci\u00f3n 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. <\/p>\n\n En la pr\u00e1ctica, esto significa que \u00abGoogle Enhanced Conversions\u00bb necesita que se conceda la se\u00f1al de consentimiento \u00abad_user_data\u00bb del \u00abConsent Mode V2\u00bb<\/a> antes de activarse. Si un usuario deniega ese consentimiento, la etiqueta de Google no incluir\u00e1 en absoluto los datos con hash en el registro de conversi\u00f3n. Esto es as\u00ed por dise\u00f1o, no es un error, y es el comportamiento correcto y conforme a la normativa. El modelo de conversi\u00f3n agregada sigue aplic\u00e1ndose a los usuarios que no dan su consentimiento. <\/p>\n\n Para las agencias de la UE, el riesgo real no suele ser el programa \u00abEnhanced Conversions\u00bb en s\u00ed mismo. El problema son aquellas configuraciones en las que se concede el permiso \u00abad_storage\u00bb, pero nunca se ha configurado expl\u00edcitamente \u00abad_user_data\u00bb, por lo que el banner de consentimiento funciona t\u00e9cnicamente, mientras que la se\u00f1al subyacente que Google comprueba realmente para \u00abEnhanced Conversions\u00bb nunca se ha activado. La etiqueta se activa, los datos se env\u00edan y no hay ning\u00fan registro de consentimiento que lo respalde. Esa es una brecha de cumplimiento que no aparecer\u00e1 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. <\/p>\n\n El GTM server-side no elimina el requisito del consentimiento, ni deber\u00eda 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\u00ede nada a Google, Meta o cualquier otra plataforma. <\/p>\n\n Para tener una visi\u00f3n completa sobre las se\u00f1ales de consentimiento y el seguimiento server-side, echa un vistazo a la gu\u00eda sobre el RGPD y el seguimiento server-side<\/a>.<\/p>\n\n Revisar las conversiones mejoradas en todas las cuentas de los clientes cada vez que Google hace una actualizaci\u00f3n no es un proceso viable para la mayor\u00eda de las agencias. Nadie tiene tiempo de abrir el modo de vista previa de GTM en cincuenta cuentas cada vez que Google cambia algo. <\/p>\n\n TAGGRS ejecuta las \u00abconversiones mejoradas\u00bb a trav\u00e9s del mismo contenedor de GTM server-side que se encarga del resto del seguimiento de una cuenta. Como el hash y la construcci\u00f3n de \u00abuser_data\u00bb se realizan en el lado server-side, en lugar de a trav\u00e9s de un batiburrillo de etiquetas del navegador, hay menos puntos en los que pueda colarse un error silencioso \u2014como una carga \u00fatil vac\u00eda o un campo con doble hash\u2014 sin que nadie se d\u00e9 cuenta. <\/p>\n\n El control de consentimientos tambi\u00e9n se gestiona desde un \u00fanico lugar. En lugar de comprobar si cada etiqueta server-side en la web de un cliente respeta correctamente el par\u00e1metro `ad_user_data`, el contenedor del servidor se encarga de garantizarlo de forma centralizada, antes de que cualquier dato de usuario se env\u00ede a Google, Meta u otra plataforma. <\/p>\n\n Para los equipos que ya utilizan el seguimiento de Google Ads a trav\u00e9s de TAGGRS, las \u00abconversiones mejoradas\u00bb forman parte del mismo proceso que cualquier otro evento de conversi\u00f3n, y se pueden supervisar en los paneles de an\u00e1lisis centralizados de la cuenta de TAGGRS. <\/p>\n\n La actualizaci\u00f3n de junio de 2026 hizo que las \u00abConversiones mejoradas\u00bb fueran m\u00e1s f\u00e1ciles de activar y m\u00e1s f\u00e1ciles de pasar por alto. Ese es el riesgo que se esconde tras una simplificaci\u00f3n: tener menos ajustes que gestionar tambi\u00e9n significa menos recordatorios visibles para comprobar si lo que configuraste hace meses sigue funcionando como es debido. <\/p>\n\n Una configuraci\u00f3n que parezca activa en Google Ads puede que, aun as\u00ed, no est\u00e9 enviando nada \u00fatil. La \u00fanica forma de saberlo es comprobar el informe de diagn\u00f3stico 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\u00f3n server-side elimina la mayor\u00eda de los puntos dependientes del navegador en los que suele fallar. <\/p>\n\n Hacer un seguimiento de las conversiones mejoradas en todas las cuentas de tus clientes es justo el tipo de trabajo que una configuraci\u00f3n server-side est\u00e1 pensada para ahorrarte. Puedes crear una cuenta gratuita en TAGGRS<\/a> para empezar, o echar un vistazo a las gu\u00edas de configuraci\u00f3n<\/a> si prefieres ver primero c\u00f3mo funciona. <\/p>\n\n Google ha fusionado \u00abConversiones mejoradas para web\u00bb y \u00abConversiones mejoradas para clientes potenciales\u00bb en un \u00fanico bot\u00f3n de activaci\u00f3n\/desactivaci\u00f3n y ha eliminado la pantalla en la que los anunciantes eleg\u00edan el m\u00e9todo de implementaci\u00f3n. Las cuentas existentes que ya hab\u00edan aceptado las condiciones de Google sobre datos de clientes se han migrado autom\u00e1ticamente. El mecanismo subyacente de hash y coincidencia no ha cambiado. <\/p>\n\n Porque la etiqueta de conversi\u00f3n y los datos ampliados son dos cosas distintas. La etiqueta puede activarse y la conversi\u00f3n puede registrarse con normalidad aunque el campo \u00abuser_data\u00bb que contiene est\u00e9 vac\u00edo, tenga un doble hash o ni siquiera aparezca. Google Ads muestra la acci\u00f3n de conversi\u00f3n como activa en cualquier caso, ya que la conversi\u00f3n b\u00e1sica sigue registr\u00e1ndose correctamente. <\/p>\n\n Abre el modo de vista previa de GTM, realiza una conversi\u00f3n de prueba y comprueba que el objeto \u00abuser_data\u00bb contenga valores hash en lugar de estar vac\u00edo. A continuaci\u00f3n, comprueba si la solicitud de red incluye el par\u00e1metro \u00abem\u00bb. Si falta o est\u00e1 vac\u00edo, los datos mejorados no llegan a Google, aunque se realice el seguimiento de la conversi\u00f3n b\u00e1sica. <\/p>\n\n No. Un campo mal configurado sigue estando mal configurado, independientemente de d\u00f3nde 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\u00f1o y el doble hash causado por la divisi\u00f3n de la l\u00f3gica entre la p\u00e1gina y la etiqueta. <\/p>\n\n S\u00ed, y el requisito no ha cambiado. \u00abEnhanced Conversions\u00bb sigue necesitando que se conceda el consentimiento para \u00abad_user_data\u00bb a trav\u00e9s del \u00abConsent Mode V2\u00bb antes de poder enviar datos con hash. El hash no convierte los datos en an\u00f3nimos seg\u00fan el RGPD, ya que Google sigue pudiendo relacionarlos con los datos de la cuenta que tiene almacenados. <\/p>\n\n No necesariamente. Si tu cuenta ya hab\u00eda aceptado las condiciones sobre los datos de los clientes, la migraci\u00f3n se ha realizado autom\u00e1ticamente. Aun as\u00ed, vale la pena echar un vistazo al informe de diagn\u00f3stico, ya que la fusi\u00f3n es una buena ocasi\u00f3n para detectar alguna configuraci\u00f3n que ya fallaba antes de la actualizaci\u00f3n, pero que nadie hab\u00eda notado. <\/p>\n","protected":false},"excerpt":{"rendered":" En junio de 2026, Google Ads cambi\u00f3 el funcionamiento de \u00abConversiones mejoradas\u00bb. Los dos productos ...<\/p>\n","protected":false},"author":15,"featured_media":74146,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[338,346],"tags":[],"class_list":["post-74161","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-avanzado","category-google-ads-es"],"acf":[],"_links":{"self":[{"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/posts\/74161","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/comments?post=74161"}],"version-history":[{"count":2,"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/posts\/74161\/revisions"}],"predecessor-version":[{"id":74163,"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/posts\/74161\/revisions\/74163"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/media\/74146"}],"wp:attachment":[{"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/media?parent=74161"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/categories?post=74161"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/taggrs.io\/es\/wp-json\/wp\/v2\/tags?post=74161"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Actualizaci\u00f3n de \u00abConversiones mejoradas\u00bb de Google de junio de 2026: qu\u00e9 ha cambiado<\/h2>\n\n
Por qu\u00e9 falla \u00abEnhanced Conversions\u00bb sin avisar y c\u00f3mo detectarlo<\/h2>\n\n
\n
C\u00f3mo el GTM server-side hace que las conversiones mejoradas de Google sean m\u00e1s fiables<\/h2>\n\n
\n
Las conversiones mejoradas de Google y el RGPD: lo que deben saber las agencias de la UE<\/h2>\n\n
D\u00f3nde encaja TAGGRS<\/h2>\n\n
Conclusi\u00f3n<\/h2>\n\n
Preguntas frecuentes<\/h2>\n\n
\u00bfQu\u00e9 ha cambiado con la actualizaci\u00f3n \u00abEnhanced Conversions\u00bb de junio de 2026?<\/strong><\/h3>\n\n
\u00bfPor qu\u00e9 las \u00abConversiones mejoradas\u00bb parecen estar activas pero en realidad no funcionan?<\/strong><\/h3>\n\n
\u00bfC\u00f3mo puedo comprobar si mi configuraci\u00f3n de \u00abConversiones mejoradas\u00bb est\u00e1 enviando datos \u00fatiles?<\/strong><\/h3>\n\n
\u00bfEl GTM server-side soluciona todos los problemas relacionados con las conversiones mejoradas?<\/strong><\/h3>\n\n
\u00bfLas conversiones mejoradas siguen cumpliendo con el RGPD tras la actualizaci\u00f3n?<\/strong><\/h3>\n\n
\u00bfTengo que volver a configurar las \u00abConversiones mejoradas\u00bb por la fusi\u00f3n?<\/strong><\/h3>\n\n