Meta puede recibir los eventos de tu tienda Shopify desde un Pixel del navegador, desde una llamada del servidor a la Conversions API o desde ambos a la vez. No son tres productos que compitan: son tres niveles de cobertura sobre el mismo embudo, y las diferencias aparecen en lo que cada fuente puede ver.
Esta guía es para un comerciante de Shopify o un responsable de marketing interno que decide cómo debe recibir Meta los eventos, y para el desarrollador que lo implementa. Compara las tres opciones a nivel de mecanismo: dónde se dispara el evento, qué parámetros viajan, cómo se respeta el consentimiento, cómo funciona la deduplicación y qué te permite conciliar cada una contra los pedidos de Shopify. No elige un ganador, no cita costes ni promete mejoras en la calidad de emparejamiento; eso depende de tu tráfico, tu catálogo, tus tasas de consentimiento y tu equipo.
¿Qué mide realmente un Pixel de Meta solo en el navegador?
Un Pixel solo en el navegador mide lo que puede reportar la página del comprador: páginas vistas y las acciones a nivel de página que tu tema o un web pixel de Shopify dispara en el navegador. Ve ViewContent, AddToCart e InitiateCheckout de forma natural, y pierde cualquier evento que el navegador no llegue a ejecutar.
Instalas el código base una vez, y a partir de ahí el Pixel reporta mediante fbq('track', ...). Cada vez que el Pixel carga llama automáticamente a fbq('track', 'PageView'), así que las páginas vistas no dependen de que escribas código de evento. Los eventos estándar cubren el embudo: ViewContent en una página de producto, AddToCart cuando un artículo entra al carrito, InitiateCheckout cuando empieza el checkout y Purchase en la página de confirmación o de agradecimiento. Cada uno acepta un objeto de parámetros —content_ids, contents, currency, value, content_type—, de modo que el evento lleva el producto y su valor.
Hay dos detalles que importan más allá de disparar el evento. El Advanced Matching: los valores que pasas a fbq('init') los hashea el Pixel con SHA-256 antes de salir del navegador, así que un email con hash puede viajar sin que lo haga el valor en claro. Y el par de identificadores _fbp y _fbc: el Pixel establece un identificador de navegador (_fbp) y deriva un identificador de clic (_fbc) a partir del fbclid del clic de anuncio que trajo al visitante. Esos valores enlazan un evento del navegador con un clic.
Como todo ocurre en el navegador, el navegador es también el techo. El control por consentimiento detiene el Pixel para los compradores que rechazan fines de marketing; los bloqueadores de anuncios, una página que nunca llega a renderizarse o una pestaña cerrada antes de la página de confirmación no producen ningún evento. En Shopify en concreto, una compra del navegador depende de checkout_completed, que se dispara una vez por checkout —normalmente en la página de agradecimiento, o en la primera página de upsell cuando hay ofertas post-compra— y no se dispara en absoluto si esa página no carga. Las protecciones de privacidad del navegador también pueden acortar o bloquear las cookies que establece un script, _fbp incluida, y eso es una cuestión de vida útil que se comprueba, no se da por supuesta.
Lo que el Pixel del navegador te permite conciliar es un recuento de las compras que vio el navegador; un reembolso procesado después en el back office queda fuera de su vista.
// Browser: one id per purchase, derived from the order so the server can reproduce it
fbq('track', 'Purchase', {
value: 129.00,
currency: 'USD',
contents: [{ id: 'SKU-123', quantity: 1 }],
content_type: 'product'
}, { eventID: 'purchase_4512890' });¿Qué mide realmente una Conversions API solo de servidor?
Una Conversions API solo de servidor mide lo que sabe tu backend. Envía eventos con nombre directamente a Meta desde tu infraestructura, así que reporta las compras que registra tu sistema —incluidos pedidos que el navegador nunca completó— sin depender de la página del comprador en el momento del envío.
Haces un POST de un array data al endpoint de eventos de Meta para tu Pixel, autenticándote con un token de acceso. Cada evento de servidor lleva campos obligatorios: event_name (el nombre del evento estándar o personalizado), event_time (cuándo ocurrió) y action_source, que declara dónde se produjo la conversión. Un evento de tipo website también debe enviar event_source_url y client_user_agent; sin ellos no es válido.
action_source no es decoración. Meta lo exige en todos los eventos; sus valores son website, app, email, phone_call, chat, physical_store, system_generated, business_messaging y other. Elegir el incorrecto tergiversa dónde ocurrió la conversión, y los términos de Meta te hacen responsable de su exactitud. Para una compra en un storefront de Shopify el valor honesto es website, y por eso lo acompañan event_source_url y el user agent.
Los datos de usuario son donde el servidor tiene a la vez ventajas y huecos. Puede enviar em y ph, normalizados (por ejemplo, un email sin espacios sobrantes y en minúsculas) y hasheados con SHA-256, además de external_id y client_ip_address. También puede enviar fbc y fbp, pero solo si esos valores existen. _fbc procede de un fbclid en una URL de destino y _fbp lo establece el navegador; un servidor que nunca interactúa con el navegador no tiene ninguno de los dos y no puede inventarlos. Un pipeline solo de servidor ve acciones a nivel de página como ViewContent y AddToCart solo si la página se lo indica explícitamente, porque nada más que el navegador las observa.
Hay una propiedad más que importa: la deduplicación no se aplica dentro de una misma fuente. Meta no descarta dos eventos de servidor idénticos enviados uno tras otro, ni dos eventos de navegador idénticos. La deduplicación existe solo entre un evento del navegador y su gemelo en el servidor.
Los reembolsos se comportan de otra forma aquí. Un servidor que lee el pedido y el registro de reembolsos es el lugar natural para representar un reembolso; cómo se expresa es una decisión de diseño que verificas contra la documentación de Meta.
¿Qué cambia cuando usas ambos con deduplicación por event_id?
Usar ambos convierte dos registros parciales en uno completo, pero solo cuando Meta puede emparejarlos. En la configuración redundante recomendada, el Pixel y la Conversions API envían el mismo event_name y el mismo event_id, y Meta funde la pareja en un único evento.
Meta documenta la configuración redundante —enviar todos los eventos desde ambas fuentes— como la configuración recomendada, siempre que puedas generar un event_id persistente para las dos. La regla es concreta: el eventID del Pixel debe ser igual al event_id del servidor, y el event del Pixel debe ser igual al event_name del servidor. Cuando ambos coinciden y el segundo evento llega dentro de las 48 horas siguientes al primero, Meta conserva el primero y descarta el duplicado; si los dos llegan con unos cinco minutos de diferencia, Meta prefiere el evento del navegador.
Existe un mecanismo de reserva documentado —emparejar por event_name más fbp y/o external_id— y viene con condiciones: por lo general solo funciona cuando el evento del navegador llega primero y el del servidor después, y un evento de servidor no se descarta solo porque un evento de navegador idéntico aparezca más tarde.
Lo que exige la deduplicación, entonces, es un identificador estable que ambas partes puedan producir por separado. Un número de pedido o un transaction ID es lo habitual, porque el navegador puede leerlo en la página de confirmación y el servidor ya lo tiene. Lo que la rompe es cualquier desacuerdo: un identificador generado de nuevo en cada carga de página, un identificador presente en un lado y ausente en el otro, una diferencia de mayúsculas o de escritura en el nombre del evento (purchase frente a Purchase), un intervalo mayor que la ventana de emparejamiento o una configuración en la que solo una fuente está activa. Cada caso deja dos eventos, y dos eventos se leen como dos compras.
Events Manager muestra el resultado. Test Events muestra los eventos entrantes con su origen; una pareja emparejada se presenta como deduplicada en lugar de como dos conversiones separadas, y el detalle del evento muestra cómo llegó cada una. El panel agregado solo muestra totales, y los totales ocultan la duplicación que estás buscando.
{
"data": [{
"event_name": "Purchase",
"event_time": 1690000000,
"event_id": "purchase_4512890",
"action_source": "website",
"event_source_url": "https://store.example/checkout/thank-you",
"user_data": {
"em": ["<sha256 of the normalized email>"],
"fbp": "fb.1.1690000000.1234567890",
"fbc": "fb.1.1690000000.AbCdEfGh"
},
"custom_data": { "value": 129.00, "currency": "USD" }
}]
}Comparación lado a lado
La tabla compara las tres opciones según los criterios que deciden la mayoría de implementaciones en Shopify. Describe contrapartidas en lugar de clasificarlas, y no incluye precios de proveedores.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Criterio | Solo Pixel del navegador | Solo Conversions API | Ambos, con event_id |
|---|---|---|---|
| Origen del evento | El navegador del comprador, en la página | Tu servidor o backend | Ambos, describiendo la misma acción |
| Cobertura de compra y reembolso | Compra cuando se ejecuta la página de confirmación; reembolsos no vistos | Compras del back office; reembolsos representables desde los datos del pedido | Compra cubierta dos veces y fundida en una; los reembolsos siguen siendo una decisión de diseño |
| Deduplicación | No aplica — una sola fuente | No aplica — una sola fuente | Emparejar por event_id y event_name |
| Gestión del consentimiento | Controlado en el navegador por la herramienta de consentimiento | Tu pipeline debe llevar la señal de consentimiento y suprimir los eventos rechazados | Ambas partes deben respetar la misma señal |
| Propiedad de los datos | Los datos del evento los ensambla y los envía el navegador | Los datos del evento los ensambla y los envía tu infraestructura | Dividida: el navegador captura, el servidor reenvía |
| Dependencia / lock-in | Depende de que la página se ejecute y de las protecciones del navegador | Depende de tu endpoint, tu token y tu esquema de identificadores | Depende de que ambas partes sigan de acuerdo |
| Carga de mantenimiento | Baja, hasta que un cambio de privacidad o de tema rompe la ruta | El esquema de identificadores, los reintentos y la monitorización son tuyos | La más alta — dos rutas que deben coincidir |
| Para quién encaja | Tiendas con suficiente señal de navegador y ninguna otra fuente de Meta | Tiendas cuya pérdida está en el navegador y que pueden mantener un pipeline | Tiendas que quieren cobertura de todo el embudo y una sola compra contada |
Tabla de decisión
Empareja la tienda que tienes delante con un punto de partida. Son valores por defecto para casos comunes, no reglas.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Si tu situación es… | Elige… |
|---|---|
| Optimizas solo para Purchase y la ruta del navegador ya lo cubre | Solo Pixel del navegador |
| Quieres señales de embudo superior (view, add to cart) además de las compras | Pixel del navegador más Conversions API, deduplicados por event_id |
| Necesitas compras que el navegador nunca completó —pedidos manuales, checkouts fuera del sitio, algunos upsells | Conversions API, manteniendo el Pixel del navegador para los eventos de página |
| Otro sistema ya envía un Purchase a Meta (un canal de ventas o una app) | Decide qué única ruta es dueña de Purchase y luego deduplica el resto con un event_id compartido |
| Necesitas controlar qué parámetros de usuario viajan y cuándo el consentimiento bloquea el envío | Conversions API, normalmente mediante recogida server-side |
| No puedes mantener un identificador que sobreviva a las recargas | Solo Pixel del navegador, y acepta sus límites de cobertura |
| Meta y Shopify no coinciden en los totales | Primero la conciliación — el desajuste puede ser de reglas de recuento, no de cobertura |
Cuándo no usar cada opción
Un Pixel solo de navegador es la opción equivocada cuando la pérdida es de transporte; una configuración solo de servidor lo es cuando nadie mantiene el esquema de identificadores; usar ambos lo es cuando nadie consigue que los identificadores coincidan. Ninguna de las tres es un atajo para el consentimiento.
No elijas solo navegador cuando:
- La mayoría de las compras ocurren después de una página que suele fallar al cargar, o dentro de un flujo post-compra.
- Tus campañas necesitan eventos de embudo superior atribuidos de forma coherente y tu ruta de navegador está muy bloqueada.
- Quieres una comprobación cruzada del recuento de compras, que una sola fuente no puede darte.
No elijas solo servidor cuando:
- Tus campañas necesitan ViewContent y AddToCart para públicos de catálogo o de retargeting; el servidor no puede verlos salvo que la página se los envíe.
- No tienes forma de capturar
fbclidni los identificadores del navegador, así quefbpyfbcestarán ausentes y el enlace con el clic se pierde. - Nadie va a hacerse cargo del token, los reintentos y la monitorización. Una ruta de servidor falla en silencio.
No elijas ambos cuando:
- Nadie puede definir un identificador estable que produzcan las dos partes. Dos fuentes sin emparejar inflan los recuentos más que una fuente imperfecta.
- La segunda fuente es un sistema que no puedes cambiar —una app de canal que genera su propio identificador—. Consolida en lugar de añadir una tercera.
Y ninguna de las tres arregla:
- El consentimiento. Una ruta de servidor bien construida sigue suprimiendo eventos para los visitantes que rechazaron. (Esto cubre la implementación técnica, no asesoramiento legal.)
- Una definición de conversión equivocada o un evento de compra ausente.
- La brecha estructural entre el recuento de Meta y los pedidos de Shopify — eso es conciliación de pedidos, no una fuente de eventos nueva.
Cómo verifico esto en implementaciones reales
Verifico contando y emparejando, no leyendo paneles: confirmo las fuentes activas, observo un evento real en Test Events de Meta, compruebo los identificadores y concilio el recuento contra una exportación de pedidos de Shopify.
- Haz inventario de todas las fuentes que pueden enviar eventos a Meta. Canal de ventas, apps, web pixel, código del tema, pipeline de servidor. La duplicación empieza con una fuente que nadie recordaba.
- Observa un evento en directo. Usa Test Events de Events Manager y envía un evento de servidor con un
test_event_codepara que aparezca junto al del navegador. DebugView es la superficie de GA4 y no muestra eventos de Meta. - Comprueba la clave, no solo la llegada. Confirma que el
eventIDdel navegador y elevent_iddel servidor son la misma cadena, y que ambos nombres de evento coinciden exactamente. Una pareja deduplicada es la señal; dos conversiones separadas son el bug. - Confirma la cobertura en ambas partes. Verifica que ViewContent, AddToCart e InitiateCheckout llegan desde el navegador, y que Purchase llega desde las dos fuentes para el mismo pedido.
- Confirma que los identificadores viajan. Donde hubo una captura en el navegador, comprueba que
fbpyfbcestán presentes en el evento de servidor; donde no la hubo, no des nada por supuesto. - Concilia contra un periodo cerrado. Compara el recuento de eventos Purchase con una exportación de pedidos de Shopify para una ventana fija.
- Comprueba el consentimiento en ambos sentidos. Con el consentimiento de marketing rechazado, confirma que no se dispara nada; concédelo y confirma que los eventos fluyen.
Modos de fallo habituales
La mayoría de los fallos no son exóticos: un identificador que cambia, un nombre de evento que no coincide, un parámetro que el servidor nunca recibió o una segunda fuente que nadie recordaba.
- Un identificador regenerado en cada carga de página. Un
event_idconstruido en el render a partir de un UUID nuevo o una marca temporal nunca puede coincidir con el gemelo del servidor. - Un identificador derivado solo en una parte. El Pixel y el servidor envían cadenas distintas para el mismo pedido, así que Meta ve dos.
- Deriva del nombre del evento.
Purchaseen un lado,purchaseo un nombre personalizado en el otro. Los identificadores pueden coincidir a la perfección y aun así falla. - Un identificador ausente en una parte. No hay nada con lo que emparejar.
- Un envío de servidor retrasado que aterriza fuera de la ventana de emparejamiento.
- Una segunda fuente que sigue activa tras una migración, y cada mitad genera su propio identificador.
- Un evento de servidor marcado como
websitesinevent_source_urlniclient_user_agent, que no es un evento website válido. fbp/fbcdados por supuestos en lugar de capturados. El servidor los tiene solo si el navegador se los pasó.- Consentimiento respetado en el navegador pero no en el pipeline de servidor.
Limitaciones
Cada opción tiene un techo marcado por lo que llega hasta ella. Un Pixel del navegador no puede reportar lo que el navegador nunca ejecuta; una configuración solo de servidor no puede ver eventos de página que nadie le contó; usar ambos no se concilia solo, porque la deduplicación depende de identificadores que tú mantienes correctos.
Ninguna de estas opciones cambia las reglas de recuento de Meta ni los totales de pedidos de Shopify. fbp y fbc ayudan al enlace cuando están presentes, pero una ruta de servidor sin una captura del navegador no los tendrá. La configuración redundante añade además mantenimiento: dos rutas que deben coincidir, indefinidamente. Y las obligaciones de consentimiento y minimización de datos se aplican a las tres, esté donde esté ensamblado el evento. Usadas por lo que son —un punto de observación sobre el embudo—, son complementarias.
Alternativas
Si el problema no es qué fuente de eventos, sino qué le ocurre a la petición de camino a Meta, la respuesta está una capa más abajo: la recogida server-side mediante un endpoint de primera parte, descrita en el servicio de tracking server-side y sopesada con honestidad en Tracking server-side: beneficios, límites y arquitectura.
Si lo que eliges es un pipeline de Meta y no una fuente de eventos, la comparación de proveedores está en Meta Conversions API en Shopify: app nativa, Stape o server-side GTM. Si el síntoma es que Meta reporta de más, empieza por el diagnóstico de deduplicación de Meta CAPI y por la mecánica de Deduplicación en Meta CAPI: cómo funciona realmente event_id. Para el lado de Google de la misma tienda, consulta Arreglar el evento purchase de GA4 en Shopify y Por qué los ingresos de GA4 no cuadran con Shopify. Los conceptos de fondo están en event ID, calidad de emparejamiento de eventos y Consent Mode v2.
