Tracking de conversiones en pago contra reembolso y checkouts externos

El tracking de conversiones en pago contra reembolso consiste en enviar cada compra a tus plataformas publicitarias desde el propio pedido, en el servidor, en lugar de depender de un píxel del navegador en una página de agradecimiento. Los pedidos de apps de pago contra reembolso, checkouts externos, formularios de pedido y embudos suelen terminar fuera del checkout normal, así que el píxel no los detecta o los informa en el momento equivocado.

Esta guía explica por qué esos pedidos se pierden y por qué importa el estado del pago. Compara tres momentos para enviar la compra: cuando se crea el pedido, cuando se confirma y cuando se paga. También cubre los pedidos rechazados y los reembolsos, y cómo gestiona ROASaurus los checkouts externos.

¿Por qué los píxeles no detectan los pedidos en pago contra reembolso?

Un píxel del navegador informa de una compra cuando el comprador llega a una página que lo ejecuta. Normalmente es la página de agradecimiento de tu checkout. Todo recorrido de pedido que se salte esa página, o que la ejecute en otro dominio, pierde el evento de compra o el clic del anuncio que le corresponde.

El pedido en sí nunca se pierde. Acaba en tu tienda online o en tu herramienta de embudos con un id de pedido, un importe, una dirección de email y a menudo un número de teléfono. Por eso la solución fiable es enviar la compra a partir de los datos del pedido, desde el servidor, y llevar el clic del anuncio hasta el pedido. Server-side tracking en Shopify explica el método general. Esta entrada trata los pedidos que necesitan un cuidado extra.

Algunas apps de pago contra reembolso también disparan sus propios eventos de píxel. Si usan el mismo píxel que tu server-side tracking pero un id de evento distinto, la plataforma cuenta el pedido dos veces. Desactiva esos eventos de la app o sigue los pasos para evitar el doble conteo.

Por qué importa el estado del pago

Un pago con tarjeta se captura en el checkout, así que el pedido está pagado en cuanto existe. Un pedido en pago contra reembolso es diferente. Shopify incluye el pago contra reembolso como método de pago manual, y estos pedidos se quedan en Payment pending hasta que los marcas como pagados. En la práctica eso ocurre después de que el mensajero cobre el dinero, lo que puede tardar días. Algunos pedidos no se pagan nunca, porque el comprador rechaza el paquete o no está en casa.

Muchas configuraciones de tracking envían la compra cuando se paga el pedido, porque para los pedidos con tarjeta ese es el momento más seguro. En un pedido en pago contra reembolso, la misma regla significa que la compra llega con días de retraso o nunca. El registro de abajo muestra un caso típico en una tienda que envía las compras al pagarse.

WooCommerce funciona al revés. Pone los pedidos en pago contra reembolso en Processing hasta que se cobra el pago, salvo los pedidos con un producto descargable, que pasan a On hold. Por tanto, una configuración que envía los pedidos en Processing los envía en cuanto se realizan. Comprueba qué estado da tu plataforma a estos pedidos antes de decidir nada más.

Creado, confirmado o pagado: ¿cuándo conviene enviar la compra?

Hay tres momentos entre los que elegir. Cada uno intercambia velocidad por precisión.

Por qué son un problema los eventos de compra tardíos

Las plataformas publicitarias atribuyen una compra a un anuncio solo cuando ocurre dentro de la ventana de atribución posterior al clic. Con una atribución de clic de 7 días en Meta, una compra cuenta para un anuncio hasta 7 días después del clic. La Conversions API de Meta también rechaza los eventos cuyo event_time tiene más de 7 días de antigüedad, y rechaza toda la solicitud cuando un evento es demasiado antiguo. Por eso, una compra que se envía al pagarse tiene dos malas opciones:

• Enviarla con la hora del pedido. Si el pago llegó más de 7 días después, Meta la rechaza.
• Enviarla con la hora del pago. Meta la acepta, pero el clic del anuncio puede tener ya más de 7 días, así que la compra no se atribuye al anuncio.

La velocidad también importa para la optimización. Las campañas que optimizan para compras aprenden de las compras que envías. Una señal que llega con una semana de retraso informa al algoritmo sobre la audiencia de la semana pasada.

Qué momento elegir

En la mayoría de las tiendas con pago contra reembolso, enviar al crear el pedido es la mejor opción por defecto. La señal es inmediata, el clic sigue dentro de la ventana y no se rechaza nada. El coste es que los pedidos rechazados cuentan como compras en Ads Manager. Lo corriges en tus objetivos, como muestra la siguiente sección.

Si tu equipo confirma cada pedido por teléfono o mensaje antes de enviarlo, la confirmación es un buen término medio. Elimina los pedidos falsos y suele ocurrir en un día. Úsala cuando tu propio sistema pueda enviar la compra en ese momento, por ejemplo mediante una API. Los pedidos falsos importan más de lo que parece: si la plataforma publicitaria aprende de ellos, busca más personas que hacen pedidos y no los pagan.

Cómo gestionar pedidos rechazados, cancelaciones y reembolsos

Una vez enviada una compra, se queda en Ads Manager. Un paquete rechazado en la puerta no la elimina. ROASaurus tampoco envía reembolsos ni cancelaciones a Meta, TikTok y la mayoría de las demás plataformas publicitarias, así que los ingresos que muestran incluyen pedidos que nunca cobraste. Solo los valores de Google Ads y Microsoft Advertising se pueden corregir tras un reembolso, cuando las correcciones de valor están activadas. La solución es medir tu tasa de rechazo y ajustar las cifras con las que comparas.

Aquí tienes un ejemplo resuelto para un mes. Para simplificar, los precios son sin IVA.

Con $3,000 de gasto publicitario, el mismo mes se ve muy distinto según los ingresos que uses:

La tasa de margen bruto de los ingresos entregados es $3,878 ÷ $8,200 = 47.3%, así que el ROAS de equilibrio es 1 ÷ 0.473 = 2.11. Ese equilibrio se aplica a los ingresos entregados. Ads Manager también cuenta los pedidos rechazados, así que tienes que convertirlo antes de comparar. ROAS de equilibrio explica la fórmula base.

Puedes comprobar el resultado directamente. Los anuncios alcanzan el equilibrio cuando el gasto publicitario es igual al beneficio bruto de $3,878, y $10,000 de ingresos informados ÷ $3,878 = 2.58.

Las tasas de rechazo suelen variar según la región, el producto y la campaña. Calcúlalas por campaña cuando tengas suficientes pedidos y usa la calculadora de POAS para comprobar el resultado sobre el beneficio bruto.

Reembolsos y cancelaciones en tus propias cifras

En Shopify, las cancelaciones y los reembolsos llegan a ROASaurus por webhook, así que el análisis de beneficios descuenta los reembolsos de los ingresos. Tú eliges si cuentan los pedidos cancelados que nunca se enviaron, y por defecto se excluyen. Un pedido cancelado que ya se había enviado sigue contando, porque su envío te costó dinero igualmente. Para los pedidos recientes que aún pueden devolverse, el ajuste Predicted returns retiene una proporción esperada de las ventas hasta que llegan los reembolsos reales.

Cómo gestiona ROASaurus el pago contra reembolso y los checkouts externos

Shopify

Cada tienda de Shopify tiene un Checkout type en Store settings, con dos opciones:

• Shopify checkout: la compra se envía cuando Shopify informa del pedido como pagado, mediante el webhook orders/paid.
• External / COD checkout: la compra se envía cuando se crea el pedido, mediante el webhook orders/create. Úsalo para el pago contra reembolso y para checkouts externos, como CheckoutChamp o Checkify, que crean ellos mismos el pedido de Shopify.

El ajuste se aplica a todos los pedidos de la tienda. Los pedidos con tarjeta que se pagan en el checkout se crean y se pagan casi en el mismo momento, así que la elección cambia sobre todo cuándo se envían los pedidos sin pagar. Cada pedido se envía una sola vez. Cuando más tarde llega la actualización de pagado de un pedido en pago contra reembolso, no se envía una segunda compra.

La compra usa los datos propios del pedido: el importe, la moneda, los productos, y el email, el teléfono y la dirección del comprador, con hash antes de salir. ROASaurus vincula el pedido con el clic del anuncio mediante el id de visitante que su script guarda en el carrito. Cuando un pedido no lo lleva, ROASaurus prueba, por este orden: los tokens del carrito y del checkout, el evento de compra del checkout, un email que el visitante dio antes en tu sitio y la misma dirección IP y el mismo navegador poco antes del pedido, cuando encaja exactamente un visitante. La página de la integración con Shopify tiene toda la configuración.

WooCommerce y otras tiendas online

El plugin de WooCommerce envía un pedido cuando llega a Processing o Completed. Los pedidos en pago contra reembolso llegan a Processing cuando se realizan, así que se envían enseguida. Los pedidos por transferencia bancaria se envían cuando pasan a Processing. Los demás conectores de tiendas online envían un pedido en estos momentos:

• Wix, Squarespace, Ecwid, Lightspeed, CCV Shop y Shopware: cuando el estado de pago del pedido es pagado.
• BigCommerce: cuando el pedido llega a un estado como Awaiting Fulfillment, Awaiting Shipment, Shipped o Completed.
• Magento: cuando el estado del pedido es Processing o Complete.
• PrestaShop: cuando el pedido se marca como válido.
• Webhook personalizado y API de pedidos: cuando tu propio sistema envía el pedido.

Comprueba cómo marca tu plataforma los pedidos en pago contra reembolso. Si siguen sin pagarse hasta que el mensajero liquida, sus compras llegan tarde.

Embudos y tu propio checkout

1. Añade el script a las páginas del embudo

   Usa la misma clave de tienda que tu tienda online, para que un visitante conserve un único id de visitante en ambos dominios.

2. Indica tus dominios

   En Store settings, añade los dominios del embudo y de la tienda en Linked domains. Los enlaces entre esos dominios llevan entonces el id de visitante y los click ids.

3. Envía los pedidos a través de la API de pedidos

   Si el embudo toma el pedido él mismo, envía cada pedido a /api/v1/orders con la cookie _tl como visitor_id. Tu sistema decide el momento: al crear el pedido, al confirmarlo o al pagarlo.

4. Revisa el Event log

   Cuando lleguen los primeros pedidos reales, abre el Event log y comprueba que cada uno se envió a todas las plataformas conectadas.

POST /api/v1/orders
X-Roasaurus-Key: <store key>
Authorization: Bearer <API key>
Content-Type: application/json

{
  "order_id": "F-20931",
  "created_at": "2026-10-20T14:05:00Z",
  "total": 50.00,
  "currency": "USD",
  "email": "buyer@example.com",
  "phone": "+15555550123",
  "country": "US",
  "visitor_id": "<value of the _tl cookie>",
  "click_ids": { "fbc": "<_fbc cookie>", "fbp": "<_fbp cookie>" },
  "client_ip": "203.0.113.7",
  "user_agent": "Mozilla/5.0 ...",
  "items": [{ "variant_id": "SKU1", "quantity": 1, "price": 50.00 }]
}

La API de pedidos conserva la primera copia de cada id de pedido. Si tu sistema la llama al crear el pedido y otra vez al pagarlo, solo la primera llamada envía una compra. Hay más detalle en embudos y varios dominios.

Errores habituales que evitar

• Esperar al estado de pagado en una tienda con pago contra reembolso. Las compras llegan con una semana de retraso o no llegan, y los eventos tardíos se rechazan o quedan fuera de la ventana de atribución.
• Comparar el ROAS de Ads Manager con un equilibrio calculado para pedidos pagados. Divide antes el equilibrio entre tu tasa de pago.
• Dos fuentes para una misma compra. El píxel propio de una app de formularios y tus eventos del servidor cuentan el mismo pedido dos veces. Consulta eventos de compra duplicados.
• Perder el clic entre dominios. Un embudo en otro dominio necesita el script y los dominios vinculados, o sus pedidos llegan sin clic de anuncio.
• Dejar fuera los pedidos manuales. Los pedidos por teléfono y chat no tienen sesión de navegador, pero siguen teniendo una dirección de email o un número de teléfono. Enviados a partir de los datos del pedido, dan a la plataforma publicitaria algo con lo que vincularlos.

Fuentes

1. Meta for Developers: Server Event Parameters
2. Shopify: WebhookSubscriptionTopic (GraphQL Admin API)
3. Shopify Help Center: Manual payment methods
4. Shopify Help Center: Understanding your order statuses
5. WooCommerce: Cash on Delivery documentation

En ROASaurus

• Integración con Shopify
• Integración con WooCommerce
• Ayuda: embudos y varios dominios
• Análisis de beneficios en ROASaurus

Sigue leyendo