Postbacks, píxeles y etiquetas de imagen: solo uno sirve para cobrar
Tres mecanismos para reportar una conversión, explicados para que los entienda alguien que no es ingeniero, más las seis formas en que las integraciones se rompen de verdad. Escrito para operadores y responsables de afiliación técnicos que han depurado esto a las once de la noche.
Una conversión se puede reportar de tres maneras: una etiqueta de imagen, un píxel de JavaScript o un postback servidor a servidor. Solo el postback aguanta lo bastante bien como para pagar comisiones contra él, porque no necesita que el navegador del jugador colabore. La mayoría de las integraciones que "no trackean" no son postbacks rotos: son identificadores de clic que faltan en el registro del jugador.
La llamada llega siempre a mala hora. Un gestor de afiliados tiene a un socio amenazando con cortar el tráfico, el operador jura que la integración está viva y el panel marca cero. Alguien manda una captura de una etiqueta en el pie de la página de depósito completado y pregunta por qué no funciona.
No funciona porque es una etiqueta en el pie de una página.
Reportar una conversión es un problema pequeño con muchas formas de hacerlo mal, y esas formas no han cambiado mucho en diez años. Lo que cambió es que dos de los tres mecanismos dejaron de ser fiables en silencio mientras todo el mundo seguía enviándolos igual. Este texto es el que hay que darle a su ingeniero antes de la integración, no después.
Tres formas de decir que un jugador ha depositado
La etiqueta de imagen. La más antigua. Su página incluye una imagen de un píxel cuya fuente es una URL de la plataforma de tracking. El navegador intenta cargar la imagen, esa petición llega a la plataforma, y la petición en sí es el mensaje. No hace falta ninguna imagen de verdad, la descarga es el objetivo. No requiere más que HTML, y por eso sobrevivió tanto tiempo en sistemas de plantillas donde nadie quería tocar JavaScript.
El píxel de JavaScript. La misma idea con un script en lugar de una imagen. Un fragmento se ejecuta en la página, recoge algo de contexto y lanza la llamada. Es más flexible: puede leer un valor que la página haya puesto en una variable, puede esperar a que se renderice una confirmación, puede pasar un importe de depósito que solo se conocía en tiempo de ejecución. También es más frágil, porque depende de que el script cargue, de que la variable exista y de que la página no haya lanzado un error más arriba.
El postback servidor a servidor. Sin navegador de por medio. Cuando su backend registra el evento que importa, hace una petición HTTP a una URL, llevando el identificador que le entregaron cuando el jugador llegó por primera vez. Su servicio de pagos confirma un depósito, su sistema escribe la transacción, y en ese mismo camino sale una petición que dice: este jugador, este evento, este importe, esta moneda.
Esa es toda la idea. Suena menos ingenioso que las otras dos, y esa es precisamente la razón de que aguante.
Por qué dos de los tres dejaron de ser fiables
No hay una única causa. Hay una pila de ellas, y cada una por separado sería llevadera.
Safari y Firefox bloquean las cookies de terceros por defecto, y Firefox bloquea además las peticiones a dominios de su lista de rastreadores. Chrome todavía permite cookies de terceros, así que en Chrome el bloqueo viene del bloqueador de anuncios y no del navegador. Safari limita encima cuánto sobrevive el almacenamiento escrito por script, en algunos casos hasta unos pocos días, lo que significa que cualquier cosa que dependa de un estado escrito en el momento del clic y leído en el momento del depósito tiene una caducidad medida en una fracción de una ventana de decisión normal. Los bloqueadores de anuncios se sientan encima de todo eso y son habituales justo en las audiencias que leen contenido comparativo antes de registrarse. Nada de esto se anuncia. Su operador ve que la página se renderiza bien y concluye que la integración funciona.
Y luego está la parte que no arregla ningún ajuste del navegador. Un jugador hace clic en un ordenador de escritorio en el trabajo, se lo piensa, y esa noche deposita desde el móvil. O se registra en la web y deposita dentro de la app nativa, donde no hay navegador, ni página, ni etiqueta que disparar. En apuestas deportivas sobre todo, el depósito sigue al calendario de partidos y no al clic, y lo sigue hasta dentro de la app. Si quiere ver hasta qué punto se comportan distinto esos dos recorridos, el tráfico de casino y el de apuestas deportivas divergen exactamente en este punto.
Un píxel no puede dispararse desde un sitio que el navegador nunca visita. Nada de eso se arregla colocando mejor la etiqueta.
| Lo que le importa | Etiqueta de imagen | Píxel de JavaScript | Postback servidor a servidor |
|---|---|---|---|
| Se dispara desde | El navegador del jugador | El navegador del jugador | Su propio backend |
| Sobrevive a los bloqueadores de anuncios | Rara vez | Rara vez | Sí, no interviene |
| Sobrevive al cambio de dispositivo | No | No | Sí |
| Sobrevive a un depósito dentro de la app | No | No | Sí |
| Puede leer el estado de la página en ejecución | No | Sí | No aplica |
| Reporta un importe liquidado | Solo lo que sabe la página | Solo lo que sabe la página | Sí, desde el sistema de registro |
| Cuándo usarlo | Sistemas heredados que no puede cambiar | Una señal dentro de la misma sesión, como secundaria | Cualquier cosa que decida dinero |
Los modos de fallo que conviene conocer
Nadie rompe una integración de una forma interesante. Los mismos seis errores explican casi todo.
Disparar al cargar la página en lugar de al producirse el evento. La etiqueta vive en la página de confirmación de depósito, así que se dispara cada vez que se abre esa página. Un jugador recarga, vuelve por el historial o aterriza ahí después de un intento fallido, y cada una de esas veces es una conversión en sus informes. Esto infla los números en la dirección que queda bien, y por eso sobrevive tanto antes de que alguien lo cuestione.
¿Es realmente del lado del servidor? Un framework de backend renderizando una plantilla sigue emitiendo una etiqueta que el navegador tiene que ejecutar. Si la petición se origina en el dispositivo del jugador, es del lado del navegador, esté escrita en el archivo que esté. La prueba lleva un minuto: bloquee los scripts en su propio navegador y compruebe si el evento sigue llegando.
Y luego está el identificador de clic que falta en el registro del jugador. Este es con diferencia el fallo más común y tiene su propia sección más abajo.
El depósito se reporta antes de liquidarse. El pago se autoriza, sale el postback, y después el pago falla o se revierte. Ahora hay una comisión atada a un dinero que nunca llegó. Dispare sobre el estado que reconocería su equipo financiero, no sobre el estado que muestra su página de pago.
La idempotencia, o su ausencia. Las redes dan timeout. Un emisor bien construido reintenta, y eso es correcto. Si el lado receptor no puede saber que el segundo intento es el mismo evento que el primero, el reintento se convierte en una segunda conversión. Cada evento necesita una referencia única y estable por su parte, el mismo valor en cada reintento, para que un duplicado se reconozca y se descarte en lugar de pagarse dos veces.
Los eventos también llegan desordenados. Un depósito aterriza antes del registro al que pertenece, porque dos servicios dispararon de forma independiente y uno fue más rápido. Ordene los eventos que dependen unos de otros, o haga que cada uno lleve contexto suficiente para sostenerse solo.
Lo único que lo decide todo
Todos los fallos de arriba se reparan en una tarde. Este no.
Cuando un jugador llega a través de un enlace de tracking, el identificador de ese enlace tiene que guardarse en el registro del jugador en el momento del alta. No en una sesión. No en una cookie. En la fila de su base de datos que representa esa cuenta, junto a la dirección de correo, en la misma transacción que la crea.
Si eso no ocurre, nada de lo que venga después se puede atribuir. El jugador deposita tres semanas más tarde, su backend dispara un postback técnicamente perfecto, y no lleva ningún identificador, porque no hay nada que llevar. Ninguna cantidad de ajuste del postback lo arregla. No está depurando un problema de reporting, está depurando un problema de registro, y el arreglo está en el flujo de alta.
Dos hábitos relacionados ahorran muchas discusiones. Conserve el identificador aunque el valor parezca raro, porque está guardando un token, no validándolo. Y consérvelo durante toda la vida de la cuenta y no durante treinta días, porque un CPA que paga sobre un depósito cualificado necesita que el vínculo siga existiendo en el momento en que el depósito cualifica, que puede ser meses después del clic. Si el vocabulario alrededor de los depósitos cualificados y los primeros depósitos está borroso de su lado, el glosario de FTD, NGR, CPA, CPL y CPR merece diez minutos antes de escribir el esquema.
Probarlo antes de que corra el tráfico
Una prueba de integración correcta es aburrida y lleva alrededor de una hora.
- Haga clic en un enlace de tracking real y complete el registro como lo haría un jugador normal. Después mire el registro del jugador en su propia base de datos y confirme que el identificador está ahí. Si no está, pare, porque todo lo que venga después es teatro.
- Deposite dinero real. Una cantidad pequeña vale, EUR 20 sirve. Los pagos en modo de prueba se saltan con frecuencia justo la ruta de código que dispara el evento, y así es como las integraciones pasan en staging y fallan el primer día.
- Compruebe que el evento de depósito llegó una vez, con el importe y la moneda correctos, después de que el pago se liquidara y no cuando se envió.
- Mande el mismo evento otra vez a propósito. Debería reconocerse como duplicado y no contarse dos veces.
- Repita todo desde un teléfono, y una vez más con el depósito hecho en la app en lugar de en el navegador, si tiene app.
Una hora del tiempo de un ingeniero y un depósito, frente a un mes de conciliación con un afiliado que ya está convencido de que le están recortando el tráfico. El repaso de QA de un enlace de tracking cubre el lado del afiliado de la misma prueba, y correr los dos extremos a la vez es como se encuentra el desajuste en una tarde en lugar de en un trimestre.
Lo que AFFILIFY espera de un operador
La referencia de integración vive en affilify.partners/docs, con el endpoint, los nombres de los parámetros y los tipos de evento aceptados. Léala ahí y no en una entrada de blog, porque esa página es la que mantenemos al día.
La forma es pequeña. Un nombre de evento, el identificador que le entregaron en el momento del clic, un importe y una moneda, más su clave. El registro, el primer depósito, los depósitos siguientes y los eventos de ingresos son mensajes separados, porque el modelo de comisión asociado a un acuerdo decide cuáles importan, y un programa no puede pagar RevShare sobre datos que nunca recibió. Si todavía está eligiendo entre modelos, CPA, RevShare e híbrido expone lo que necesita cada uno de su lado.
Dos cosas que conviene decir con claridad. La atribución de nuestro lado tiene mecanismos de respaldo en capas. Son un seguro, no un plan. El identificador guardado en el momento del alta es la parte que usted controla, así que envíelo. Y la calidad del tráfico se evalúa de forma continua, lo que significa que algunas conversiones quedan retenidas mientras se comprueban en lugar de acreditarse al llegar. Eso no es un rechazo, y el afiliado ve el estado en lugar de un hueco silencioso.
Un operador que devuelve el identificador, reporta los eventos liquidados una sola vez y se puede probar con un depósito real en una hora nunca tendrá la conversación de las once de la noche. Esa es toda la ambición aquí.
Preguntas frecuentes
¿Cuál es la diferencia entre un postback y un píxel?
Un píxel lo dispara el navegador del jugador mientras hay una página abierta. Un postback lo dispara su propio backend cuando se registra el evento, sin navegador de por medio. Esa única diferencia lo decide todo lo demás: al postback no le afectan los bloqueadores de anuncios ni la política de cookies del navegador, sigue funcionando cuando el jugador se registra en un portátil y deposita desde el móvil, y funciona cuando el depósito ocurre dentro de una app nativa donde nunca carga ninguna página. Además reporta el importe que tiene su sistema de registro, no el que casualmente conocía una página.
¿Podemos mantener un píxel como respaldo junto al postback?
Puede, pero tenga claro lo que vale. Un píxel solo va a confirmar los eventos que puede ver, que son un subconjunto de los que ocurrieron de verdad, y el tamaño de ese subconjunto es invisible para usted. Trátelo como una comprobación de sensatez dentro de la misma sesión durante el desarrollo, no como una segunda fuente de verdad, y no concilie pagos nunca contra él. Si los dos se disparan por el mismo evento, su plataforma necesita una referencia única y estable por su parte para que el par se reconozca como una sola conversión y no como dos.
Nuestros postbacks se disparan pero no se atribuye nada. ¿Por qué?
Casi siempre porque el identificador de clic nunca se guardó en el registro del jugador en el momento del alta. El postback sale correctamente, a tiempo, con una clave válida, y no lleva nada con lo que hacer match. Mire primero una fila real de jugador en su base de datos. Si el identificador falta ahí, el fallo está en su flujo de alta y no en el código del postback, y ninguna lógica de reintentos ni ajuste del endpoint va a cambiar el resultado.
¿Cómo deberíamos probar una integración de postbacks antes de enviar tráfico?
Haga clic en un enlace de tracking real, regístrese como jugador y confirme que el identificador aterrizó en la fila de la cuenta. Después deposite dinero real, porque los pagos en modo de prueba se saltan a menudo justo la ruta de código que dispara el evento. Confirme que el depósito llegó una vez, con el importe y la moneda correctos, después de que el pago se liquidara. Mande el mismo evento otra vez a propósito y confirme que se descarta como duplicado. Luego repítalo en un teléfono, y en la app si la tiene. Una hora, y un depósito pequeño.
