Cómo configurar el píxel de Facebook con Stripe

Stripe es la excepción del grupo de artículos de píxel, por una razón estructural: no es plataforma de tienda, es procesador de pago. No existe un campo para el identificador del píxel, y su Checkout alojado no ejecuta scripts de terceros.

Eso no es una limitación a rodear con un truco. Es una decisión de arquitectura — la página donde se escribe la tarjeta no corre código externo, y eso es bueno para todos. Lo que cambia es de dónde sale tu evento de compra.

Los dos caminos posibles

Página de retorno. Después del pago, Stripe redirige a una URL tuya de éxito. Disparas el evento de compra ahí, con el píxel que ya está en tu sitio.

Webhook en el servidor. Stripe avisa a tu servidor que el pago se completó. Tu servidor envía la compra a Meta por la API de conversiones, sin depender del navegador.

Los dos funcionan. No miden lo mismo, y la diferencia es grande como para decidir por ella.

Por qué la página de retorno pierde ventas

La redirección depende de que la persona vuelva. Tres situaciones comunes en que no vuelve:

• Cierra la pestaña apenas ve la confirmación de Stripe.
• Paga por un método diferido, donde la aprobación llega minutos o días después, fuera de esa sesión.
• Pierde la conexión a mitad de la redirección.

En todas, el dinero entró y Meta no se enteró. El efecto en el reporte es siempre el mismo: la plataforma muestra menos ventas de las que registró Stripe, y la campaña parece peor de lo que es. Quien decide presupuesto con ese número corta una campaña rentable.

Por qué el webhook es el camino correcto

El webhook no depende del navegador de nadie. Stripe avisa a tu servidor cuando el pago se completa, el servidor envía el evento, y el registro ocurre sin importar qué hizo la persona después.

Eso resuelve las tres pérdidas de la sección anterior de una vez. Resuelve también el caso de pago asíncrono: la compra se registra cuando el dinero cae, que es cuando existe de verdad.

El costo es que exige desarrollo — alguien tiene que escribir el código que escucha el webhook y llama a la API. No es trabajo grande, pero no es configuración de panel. El funcionamiento de la API está en API de conversiones de Meta.

El diseño que la mayoría debería usar

En la práctica, el arreglo más robusto usa los dos:

1. Píxel en el sitio, midiendo visita, vista de producto e inicio de checkout. Eso ya lo tienes.
2. Webhook en el servidor, disparando la compra por la API de conversiones.
3. Un identificador de evento común entre las dos fuentes, para que Meta descarte el duplicado.

El punto 3 es lo que evita el problema de la sección siguiente. Sin él, los dos caminos encendidos a la vez cuentan la venta dos veces.

El error que duplica la venta

Encender la página de retorno y el webhook sin identificador común. El síntoma es exactamente el doble de las ventas reales, con un ROAS excelente y una cuenta bancaria que no coincide.

La corrección no es apagar uno de los dos: es enviar el mismo identificador de evento por ambos caminos, para que Meta reconozca que es la misma compra llegando por dos puertas. Ese es justamente el problema que la deduplicación existe para resolver.

Si no tienes cómo generar ese identificador, elige un camino solo — y elige el webhook.

El valor y la moneda

Dos parámetros que suelen faltar en instalaciones hechas por servidor, y que cambian el reporte entero:

Valor. Sin él, un pago de 50 y uno de 2,000 cuentan igual. El algoritmo optimiza volumen de eventos en lugar de ingreso.

Moneda. Stripe procesa en varias monedas. Si el evento llega sin la moneda declarada, o con la equivocada, Meta suma valores de magnitudes distintas y el ROAS queda sin sentido.

Revisa los dos en el Administrador de eventos, dentro del evento de compra, antes de confiar en cualquier número de retorno.

Suscripciones: el caso que casi todos hacen mal

Si vendes recurrencia por Stripe, hay una decisión que tomar antes de enviar el primer evento, y cambia el significado de todo el reporte.

Enviar solo el primer cobro como compra. Meta pasa a optimizar para adquisición de cliente nuevo, que es casi siempre lo que quieres del anuncio. Las renovaciones no entran como conversión.

Enviar todos los cobros. El número de conversiones se infla mes a mes sin ninguna venta nueva, el costo por resultado baja artificialmente, y la optimización empieza a perseguir un evento que el anuncio no causó.

La segunda es la que ocurre por accidente, porque el webhook de pago completado dispara en cada renovación. Quien no filtra termina con un reporte que mejora solo todos los meses — y presupuesto creciendo sobre un número falso.

El filtro es simple en el código: tratar como compra solo cuando sea el primer cobro de ese cliente. Si quieres medir renovación, usa un evento personalizado con otro nombre, fuera de la optimización.

Cómo confirmar que quedó bien

1. Administrador de eventos, actividad reciente del píxel.
2. Haz un pago de prueba en el modo de prueba de Stripe.
3. Confirma el evento de compra llegando, con valor y moneda.
4. Cierra la pestaña antes de la redirección y haz otro pago de prueba. Si la compra igual aparece, el webhook funciona.
5. Compara el total del mes entre el panel de Stripe y el Administrador de eventos.

El paso 4 es la única prueba que distingue los dos caminos, y es la que casi nadie hace.

Por qué los números nunca coinciden exactamente

El panel de Stripe cuenta cobros; Meta cuenta conversiones atribuidas a anuncio dentro de una ventana. Suscripción recurrente, venta orgánica y cobro fuera de la ventana existen en el primero y no en el segundo.

Una diferencia de 10% a 20% es normal. Una de 90% es instalación rota. El plazo que crea parte de la diferencia está en ventana de atribución.

Antes de escalar

Con la compra llegando por el servidor, con valor y moneda, acumula volumen suficiente para leer resultado antes de subir presupuesto. El criterio está en cuándo escalar una campaña, y el seguimiento semanal, en el reporte de tráfico pago.