Conversiones que la plataforma reporta y la factura no

La discrepancia entre lo que reporta Meta o Google y lo que registra tu sistema financiero es el síntoma clásico de pérdida de atribución. Cuando no se recupera el identificador único del click del anuncio, esa conversión nunca puede ligarse al source platform, aunque haya ocurrido en tu sitio. La consecuencia es un ROAS que suena mejor en el reporte de publicidad que en el de caja.

Los click identifiers — los parámetros que Google, Meta, TikTok y otros añaden a tus URLs de anuncios — son la infraestructura que sostiene esta conexión. Sin ellos, no hay forma verificable de saber si un click en un anuncio condujo a una compra. Pero capturarlos parece simple y no lo es: seis errores comunes en su implementación explican por qué se pierden.

El error más obvio: alterar el valor mientras lo capturas

El identificador de Google es `gclid`. El de TikTok es `ttclid`. El de Meta es `fbclid`. Estos valores son case-sensitive: `abc123XYZ` no es lo mismo que `abc123xyz`. Si tu GTM o tu código normalizan el identificador a minúsculas o mayúsculas, el valor cambia. Cuando lo envías de vuelta a Google o Meta para el reporte de conversiones, no coincide con el que generó la plataforma. Attribution rota.

Google lo documenta explícitamente: `gclid` nunca debe ser normalizado en ningún punto de la captura. El mismo principio aplica a todos los identificadores de todas las plataformas. Es una regla que suena obvia hasta que las revisas en tu GTM y descubres transformaciones de string que alguien agregó porque "normalizar es buena práctica".

El error que ocurre en tu website, no en GTM

Tu implementación en Google Tag Manager es correcta. Captura el identificador del URL. Pero tu website tiene lógica que automáticamente elimina parámetros de URL que no reconoce — a menos que antes los hayas incluido en una lista de permitidos.

Si tu equipo de frontend no ha permitido explícitamente `gclid`, `fbclid`, `ttclid` y los otros parámetros en la configuración de URL cleaning, el parámetro desaparece del URL después del primer load de la página. Cuando luego intenta capturarlo, no está.

La prueba es simple: simula un click en un anuncio con un URL que incluya el identificador correspondiente y recarga la página. Si el parámetro desaparece del URL, tu website es el culpable. Tu equipo de ingeniería tiene que permitir esos parámetros específicos; no eliminarlos por defecto.

Confiar solo en que el identificador siga en el URL

El identificador llega en el URL de destino: `https://ejemplo.com/thank-you?gclid=xyz`. Si el usuario completa un formulario en esa misma página, capturarlo del URL funciona. Pero si navega a otra página antes de convertir, el parámetro no viaja en el URL — y lo pierdes.

Por eso existen las cookies: para que el identificador persista mientras el usuario navega. La mayoría de plataformas publicitarias hacen esto automáticamente si su píxel nativo está corriendo en tu sitio. Pero eso ocurre solo si el píxel está correctamente instalado y activo en la página de destino.

Si no usas el píxel nativo de la plataforma, tienes que capturar el identificador del URL y almacenarlo en una cookie manualmente. Sin esa cookie, el identificador vive solo en el first page load.

Errores de configuración en la cookie del identificador

Asumir que las cookies están bien configuradas es el tercer punto de falla. Tres errores específicos ocurren aquí.

Primero: dominio y path incorrectos. Si el usuario llega a `create.ejemplo.com` y configuras la cookie solo para ese subdominio, cuando se mueva a `www.ejemplo.com` para completar la compra, la cookie no estará disponible. Lo mismo ocurre si configuras la cookie solo para una ruta específica — `/signup` — pero el formulario está en `/checkout`.

La solución es configurar la cookie en el dominio raíz (`ejemplo.com`) y la ruta raíz (`/`), para que sea accesible en todo el sitio.

Segundo: guardar la cookie cuando el identificador no está presente. Si configuras tu GTM para siempre guardar el parámetro en una cookie, pero a veces ese parámetro es `undefined` o `null`, el valor guardado es inútil. Cuando intentas enviarlo de vuelta a la plataforma, falla porque el valor no es válido.

La solución es condicionar el guardado de la cookie: solo se guarda si el parámetro existe en el URL.

Tercero: no actualizar la cookie cuando el usuario vuelve con un nuevo click. Un usuario puede llegar vía un anuncio de YouTube, y semanas después volver vía Google Search. Si la cookie que guardaste tiene el identificador del primer click, nunca la actualizas, entonces toda la segunda conversión se atribuye al primer click. En offline conversion tracking, esto distorsiona completamente tu medición.

La solución es actualizar la cookie siempre que encuentres un nuevo identificador en el URL.

Usar el nombre del parámetro en el caso incorrecto

No solo el valor del identificador es case-sensitive; el nombre del parámetro también lo es. `&GCLID` no es lo mismo que `&gclid`. Snapchat usa `ScCid` — no `sccid`, no `SCCID`. Si tu variable de URL en GTM busca `sccid` en minúsculas, no encontrará nada.

Consultá la documentación de cada plataforma o la tabla de identificadores. Asegúrate de que tu GTM, tu código custom o tu datos layer usen exactamente el mismo case format que el que usa la plataforma. Google Tag Manager es case-sensitive en sus variables de URL, así que una letra fuera de lugar significa cero coincidencias.

No tener un respaldo de almacenamiento más allá de cookies

Los navegadores modernos, especialmente Safari, aplican protecciones de tracking que acortan la vida de las cookies o las bloquean completamente. Una cookie que sinceramente esperabas que durara 30 días puede expirar en una hora.

Por eso vale la pena usar un respaldo: `localStorage` es más simple que cookies, persiste incluso después de que el usuario cierra el navegador (a diferencia de `sessionStorage`), y no añade peso a las peticiones HTTP como el header `Cookie` sí lo hace.

La desventaja: `localStorage` también sufre las protecciones de tracking del navegador. Si Safari bloquea cookies, también bloqueará `localStorage`. Pero tener ambos aumenta la probabilidad de recuperar el identificador cuando sea necesario.

Más allá del navegador, puedes construir un identity graph del lado del servidor que correlacione click identifiers con identificadores más permanentes — hashed email addresses, por ejemplo — pero eso es un nivel adicional de complejidad. Para la mayoría de casos, cookies + `localStorage` es suficiente.

Qué revisar esta semana

Pídele a tu equipo de analytics o ingeniería que haga una auditoría de los seis errores. Simula un click en un anuncio de Google, Meta, TikTok y LinkedIn. Sigue la captura del identificador desde el URL inicial hasta que se envíe de vuelta a la plataforma para atribuir la conversión.

Responde estas preguntas concretas: ¿se modifica el valor durante la captura? ¿El website elimina el parámetro del URL? ¿La cookie está configurada en el dominio y ruta correctos? ¿Coincide exactamente el nombre del parámetro en GTM con el que usa la plataforma? ¿Hay un respaldo en `localStorage` o en un servidor identity graph?

Si alguna de estas falla, encontraste dónde se pierde la atribución. No es que las plataformas mienta — es que tu señal nunca llega.