El pixel del navegador es la parte de la atribución que se rompe primero. Intelligent Tracking Prevention de Apple limita las cookies de terceros y degrada el referrer; los bloqueadores de anuncios eliminan la llamada de red del pixel antes de que abandone la página; App Tracking Transparency de iOS 14.5 redujo la calidad de la señal de Meta en el tráfico iPhone lo suficiente como para que la propia Meta ahora trate el pixel del navegador como respaldo.
El tracking de conversiones server-side es la respuesta en la que todos están de acuerdo. La implementación es lo que la gente hace mal. Esta publicación recorre la arquitectura tal como queda cuando un acortador de URL posee el click_id - qué hace el acortador, qué hace su back-end, qué esperan las plataformas publicitarias en su extremo, y la forma de deduplicación que evita el doble conteo cuando se disparan eventos tanto del navegador como del servidor.
Las tres plataformas a las que la mayoría de los equipos reenvían: Meta CAPI, GA4 Measurement Protocol, TikTok Events API. Mixpanel, Klaviyo y Pinterest aceptan la misma forma con nombres de campo específicos del proveedor. Seré específica sobre Meta y GA4 porque son las que impulsan la mayor parte del presupuesto; las demás siguen la misma plantilla.
Por qué server-side#
La versión corta: el navegador ya no es una fuente de señal confiable. La versión más larga vale la pena entenderla porque da forma a cómo configura la deduplicación.
Tres cosas degradan las conversiones del lado del navegador:
Particionado de cookies y límites de vida útil. ITP de Safari particiona las cookies por sitio de nivel superior y limita las cookies de primera parte establecidas por script a 7 días (24 horas después de detectar un rastreador cross-site conocido). Total Cookie Protection de Firefox hace un particionado similar. Brave y la cohorte de extensiones de privacidad van más allá. El flujo de atribución por cookies de primera parte que funcionaba en 2018 no funciona en 2026.
Bloqueadores de anuncios. uBlock Origin, AdBlock Plus, Pi-hole, NextDNS y los bloqueadores a nivel de red envían reglas predeterminadas para connect.facebook.net, googletagmanager.com, analytics.tiktok.com y el resto de la superficie de etiquetas de marketing. El pixel nunca se dispara; la conversión nunca se registra.
App Tracking Transparency de iOS y los cambios de tracking de enlaces de iOS 17. ATT redujo la calidad de la señal de Meta. Las notas de la versión iOS 17 Link Tracking Protection extendieron esto a los parámetros de consulta en navegación privada y Mail, eliminando fbclid, gclid y una lista de otros antes de que se abra el enlace.
El efecto acumulado en una tienda Shopify típica con tráfico mayoritariamente iOS: del 25 al 40% de las conversiones son perdidas por los pixels del lado del navegador. El número exacto depende de la mezcla de tráfico; las marcas de belleza y moda con mucho tráfico iOS están en el extremo superior. La aritmética de ingresos recuperados es lo que justifica el trabajo de ingeniería - para una tienda con 10M€/año en ingresos con una brecha de atribución del pixel del 30%, recuperar incluso la mitad de esa brecha son 1,5M€ de ingresos atribuibles redirigidos de vuelta a las plataformas que los impulsaron.
El reenvío de conversiones server-side cierra la mayor parte de la brecha. No cierra toda - hay conversiones donde nunca se capturó el click_id (orgánico, directo, búsqueda de marca) que ningún CAPI recuperará - pero cierra la brecha que vino del bloqueo del lado del navegador.
La arquitectura#
El flujo de datos tiene cuatro saltos: anuncio → enlace corto → sitio → reenvío server-side.
Plataforma publicitaria → enlace corto. El destino del creativo de Meta o Google Ads es un enlace corto. El usuario hace clic; el manejador edge del enlace corto captura el evento de clic y redirige a la URL de destino con un click_id añadido.
Enlace corto → sitio. La URL de destino tiene ?elido_click=<id> añadido (configurable por workspace). El tag manager del sitio o el código del tema lo lee y lo escribe en una cookie de primera parte o, más importante, en el atributo personalizado del carrito o pedido.
Sitio → pedido. Cuando el usuario finaliza un pedido (carrito Shopify enviado, pedido WooCommerce creado, carrito headless convertido), el click_id está en los atributos/metadatos del registro del pedido. Este es el punto de entrega duradero - una vez que el click_id está en el pedido, no está sujeto a la expiración de cookies ni al tiempo de vida de la sesión del navegador.
Pedido → reenvío server-side. El webhook order-paid se dispara desde su plataforma de comercio. Su back-end (o Elido, si lo ha delegado) lee el click_id, busca las credenciales de reenvío de conversión y hace POST de la conversión a cada plataforma publicitaria conectada. Las plataformas reciben la conversión y acreditan la campaña originadora.
El rol del acortador es el click_id en el salto 2 más la orquestación en el salto 4. El primero es sencillo; el segundo es donde la integración se gana su salario.
Deduplicación: lo que nadie menciona hasta producción#
El gran incidente de producción que veo con más frecuencia es el doble conteo. El pixel del lado del navegador sigue en la página (el equipo no lo deshabilitó porque querían un respaldo del navegador para tráfico no Safari), y el reenvío server-side también se dispara. Meta ingiere ambos eventos. La conversión se cuenta dos veces, el asignador de presupuesto sobre-tira, la próxima revisión de presupuesto de campaña nota "espera, ¿por qué nuestro ROAS reportado es 3× los ingresos?".
La solución es el identificador de deduplicación. Meta CAPI acepta un event_id. GA4 Measurement Protocol acepta un client_id y un transaction_id. TikTok Events acepta un event_id. Si tanto el navegador como el servidor envían el mismo evento con el mismo ID de dedup, la plataforma acredita uno e ignora el segundo.
El ID de dedup tiene que ser el mismo valor en ambos lados. El ID de pedido funciona para eventos de compra - tanto el pixel del lado del navegador como el reenvío server-side lo ven. El click_id funciona para eventos upstream (lead, add-to-cart, view-content) donde el pedido aún no existe.
La documentación de deduplicación de Meta recorre la ventana de coincidencia: los eventos recibidos dentro de las 48 horas entre sí con el mismo event_id se tratan como duplicados. La dedup basada en client_id de GA4 es similar en principio aunque más corta en documentación.
La regla operativa: cada conversión server-side tiene que llevar el ID de dedup, y el ID de dedup tiene que ser el mismo que emitió el pixel del lado del navegador. Saltarse esto es la diferencia entre una integración CAPI funcional y una que infla silenciosamente sus números reportados durante tres meses hasta que alguien se da cuenta.
Requisitos de hashing#
Tanto Meta CAPI como TikTok Events requieren que los identificadores de email y teléfono estén hasheados con SHA-256 antes de la transmisión. GA4 no lo requiere estrictamente pero lo acepta. El hashing es sobre los identificadores del cliente - em (email), ph (phone), fn (first name), ln (last name), ge (gender), db (date of birth), ct (city), st (state), zp (zip), country (country) - no sobre los metadatos del evento.
Dos detalles. Primero, el formato tiene que estar normalizado antes del hashing - minúsculas, recortado, código de país eliminado del teléfono, guiones eliminados. Hashear [email protected] produce un valor diferente que hashear [email protected]; las plataformas esperan lo último. La página de requisitos de parámetros de Meta lista las reglas de normalización por campo.
Segundo, el hash tiene que ser hex en minúsculas sin espacios. SHA256("[email protected]") produce a3b6...; la API espera a3b6..., no A3B6... ni \xa3\xb6.... La mayoría de los SDKs de lenguajes devuelven hex en mayúsculas por defecto; tiene que poner el resultado en minúsculas.
Si está enrutando a través del endpoint POST /v1/conversions de Elido, el hashing se maneja del lado de la plataforma - usted hace POST del email/teléfono en bruto, Elido hace la normalización y el hashing según los requisitos de la plataforma, y reenvía. El beneficio es un conjunto de reglas de normalización para que su back-end mantenga en lugar de tres. El coste es que está confiando en Elido con el PII en bruto en el momento del reenvío; la solicitud está cifrada en tránsito y no se persiste en el servidor, pero vale la pena entender el modelo de confianza antes de cablearlo.
Un POST de Meta CAPI trabajado#
Lo que la plataforma realmente quiere. El endpoint es POST https://graph.facebook.com/v21.0/{pixel_id}/events. El cuerpo es JSON.
{
"data": [
{
"event_name": "Purchase",
"event_time": 1716480000,
"event_id": "order-acme-2026-05-23-001847",
"action_source": "website",
"event_source_url": "https://acme.example/checkout/thanks?order=001847",
"user_data": {
"em": ["a3b6...sha256 of email"],
"ph": ["c4d7...sha256 of phone"],
"client_user_agent": "Mozilla/5.0 ...",
"client_ip_address": "203.0.113.42",
"fbc": "fb.1.1716470000.AbCdEf",
"fbp": "fb.1.1716470000.987654321"
},
"custom_data": {
"currency": "EUR",
"value": 89.5,
"content_ids": ["sku-spring-jeans-32-blue"],
"content_type": "product",
"num_items": 1
}
}
],
"test_event_code": "TEST12345",
"access_token": "EAAxxxxxxx"
}
Tres cosas que vale la pena notar:
El event_id es la clave de dedup. Configúrelo como su ID de pedido; el pixel Purchase del lado del navegador establece el mismo valor. Meta deduplica dentro de la ventana de coincidencia de 48 horas.
fbc y fbp son los identificadores de cookies de Meta. fbc es el identificador de clic (fbclid de la URL de aterrizaje, con prefijo); fbp es el identificador del navegador de la cookie _fbp. Ambos son de primera parte desde la perspectiva de su dominio y capturables del lado del servidor una vez que los ha persistido fuera de la página de aterrizaje. Si no los tiene, la tasa de coincidencia de Meta cae; si los tiene, la tasa de coincidencia es excelente.
test_event_code le permite disparar eventos de prueba que no cuentan para los informes de producción. Siempre cablee esto primero; verifique en Events Manager Test Events antes de activar el tráfico de producción.
El equivalente de la API de Elido: POST /v1/conversions con {click_id, event_name: "Purchase", value, currency, order_id, customer: {email, phone}}. Elido normaliza y hashea según las especificaciones de Meta, busca el fbc/fbp del workspace del evento de clic y construye el payload CAPI.
Un POST de GA4 Measurement Protocol trabajado#
El formato de cable de GA4 es similar en forma pero los nombres de los campos difieren. Endpoint: POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXX&api_secret=xxx.
{
"client_id": "click-id-as-fallback-if-no-ga4-cookie",
"user_id": "user-acme-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "order-acme-2026-05-23-001847",
"value": 89.5,
"currency": "EUR",
"items": [
{
"item_id": "sku-spring-jeans-32-blue",
"item_name": "Spring Jeans 32 Blue",
"quantity": 1,
"price": 89.5
}
],
"engagement_time_msec": 1
}
}
]
}
Notas:
client_id es el valor _ga de la cookie de GA4 si está presente; si no, el click_id sirve como respaldo utilizable (porque GA4 creará una sesión contra él).
transaction_id es la clave de dedup - configúrelo como su ID de pedido, mismo valor que el evento purchase de gtag del navegador, GA4 deduplica dentro de su ventana de sesión.
engagement_time_msec tiene que estar presente y ser positivo para que el evento cuente para la atribución; configurarlo a 1 satisface el requisito.
api_secret es a nivel de workspace. La documentación de GA4 MP cubre la configuración de credenciales.
Semántica de reintentos#
Las plataformas aceptan reintentos; lo que no puede hacer es reintentar ciegamente. Tres patrones funcionan.
Idempotencia en el ID de dedup. Si el event_id / transaction_id de la plataforma es el ID de pedido, y reintenta el mismo payload, la plataforma deduplica - el segundo envío se ignora silenciosamente. Seguro.
Backoff exponencial en 5xx. Tanto Meta como GA4 ocasionalmente devuelven 5xx. Reintente con backoff (1s, 2s, 4s, 8s hasta 60s, luego ríndase). Los reintentos deben preservar el mismo event_id para que la plataforma deduplique cualquier caso de éxito parcial.
No reintente en 4xx. Una respuesta 4xx significa que el payload está malformado o las credenciales son incorrectas. Reintentar no lo arreglará; el reintento solo quema presupuesto de rate-limit. Regístrelo, alerte, arregle el problema upstream.
Si está enrutando a través de Elido, el retry/backoff se maneja - POST /v1/conversions devuelve inmediatamente y el fan-out a las plataformas ocurre en segundo plano, con el estado de reintento observable a través de GET /v1/conversions/{id}. Si está haciendo el suyo propio, la capa de cola (RabbitMQ, Kafka, AWS SQS) es donde vive la forma del reintento.
Modo de prueba y dry-run#
El mayor error que cometen los equipos es saltarse el dry-run.
Meta tiene Test Events. Configura test_event_code en el payload, los eventos aparecen en el panel de Test Events en segundos, verifica la forma y la deduplicación. Los eventos de producción pasan por el mismo endpoint pero sin el test_event_code.
GA4 tiene DebugView. Configura debug_mode: 1 en los params del evento, los eventos aparecen en DebugView, verifica antes de activar el tráfico de producción.
TikTok tiene un modo de prueba similar en la interfaz de Events Manager.
La checklist de verificación es corta. Coloque un pedido de prueba, observe el webhook order-paid, observe el reenvío de conversión disparándose, observe que aterriza en el panel de prueba de la plataforma. Confirme que el event_id coincide con el valor del pixel del lado del navegador. Confirme que el value, currency y content_ids se ven correctos. Luego deshabilite el modo de prueba y observe los primeros diez pedidos de producción.
Si se salta esto, se entera de que la integración está rota tres días después cuando los informes están planos. Saltarse el dry-run es el modo de falla único más común que veo.
Modos de falla comunes#
Click_id ausente en el pedido. El más común. Ya cubierto en la cornerstone de ecommerce; la solución es canalizar el click_id a través del carrito al pedido.
Discrepancia de hash. [email protected] hasheado sin normalización produce un valor diferente que [email protected]. Las plataformas rechazan la coincidencia, la conversión aterriza sin coincidencia de identificador y los informes de Meta lo atribuyen a "no coincidido". La solución son las reglas de normalización en el documento de parámetros de Meta CAPI; la respuesta más limpia es delegar el hashing al acortador para que las reglas vivan en un solo lugar.
fbc no capturado. Cuando el usuario aterriza desde un anuncio de Meta, la URL contiene fbclid; la página tiene que capturarlo y persistirlo (típicamente en los atributos personalizados del pedido). Sin fbc, la tasa de coincidencia de Meta cae materialmente. La solución es el paso del tag manager de la página de aterrizaje que escribe fbc en una cookie de primera parte o en el atributo del carrito.
ID de dedup inconsistente. El pixel del lado del navegador usa el ID de pedido; el lado del servidor usa un UUID generado en el momento del reenvío. Ambos eventos se ingieren, ninguno se deduplica. La solución es asegurarse de que el reenvío server-side use el mismo valor event_id que emitió el pixel del lado del navegador - ID de pedido para compras es la respuesta estándar.
Discrepancia de moneda. El navegador envía USD (porque la configuración de gtag por defecto es USD); el servidor envía EUR (porque el pedido está en EUR). GA4 y Meta ambos tratan la moneda como parte de la firma del evento en algunos contextos de coincidencia, y las conversiones aterrizan pero no se agregan limpiamente. La solución es obtener la moneda del pedido, no de la configuración a nivel de página.
Dónde vive esto en el plano de datos#
El reenvío de conversiones es una pieza del pipeline de atribución más amplio. La cornerstone para el pipeline circundante es Cómo trackear campañas UTM de extremo a extremo sin un CDP - esa publicación cubre la plantilla UTM del workspace, los overrides a nivel de campaña, la importación masiva y el paso de verificación dry-run en detalle. Esta publicación es el deep-dive sobre el fan-out server-side que cierra el bucle.
Para la guía operativa, el documento de reenvío de conversiones es el paso a paso. Para el detalle arquitectónico de cómo Elido hace fan-out sin exceder los límites de tasa de la plataforma, la publicación sobre arquitectura de ingestión de clics cubre el pipeline fire-and-forget.
Lee el cluster#
Publicaciones hermanas en el cluster de features: Smart links explained (la cornerstone), Webhooks for link events (la forma de evento más amplia), y Forwarding conversions to Meta CAPI (el deep-dive más profundo específico de Meta). Para la versión orientada a la persona, solutions/marketers es la página; la página de la feature de conversion-tracking es la superficie del producto.
Relacionados en el blog#
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Gratis, sin registro · 2 por día