Arquitectura

Click-IDs explicadas: gclid, fbclid, ttclid, li_fat_id lado a lado

Cuando alguien hace clic en un anuncio y aterriza en tu sitio, la plataforma añade un token a la URL. Ese token, la click-ID, es la señal de atribución más fuerte que tiene la plataforma. Cada red lo hace ligeramente distinto. Mecánica, vida útil y reglas de captura en un solo sitio.

Tiempo de lectura: ~6 minPublicado: 2026-05-02

Qué es realmente una click-ID

Un clic en un anuncio lleva al visitante de la superficie publicitaria (Google Search, feed de Facebook, For You de TikTok, timeline de LinkedIn) a tu URL de aterrizaje. Justo antes del redirect, la plataforma añade un parámetro de query a la URL: ?gclid=..., ?fbclid=..., ?ttclid=..., ?li_fat_id=.... El valor es un token firmado y opaco que solo la plataforma puede decodificar. Codifica la campaña, el ad-group, el creative, el timestamp del clic y un checksum que prueba que el clic vino del propio ad-server de la plataforma.

En cuanto envías ese token de vuelta a la plataforma junto a un evento de conversión, la plataforma puede emparejar la conversión al clic original con certeza. Sin fingerprinting, sin emparejamiento de cookies, sin atribución probabilística. Solo una prueba de una línea.

Las cuatro click-IDs lado a lado

PlataformaParámetroVida útilCampo servidor
Google Adsgclid (también wbraid, gbraid)90 días, click-throughgclid en upload click_conversion
Metafbclid7 días para emparejamiento de cookiesCampo fbc en evento CAPI
TikTokttclid30 días, firmadottclid en evento Events API
LinkedInli_fat_id180 días para funnels B2BconversionEventToken en CAPI

Captura: leer una vez, guardar inmediatamente

Las click-IDs solo existen en la URL de la primerísima página en la que aterriza el visitante. En cuanto navega a una segunda página, el parámetro desaparece. Si no capturas y persistes el valor antes de que el visitante se mueva, pierdes la atribución para todo lo que venga después.

El nl-data.js de Beaconry lee document.location.search en el primer page-view, extrae cada click-ID conocida y las guarda en una sola cookie first-party llamada nl_ext. La estructura es JSON: {"gclid":"...","fbclid":"...","ttclid":"...","li_fat_id":"..."}. El scope de la cookie es solo tu dominio, expira a 90 días, gated por consentimiento.

Persistencia y decay

Cada plataforma tiene su propia ventana de atribución. Pasada la ventana, la plataforma deja de aceptar la click-ID para emparejamiento aunque sigas enviándola. El efecto práctico:

  • Si el visitante convierte dentro de los 7 días de Meta, enviar fbclid funciona.
  • Si convierte el día 8, la fbclid sigue técnicamente en nl_ext pero Meta rechaza el match.
  • La cookie first-party fbp de Meta (puesta por el pixel del navegador en modo híbrido) extiende esto a 90 días como señal de respaldo.

Beaconry envía cada click-ID que tiene en cada evento. Las plataformas ignoran los valores caducados, sin daño. El error opuesto, eliminar deliberadamente las IDs caducadas, te cuesta los casos límite donde la ventana de la plataforma resulta más larga de lo esperado.

Qué envía Beaconry, por canal

  • Meta CAPI: campo fbc construido a partir de fbclid + timestamp de aterrizaje, más cookie fbp con modo híbrido.
  • TikTok Events API: campo ttclid tal cual capturado, más cookie _ttp en modo híbrido.
  • Google Ads API: gclid en cada upload de conversion-action. wbraid y gbraid enviados cuando están presentes (variantes de atribución móvil e iOS).
  • LinkedIn CAPI: conversionEventToken construido a partir de li_fat_id, adjunto al evento.

Para el payload del evento de conversión, Beaconry adjunta las click-IDs que coinciden con el canal al que despacha. Un evento de purchase enviado a Meta lleva fbc, el mismo evento purchase enviado a Google Ads lleva gclid. Sin contaminación cruzada.

Qué pasa sin click-IDs

La atribución de conversión cae a la siguiente señal más fuerte que tenga la plataforma:

  1. Cookie first-party puesta por el pixel del navegador propio de la plataforma (solo disponible con modo híbrido).
  2. Match de PII hasheada (email, teléfono) enviada en un formulario durante la misma sesión.
  3. Huella IP + user-agent, la señal más débil, a menudo descartada por completo en iOS.

Para visitantes de ad-click que convierten sin rellenar un formulario, la click-ID es la diferencia entre "atribuido correctamente" y "no trackeado". Efecto neto en un setup e-commerce típico: 30-50 % de las conversiones de paid-search se vuelven invisibles para Google Ads si gclid no se captura y replay.

Visitas directas y tráfico orgánico

Visitantes que llegan sin click-ID, búsqueda orgánica, tráfico directo, referrer, nunca tienen una. No hay nada que capturar, la cookie nl_ext queda vacía para ellos. Beaconry envía el evento de conversión con el campo de click-ID vacío; las plataformas simplemente no acreditan la conversión a un clic pagado. Es comportamiento correcto, porque no fue un clic pagado.

Trampas comunes

  • Stripping de URL. Algunos CDNs y herramientas de seguridad eliminan parámetros de query que no reconocen. Si no aterriza ninguna click-ID en nl_ext, revisa Page Rules de Cloudflare y herramientas "Always Online" buscando stripping de parámetros. Pon en whitelist los cuatro nombres de click-ID.
  • Redirects en servidor. Si tu URL de aterrizaje redirige a una ruta canónica, asegúrate de que el redirect preserve el query string. 301 /landing?fbclid=... → /home pierde el fbclid.
  • Single-page apps. Las SPAs que manejan la navegación en cliente sin page-loads no disparan el parsing de URL de Beaconry en navegaciones posteriores. La captura ocurre solo en la carga inicial, que es lo que quieres, pero asegúrate de que la SPA no reemplace la URL vía history.replaceState antes de que Beaconry corra.
  • iOS Mail privacy y click-throughs por email. iOS Mail hace prefetch de los enlaces, lo que significa que la click-ID se "gasta" por el prefetcher de Apple, no por el visitante humano. Mitigación: campañas a listas de email deben esperar 10-15 % de pérdida de atribución en audiencias iOS, independiente de la herramienta de tracking.

Para llevar

Cuatro parámetros de query, cuatro plataformas, un patrón arquitectónico: leer al aterrizar, persistir en una cookie first-party, replay en cada evento de conversión. Beaconry maneja las cuatro out of the box, en la misma cookie nl_ext, con el mapeo correcto en servidor por canal. Lo único en lo que el cliente tiene que pensar es si la URL realmente llega intacta, que normalmente es una pregunta de configuración de CDN, no de tracking.