Cómo evitar conversiones duplicadas en campañas de Adgora

Conversiones duplicadas en campañas de Adgora tras un postback: comparación de soluciones

Una conversión puede aparecer dos veces aunque el visitante haya completado la acción una sola vez. El registro adicional puede deberse a un postback repetido, a un endpoint receptor que acepta el mismo evento más de una vez o a informes que contabilizan un evento en dos lugares. Para entender cómo detectar postbacks repetidos, sigue todo el recorrido e identifica dónde aparece por primera vez el segundo registro antes de cambiar la configuración de la campaña.

Esta comparación se centra en tres formas de evitar duplicados: la deduplicación de postbacks por ID de evento, la comprobación del ID de transacción y las reglas basadas en intervalos de tiempo. La opción adecuada depende de los identificadores que proporcione tu integración y de si los clientes pueden realizar conversiones legítimas más de una vez. Una regla demasiado amplia puede eliminar ventas o registros reales.

Define los criterios antes de comparar soluciones

Evalúa cada solución según tres criterios: si bloquea un evento repetido, si conserva las conversiones repetidas legítimas y si puedes probarla sin interrumpir las campañas activas. Anota estos criterios antes de modificar el flujo de postbacks. De lo contrario, una reducción en el número de conversiones podría parecer un éxito, aunque la regla haya suprimido actividad válida.

Define qué se considera un duplicado para la acción que estás midiendo. En una compra puntual, es probable que un mismo pedido registrado dos veces sea un duplicado. En una renovación de suscripción, dos compras del mismo cliente en momentos distintos pueden ser válidas. La definición debe ser específica para el evento, no solo para la campaña.

Conserva los registros necesarios para comparar los resultados: el evento de origen, cualquier identificador de evento o transacción, los intentos de postback, las respuestas del endpoint y el informe de conversiones de Adgora. Si no tienes un campo disponible, deja constancia de ello en lugar de dar por sentado que dos registros corresponden a la misma acción. Un registro de pruebas breve resulta más útil que una afirmación imprecisa de que las conversiones «parecen infladas».

Sigue una conversión a través del flujo de postbacks

Elige una conversión del informe y síguela desde la acción original hasta la vista de informes. Empieza por el evento de origen, como la confirmación de un pedido, el envío de un formulario o una acción en una aplicación. Anota la marca de tiempo y cualquier identificador asociado en ese momento. Después, localiza el postback saliente correspondiente y el registro en el endpoint receptor.

Compara los identificadores y las marcas de tiempo en cada paso. Si el origen tiene un evento y el endpoint tiene dos registros coincidentes, el segundo registro se generó en algún punto entre la entrega del postback y el almacenamiento en el endpoint. Si el endpoint tiene un solo registro, pero Adgora muestra dos conversiones, investiga el flujo de informes o importación en vez de cambiar la deduplicación del endpoint.

Busca el punto exacto en el que divergen los registros. Por ejemplo, un evento del navegador y otro del servidor podrían informar de la misma compra, o un reintento podría llegar a un endpoint que almacena cada solicitud como nueva. Son patrones de fallo distintos y requieren soluciones diferentes. Si ambas rutas incluyen un identificador de evento común, será más fácil conciliarlas; si no, quizá tengas que añadir uno en el origen.

Registra el flujo en orden: evento de origen, generación del postback, intento de entrega, respuesta del endpoint, registro almacenado e informe de Adgora. Así, el equipo tendrá una secuencia concreta que probar. También evitarás una desviación habitual: culpar a la campaña antes de comprobar si el endpoint ya ha creado dos registros.

Compara las estrategias de deduplicación

La deduplicación por ID de evento suele ser la opción más clara cuando una misma conversión puede llevar un identificador de evento único y estable desde el origen hasta el receptor. El endpoint guarda el primer evento y considera que una solicitud posterior con el mismo ID ya se ha procesado. Comprueba que el ID no cambie durante los reintentos ni entre las rutas del navegador y del servidor que puedan informar de la misma acción.

La comprobación del ID de transacción puede funcionar bien en las compras cuando cada pedido tiene una referencia estable. Es menos adecuada para un formulario de contacto, el inicio de una prueba gratuita u otro evento que no genere de forma natural un ID de transacción. Comprueba también el ámbito: una referencia de transacción podría ser única solo dentro de una cuenta o tienda, por lo que la clave de deduplicación quizá también deba incluir ese contexto.

Las reglas basadas en intervalos de tiempo son una alternativa cuando la integración no dispone de un identificador estable de evento o transacción. Pueden considerar como una sola las conversiones coincidentes que se producen con poca diferencia de tiempo, pero «con poca diferencia» no significa «el mismo evento». Un cliente podría completar dos acciones válidas dentro del intervalo elegido. Usa el intervalo más corto que resuelva el patrón de duplicados observado y prueba las repeticiones legítimas antes de aplicar la regla de forma generalizada.

Para quienes investigan cómo evitar conversiones duplicadas en Adgora y revisan de forma más amplia la medición de campañas, se aplican los mismos criterios a las fuentes de tráfico y las definiciones de conversión. La guía de opciones de segmentación en redes publicitarias de criptomonedas de Adgora puede ayudar a definir las decisiones de segmentación, pero esos cambios no corregirán un duplicado creado después de que el postback llegue al endpoint.

Comprueba el comportamiento de los reintentos y las respuestas

Un tiempo de espera agotado no demuestra que el postback haya fallado. Puede que el endpoint haya almacenado el evento, pero no haya enviado una confirmación clara, lo que lleva al emisor a intentarlo de nuevo. Confirma cómo gestiona los tiempos de espera el emisor, qué códigos de respuesta activan los reintentos y si el endpoint responde solo después de guardar el evento.

Revisa los registros reales de solicitudes y respuestas antes de atribuir los duplicados a los reintentos. Comprueba el número de intentos, las marcas de tiempo, los códigos de respuesta y si cada intento incluía el mismo ID de evento. Después, confirma el comportamiento documentado del endpoint en el entorno que utilizas.

Hay una diferencia práctica importante. Si todas las solicitudes repetidas llevan el mismo ID y el endpoint guarda ambas, puede que el sistema receptor necesite un procesamiento idempotente. Si las solicitudes repetidas llevan ID distintos para una misma acción de origen, investiga dónde se generan esos ID. La política de reintentos, por sí sola, no explica esa discrepancia.

Prueba las soluciones con casos de duplicados y eventos repetidos

Antes de implementar una regla, usa dos casos controlados. Primero, envía dos veces el mismo postback de conversión con el mismo identificador. El resultado esperado es una sola conversión almacenada. Después, genera dos conversiones legítimas con identificadores distintos —por ejemplo, dos pedidos separados— y confirma que ambas sigan apareciendo.

Compara los registros de origen, de entrega y del endpoint, además del informe de Adgora, para ambos casos. La solución solo funciona si elimina el evento repetido sin suprimir el segundo evento válido. Si usas una regla basada en intervalos de tiempo, prueba el caso repetido dentro del intervalo propuesto; una prueba fuera de ese intervalo no permitirá detectar si la regla es demasiado amplia.

Siempre que sea posible, mantén las pruebas aisladas de la optimización en curso. Usa una campaña de prueba, un endpoint de ensayo o un evento de prueba claramente marcado para que el resultado no influya en las decisiones de campaña. Si no queda más remedio que probar en producción, acuerda el evento de prueba y el periodo de observación con las personas responsables de los informes antes de enviarlo.

Si las campañas también miden acciones en aplicaciones, asegúrate de que la prueba refleje cómo se envían esos eventos. Este resumen de la publicidad de criptomonedas para campañas de instalación de aplicaciones puede aportar contexto sobre la campaña, pero la comprobación de duplicados debe seguir el recorrido específico de cada instalación o evento dentro de la aplicación a través de su propio flujo de postbacks.

Implementa el cambio con un plan para revertirlo

Empieza con una implementación limitada: un tipo de evento, un endpoint o una campaña de prueba. Antes de cambiar la regla, guarda la configuración actual y anota los recuentos de referencia de eventos de origen, postbacks entregados, registros del endpoint y conversiones informadas. Sin esos valores de referencia, será difícil interpretar una reducción posterior.

Supervisa ambos lados del problema. Reducir los duplicados solo es positivo si las conversiones legítimas se conservan. Vigila si faltan registros, si disminuyen de forma inesperada las compras repetidas, si aumentan los errores de entrega o si aparece una discrepancia entre los datos almacenados en el endpoint y los informes de Adgora. Si aparece alguna de estas señales, pausa el cambio y compara los ID de evento o las referencias de transacción afectados.

Define un criterio claro para revertir el cambio antes de implementarlo. Por ejemplo, vuelve a la configuración anterior si se suprime una conversión de prueba conocida o si desaparecen eventos repetidos válidos del registro del endpoint. Mantén disponible la regla anterior hasta que hayas comprobado la nueva con registros reales de la campaña.

Documenta qué cambió, cuándo y qué tipos de eventos abarca. Ese registro ayuda a distinguir una solución para los postbacks de otros cambios en la campaña. También permite que otra persona restaure directamente el comportamiento anterior si el recuento de conversiones cambia de forma inesperada.

Conclusión: prioriza la identificación del evento cuando esté disponible

Usa un identificador de evento único y estable cuando la integración lo permita y ese mismo identificador pueda viajar desde el evento de origen hasta el endpoint receptor. Así, el receptor podrá reconocer directamente una solicitud repetida, sin tratar como duplicada cualquier conversión que se produzca poco después de otra.

Si no existe un ID de evento adecuado, usa un ID de transacción para las compras cuya referencia sea fiable. Para otros eventos, una regla basada en intervalos de tiempo puede ser la alternativa más precisa, pero debes validarla con conversiones repetidas legítimas antes de implementarla. Ante un caso como las conversiones duplicadas en campañas de Adgora tras un postback, la mejor solución es la que elimina un registro repetido y conserva la segunda acción real, no la que simplemente reduce el total.