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.
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
| Plataforma | Parámetro | Vida útil | Campo servidor |
|---|---|---|---|
| Google Ads | gclid (también wbraid, gbraid) | 90 días, click-through | gclid en upload click_conversion |
| Meta | fbclid | 7 días para emparejamiento de cookies | Campo fbc en evento CAPI |
| TikTok | ttclid | 30 días, firmado | ttclid en evento Events API |
li_fat_id | 180 días para funnels B2B | conversionEventToken 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
fbclidfunciona. - Si convierte el día 8, la
fbclidsigue técnicamente ennl_extpero Meta rechaza el match. - La cookie first-party
fbpde 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
fbcconstruido a partir defbclid+ timestamp de aterrizaje, más cookiefbpcon modo híbrido. - TikTok Events API: campo
ttclidtal cual capturado, más cookie_ttpen modo híbrido. - Google Ads API:
gcliden cada upload de conversion-action.wbraidygbraidenviados cuando están presentes (variantes de atribución móvil e iOS). - LinkedIn CAPI:
conversionEventTokenconstruido a partir deli_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:
- Cookie first-party puesta por el pixel del navegador propio de la plataforma (solo disponible con modo híbrido).
- Match de PII hasheada (email, teléfono) enviada en un formulario durante la misma sesión.
- 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=... → /homepierde elfbclid. - 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.replaceStateantes 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.