Sin impuesto Con impuesto

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.

Jesús Meilán
Actualizado: 23/10/2026 32
Conversiones desde el servidor: Meta CAPI, GA4 y deduplicación en tu tienda
Compartir:

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 navegadorEnvío desde el servidor
BloqueadoresLo bloqueanNo le afectan
Pago que vuelve de la pasarelaPuede perderseSe envía al crear o cobrar el pedido
Datos del pedidoLo que haya en la páginaTodo lo que tiene la tienda
Comportamiento en la webLo ve todoSolo 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 ejemplo Purchase), event_time y action_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 _fbp y _fbc si 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_id del 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.
Error típico: enviar la compra a GA4 desde el servidor y, además, desde la página de confirmación con un 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

  1. Píxel y servidor comparten event_id en Meta.
  2. GA4 recibe el client_id real y un transaction_id único y constante.
  3. La compra se envía al cobrar, y los reembolsos también.
  4. El consentimiento se respeta antes de cargar etiquetas y antes de enviar desde el servidor.
  5. Comparas cada semana pedidos de la tienda con conversiones en cada plataforma.
  6. 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.

Cargando...
Cookies
Volver arriba