API de conversiones.
La vía de Meta para recibir tus conversiones desde tu servidor. Va junto al píxel, no en su lugar: las dos copias de cada compra se casan por un identificador, y lo que vale cada evento depende de cuánto sabe Meta de quién compró.
La API de conversiones de Meta, o Conversions API, es la interfaz con la que un servidor envía a Meta los eventos de conversión de una web, una app o una tienda física sin pasar por el navegador del usuario. Se usa junto al píxel: las dos copias de un mismo evento se deduplican por event_name y event_id, y lo que aporta cada evento depende de los datos de cliente que lo acompañan.
También: meta capi · eventos de servidor de meta
Agencia Snowball, Barcelona · Revisado el
La medición en servidor, con las reglas de Meta.
La medición en servidor es la idea general: que el aviso de cada venta lo mande tu servidor y no el móvil del comprador. La API de conversiones es la forma concreta en que Meta lo acepta. Es una puerta con un formato fijo: qué campos lleva cada evento, cuáles viajan cifrados y cuál sirve para reconocer que dos avisos hablan de la misma compra.
Lo que viaja es un evento de conversión, el mismo que ya manda el píxel, con una diferencia que lo cambia todo. El píxel vive dentro del navegador y Meta reconoce a la persona por su cookie y su sesión. Tu servidor no tiene esa sesión, así que el evento tiene que llevar encima las pistas de quién ha comprado. Por eso la mitad del formato no describe la compra: describe al comprador.
El malentendido caro es “montamos la API y quitamos el píxel”. Meta no lo plantea así. Lo que recomienda es enviar por las dos vías a la vez: el píxel recoge lo que solo sabe el navegador y la API recoge lo que el navegador pierde. El precio de hacerlo así es que la misma compra llega dos veces, y alguien tiene que decirle a Meta que es una sola.
event_namePurchaseEl nombre del evento. Tiene que ser idéntico, letra a letra, al que manda el píxel.
event_timemomento de la compraLa hora en que se compró, no la hora en que tu servidor lo envía.
action_sourcewebsiteDónde ocurrió: la web, una app, una tienda física, una llamada.
custom_datavalue · currencyImporte y moneda. Sin ellos Meta sabe que hubo compra, pero no cuánto vale.
em · ph · external_idcifradosEmail, teléfono e id de cliente, normalizados y pasados por SHA-256 antes de salir de tu servidor.
fbp · fbctal cualLa cookie que pone el píxel y el identificador del clic en el anuncio.
client_ip_address · client_user_agenttal cualLa IP y el navegador desde los que se hizo la compra.
event_idel número de pedidoEl mismo valor que el píxel manda como eventID para esa misma compra.
Cuatro campos dicen qué ha pasado, tres grupos de campos dicen quién ha sido y uno solo dice cómo se reconoce la copia. Ese último es el más corto del formato y el que más dinero cuesta cuando falta. Los del medio son tus datos de origen propio, y salen de tu servidor con las mismas condiciones que en el navegador: si el usuario no ha dado su consentimiento, no viajan. La API es una pieza de tu sistema de atribución, la de la recogida en Meta. No decide el reparto del mérito ni sustituye a ninguna otra.
Dos copias de la misma compra, y una sola cuenta.
Meta da por hecho que dos eventos son la misma compra cuando coinciden en dos campos: el nombre del evento y el identificador del evento. En el píxel ese identificador se llama eventID; en la API, event_id. Si los dos traen el mismo valor y llegan con menos de 48 horas de diferencia, Meta se queda con uno y descarta el otro.
La regla es mecánica, y por eso se rompe por detalles mecánicos. El identificador tiene que nacer en un solo sitio —lo natural es el número de pedido— y viajar a las dos vías. Si el píxel genera el suyo y el servidor el suyo, para Meta son dos compras. Lo mismo si uno manda Purchase y el otro manda purchase o un nombre inventado: el nombre también tiene que ser idéntico.
Pongamos 100 compras en un mes. 66 llegan por las dos vías, 4 solo por el píxel, 24 solo por la API y 6 no llegan por ninguna. El píxel manda 70 y la API, 90.
- Llegan por las dos vías66
- Solo por el píxel4
- Solo por la API24
- No llegan por ninguna6
Sobre 100 compras reales
Sin event_id, Meta registra 1,60 compras por cada compra real.
Con el identificador bien puesto, Meta cuenta 94: las 66 que llegaron dos veces cuentan una vez, y se suman las 28 que solo llegaron por un lado. Sin identificador cuenta 160, que es la suma a pelo de las dos vías: 1,60 compras registradas por cada compra real. El ROAS que ves en el panel sube en la misma proporción, y no ha entrado ni un euro más.
Fíjate también en lo que la deduplicación no hace. Las 6 compras que no llegaron por ninguna vía siguen sin existir para Meta: deduplicar no recupera nada, solo evita inventar. Lo que la API aporta de verdad son las 24 que el píxel perdía. Si esas 24 son muchas o pocas en tu caso solo lo sabrás contando contra tus pedidos cobrados, antes y después de encenderla.
El evento ha llegado. Ahora tiene que saber de quién es.
Que Meta reciba la compra es la mitad del trabajo. La otra mitad es que la case con una persona a la que le enseñó un anuncio. Si no lo consigue, la compra suma al total pero no se atribuye a ninguna campaña ni le enseña nada a ninguna.
Meta lo llama calidad de la coincidencia de eventos —Event Match Quality en el panel en inglés— y la puntúa de 0 a 10, evento por evento, en el Administrador de eventos. La nota sube con los identificadores que acompañan al evento y con lo bien formados que llegan. No hay truco: cuanto más sabe tu servidor del comprador, y más de eso le pasas con permiso, mejor se empareja. Y lo que sabe tu servidor cambia según el momento del embudo.
| Identificador | Ver página | Carrito | Lead | Compra |
|---|---|---|---|---|
| no lo tiene | no lo tiene | lo tiene siempre | lo tiene siempre | |
| Teléfono | no lo tiene | no lo tiene | solo a veces | lo tiene siempre |
| Id de cliente | solo a veces | solo a veces | solo a veces | solo a veces |
| Clic del anuncio (fbc) | solo a veces | solo a veces | solo a veces | solo a veces |
| Cookie del píxel (fbp) | lo tiene siempre | lo tiene siempre | lo tiene siempre | lo tiene siempre |
| IP y navegador | lo tiene siempre | lo tiene siempre | lo tiene siempre | lo tiene siempre |
| Seguros | 2 | 2 | 3 | 4 |
- lo tiene siempre
- solo a veces: según haya sesión iniciada, llegue desde un anuncio o lo pida el formulario
- no lo tiene
Al ver una página tu servidor solo tiene asegurados 2 identificadores, la cookie del píxel y la IP con el navegador. En la compra tiene 4. De ahí sale dónde se pone el esfuerzo. Primero en los eventos por los que pujan tus campañas: si optimizas a compra o a lead, la nota de esos dos es la que decide de qué aprende el algoritmo, en la fase de aprendizaje y después. Subir la nota de “ver página” está bien; subir la de la compra es lo que mueve el dinero.
Segundo, en el fbc, que es el que más se pierde sin que nadie lo note. El identificador del clic llega pegado a la URL cuando alguien entra desde un anuncio. Si tu web no lo guarda en ese momento, tres páginas después ya no está, y el servidor manda la compra sin la pista que mejor la ataba a la campaña.
Queda elegir cómo se monta, y hay tres vías. La integración de tu plataforma de tienda o de tu CRM, si la tiene: la más rápida y la que menos controlas. La pasarela que ofrece la propia Meta, alojada en tu nube. O una propia, desde tu backend o desde un contenedor de servidor de Google Tag Manager. Se elige con una sola pregunta: quién va a saber arreglarla el día que cambies el checkout. Si tu paid media depende de Meta, esa persona tiene que existir antes de montarla, no después.
Cuatro formas de enviarlo todo y que no cuente.
Dos identificadores para una compra
El píxel genera un id aleatorio y el servidor usa el número de pedido, o uno manda Purchase y el otro un nombre propio. Meta no ve dos copias, ve dos compras. El panel se infla y la discrepancia con tu facturación crece justo cuando creías estar cerrándola.
Cifrar sin normalizar
Meta compara huellas SHA-256, y la huella de un email con una mayúscula o un espacio al final no se parece en nada a la del mismo email bien escrito. Primero se normaliza —minúsculas, sin espacios, el teléfono con prefijo de país y sin símbolos— y después se cifra. Y fbp, fbc, IP y navegador van sin cifrar: cifrarlos también los rompe.
Apagar el píxel el día que se enciende la API
La cookie fbp la pone el píxel en el navegador. Sin píxel, tu servidor pierde uno de los dos identificadores que tenía asegurados en cada evento, y las compras que la API recupera llegan peor emparejadas. Las dos vías a la vez son el diseño, no una fase de transición.
Mandarlo en lote, tarde
Un proceso nocturno o semanal que vuelca las compras de golpe. Meta rechaza los eventos de web con más de siete días de antigüedad, y los que entran a tiempo llegan tarde para que la campaña ajuste la puja con ellos. Se envía en el momento de la compra, o lo más cerca posible.
Lo que se pregunta sobre api de conversiones.
¿Qué es la API de conversiones de Meta?
Es la forma en que Meta acepta eventos de conversión enviados desde tu servidor en vez de desde el navegador del comprador. Cada evento lleva qué ha pasado (nombre, momento, importe y moneda), quién ha sido (email, teléfono e id de cliente cifrados, más la cookie del píxel, el identificador del clic, la IP y el navegador) y un identificador de evento para reconocer la copia que manda el píxel.
¿La API de conversiones sustituye al píxel de Meta?
No. Meta recomienda usar las dos vías a la vez: el píxel recoge lo que solo sabe el navegador, como su cookie, y la API recoge lo que el navegador pierde por bloqueadores o pestañas cerradas. Apagar el píxel el día que se enciende la API deja a tu servidor sin uno de los identificadores que tenía asegurados en cada evento.
¿Cómo evita Meta contar dos veces la misma compra?
Deduplicando: si un evento del píxel y otro de la API llegan con el mismo nombre de evento y el mismo identificador de evento, con menos de 48 horas de diferencia, Meta se queda con uno. El identificador tiene que nacer en un solo sitio, normalmente el número de pedido. Si cada vía genera el suyo, Meta cuenta dos compras y el ROAS del panel se infla.
¿Qué es la calidad de la coincidencia de eventos?
Es la nota de 0 a 10 con la que Meta puntúa, evento por evento, lo bien que consigue casar los eventos que le mandas con personas concretas. Sube con los identificadores que acompañan al evento y con lo bien formados que llegan: email y teléfono normalizados antes de cifrar, el identificador del clic guardado al entrar y la cookie del píxel. Importa sobre todo en los eventos por los que pujan tus campañas.
Los que hacen falta para usar este.
Saber de dónde viene cada venta y poder demostrarlo cuando alguien lo discuta.
Enviar las conversiones desde tu servidor y no desde el navegador del usuario. Recupera parte de lo que bloquean navegadores y extensiones.
Saber de dónde viene cada venta. Sin esto, cualquier decisión de inversión es el cuento de la vieja.
El tráfico por el que pagas de forma directa. Su precio lo fija una subasta contra tu competencia, así que se encarece solo cuando lo usas más.
Los datos que tienes porque te los dio tu cliente. El único activo de medición que no depende de una plataforma ajena.
Lo que el usuario te deja medir. Hoy decide qué porcentaje de tus datos existe, y ningún arreglo técnico se lo salta.
Meta dice 40, Analytics dice 35 y tu facturación dice 52. Por qué pasa siempre y a cuál se le hace caso.
