Sector oct. 7, 2026

Revisión de leads: estados, plazos y decisiones disputadas

Organiza la revisión de leads con responsables, plazos, pruebas, motivos de rechazo y reconsideración. Ejemplos didácticos y lista de preparación.

A
AffiliateCore
58 visualizaciones
Revisión de leads: estados, plazos y decisiones disputadas

Un lead puede llegar a tiempo y pasar semanas sin una decisión comprensible. El afiliado ve una espera, el anunciante una cola y el equipo busca conversaciones en lugar de comprobar un evento. El punto de partida es acordar quién revisa cada solicitud, con qué condiciones, hasta cuándo y cómo explica su decisión.

Esta guía ayuda a anunciantes y equipos operativos a organizar solicitudes ya recibidas. Se aplica a productos permitidos tras comprobar los requisitos regionales correspondientes. Todos los plazos, códigos y cifras son didácticos, no condiciones de AffiliateCore. El ejemplo trata de un servicio digital ordinario; no demuestra que exista una oferta así en el catálogo.

1. Define qué se decide

Separa si ocurrió el evento, si cumple las condiciones acordadas y si terminó la liquidación financiera. Recibir un postback demuestra la recepción de un mensaje, no por sí mismo la calidad del lead. Una conversión confirmada tampoco significa necesariamente dinero disponible para retirar: la retención y las operaciones financieras se comprueban aparte.

Antes del lanzamiento documenta el evento, los atributos obligatorios, las fuentes permitidas, las reglas para solicitudes repetidas, la ventana de observación y la versión de condiciones. En una solicitud didáctica de demostración de software, el evento puede ser un formulario enviado con el producto seleccionado. Comprar durante el mes siguiente no puede convertirse discretamente en condición adicional después de recibir tráfico. Si se remunera otro evento, defínelo antes.

El resultado es una página de reglas con fecha de entrada en vigor. Conserva las versiones anteriores para reconstruir las condiciones de una solicitud disputada. Acuerda los cambios para eventos futuros; no los utilices para reducir resultados ya aceptados.

2. Asigna responsables por etapa

Una persona recibe la cola, un responsable técnico comprueba pruebas cuando hace falta y una parte autorizada registra el resultado. En equipos pequeños pueden combinarse funciones, pero conviene que una disputa la examine alguien distinto de quien tomó la primera decisión. Nombra suplente para vacaciones y contacto de escalado.

Esquema didáctico: recibido → identificado → condiciones comprobadas → decisión motivada → notificación → reconsideración si aparecen nuevas pruebas. La información insuficiente genera una petición con responsable y fecha. Es un proceso del equipo, no una representación de automatizaciones integradas en AffiliateCore.

Con las reglas preparadas, puedes registrarte como anunciante en AffiliateCore, completar la información requerida y utilizarlas para preparar tu propia oferta. Registrarse no demuestra que el producto esté admitido ni listo para lanzarse.

3. Distingue etapas de trabajo y estados

La lista de conversiones verificada en el panel del anunciante de AffiliateCore permite consultar y filtrar por estado. Incluye tipo de evento, identificador externo, importe y moneda del evento, cargo al anunciante, motivo de rechazo, oferta y hora del evento. Esta lista no permite al anunciante editar o eliminar libremente conversiones.

Estado mostrado Pregunta operativa
pending ¿Quién revisa y cuándo se espera la decisión?
confirmed ¿Qué condición se confirmó? Retención y liquidación se verifican aparte.
rejected ¿Qué regla no se cumplió y dónde está la prueba?
reversed ¿Por qué se anuló un resultado anterior? No es un primer rechazo.
disputed ¿Qué se discute y quién lo examina?

La etiqueta disputed no demuestra que haya presentación automática de apelaciones, contador o espacio específico para disputas. No se confirmó un flujo completo de apelación accesible a los participantes. Mantén el registro de casos y los plazos propuestos en la herramienta de trabajo acordada; los estados del sistema los modifica la parte autorizada. No prometas un botón inexistente.

4. Establece desde cuándo cuentan los plazos

«Revisamos rápido» es impreciso. «Primera revisión hasta el siguiente día laborable desde la recepción; si faltan datos, indicamos cuáles y una nueva fecha» permite actuar. Un piloto didáctico podría asignar dos días laborables a una decisión ordinaria y otro para escalar un retraso. Acuerda valores reales según carga, festivos, región y momento en que puede observarse el evento objetivo.

Registra por separado hora del evento, recepción y fecha límite de decisión. Define una zona horaria e incluye su desplazamiento al intercambiar marcas temporales. Un evento entregado tarde no implica automáticamente una infracción del afiliado: primero determina la causa y la regla aplicable.

Esperar pruebas no debe reiniciar silenciosamente la antigüedad del lead. Conserva plazo original, motivo de prórroga, responsable y nueva fecha. Vencer el plazo significa escalar, no rechazar ni abonar automáticamente, salvo que ese mecanismo esté acordado e implementado.

5. Reúne pruebas suficientes y limitadas

Para revisar necesitas ID del evento en origen, ID de conversión de plataforma si existe, relación con el clic, oferta, hora, versión de regla y referencia a la prueba. El ID de usuario no sustituye al del evento: una persona puede realizar distintas acciones permitidas.

En el registro de decisiones añade estado anterior y nuevo, revisor, fecha, fundamento y enlace con la decisión previa. La entrega repetida de un mensaje no es un lead nuevo. Una IP compartida o una dirección parecida tampoco demuestran por sí solas duplicación o fraude. Comprueba la identidad del evento y las condiciones acordadas.

No envíes contraseñas, secretos del postback, documentos completos ni datos de contacto innecesarios de visitantes. Utiliza acceso restringido o un extracto anonimizado suficiente para explicar el motivo. OWASP Logging Cheat Sheet ofrece orientación general sobre registros y protección; este proceso de revisión es una plantilla editorial práctica.

6. Separa rechazo y petición de pruebas

Estos códigos didácticos evitan un «tráfico malo» sin explicación. No forman un catálogo integrado en AffiliateCore.

EVENT_DUPLICATE — Se registró de nuevo el mismo evento. Qué aportar: Referencia original y criterio de coincidencia.

TERMS_MISMATCH — No se cumplió una condición vigente concreta. Qué aportar: Cláusula, versión y hecho comprobable.

EVENT_NOT_MET — No se completó la acción objetivo acordada. Qué aportar: Estado de origen al cerrar la ventana de observación.

NEEDS_EVIDENCE — No hay información suficiente para decidir. Qué aportar: Petición exacta, destinatario y plazo de respuesta.

La última fila es una tarea, no un motivo definitivo de rechazo. Las señales antifraude también necesitan interpretación. Si una avería propia impide obtener pruebas, registra el incidente y una fecha de revisión. No conviertas la incertidumbre en una acusación al socio.

7. Ejemplo: informar sin distorsionar porcentajes

Un servicio digital ficticio recibe 100 leads únicos en una semana después de excluir entregas repetidas. Al preparar el informe hay 60 confirmados, 20 rechazados con fundamento y 20 pendientes. Se han completado 80 revisiones. La confirmación entre leads decididos es 60 / 80 = 75%; entre todos los recibidos, 60 / 100 = 60%. Indica el denominador porque son métricas diferentes.

Ocho de los 20 pendientes están fuera de plazo. Su proporción en la cola abierta es 8 / 20 = 40%. No conviertas los pendientes en rechazos para cerrar el informe. Asigna primero responsables a esos ocho y revisa después antigüedad y motivos de espera de los demás.

Si 12 de los 20 rechazos se explican como mensajes repetidos, revisa la definición de la cohorte. El ejemplo ya excluía entregas repetidas; esa explicación exigiría corregir los datos iniciales. La aritmética debe coincidir con la unidad contada, no limitarse a sumar cien.

Ejercicio: prepara esta tabla para tu oferta sin datos personales. Compárala con los estados disponibles en la cuenta de anunciante y entrega una lista separada de diferencias al operador responsable. No generes eventos ficticios remunerables para probar una hoja de cálculo.

8. Ejemplo: reconsiderar una decisión disputada

L-041 se rechazó como duplicado de L-019. El socio presenta dos identificadores de evento distintos. El revisor recupera las condiciones aplicables: una nueva solicitud solo se permite para otro producto. Después compara producto y hora en origen. Un identificador distinto no demuestra por sí solo que el socio tenga razón; la misma IP tampoco demuestra que el rechazo sea correcto.

Si se confirma un evento distinto y admisible, la parte autorizada corrige el resultado mediante el procedimiento disponible. Conserva decisión inicial, nuevas pruebas, fecha y motivo de reconsideración. Comprueba el efecto financiero por separado: reenviar un postback no debe utilizarse para «añadir el abono pendiente».

Si se mantiene la decisión, responde con la regla y el hecho concretos, no solo «rechazado». Si aún faltan pruebas, indica siguiente paso y fecha. Cerrar un caso únicamente porque venció un plazo interno no sustituye a una decisión razonada.

9. Mide el trabajo de revisión

Cada semana examina la cola abierta en un momento indicado, número de vencidos, mediana y percentil 90 del tiempo hasta la primera decisión, proporción de decisiones motivadas y resultados de reconsideraciones. Calcula el tiempo de decisión sobre registros terminados y muestra aparte la antigüedad de los abiertos. De otro modo, los casos más lentos desaparecen de la métrica de velocidad.

Calcula decisiones iniciales revocadas entre apelaciones resueltas, no entre todos los leads. Tres revisiones no permiten concluir con seguridad sobre una fuente. Compara periodos y versiones consistentes y cohortes suficientemente maduras. Más rechazos pueden reflejar cambios en la definición del evento o errores de proceso: investiga antes de juzgar el tráfico.

10. Preparación y siguiente acción

Antes del piloto verifica evento y versión de condiciones; responsable y suplente; inicio de plazos; pruebas de cada motivo; distinción entre aclaración y rechazo; receptor de disputas; historial conservado; e informes separados de pendientes y decididos.

Ensaya con tres fichas didácticas: lead ordinario, mensaje repetido y disputa con pruebas nuevas. El criterio de preparación es que el revisor identifique regla, siguiente paso, responsable y plazo en cada una. Si no puede, aclara el procedimiento antes del lanzamiento en lugar de inventar más estados.

Consulta las guías de presentación clara de una oferta y diferencias entre informes. El resultado de esta guía es una decisión reproducible por lead, no configurar atribución ni prometer una tasa de aceptación.

Regístrate como anunciante en AffiliateCore, completa los datos obligatorios y prepara tu oferta con condiciones de revisión acordadas. Admisión, comprobaciones y moderación siguen siendo etapas distintas. Crear una oferta no garantiza lanzamiento ni tráfico. Guarda el procedimiento con tu equipo y confirma la forma de comunicación disponible con la plataforma antes del primer test.