GCLID: qué es y por qué lo estás perdiendo sin saberlo

Qué es exactamente el GCLID

GCLID son las siglas de Google Click Identifier. Es una cadena larga que Google añade al final de la URL de tu landing cada vez que alguien pulsa un anuncio de Google Ads. La primera vez que lo ves escama un poco:

https://tu-landing.com/?gclid=Cj0KCQjwwYOwBhDYARIsAJFb8qWzXj...

Ese string lo genera Google en el momento del clic y solo Google sabe qué hay dentro. Es un token cifrado que contiene campaña, grupo de anuncios, keyword, hora, dispositivo, ubicación y más. Tú lo ves como ruido; para Google es la ficha completa del clic.

La utilidad del GCLID en una frase: si tu servidor captura el GCLID y lo guarda junto con el lead, más tarde puedes devolvérselo a Google con la venta cerrada y Google re-atribuye esa venta al clic original. Sin usuarios, sin cookies, sin pixel. Es privacy-safe attribution en una cadena de texto. De ahí que todo lo demás dependa de esto.

Cómo Google lo mete sin que hagas nada

El GCLID aparece automáticamente si tu cuenta tiene auto-tagging activado, que es el default desde hace años. Para confirmarlo: Google Ads → Herramientas → Configuración de la cuenta → Seguimiento → Etiquetado automático = Sí.

Con esto activado, Google añade el parámetro ?gclid=... a cualquier URL de destino de tus anuncios, sin que tú toques las URLs. También deposita una cookie propia llamada _gcl_aw con el mismo identificador. Esa cookie es la que permite a Google hacer attribution dentro del propio Google Ads sin que tú hagas nada. El problema empieza cuando tú quieres usar el GCLID fuera de Google Ads (en tu CRM, en tu reporting, para subir conversiones offline). Ahí es cuando descubres que la cookie no te vale de nada y que el query param es tu única fuente.

Los 3 sitios donde el GCLID se rompe en cuentas reales

En la mayoría de auditorías el GCLID se pierde en uno de estos tres puntos. Casi nunca es un fallo de Google. Casi siempre es un fallo de configuración del lado del anunciante.

1. Antes de llegar a la landing

Si tu anuncio apunta a un URL shortener (bit.ly, un dominio redirector propio, un tracking link de un partner), el shortener tiene que preservar explícitamente el query string al hacer el 301. Muchos no lo hacen por defecto. Resultado: Google añade el ?gclid=..., el shortener redirige a la landing final sin el parámetro, y tu captura llega vacía aunque el auto-tagging está correctamente activado.

Otro caso típico: anuncios que apuntan a secciones de la web que hacen su propio redirect interno (un /es/ que lleva a /spain/). Si el servidor hace 301 sin preservar query, adiós GCLID. En una cuenta de seguros que auditamos el año pasado, el 40 % de los clics estaban llegando sin GCLID por esta causa. Un cambio de configuración en nginx lo arregló en diez minutos, pero llevaban 14 meses perdiendo atribución.

2. En la propia landing

Aquí hay varios sub-escenarios. Los más frecuentes:

• Safari con ITP. Intelligent Tracking Prevention borra localStorage tras 7 días de inactividad. Si tus ventas tardan más que eso, pierdes el GCLID casi siempre en usuarios iOS.
• Navegación en incógnito. Persistencia cero. Si el visitante anda en incógnito, tienes una sola sesión para capturar.
• SPAs que cambian la URL. Single-page apps que hacen history.pushState sin preservar el query string eliminan el GCLID al segundo clic interno del usuario.
• Iframes cross-origin. Si tu formulario está embebido en un iframe de otro dominio (Bitrix, Calendly, algunos CRMs), el iframe tiene su propio localStorage y no puede leer el del top-level.
• Cookie banners que bloquean scripts. Si tu banner de cookies bloquea Google Tag Manager hasta aceptar, el GCLID no se captura en usuarios que rechazan o no interactúan con el banner.

3. Después de la landing, cuando viaja al CRM

Aunque la captura esté perfecta, falta un viaje entre la landing y tu CRM donde también se pierden GCLIDs. Formularios de terceros que no propagan hidden fields, APIs del CRM que cortan caracteres porque el campo custom está declarado como VARCHAR(50) (los GCLID suelen ser de 90-120 caracteres), workflows de deduplicación que borran el campo al re-crear un contacto existente. En una de cada tres auditorías, el GCLID llega a la URL correctamente pero no está en la ficha del CRM porque algo lo corta por el camino.

Capturarlo bien (y todo lo que el snippet no cubre)

Asumiendo que el GCLID llega a tu landing, el siguiente paso es capturarlo y persistirlo para que sobreviva a recargas y navegación interna. El snippet mínimo, pensado para Google Tag Manager como Custom HTML con trigger All Pages y prioridad alta, cabe en 12 líneas:

<script>
(function(){
  try {
    var params = new URLSearchParams(window.location.search);
    var keys = ['gclid', 'fbclid', 'ttclid', 'msclkid',
                'utm_source', 'utm_medium', 'utm_campaign',
                'utm_content', 'utm_term'];
    keys.forEach(function(k){
      var v = params.get(k);
      if (v) localStorage.setItem('wt_' + k, v);
    });
  } catch(e) { /* silent fail */ }
})();
</script>

Esto funciona en el caso feliz. Lo que no cubre es todo lo interesante que ya mencionamos arriba: Safari con ITP, incógnito, SPAs, iframes cross-origin, cookie banners, multi-tab. En producción, el snippet que acabamos usando tiene entre 40 y 80 líneas para manejar esos casos y no romperse cuando aparece el usuario del borde que nadie había previsto.

La diferencia entre "funciona en mi máquina" y "funciona con tráfico real" son esas 60 líneas, más un sistema de logging que avise cuando la tasa de captura cae. Si nunca vuelves a mirar los logs después de la primera semana, no te vas a enterar cuando tres meses después una actualización del navegador Safari rompa algo.

El viaje del GCLID hasta el CRM

Una vez el GCLID está en localStorage, empieza el viaje de verdad. El objetivo es que llegue a la ficha del contacto en tu CRM, vinculado al lead. Los patrones según el tipo de conversión:

Formulario nativo en la propia web

El clásico. Un hidden input en el form, un script que lo rellena desde localStorage antes del submit, y tu backend lo guarda en el campo correspondiente del CRM. Cinco líneas en el frontend, otras cinco en el backend. Funciona el 95 % del tiempo. El 5 % que falla suele ser por timing (el script intenta leer localStorage antes de que esté listo, sobre todo en navegadores lentos) o por validación JS del form que borra el input si no cumple un patrón.

Formulario de terceros (Typeform, Calendly, Bitrix)

Cada plataforma tiene su propio sistema para pasar hidden fields. Typeform permite declararlos en el editor y los recibe vía query string. Calendly acepta ?utm_* pero no es consistente con otros parámetros. Bitrix24 a veces permite campos custom, a veces necesita configuración adicional del formulario. Ninguno es trivial y cada uno tiene sus gotchas propios. Para un cliente que usaba tres tipos de formulario distintos en la misma landing, las tres integraciones nos llevaron una semana de trabajo combinado.

Clic en WhatsApp o en llamada

Ninguno de los dos canales permite llevar el GCLID de forma natural. La llamada llega al call center sin pista del anuncio que la originó. El WhatsApp llega con el texto del mensaje pero sin metadata. La solución pasa por interceptar el clic antes de que el usuario abra el teléfono o el WhatsApp, e inyectar un código de referencia único que podamos cruzar después con el mensaje entrante o la llamada entrante. Es una técnica que da para un post entero, la cubrimos en la página de servicio de Click-to-WhatsApp.

CRMs grandes (HubSpot, Salesforce, Pipedrive)

Los CRMs modernos tienen campos custom pensados para esto. En HubSpot se llama hs_google_click_id (automático si usas su script de tracking); en Salesforce hay que crear un campo custom tipo texto, típicamente GCLID__c; en Pipedrive lo mismo. Configurarlos es simple pero hay que vigilar dos cosas: que la longitud del campo sea suficiente (mínimo 150 caracteres para no truncar GCLIDs largos) y que los workflows de deduplicación no pisen el campo cuando un mismo lead vuelve a dar datos.

Los 5 síntomas de que tu GCLID está roto sin que lo sepas

Sin ver tu cuenta, estos son los indicadores más claros. Si llevas semanas con alguno, probablemente el pipeline de GCLID tiene un agujero:

Síntoma	Qué suele significar
Muchos leads en CRM con el campo GCLID vacío cuando sí venían de Google Ads	Se pierde entre la captura en landing y el guardado en CRM. Típicamente iframe, SPA o form de terceros.
Enhanced Conversions for Leads con match rate bajo (<40 %)	El fallback funciona a medias, lo que confirma que la primera línea (GCLID) está rota en muchos casos.
Las campañas Brand tienen CPL parecido al de las genéricas	Smart Bidding no distingue calidad de clic porque casi no recibe señal real. Señal de GCLID perdido masivamente.
Smart Bidding "no aprende" aunque haya volumen suficiente	Estás subiendo conversiones offline pero con un ratio GCLID/lead bajo. Google tiene señal pero es ruidosa.
El CPA real (al final del embudo) diverge mucho del CPL que ves en Google Ads	Las ventas se cierran pero no vuelven atribuidas a campaña. O bien no subes conversiones offline, o bien subes pero perdiste el GCLID en el camino.

El mapa de troubleshooting

Cuando un cliente nos dice "creo que el GCLID se está perdiendo", el orden en el que miramos las cosas es siempre el mismo. No garantiza que encontremos el problema pero sí que lo encontramos en la primera mitad de los casos sin tener que pelearnos con toda la stack:

1. Confirmar auto-tagging. Google Ads → Configuración → Seguimiento → Etiquetado automático. Si está apagado, ahí está buena parte del problema y es un switch.
2. Hacer un clic real en un anuncio desde incógnito, copiar la URL de destino tras el redirect, verificar que contiene ?gclid=.... Si no lo contiene, el problema está antes de la landing.
3. Mirar la consola del navegador en la landing. localStorage.getItem('wt_gclid') debería devolverlo. Si está null, es el script de captura o un bloqueador del lado del browser.
4. Rellenar un formulario de prueba y comprobar en el CRM si el campo GCLID está relleno. Si falla aquí, es la propagación.
5. Revisar la longitud del campo GCLID en el CRM. Si está truncado a 50 caracteres, ahí está el bug. Los GCLIDs reales pasan de 90.

Cada uno de esos pasos tiene variantes según el stack del cliente (qué CMS, qué CRM, qué tipo de formulario, si hay iframe, si hay cookie banner, qué versión de GTM). En las cuentas complejas puede hacer falta un rato de trabajo extra; en las sencillas lo resolvemos en la primera sesión.

Lo que vemos en cuentas auditadas durante 2026

El año va dando confirmaciones de patrones que llevamos viendo desde 2023. Tres observaciones que valen la pena anotar para 2026.

Safari sigue siendo la principal fuente de pérdida silenciosa. ITP (Intelligent Tracking Prevention) borra localStorage tras 7 días sin interacción, y el sandboxing de iframes ha apretado más en las últimas iteraciones. Cuando una cuenta ve match rate por debajo del 50 % en Enhanced Conversions for Leads, en 8 de cada 10 casos hay un porcentaje grande de tráfico iOS Safari pasando por algún proceso que no era robusto a la limpieza periódica de la cookie. La solución no es un parche concreto, es montar tres redes de seguridad encima del localStorage estándar: cookie de primera parte con duración larga, server-side fallback con sessionStorage del backend, y Enhanced Conversions for Leads como capa de redundancia con email/teléfono hasheado.

Los formularios de terceros han mejorado en 2026, pero no del todo. Typeform, HubSpot Forms, Calendly, Marketo, Bitrix24 forms, Pipedrive, Wix Forms. Casi todos aceptan ya un campo custom para guardar el GCLID. Lo que sigue fallando es la propagación: el formulario lo recibe pero no siempre lo manda al CRM con el formato correcto, o el CRM lo guarda truncado. La auditoría en 2026 ya no se centra en "tiene el campo GCLID", sino en "el GCLID que llega al CRM tiene 90+ caracteres y termina con la cadena correcta". Sin esa verificación final, la subida posterior a Google Ads falla silenciosa y nadie se entera hasta el cierre de trimestre.

Performance Max ha vuelto a empujar la importancia del GCLID. En 2024-2025 se podía sobrevivir con tracking parcial porque las campañas de Search aceptaban señal incompleta. Con PMax dominando el budget, el algoritmo necesita señal de valor real para no canibalizar Brand y para servir bien las superficies (YouTube, Discovery, Maps). Sin GCLID limpio en el 95 %+ de los leads, PMax se queda atrapado en queries baratas y deja de escalar incremental. Las cuentas de 2026 que están escalando bien con PMax son, sin excepción, las que tienen el flujo de GCLID auditado y resuelto en sus tres eslabones.

GCLID y sus variantes técnicas: cookie, GBRAID, WBRAID, FBCLID

Cuando se trabaja con GCLID en cuentas reales, aparecen otros identificadores parecidos que conviene distinguir desde el principio. La confusión entre ellos es responsable de muchos casos de "atribución que no cuadra".

GCLID y la cookie _gcl_aw

Cuando llega un visitante con ?gclid=... en la URL, Google Ads (a través del tag global gtag o del píxel cliente) guarda automáticamente una cookie de primera parte llamada _gcl_aw con el valor del GCLID y sus metadatos. Esa cookie es la que muchos formularios y CRMs leen para propagar el GCLID al backend. La cookie por defecto vive 90 días, igual que la ventana de atribución de Google. Si la borras manualmente o si el navegador la bloquea (Safari ITP), pierdes la persistencia entre páginas y dependes de localStorage como alternativa.

GCLID vs GBRAID vs WBRAID

Desde 2021 Google introdujo dos identificadores adicionales para escenarios donde el GCLID estándar no se puede emitir por restricciones de privacidad:

• GBRAID: identificador agregado para clics en apps iOS (App Tracking Transparency). No es único por usuario, es por cohorte. Google lo usa para atribuir ventas web posteriores al clic original en app, sin violar privacidad.
• WBRAID: equivalente para tráfico web cuando el usuario está en iOS con restricciones de cookies. Google lo emite en lugar del GCLID cuando detecta que ese GCLID no se va a poder propagar fiable a la conversión.

Operativamente: en un mismo CRM probablemente verás GCLIDs estándar mezclados con GBRAID/WBRAID en porcentajes distintos según el peso de tráfico iOS. La subida a Google Ads acepta los tres con la misma API, pero hay que tener tres columnas separadas en el feed CSV (gclid, gbraid, wbraid) y pasar el valor en la columna correcta. Si pones un GBRAID en la columna gclid, Google rechaza la conversión.

GCLID vs FBCLID vs otros click IDs

Para tráfico que viene de Meta (Facebook + Instagram), el equivalente al GCLID es el FBCLID. Misma idea: cadena cifrada en la URL de destino que identifica el clic original y permite atribución posterior. Misma operativa de captura: leerlo de la URL, guardarlo en localStorage, propagarlo al CRM, devolverlo a Meta vía CAPI cuando se cierra la venta.

Otros click IDs equivalentes en otras plataformas:

• TTCLID · TikTok Ads
• LI_FAT_ID · LinkedIn Ads
• EPIK · Pinterest
• MSCLKID · Microsoft Ads (Bing)
• WA_REF · Meta Click-to-WhatsApp Ads

El patrón es siempre el mismo: cada plataforma emite su identificador, tú lo capturas en la landing, lo guardas asociado al lead, y lo devuelves al canal cuando se cierra la venta. La diferencia está en los detalles de cada API y en la normalización de phones/emails para Enhanced Conversions del proveedor que aplique.

Por qué localStorage es la mejor opción de persistencia

El GCLID llega en la URL pero solo en la primera página de la sesión. Si el usuario navega a otras URLs del site antes de convertir, sin un mecanismo de persistencia el GCLID se pierde. Las tres opciones técnicas son cookie de primera parte, localStorage y sessionStorage:

• Cookie de primera parte: persiste 90 días, accesible desde JavaScript y desde el servidor. Limitación: Safari ITP la limita a 7 días si se setea por JavaScript en lugar de por server.
• localStorage: persiste hasta que el usuario lo borre, accesible solo desde JavaScript. Limitación: Safari ITP también la borra a 7 días sin interacción del usuario con el site.
• sessionStorage: vive solo durante la sesión de pestaña. Muy frágil, no recomendado salvo como capa adicional.

En la práctica la implementación robusta usa las tres en cascada: leer el GCLID de la URL → escribirlo en localStorage + cookie de primera parte simultáneamente → si el usuario vuelve y localStorage está vacío pero la cookie sigue, recuperarlo de la cookie → si ambos están vacíos, perdido (a recuperar por Enhanced Conversions for Leads).

GCLID en HubSpot

HubSpot es el CRM donde más casos de "tengo el campo GCLID pero está vacío en la mitad de los contactos" hemos visto en auditorías. El detalle de configuración (propiedad, hidden field, workflow de captura, lifecycle, subida a Google Ads) tiene tantas capas que merece una guía propia. Está en conectar HubSpot con Google Ads sin perder atribución.

Preguntas frecuentes

¿Qué es el GCLID en Google Ads?

Es el identificador único del clic que Google añade automáticamente a la URL de tu landing cuando alguien pulsa un anuncio. Cadena tipo Cj0KCQjw... que solo Google puede descifrar, pero que permite re-atribuir ventas offline al clic original si tú lo conservas y lo devuelves a Google con la venta.

¿Caducan los GCLID?

Sí. Tienen una ventana de atribución de 90 días desde el clic. Si intentas subir una venta con un GCLID más antiguo, Google rechaza la conversión con CLICK_TOO_OLD. Para ciclos largos conviene subir estados intermedios dentro de la ventana.

¿Son únicos los GCLID o se repiten?

Son únicos por clic. Un mismo usuario que hace dos clics genera dos GCLIDs. Si tu CRM sobrescribe el GCLID cada vez que el mismo usuario vuelve, pierdes atribución. Guarda histórico, no un único campo.

¿Puedo recuperar GCLIDs perdidos?

No directamente. Pero Enhanced Conversions for Leads cubre un 10-30 % de las ventas cuyo GCLID se perdió, subiendo email o teléfono hasheado y dejando que Google haga el match. No sustituye al GCLID, lo complementa.

¿Qué diferencia hay entre GCLID y GBRAID/WBRAID?

GCLID es el identificador estándar. GBRAID y WBRAID son sus equivalentes para iOS sin consentimiento ATT y para web con restricciones de cookies. En la práctica, capturar GCLID cubre el 90 % de los casos y es la primera prioridad. GBRAID/WBRAID son para afinar en cuentas con peso iOS alto.

¿Necesito GCLID si ya tengo el píxel de Google activo?

Sí, son cosas distintas. El píxel mide conversiones que ocurren en la web (un submit de formulario, un thank you page). El GCLID es lo que te permite medir conversiones que ocurren fuera de la web (una venta por teléfono, una firma semanas después). Sin GCLID, todo lo que pase fuera de la web es invisible para Google Ads.

Sigue leyendo en el cluster de atribución