Cualquier comprador, cualquier API: cada entrega queda registrada.

Conecta cualquier CRM, postback, Telegram o destino de correo, detecta el éxito comercial real a partir de la respuesta, y conserva un registro de auditoría completo de cada entrega.

0511 funciones

Flujos y entrega

El flujo de la red envuelve cada entrega, y un lead solo cuenta como entregado cuando el CRM devuelve un ID de lead.

Un flujo por red

Configura postbacks, alertas y webhooks una vez por red, y se ejecutan en cada entrega.

Qué hace: Cuando cada oferta tiene su propia copia de los mismos postbacks y alertas, un cambio significa editar diez sitios y olvidar uno. En Alion cada red tiene un solo flujo: postbacks, Telegram, email, webhooks, filtros y continuar si falla el CRM. Se ejecuta en torno a cada entrega a esa red, y las variables de plantilla como {{offer_id}} y {{offer_identifier_name}} siempre se rellenan con la oferta a la que se enrutó el lead.
Por qué existe: Como la regla ya elige la oferta y la oferta conoce su CRM, el flujo solo tiene que gestionar lo que ocurre alrededor de la entrega. Sin un flujo compartido, los ajustes se desalinean entre ofertas de la misma red.
Ejemplo: Northgate Media tiene una oferta CPA y una oferta CRG en DE. Ambas usan el único flujo de Northgate, así que un lead en la oferta CRG dispara el postback del tracker con {{offer_identifier_code}} igual al código de la oferta CRG.

Pasos de flujo condicionales

Cualquier paso de un flujo puede ejecutarse solo para los leads que elijas.

Qué hace: Trabajar con varios trackers o fuentes de tráfico significa que cada uno necesita su propio endpoint de conversión, y algunas alertas solo importan para un país. Cada paso del flujo puede tener una condición creada con el mismo editor de condiciones que las reglas de enrutamiento: país, idioma, fuente, funnel, tracker, landing page, oferta, dominio de email, hora, puntuaciones de fraude, dispositivo o cualquier parámetro de clic.
Por qué existe: Sin condiciones, o envías cada postback a todos los trackers o creas un flujo distinto para cada caso. Un solo flujo con pasos condicionales lo mantiene todo en un lugar.
Ejemplo: En el flujo de Kestrel Ads, el postback de Meta se ejecuta solo cuando la fuente es Meta, el de Taboola solo cuando la fuente es Taboola, y una alerta de Telegram solo para leads de CA.

Entrega a cualquier API o webhook

Si una red acepta leads por HTTP, puedes conectarla hoy mismo.

Qué hace: Esperar a que una plataforma añada una red a su lista de integraciones puede costarte semanas de un acuerdo. En Alion, las solicitudes se construyen con una plantilla JSON con sustitución de variables y autenticación por encabezados, así que cualquier CRM que acepte leads por HTTP se puede conectar al momento.
Por qué existe: Porque cada semana aparecen redes nuevas y una lista fija de integraciones siempre va por detrás. Una plantilla que tú controlas significa que nunca esperas a nadie.
Ejemplo: Velora Partners te envía su documentación de API el lunes por la mañana. Asignas nombre, email, teléfono y país en una plantilla JSON, añades su clave API como encabezado, y el primer lead de UK sale antes de comer.

Cinco tipos de destino

CRM, postback, Telegram, email y webhook en un solo sistema.

Qué hace: Un lead tiene que llegar al CRM de la red, a tu tracker y, a menudo, a tu propio equipo. Alion gestiona los cinco tipos de destino en un solo lugar: CRM, postback, Telegram, email y webhook genérico.
Por qué existe: Sin esto, las alertas viven en una herramienta, los postbacks en otra y los envíos al CRM en una tercera, y nadie ve el panorama completo de un lead.
Ejemplo: Un lead de FR para Brightline Leads va a su CRM, dispara un postback a tu tracker, se publica en el chat de Telegram de tu equipo y envía un webhook a tu hoja interna.

Detección de éxito de negocio

Un lead solo cuenta como entregado cuando el CRM devuelve un ID de lead.

Qué hace: Muchos CRM devuelven HTTP 200 con un error escondido dentro del JSON. Alion lee el cuerpo de la respuesta, no solo el código de estado, y un lead solo se entrega cuando el CRM responde con un ID de lead. Tras un rechazo de negocio, Alion nunca reintenta el mismo CRM, pasa a la siguiente opción.
Por qué existe: Sin esto, registras fallos como éxitos y esperas ingresos de leads que nunca llegaron. Reintentar un CRM que ya dijo que no solo hace perder tiempo que el lead podría aprovechar en otra red.
Ejemplo: El CRM de Halcyon Traffic responde HTTP 200 con {"success": false, "error": "duplicate"}. Alion marca el intento como fallido y prueba la siguiente hoja, Kestrel Ads, que devuelve el ID de lead 88412.

Tiempos de espera por destino

Cada CRM tiene su propio tiempo de espera, y uno lento nunca bloquea el lead.

Qué hace: Un CRM lento puede retener un lead recién llegado durante un minuto mientras se enfría. En Alion cada destino tiene su propio tiempo de espera, 9 segundos por defecto y ajustable. Los destinos se prueban de uno en uno, y si un CRM no responde a tiempo el intento cuenta como fallido y se prueba la siguiente red.
Por qué existe: Porque el valor de un lead baja con cada segundo. Un tiempo de espera global único es demasiado corto para una red lenta pero buena, o demasiado largo para el resto.
Ejemplo: Le das 15 segundos al CRM de Northgate Media porque es lento pero convierte bien, y dejas Velora Partners en los 9 por defecto. Cuando Velora no responde en 9 segundos, el lead pasa directamente a la siguiente hoja.

Detección de entregas tardías y silenciosas

Los leads que un CRM aceptó después del tiempo de espera se detectan, registran y marcan.

Qué hace: A veces un CRM acepta el lead después de que Alion dejó de esperar, y el lead ya se fue a la siguiente red. Si la respuesta llega tarde, la entrega pasa a ser semi exitosa: los estados se sincronizan, el ingreso se registra y se marca como posible doble venta, cuenta contra el payable cap y recibes una alerta. Si el CRM nunca respondió pero la sincronización de estados encuentra allí el lead por email o teléfono, se trata igual.
Por qué existe: Sin esto, un lead que la red realmente tiene queda invisible: sin ingreso, sin estado y sin contar en el cap. Solo te enteras cuando la factura de la red no coincide con la tuya.
Ejemplo: Brightline Leads responde con un ID de lead a los 14 segundos, pero el lead ya fue a Halcyon Traffic. Alion registra la entrega a Brightline por 40 $, la marca como posible doble venta y te avisa por Telegram.

Control de doble entrega

Elige por red si la misma persona puede enviarse allí otra vez.

Qué hace: Enviar dos veces a la misma persona a una red puede romper un acuerdo, mientras que otras redes aceptan encantadas un segundo intento. Alion tiene un ajuste de doble entrega por red con tres niveles: Permitir, No al mismo destino o No a esta red. Comprueba el mismo lead o la misma persona por email o teléfono, el periodo es ilimitado por defecto y solo cuentan los intentos de envío reales.
Por qué existe: Porque cada red tiene su propia regla sobre duplicados. Un único ajuste global es demasiado estricto y desperdicia leads, o demasiado flexible y te causa problemas.
Ejemplo: Kestrel Ads está en No a esta red, así que una persona ya enviada en marzo se omite en junio. Velora Partners está en Permitir, así que la misma persona puede volver a Velora mediante el reciclaje.

Extracción de campos de respuesta

Extrae el ID de lead propio de la red directamente de la respuesta del CRM.

Qué hace: El ID de lead propio de la red es lo que hace posible la sincronización de estados y la conciliación posteriores. Alion lo extrae, junto con una URL de inicio de sesión automático o un estado, directamente de la respuesta con un selector interactivo, sin pasos manuales.
Por qué existe: Sin el ID de lead de la red, la sincronización de estados no tiene con qué cruzar, y los FTD no se pueden vincular a tus leads.
Ejemplo: Halcyon Traffic responde con {"data": {"lead_id": "HT-5521", "autologin": "https://..."}}. Haces clic una vez en lead_id y autologin en el selector, y cada lead futuro guarda ambos.

Registro de postbacks por lead

Ve cada postback que disparó un lead, su resultado y el valor de ingreso enviado.

Qué hace: Cuando tu tracker muestra menos ingresos que Alion, necesitas saber qué postback se disparó y con qué valor. Cada postback se registra por lead: cuál fue, su estado, éxito o fallo y el valor de ingreso enviado. Las entregas no rastreadas envían ingreso 0, y volver a disparar con un valor corregido es una acción manual.
Por qué existe: Sin esto, un postback fallido o incorrecto distorsiona en silencio la optimización de tu plataforma publicitaria, y no puedes demostrar qué se envió.
Ejemplo: Un lead de UK para Offer A muestra dos postbacks: el postback de lead de Google tuvo éxito con 25 $, y el postback de FTD falló con HTTP 500. Corriges el endpoint y vuelves a disparar el postback de FTD con 400 $.

Registro de auditoría completo de entregas

Prueba exacta de lo que enviaste y de lo que volvió.

Qué hace: «Nunca recibimos ese lead» es la disputa más común en este negocio. Alion registra cada intento de forma permanente: la solicitud exacta, la respuesta exacta y un comando curl reconstruido que puedes reproducir, para cerrar la discusión con pruebas y no con recuerdos.
Por qué existe: Sin un registro de cada intento, cada disputa con una red es tu palabra contra la suya, y normalmente pierdes el dinero.
Ejemplo: Northgate Media dice que 12 leads de DE del martes pasado nunca llegaron. Abres cada uno, muestras la solicitud y su propia respuesta con los ID de lead, y reconocen los 12.

Funciones

Más de lo que hace Alion

Distribución de leads de Alion: enrutamiento, reparto y reciclajeCómo Alion enruta cada lead automáticamente mediante reparto ponderado y respaldo consciente de los límites, y luego recicla los leads no convertidos según reglas en lugar de perderlos.Detección de fraude de Alion: bots, duplicados y proxies bloqueadosAlion analiza cada lead con cuatro señales, bloquea VPNs, proxies y correos desechables desde la entrada, y detiene duplicados y reenvíos en cada socio.Seguimiento de estados de Alion: una sola taxonomía, cada socio27 estados canónicos mapeados desde el vocabulario propio de cada socio, con un historial de solo adición y automatización que se activa en el momento en que cambia el estado.Gestión de límites de Alion: límites en tiempo real, sin excesosAplica límites diarios, semanales y contractuales a cada lead en tiempo real, previsualiza los cambios con una simulación, y recibe una alerta de Telegram antes de que se supere un límite.Seguimiento de ingresos de Alion: pagos, condiciones y reportes en vivoSigue los pagos CPL, CPA, híbridos y CRG por país con condiciones versionadas, liquidación FIFO automática, y reportes que llegan hasta un solo lead.Seguridad de Alion: aislamiento por fila y enmascaramiento de datos personalesLos datos de cada cliente permanecen aislados a nivel de fila, los datos personales se enmascaran de forma predeterminada, y los permisos granulares deciden exactamente qué puede ver o hacer cada miembro del equipo.

Ver todas las funciones

Funciones

Envíalo.

Regístrate gratis Reservar una demo