- El server-side tracking envía eventos de conversión, como las compras, desde un servidor a la API de la plataforma publicitaria, en lugar de enviarlos solo desde un píxel en el navegador.
- Cuando la compra se envía a partir de los datos del pedido de tu tienda, los bloqueadores de anuncios y una página de agradecimiento que nunca se carga ya no provocan ventas perdidas.
- El navegador sigue haciendo falta para guardar el click id al llegar, y el píxel puede funcionar junto al servidor con el mismo event_id, de modo que cada compra cuente una sola vez.
- El server-side tagging, como un contenedor de servidor de Google Tag Manager, sigue partiendo de eventos del navegador, así que no puede recuperar compras que el navegador nunca envió.
- El server-side tracking no es una forma de saltarse el consentimiento: las normas de privacidad se aplican a los datos sea cual sea la ruta que sigan.
El server-side tracking significa que los eventos de conversión, como una compra, se envían a las plataformas publicitarias desde un servidor, en lugar de enviarse solo desde un script en el navegador del comprador. En una tienda online, el servidor envía cada pedido a Meta, TikTok o Google a través de sus API, de modo que la venta se registra incluso cuando el píxel del navegador está bloqueado o nunca se carga.
Esta guía explica la diferencia entre un píxel del navegador y el server-side tracking, sigue los datos desde el clic en el anuncio hasta la plataforma publicitaria y muestra qué contiene un evento del servidor. También trata la deduplicación, el server-side tagging, el consentimiento y cómo saber si tu tienda lo necesita. Para la configuración en Shopify en sí, lee server-side tracking en Shopify.
Píxel del navegador frente a server-side tracking
Un píxel del navegador es un fragmento de JavaScript de la plataforma publicitaria. Se ejecuta en tus páginas y envía eventos desde el dispositivo del comprador directamente a la plataforma: una visualización de página, un añadido al carrito, una compra en la página de agradecimiento. Solo funciona cuando el script se carga, se ejecuta y llega a la plataforma antes de que el comprador abandone la página.
El server-side tracking traslada el envío a un servidor. El evento puede partir de datos que tu tienda ya tiene, como un pedido pagado, y el servidor lo envía a la API de la plataforma. Meta llama a esta API Conversions API y TikTok la llama Events API. Google Ads usa conversiones mejoradas, que añaden datos del cliente con hash a una conversión.
- Se ejecuta en el navegador del comprador
- Envía los eventos directamente a la plataforma publicitaria
- Crea y lee cookies first-party, como _fbp para Meta
- No envía nada cuando el script está bloqueado o la página no se carga
- Se ejecuta en un servidor que controlas tú o un proveedor de servicios
- Envía los eventos a la API de la plataforma
- Puede partir del registro del pedido en tu tienda
- No depende de que se cargue la página de agradecimiento
Usar ambos da a la plataforma los datos más completos. El evento del navegador añade cookies y contexto de la página. El evento del servidor llega aunque el navegador falle. Un id de evento compartido garantiza que la plataforma cuente cada compra una sola vez.
¿Cómo funciona el server-side tracking?
El server-side tracking de una tienda online tiene dos mitades. La primera ocurre en el navegador: cuando un comprador llega desde un anuncio, un script guarda el click id de la URL. La segunda ocurre en el servidor: cuando el pedido se paga, el servidor vincula ese click id con el pedido y envía la compra.
Captura del clic
Las plataformas publicitarias añaden un click id a la URL de llegada: fbclid en Meta, ttclid en TikTok, gclid en Google Ads y msclkid en Microsoft Ads. El click id es el vínculo más fuerte entre una venta y el anuncio que la provocó, por lo que debe guardarse en la primera visualización de página. Los parámetros UTM añaden los nombres de la campaña, el conjunto de anuncios y el anuncio en un formato que controlas tú.
Asociar el pedido
Después, el servidor necesita saber qué visitante hizo el pedido. El vínculo más fiable es un valor que viaja con el carrito hasta el pedido, como un id de visitante guardado en el carrito. Los demás métodos son más débiles: una dirección de email que el visitante introdujo antes en el sitio, o la misma dirección IP y el mismo navegador vistos poco antes del pedido. Cada plataforma de tiendas online ofrece opciones distintas. Nuestra guía para otras tiendas online enumera los métodos que ROASaurus usa en cada plataforma.
Envío del evento
Por último, el servidor envía la compra a la API de cada plataforma. El evento incluye el valor del pedido, el click id y datos del cliente que ayudan a la plataforma a encontrar a la persona que hizo clic. Si una plataforma no está disponible o devuelve un error, una buena configuración lo reintenta más tarde, para que la compra no se pierda.
¿Qué contiene un evento del servidor?
Cada plataforma tiene sus propios nombres de campo, pero un evento de compra lleva los mismos tipos de datos en todas. Este es un ejemplo abreviado para la Meta Conversions API:
{
"data": [{
"event_name": "Purchase",
"event_time": 1793009700,
"event_id": "order-1042",
"action_source": "website",
"event_source_url": "https://yourstore.com/checkout/thank-you",
"user_data": {
"em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
"ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
"client_ip_address": "203.0.113.24",
"client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
"fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
"fbp": "fb.1.1792832529000.1234567890"
},
"custom_data": { "currency": "USD", "value": 84.00 }
}]
}| Campo | Qué es | ¿Con hash? |
|---|---|---|
| Nombre y hora del evento | Purchase, y el momento en que se hizo el pedido | No |
| Valor y moneda | El valor del pedido que la plataforma usa para el ROAS y para la puja basada en valor | No |
event_id | Un id único por evento, el mismo en el navegador y en el servidor, para la deduplicación | No |
| Email, teléfono, nombre, dirección | Datos del cliente a partir del pedido, normalizados y con hash SHA-256 | Sí |
| Click id (fbc, ttclid, gclid) | El id del clic en el anuncio, guardado cuando el comprador llegó | No |
| Dirección IP y user agent | Ayudan a la plataforma a vincular el evento con un dispositivo | No |
El hash convierte una dirección de email en una cadena fija de caracteres. La misma dirección da siempre la misma cadena, pero la cadena no revela la dirección. La plataforma usa los valores con hash solo para buscar una coincidencia entre sus propios usuarios. Así es como una compra puede vincularse con la persona que vio o pulsó el anuncio, incluso cuando el navegador de esa persona bloqueó el píxel.
¿Cómo funciona la deduplicación?
Cuando el píxel y el servidor envían la misma compra, la plataforma debe contarla una sola vez. Las dos copias llevan el mismo nombre de evento y el mismo id de evento, por ejemplo order-1042. Meta compara el par y se queda con una copia, siempre que la segunda copia llegue dentro de las 48 horas posteriores a la primera.
Purchase event_id=order-1042 browserRecibido del píxelPurchase event_id=order-1042 serverMismo nombre e id: se cuenta una vezPurchase event_id=order-1043 serverEl píxel se bloqueó: la copia del servidor es la únicaPurchase event_id=1044 serverEl navegador envió order-1044: los ids difieren, así que cuenta dos vecesLa mayor parte del doble conteo viene de dos emisores que no comparten ids. Un caso típico es la app de tienda propia de una plataforma y una herramienta de tracking aparte que envían compras con sus propios ids. Nuestro artículo de ayuda sobre cómo evitar el doble conteo enumera las causas habituales y las soluciones.
Server-side tagging frente a enviar desde los datos del pedido
El término server-side tracking se usa para dos configuraciones distintas. Ambas envían eventos desde un servidor, pero empiezan en sitios diferentes.
Server-side tagging, como los contenedores de servidor de Google Tag Manager
Con el server-side tagging, el navegador envía sus eventos a tu propio servidor en lugar de enviarlos a cada proveedor. El contenedor de servidor de Google Tag Manager es un ejemplo conocido. Se ejecuta en tu propio proyecto de Google Cloud o en otro entorno que elijas. Recibe solicitudes del navegador, y sus etiquetas reenvían los datos a Google Analytics, Meta y otros proveedores. Tú decides qué datos van adónde, y el servidor puede funcionar en un subdominio de tu sitio.
Los eventos siguen empezando en el navegador. Si la etiqueta del navegador se bloquea, o la página de agradecimiento nunca se carga, el contenedor de servidor no tiene nada que reenviar. Además, tú mismo ejecutas, pagas y actualizas el servidor.
Envío a partir de los datos del pedido
El segundo enfoque hace que la compra parta del registro del pedido en tu tienda. La tienda comunica el pedido pagado al servidor mediante un webhook o una API, y el servidor lo envía a todas las plataformas conectadas. El navegador solo hace falta antes, para guardar el click id cuando el comprador llega.
| Server-side tagging | Envío a partir de los datos del pedido | |
|---|---|---|
| De dónde parte la compra | Una etiqueta en el navegador | El pedido pagado en tu tienda |
| Página de agradecimiento cerrada antes de tiempo | Compra perdida | Compra enviada |
| Etiqueta bloqueada en el navegador | Compra perdida, salvo que el endpoint first-party consiga pasar | Compra enviada |
| Pago contra reembolso y páginas de pago externas | Depende de la página de agradecimiento | Se envía cuando el pedido se crea o se paga |
| Eventos de navegación (visualizaciones de página, añadidos al carrito) | Sí | Necesita un recolector aparte en el navegador |
| Quién gestiona el servidor | Tú: alojamiento y actualizaciones | Tú o un proveedor de servicios |
Los dos enfoques se pueden combinar. Muchas tiendas recogen las visualizaciones de página y los añadidos al carrito en el navegador, y envían la compra a partir de los datos del pedido. La compra es el evento que las plataformas publicitarias usan para informar del ROAS y optimizar las pujas, así que es el que más necesita estar completo.
¿Qué soluciona el server-side tracking y qué no soluciona?
- Compras perdidas porque un bloqueador de anuncios detuvo el píxel
- Compras perdidas porque la página de agradecimiento no se cargó
- Compras de métodos de pago que terminan fuera de tu sitio
- Vinculación débil, al añadir datos del cliente con hash a cada evento
- Consentimiento: un visitante que dijo que no sigue siendo un visitante que dijo que no
- Ventanas y modelos de atribución distintos en cada plataforma
- Emisores duplicados que usan ids de evento distintos
- Click ids que nunca se guardaron al llegar
El consentimiento sigue aplicándose
El server-side tracking es una forma de entregar datos, no una forma de saltarse las normas de privacidad. Cuando la ley exige consentimiento para las cookies de marketing o el seguimiento, ese requisito abarca los datos que recoges, sea cual sea la ruta que sigan hasta la plataforma. Trasladar un rastreador a tu servidor no cambia lo que un visitante aceptó.
La atribución sigue siendo específica de cada plataforma
Cada plataforma sigue atribuyendo el mérito de las compras con sus propias ventanas y reglas. Los eventos del servidor dan mejores datos a cada plataforma, pero los totales de Meta, TikTok y Google aún pueden sumar más que los ingresos de tu tienda. Para comparar canales con un único conjunto de reglas, usa un solo modelo de atribución en todos ellos, como los modelos de la atribución de ROASaurus.
¿Necesita tu tienda server-side tracking?
Una tienda que gasta un presupuesto considerable en anuncios de pago en redes sociales o en buscadores suele salir beneficiada. El caso es más claro cuando se cumplen varios de estos puntos:
- La plataforma publicitaria recibe claramente menos eventos de compra que pedidos web tiene tu tienda. Nuestra guía sobre bloqueadores de anuncios y tracking muestra cómo medir esta diferencia.
- Muchos de tus visitantes usan Safari en iPhone o Mac, donde las cookies creadas por scripts duran 7 días como máximo. Consulta Safari ITP y el tracking de anuncios.
- Los compradores suelen comprar días después del primer clic en el anuncio.
- El pago termina fuera de tu sitio, o los pedidos se pagan más tarde, como con el pago contra reembolso o la transferencia bancaria.
- Optimizas las campañas para compras o para el valor de las compras, así que la plataforma necesita cada venta para aprender.
Veamos cómo cambia las decisiones una diferencia así en la práctica. Una tienda de ejemplo tiene 1,000 pedidos web en un mes. Su píxel de Meta registró 820 eventos Purchase, así que el 18% de los pedidos nunca llegó a Meta desde el navegador.
El ROAS de equilibrio de la tienda es 2.5, y Ads Manager muestra un ROAS de 2.3 con los datos del píxel. Con esas cifras, las campañas pierden dinero. Si los pedidos generados por anuncios se hubieran perdido al mismo ritmo del 18%, el ROAS real es de aproximadamente 2.3 ÷ 0.82 = 2.8, que está por encima del equilibrio. Es una estimación máxima, porque no todos los pedidos que faltan venían de un anuncio. Aun así, muestra cómo una diferencia de tracking puede hacer que una campaña rentable parezca una pérdida.
El server-side tracking importa menos para una tienda que no hace publicidad o que gasta muy poco en anuncios.
Cómo envía ROASaurus los eventos del servidor
ROASaurus captura 19 click ids y seis campos UTM en la llegada y los guarda con un id de visitante first-party. Envía cada compra de los pedidos pagados de tu tienda a Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll y Outbrain. En Shopify, las conversiones de Google Ads se envían desde el checkout de Shopify. Los píxeles del navegador pueden funcionar junto a los eventos del servidor con el mismo id de evento, y Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin y Spotify los deduplican. Cada envío y la respuesta de la plataforma aparecen en el Event log.
Lee más en la página de server-side tracking, o busca tu tienda online en la página de integraciones.
Fuentes
- Meta for Developers: Conversions API
- Meta for Developers: Handling Duplicate Pixel and Conversions API Events
- Meta for Developers: Customer Information Parameters
- Google for Developers: An introduction to server-side tagging
- Google Ads Help: About enhanced conversions