Postbacks S2S: el detalle que cuesta 18% de tu CPA

Soy Lucía. La última conversación que tuve con un cliente antes de salir de Mediasmart fue sobre postbacks. Llevaba ocho meses pagando un 18% más de CPA del que tocaba porque su S2S devolvía la conversión a la red 2,4 segundos después del clic original. Push tradicional pierde atribución por encima de 1,8 segundos. Esa cuenta nadie se la había hecho.

El postback servidor a servidor — S2S por su acrónimo industria — es la pieza más aburrida del stack de adtech y la que más dinero pierdes cuando está rota. No tiene UI bonita. No sale en el panel comercial. La red no te avisa cuando falla. Y cuando falla, lo que falla es tu atribución, no la cuenta de resultados de la red.

Qué hace exactamente un postback S2S

El flujo es lineal: clic en el anuncio → el tracker (Voluum, Binom, RedTrack, etc.) registra un ID único → conversión ocurre en tu LP o backend → tu sistema dispara una petición HTTP al tracker → el tracker reenvía la conversión a la red de origen con el ID que ella generó al servir el anuncio.

Suena simple. Tiene cinco puntos donde se rompe.

Los cinco fallos que veo en auditorías

Uno: latencia por encima del umbral del formato.

Popunder tolera hasta 3-4 segundos de latencia en el postback. La conversión se atribuye igual porque la red mantiene la sesión más tiempo. Push tradicional no — por encima de 1,8 segundos, el postback llega después de que la red haya descartado la atribución. La conversión se pierde para el optimizador y el algoritmo aprende que ese inventario no convierte. Optimiza fuera de él. Bajas el CPM y subes el CPA real.

En auditoría: la latencia que mido desde un tracker en Frankfurt a un postback a PropellerAds está, en promedio, entre 60 y 90ms. A Adsterra desde Madrid: 80-120ms. A RichAds: 110-180ms. Si tu medición sale por encima de 400ms, hay algo entre tu LP y el tracker — DNS lento, balanceador mal configurado, Cloudflare en geografía equivocada. Audita.

Dos: deduplicación rota.

El postback no debe disparar dos veces para la misma conversión. Si tu LP recarga la página de gracias por culpa del usuario, o si tu backend procesa la confirmación de depósito dos veces, la red recibe dos conversiones por una transacción. El algoritmo cree que ese inventario convierte el doble de lo real. Optimiza hacia él. Tres semanas después la red te ajusta retroactivamente, descuenta el duplicado y te cobra el delta de CPM porque optimizó “mal”. Eso ya lo vi en una campaña de iGaming en 2022. €11.400 de ajuste retroactivo.

Solución: hash de transacción único en el postback. La red descarta duplicados si tu tracker los marca correctamente.

Tres: parámetros que no se pasan o se pasan vacíos.

El postback estándar lleva al menos: click_id (o subid), payout, conversion_type. Si tu sistema dispara el postback con payout vacío, la red asume que la conversión vale cero. Optimiza hacia conversiones de mayor payout reportado, que en tu caso son las que se llenaron correctamente. El sesgo se acumula.

En Voluum esto se llama “macro replacement”. Hay que probarlo manualmente antes de meter dinero, no asumir que funciona porque la red dice “compatible con Voluum”.

Cuatro: postback que dispara antes de la conversión real.

Pasa con flujos donde “registro” se confunde con “depósito FTD”. El operador iGaming firma con la red por CPA-FTD pero su LP dispara el postback en el momento del signup, no del primer depósito. La red optimiza hacia signup. El operador paga CPA por signup creyendo que paga por FTD. Tres meses después audita. CPA real triplicado.

Esto no es maldad de la red. Es configuración rota del operador. Pero la red no la corrige porque cobra igual.

Cinco: GEO o vertical filtrado en el lado equivocado.

Si tu tracker filtra GEO antes del postback, la red recibe solo las conversiones del GEO objetivo y cree que su inventario convierte fenomenal en ese GEO. Si el filtro va después, la red optimiza usando datos que tú no usas. Decide tú dónde corre el filtro y mantenlo consistente. El error caro es cambiarlo mid-campaña sin avisar.

El chequeo de cinco minutos antes de aprobar campaña

Tres preguntas al equipo técnico antes de firmar:

1. ¿Cuál es la latencia media del postback medida los últimos 7 días? Por GEO. Si no la miden, la respuesta correcta no es “la red la mide por nosotros”.
2. ¿El hash de transacción es único por FTD, no por sesión? Demuéstrame con un caso de doble carga de la página de gracias.
3. ¿Qué payout pasamos? Real o nominal del rate-card? Si es nominal, el optimizador de la red sesga el inventario hacia bajo LTV. Demuéstrame con datos de campaña pasada.

Cinco minutos. Si el equipo técnico responde con “esto lo gestionamos con la red”, presupone que nadie lo gestiona.

El número que titula este post

El 18% no es teórico. Es la media que medí en 11 auditorías de iGaming DGOJ y nutra España entre 2022 y 2024. CPA pagado vs CPA óptimo si los cinco puntos anteriores estaban correctos. La distribución del 18%:

• 6% por latencia fuera de umbral.
• 5% por deduplicación rota o doble disparo.
• 4% por payout vacío o nominal.
• 2% por confusión signup/FTD.
• 1% por filtros GEO inconsistentes.

No siempre 18%. He visto auditorías al 3% y al 31%. La media cae ahí.

Adsterra paga mejor a publishers, PropellerAds escala mejor a buyers. No es la misma optimización. Las dos son legítimas. Pero las dos dependen de que tu postback funcione, y eso es responsabilidad tuya, no de ellas.

La regla es simple: si no auditas tu postback cada trimestre, no estás midiendo CPA. Estás midiendo el CPA que la red prefiere que veas.

Preguntas frecuentes

¿Qué es un postback S2S y por qué importa más que el píxel de la red?

Un postback S2S es una petición HTTP que tu sistema dispara al tracker —Voluum, Binom, RedTrack— cuando ocurre una conversión, llevando el ID único que la red generó al servir el anuncio. La diferencia con el píxel de la red: el píxel lo mide el vendedor con sus propios datos. El postback S2S te da tu propia atribución, auditable e independiente. Si estás midiendo CPA con el panel de la red sin tracker S2S propio, no mides CPA —mides la factura que la red prefiere que veas.

¿Por qué la latencia del postback cuesta el 18% del CPA en push?

Push tradicional pierde atribución por encima de 1,8 segundos de latencia entre conversión y llegada del postback a la red. La conversión entra en tu CRM pero no llega al optimizador de la red, que aprende que ese inventario no convierte y optimiza fuera de él. Bajas el CPM y subes el CPA real sin que nadie te lo señale. El 18% que titula este post es la media que medí en 11 auditorías de iGaming DGOJ y nutra España entre 2022 y 2024. No es teórico. Es lo que pierde el comprador que no audita la latencia.

¿Qué pasa si el postback dispara dos veces para la misma conversión?

La red recibe dos conversiones por una transacción real y optimiza hacia ese inventario creyendo que convierte el doble. Tres semanas después la red ajusta retroactivamente, descuenta el duplicado y te cobra el delta de CPM porque “optimizó mal”. En una campaña iGaming que audité en 2022, el ajuste retroactivo fue de €11.400. La solución es un hash de transacción único en el postback: la red descarta duplicados si tu tracker los marca correctamente. Si no lo compruebas manualmente antes de meter dinero, asume que el riesgo existe.

¿Cuál es la latencia de postback aceptable según el formato publicitario?

Popunder tolera hasta 3-4 segundos de latencia —la red mantiene la sesión más tiempo. Push tradicional no: por encima de 1,8 segundos el postback llega después de que la red haya descartado la atribución. Native aguanta hasta 3 segundos. La latencia que mido desde un tracker en Frankfurt: a PropellerAds entre 60 y 90ms, a Adsterra desde Madrid entre 80 y 120ms, a RichAds entre 110 y 180ms. Si tu medición sale por encima de 400ms, hay algo roto entre tu landing page y el tracker: DNS lento, balanceador mal configurado, Cloudflare en geografía equivocada.

¿Cómo se distribuye el 18% de CPA perdido entre los distintos fallos de postback?

Según la media de mis 11 auditorías: 6% por latencia fuera de umbral, 5% por deduplicación rota o doble disparo, 4% por payout vacío o nominal, 2% por confusión entre signup y FTD, 1% por filtros GEO inconsistentes. No siempre 18% —he visto auditorías al 3% y al 31%. Pero la media cae ahí. Adsterra paga mejor a publishers, PropellerAds escala mejor a buyers. Las dos dependen de que tu postback funcione, y eso es responsabilidad tuya, no de ellas.

¿Con qué frecuencia debo auditar el postback S2S de una campaña activa?

Cada trimestre como mínimo, con revisión exprés de tres preguntas antes de aprobar cualquier campaña nueva: ¿cuál es la latencia media del postback medida los últimos 7 días por GEO?, ¿el hash de transacción es único por FTD —no por sesión—?, y ¿qué payout pasan —real o nominal del rate card? Si el equipo técnico responde con “esto lo gestionamos con la red”, presupone que nadie lo gestiona. La regla es simple: si no auditas tu postback cada trimestre, no estás midiendo CPA.