La API de Conversiones de Meta Ads (CAPI) dejó de ser opcional hace dos años. En 2026, con iOS bloqueando cookies de terceros por defecto, Safari aplicando ITP agresivo y los navegadores Brave/Firefox limitando el seguimiento, un eCommerce que sólo confíe en el píxel está enviando a Meta entre un 20% y un 40% menos de eventos de compra de los que realmente ocurren — y el algoritmo aprende con datos parciales.
Esta guía cubre lo que un fundador D2C necesita entender para decidir cómo implementar CAPI: qué es realmente, qué impacto tiene en el rendimiento, cómo se implementa en Shopify, qué eventos enviar, cómo deduplicar correctamente con el píxel y cómo verificar que está bien configurada.
Qué es la API de Conversiones (CAPI) y por qué importa
CAPI es un canal de envío de eventos server-side: tu servidor (Shopify, una app intermedia o un endpoint propio) envía directamente a los servidores de Meta los eventos de conversión, sin pasar por el navegador del usuario. El píxel hace lo mismo pero desde el navegador, y por tanto está sujeto a todas las limitaciones de privacidad modernas.
La documentación oficial de Meta sobre la API de Conversiones es explícita: la combinación de píxel + CAPI es el setup recomendado para todos los anunciantes que dependan de optimización por conversión. No se trata de elegir uno u otro, sino de enviar la señal por las dos vías y dejar que Meta deduplique.
Impacto real en el rendimiento (datos de cuentas migradas)
Estos son los rangos de mejora que hemos visto en cuentas D2C españolas tras migrar de píxel-only a píxel + CAPI deduplicada correctamente:
| Métrica | Mejora típica | Por qué ocurre |
|---|---|---|
No es un tema marginal de tracking: es la diferencia entre escalar con el algoritmo trabajando con buenos datos o escalar a ciegas. En cuentas con mucho tráfico iOS, donde Safari y la App Tracking Transparency capan más eventos, la mejora suele estar en la parte alta del rango.
Cómo implementar CAPI en Shopify: 3 rutas
Para Shopify hay tres formas de implementar CAPI, con diferente nivel de control, coste y mantenimiento:
—
Pros:
Contras:
Cuándo encaja:
Eventos críticos a enviar y parámetros obligatorios
No todos los eventos pesan lo mismo. Estos son los que un eCommerce D2C debe enviar por CAPI sí o sí, en orden de prioridad:
| Evento | Para qué se usa | Prioridad |
|---|---|---|
Cada evento debe enviarse con: event_id (mismo en píxel y CAPI para deduplicar), event_time, action_source, datos de cliente hasheados (email, teléfono, IP, user_agent, fbp, fbc) y custom_data (value, currency, content_ids). Si falta el hash de email o el fbp, el Event Match Quality cae y la deduplicación se rompe.
Deduplicación: el detalle que rompe la mayoría de implementaciones
El error más común que vemos al auditar cuentas con CAPI activa: eventos duplicados porque la deduplicación no está bien hecha. Cuando ocurre, Meta cuenta dos compras donde sólo hubo una, infla el ROAS reportado y degrada la calidad de las audiencias.
Para deduplicar correctamente, el píxel y CAPI deben enviar el mismo event_id y el mismo event_name para el mismo evento. Meta entonces compara y se queda sólo con uno (prioriza el que tenga más datos, normalmente CAPI). Para verificarlo, en Events Manager → Diagnostics no debe aparecer ninguna alerta de eventos duplicados durante el primer mes tras la implementación.
Las apps de partner como Aimerce o Elevar gestionan esto out-of-the-box. En implementaciones custom es donde suele fallar: el desarrollador genera un event_id por cada vía y Meta no puede deduplicar. Shopify Engineering ha documentado los patrones de implementación recomendados que conviene revisar antes de cualquier custom.
RGPD, consentimiento y CAPI
Una confusión peligrosa: pensar que CAPI sirve para esquivar el consentimiento. No es así. Si un usuario rechaza cookies en tu CMP, no debes enviar su evento ni por píxel ni por CAPI. Lo que CAPI permite es capturar eventos de usuarios que sí han consentido pero cuyo navegador habría descartado el píxel. La integración correcta lee el flag del CMP (Cookiebot, OneTrust, Didomi) en el servidor antes de disparar el evento server-side.
Cómo verificar que tu CAPI está bien (3 chequeos)
Cómo trabajamos en DayByDay con CAPI
No tocamos campañas hasta tener CAPI deduplicada y validada. Ese es nuestro día 1 con cualquier cuenta D2C nueva. Así lo implementamos:
¿Quieres saber cómo está tu CAPI hoy?
Auditoría gratuita en 30 minutos: revisamos EMQ, deduplicación y cobertura server-side de tu cuenta. Te decimos exactamente cuántos eventos estás perdiendo y cómo recuperarlos.
Artículos relacionados
El siguiente paso: arquitectura sGTM/Stape, deduplicación cliente-servidor y EMQ >8,5
Cómo extender la CAPI con eventos custom (wishlist, scroll PDP) compartidos a GA4 para audiencias BOFU
Por qué la CAPI básica ya no basta y cuánto matching pierde una cuenta D2C con tráfico iOS
MER, CPA real vs ROAS de plataforma y por qué CAPI cambia los números reportados
Diagnóstico en 5 capas — el tracking es la primera causa que descartar
Auditoría operativa con CAPI, EMQ y cobertura server-side incluidos
El caso de uso #1 donde CAPI determina el rendimiento real: content_ids, product sets y estructura DPA
Cómo configurar Conversions API multi-país con campo país en custom_data para discriminar EMQ por mercado y reporting localizado
El pilar completo: tracking, estructura, creatividades y escalado para D2C
Por qué CAPI server-side es requisito para que el DPA recupere ROAS post-iOS
Sin CAPI con EMQ >7, la semilla del lookalike pierde la mitad de su match rate
Sin CAPI server-side las audiencias de retargeting pierden la mitad de su tamaño