Conversiones desde el servidor: Meta CAPI, GA4 y deduplicación en tu tienda
Los bloqueadores y los límites de cookies hacen que el píxel del navegador pierda parte de las compras. Enviar las conversiones desde el servidor lo corrige, siempre que se deduplique bien y se respete el consentimiento.
Abres el administrador de anuncios y ves 40 compras. Tu tienda tiene 60 pedidos de esa campaña. La diferencia no es un error de la plataforma: son compras que el navegador del cliente nunca llegó a comunicar. Bloqueadores de anuncios, navegadores que limitan las cookies, pestañas cerradas antes de que cargue la página de confirmación o pagos que vuelven desde la pasarela por otra ruta.
El resultado es que las plataformas optimizan tus campañas con datos incompletos. La medición desde el servidor (server-side) envía las conversiones directamente desde tu tienda a la plataforma, sin depender del navegador.
Navegador frente a servidor
| Píxel en el navegador | Envío desde el servidor | |
|---|---|---|
| Bloqueadores | Lo bloquean | No le afectan |
| Pago que vuelve de la pasarela | Puede perderse | Se envía al crear o cobrar el pedido |
| Datos del pedido | Lo que haya en la página | Todo lo que tiene la tienda |
| Comportamiento en la web | Lo ve todo | Solo lo que el servidor conoce |
No se trata de elegir uno: lo habitual es usar los dos y deduplicar.
Meta: la API de Conversiones
La API de Conversiones (CAPI) recibe eventos desde tu servidor con un token de acceso del píxel. Cada evento lleva:
event_name(por ejemploPurchase),event_timeyaction_source(website).event_id: el identificador que permite deduplicar.user_data: datos del cliente con hash SHA-256 (correo, teléfono, nombre…), más la IP, el agente de usuario y las cookies_fbpy_fbcsi existen.custom_data: valor, moneda, productos.
Deduplicación: si el píxel y el servidor envían la misma compra con el mismo event_name y el mismo event_id, Meta la cuenta una sola vez. Sin un event_id compartido, tendrás compras dobles.
GA4: el Measurement Protocol
GA4 acepta eventos desde el servidor mediante el Measurement Protocol, con un api_secret creado en el flujo de datos y el ID de medición. Diferencias importantes con Meta:
- Necesita el
client_iddel navegador (sale de la cookie_ga) para unir el evento con la sesión del usuario. Sin él, la compra aparece sin origen de tráfico. - Para las compras, la deduplicación se hace con el
transaction_id: GA4 descarta compras repetidas con el mismo identificador. - Los eventos enviados con mucho retraso pueden no atribuirse a la sesión correcta.
transaction_id distinto (por ejemplo, el número de carrito en uno y la referencia del pedido en otro). GA4 no los reconoce como el mismo pedido y lo cuenta dos veces.¿Cuándo enviar la compra?
- Al crear el pedido: rápido, pero incluye pedidos por transferencia o contra reembolso que quizá nunca se paguen.
- Al cobrar el pedido (cuando pasa a un estado de pago aceptado): más fiel a la realidad. Es la opción recomendable para la mayoría de tiendas.
También conviene enviar los reembolsos, para que los informes reflejen las ventas netas.
Consentimiento: no es opcional
Que el envío se haga desde el servidor no cambia las reglas. Los datos que envías a Meta o a Google para publicidad requieren el consentimiento del usuario cuando así lo exige la normativa de cookies y protección de datos (en España, el artículo 22.2 de la LSSI y el RGPD). En la práctica:
- Si el usuario ha rechazado las cookies de publicidad, no se envían sus identificadores a esas plataformas.
- Google Consent Mode v2 permite comunicar el estado del consentimiento (
ad_storage,analytics_storage,ad_user_data,ad_personalization) para que Google trate los datos en consecuencia. - Una denegación explícita nunca debe sobrescribirse con un valor por defecto.
- Envía solo lo necesario y con hash; el precio de coste o los márgenes no tienen por qué salir de tu tienda salvo que lo decidas.
Relay: un intermediario entre la tienda y las plataformas
Una variante es no enviar directamente desde la tienda, sino a un servidor intermedio (un relay) que recibe los eventos firmados y se encarga de entregarlos a cada plataforma, con sus reintentos y sus credenciales. Ventajas: las claves de las plataformas no viven en la tienda, los reintentos no cargan tu servidor y se puede gestionar varias tiendas desde un mismo sitio.
Checklist
- Píxel y servidor comparten
event_iden Meta. - GA4 recibe el
client_idreal y untransaction_idúnico y constante. - La compra se envía al cobrar, y los reembolsos también.
- El consentimiento se respeta antes de cargar etiquetas y antes de enviar desde el servidor.
- Comparas cada semana pedidos de la tienda con conversiones en cada plataforma.
- Revisas en el administrador de eventos de Meta la calidad de coincidencia de los eventos.
Cómo resolverlo en PrestaShop
RKR API Conversions Pro envía las conversiones desde el servidor a Meta, GA4, Google Ads, TikTok, Microsoft Ads, Pinterest, Snapchat, LinkedIn y OpenAI / ChatGPT Ads, con el mismo event_id que la etiqueta del navegador para que la plataforma deduplique, y en GA4 evita que un evento llegue dos veces. Las compras pueden enviarse al cobrar el pedido, e incluye reembolsos parciales y cancelaciones. Aplica Consent Mode v2, restaura el consentimiento guardado antes de cargar las etiquetas, tiene adaptadores para Cookiebot, CookieYes, Complianz y OneTrust y nunca sobrescribe una denegación explícita. En modo cola no hace llamadas de red mientras se genera la página o se paga, y una conciliación diaria compara los pedidos con lo entregado a cada plataforma. También puede enviar los eventos a un relay del lado del servidor, con llamadas firmadas y solo identificadores con hash; los planes de relay de Rekire acompañan este artículo.