Postback y seguimiento server-to-server (S2S)

Si compras tráfico y tus conversiones no cuadran con lo que reporta tu red, el culpable casi siempre es el seguimiento — y en 2026 la solución es el seguimiento por postback server-to-server (S2S), no los píxeles.

Un postback es simple en concepto: cuando alguien hace clic, tu tracker marca ese clic con un ID único y lo arrastra hasta la oferta; cuando el usuario convierte, el servidor de la red llama a una URL que le diste y te devuelve ese mismo ID, de modo que la conversión aterriza sobre el clic exacto que la produjo. Sin cookies, sin navegador, sin JavaScript que un bloqueador de anuncios pueda eliminar. Si los fundamentos del seguimiento te son nuevos, empieza por el seguimiento en afiliación, explicado, y ten a mano el glosario de seguimiento para cualquier término que se te atragante.

El bucle del postback: cómo funciona de verdad el seguimiento S2S

Cuando un usuario hace clic en tu anuncio, el tracker genera un click ID: una cadena alfanumérica aleatoria que identifica de forma única ese clic y lo vincula a una campaña y a una oferta. El tracker añade ese ID a la URL saliente de la oferta mediante un token o macro, así que el ID viaja con el usuario hasta la página del anunciante. Es clave entender que el tracker no guarda memoria del clic una vez el usuario se marcha, así que el sistema receptor debe persistir el ID — en un campo de formulario oculto, una cookie de origen o una base de datos — hasta la conversión. Cuando el usuario convierte, el servidor de la red dispara una petición HTTP a tu URL de postback, sustituyendo de vuelta el click ID almacenado; tu tracker lo lee, lo empareja con el clic original y acredita la conversión con su payout y su estado. Como esa llamada final es server-to-server, nunca hay un navegador, una cookie ni un bloqueador de anuncios en el camino.

Click ID, URL de postback y macros: las tres piezas móviles

El click ID (también llamado subid, cid o tid) es el único valor obligatorio — el hilo que sobrevive a todo el funnel; piérdelo y nada más importa. La URL de postback es un endpoint de servidor tuyo al que la red llama al producirse la conversión; transporta los datos puramente en parámetros de query-string, no en cookies. Las macros (tokens) son marcadores como {clickid}, {payout} o {status} que se sustituyen por valores reales en el instante en que se dispara el postback. El trabajo de montaje es casi por completo un ejercicio de emparejar nombres: tu tracker espera un parámetro con un nombre fijo, y tú asignas a su valor la macro propia de la red para el ID que ella almacenó. Cada plataforma los nombra de forma distinta, y por eso exactamente se rompen los postbacks.

Postback vs píxel: por qué gana el S2S

Un píxel (una imagen de 1×1 o un snippet de JS en la página de conversión) se dispara en el navegador del usuario y se apoya en cookies. Es trivial de instalar y captura datos ricos del lado del navegador que alimentan el retargeting, pero pierde conversiones en silencio por culpa de bloqueadores de anuncios, errores de JavaScript y caducidad de cookies. Un postback se dispara desde el servidor de la red, así que es inmune a las tres cosas, funciona para apps móviles y recorridos entre dispositivos donde las cookies no pueden seguir al usuario, y es más difícil de defraudar porque se ata a un evento confirmado en el backend. La contrapartida es el coste de montaje: el S2S exige generar, almacenar y pasar el click ID por el funnel. La comparación de abajo los pone lado a lado.

Dimensión	Píxel	Postback (S2S)
Se dispara desde	El navegador del usuario	El servidor de la red
Depende de cookies	Sí	No
Sobrevive a los bloqueadores de anuncios	No	Sí
Entre dispositivos y en app	Poco fiable	Funciona
Esfuerzo de montaje	Bajo — pegar un snippet	Mayor — pasar un click ID
Mejor rol	Retargeting y datos de comportamiento	Fuente de verdad para el payout

El consenso en 2026 es híbrido: el S2S como fuente de verdad para la conversión confirmada, y píxeles superpuestos para retargeting y señal de comportamiento. A qué punto de contacto se acredita esa conversión confirmada es otra cuestión, decidida por tu modelo de atribución.

Montaje práctico: la URL y dónde va

Una URL de postback genérica no es más que un endpoint más parámetros de query — uno obligatorio (el click ID) y el resto opcionales:

https://your-tracker.com/postback?clickid={click_id}&payout={payout}&status={status}&txid={transaction_id}

Sustituye cada marcador por la macro que la red usa para ese valor y luego pega la URL terminada en el panel de la red de afiliación: la red es quien la dispara. Existe un segundo postback, distinto, que va del tracker a la fuente de tráfico, para que la plataforma publicitaria se entere de la conversión y pueda optimizar; ese se pega dentro de la plantilla de fuente de tráfico de tu tracker y devuelve el click ID propio de la fuente de tráfico. Confundir estos dos es el error de montaje más común. Testea pegando la URL completa con un click ID real (capturado de un clic de prueba auténtico, no uno inventado) en un navegador y confirmando que aparece una conversión. Deduplica pasando un ID único de transacción o pedido para que los upsells y las recargas no cuenten doble.

Fallos comunes y cómo depurarlos

Cinco fallos se comen la mayoría de los tickets de "conversión perdida". Primero, llega una macro literal: el log muestra clickid={clickid} en lugar de un valor real, lo que significa que usaste una macro que la red no reconoce; copia la macro exacta de la documentación de esa red. Segundo, un desajuste de click ID: envías el ID en un campo pero la red lo devuelve en otro, así que nada cuadra. Tercero, el subid se pierde en una redirección: un rotador de landings o un redirect por JS elimina el parámetro; traza un clic manual con un valor de prueba conocido y confirma que sobrevive a cada salto. Cuarto, doble disparo: una recarga de la página de confirmación cuenta dos veces; deduplica con un ID de pedido único. Quinto, el postback se dispara pero no se registra nada: falta un parámetro obligatorio, la IP no está en la whitelist o el ID no coincide con ningún clic almacenado. El log de postbacks es siempre tu primera parada: un log vacío significa que la red no está enviando nada, mientras que "click ID no encontrado" significa que hay un desajuste. Lanzar campañas de pago antes de tener esto blindado es uno de los clásicos errores de principiante, porque te permite escalar una campaña que solo crees que es rentable.

El panorama de privacidad de 2026: por qué el server-side es ahora lo estándar

El seguimiento del lado del cliente es estructuralmente deficitario hoy, y quien lo provoca es la política de los navegadores, no tu configuración. La ITP de Safari bloquea de plano todas las cookies de terceros y limita a 7 días las cookies de origen creadas por JavaScript, lo que rompe en silencio cualquier ventana de atribución superior a una semana. Firefox activó la Protección Total de Cookies para todos los usuarios por defecto, aislando las cookies de cada sitio. Chrome es el matiz: tras anunciar la eliminación de las cookies de terceros y retrasarla durante años, Google dio marcha atrás — así que las cookies de terceros siguen existiendo y están activadas por defecto en Chrome a fecha de 2026, pero Chrome es ahora el único navegador importante donde eso es cierto. La conclusión práctica: no cuentes con las cookies, porque una gran parte de tu tráfico (usuarios de Safari, de Firefox y de bloqueadores de anuncios) ya es cookieless, independientemente de Chrome. El seguimiento S2S del lado del servidor esquiva todo el lío: nunca lee ni escribe una cookie de terceros. Por eso el S2S es el estándar duradero y los píxeles son el añadido opcional. Para ver cómo esto reconfigura la asignación de crédito, consulta modelos de atribución; para la foto completa de medición, consulta analítica para principiantes.

FAQ

¿Cuál es la diferencia entre un click ID y un subid?

Son el mismo concepto con nombres distintos. "Click ID" es el término genérico para la cadena única que identifica un clic; "subid" (sub1, sub2…) es como muchas redes y fuentes de tráfico llaman a los campos de parámetro que usan para transportar ese ID. Tu trabajo es asegurarte de que el ID que envías vuelve en el campo que tu tracker lee.

La red disparó el postback pero la conversión no está en mi tracker. ¿Por qué?

Revisa primero tu log de postbacks. Un log vacío significa que la red no envió nada (URL equivocada o no configurada de su lado). Un error de "click ID no encontrado" significa que el ID que volvió no coincide con ningún clic almacenado, normalmente porque el subid se perdió en una redirección o se envió una macro literal en lugar de un valor real. Un parámetro obligatorio ausente también puede provocar una pérdida silenciosa.

¿Sigo necesitando un píxel si tengo el S2S montado?

Solo si quieres lo que el S2S no puede darte: audiencias de retargeting y datos de comportamiento on-page en tiempo real. Para el recuento de conversiones y el payout que paga tus facturas, el S2S es la fuente de verdad fiable. La mayoría de operadores usan S2S como principal y añaden un píxel para retargeting.

¿Cómo evito que los upsells y las recargas cuenten como duplicados?

Pasa un ID único de transacción o de pedido con cada postback. El tracker lo usa para reconocer repeticiones — ignorando los duplicados exactos o registrando transacciones distintas — en lugar de sobrescribir o contar dos veces.

Sigue leyendo