Return prediction para real-time ad bidding

Return prediction conecta el modelo ML al embudo de pago y a los paneles publicitarios. El modelo evalúa la probabilidad de devolución del pedido en el momento de la compra y transmite esa señal a las estrategias de puja en Google Ads, Meta Ads y otras plataformas. La solución funciona en segundo plano: el performance marketer ve el cambio en las pujas y la atribución, pero no modifica su proceso diario.

Qué hace la automatización — paso a paso:

1. Lee los datos históricos de pedidos y devoluciones desde el data warehouse o la capa de BI.
2. Entrena un modelo de clasificación sobre atributos: categoría de producto, talla, precio, marca, perfil del cliente, comportamiento en sesión, momento de la compra, método de entrega.
3. Con cada nuevo pedido, calcula la probabilidad de devolución y almacena el valor en el data mart.
4. Transmite la señal a las plataformas publicitarias a través de Offline Conversions API o Customer Match: para los pedidos con alta probabilidad de devolución se transmite un valor de conversión ajustado.
5. El algoritmo Smart Bidding del lado de Google o Meta reduce automáticamente las pujas para las audiencias y palabras clave que generan devoluciones.
6. Recalcula el modelo semanalmente con datos actualizados — se tiene en cuenta la deriva del comportamiento.
7. Exporta un informe a BI: cuánto se ha ahorrado en publicidad, cómo ha cambiado la unit economics por canal y por grupo de productos.

Qué NO hace la automatización:

• No cancela ni bloquea pedidos con alta probabilidad de devolución. El cliente recibe el pedido con normalidad — solo se ajusta la puja publicitaria en las siguientes impresiones.
• No reemplaza la segmentación CRM ni las campañas de retention. Es una señal para el presupuesto publicitario, no para la comunicación con el cliente.
• No predice la causa de la devolución (talla, calidad, no encajó). Para eso se necesita un modelo separado o una encuesta al cliente.

El resultado es visible en dos lugares: en los paneles de Google y Meta (cambio de CPA y ROAS por segmentos) y en el informe de BI sobre el margen neto tras las devoluciones. En el retail de moda el efecto se manifiesta con mayor rapidez — históricamente tiene un nivel alto de devoluciones, y la reducción de pedidos problemáticos cambia de forma notoria la unit economics del canal. El caso de Bestseller muestra la mecánica práctica: el modelo predice las devoluciones en el momento de la compra, Google Ads ajusta de inmediato las pujas, y el equipo deja de pagar por los clics que generan pedidos no rentables.

La automatización está construida como un pipeline: fuentes de datos → modelo ML → scoring API → integración con plataformas publicitarias → retroalimentación en BI. Dado que es un proyecto de custom-code, los componentes principales se ensamblan según el stack del cliente — Python y SQL para el modelo, data warehouse en la nube para el almacenamiento, Ads API para la entrega de señales.

Flujo técnico

1. Capa de datos. Los pedidos históricos, devoluciones, catálogo de productos y datos de clics publicitarios se consolidan en un data warehouse (BigQuery, Snowflake, Redshift). Se construye una vista única order_fact con características del pedido, del cliente y atribución de canal.
2. Feature engineering. Se crean características de dos tipos: estáticas (categoría, precio, marca, tabla de tallas) y de comportamiento (número de visitas antes de la compra, tiempo en la página del producto, historial de devoluciones del cliente). Para fashion son críticas las características de tallas y el comportamiento previo en devoluciones.
3. Modelo. Un clasificador de gradient boosting (XGBoost o LightGBM) se entrena con datos históricos, la variable target es si el pedido fue devuelto o no. La calibración de probabilidades mediante Platt scaling o isotonic regression es obligatoria: la señal va a los algoritmos de bid, sensibles a los valores absolutos.
4. Scoring API. El modelo se publica como servicio (FastAPI, Cloud Run, AWS Lambda). El API recibe order_id y devuelve la probabilidad de devolución.
5. Integración con Ads. A través de Google Ads Offline Conversions API o Enhanced Conversions se transmite el valor de conversión ajustado: value × (1 − probabilidad de devolución). De manera similar para Meta Conversions API. Smart Bidding utiliza estos datos en el siguiente entrenamiento de pujas.
6. Monitoreo. Metabase, Data Studio o Looker muestran la calidad del modelo (AUC, calibration plot), la deriva de características y el efecto de negocio (CPA, ROAS, gross margin tras las devoluciones).

Pasos de implementación

1. Auditoría de datos: si hay suficiente historial de devoluciones, qué proporción de devoluciones hay por categorías, si existen etiquetas de motivos de devolución.
2. Conexión del data warehouse al sistema de pedidos y a las cuentas publicitarias.
3. Prototipo del modelo con datos históricos — verificación de que la calidad es suficiente para production (AUC, calibración, estabilidad por segmentos).
4. Configuración del scoring API y del cálculo batch diario para todos los pedidos activos.
5. Conexión de Offline Conversions API a Google Ads, lanzamiento de prueba en una proporción limitada del tráfico.
6. Comparación A/B: segmento con return-adjusted bidding frente al segmento de control durante 4-6 semanas.
7. Escalado a todas las campañas, configuración de weekly retrain y alertas por degradación de métricas.

Componentes clave

La complejidad del proyecto es de un mes o más. La mayor parte del tiempo se dedica al feature engineering, la calibración del modelo para el contexto publicitario y la configuración del circuito de atribución. Tras el primer lanzamiento se necesitan al menos 4-6 semanas de observación y ajuste antes de trasladar el presupuesto completo a la nueva señal.

Return prediction es un proyecto data-heavy. Sin un historial limpio de pedidos y devoluciones, el modelo no podrá capturar el patrón. El mínimo recomendado son datos históricos que cubran al menos un ciclo estacional completo de la categoría.

Datos y accesos

• Historial de pedidos por un período suficiente para la estacionalidad (para fashion se recomiendan no menos de 12 meses), con la etiqueta «devolución / no devolución» y el motivo de devolución, donde se registre.
• Catálogo de productos con atributos: categoría, marca, precio, tabla de tallas.
• Datos de campañas publicitarias: vínculo clic → pedido mediante UTM o GA4 ↔ CRM.
• Acceso a Google Ads y Meta Ads con permisos para Offline Conversions API.
• Data warehouse (BigQuery, Snowflake o similar) o disposición para implementarlo en el marco del proyecto.

Disposición del equipo

• El responsable de marketing o head of performance — propietario de la automatización, toma las decisiones de lanzamiento y los umbrales de ajuste de pujas.
• Data analyst del lado del cliente, al menos a tiempo parcial — analiza la atribución y la calidad de las etiquetas de devoluciones.
• CTO o tech lead, que aprueba los accesos a Ads API y data warehouse.

Cronograma

La complejidad media del proyecto es de 6-10 semanas desde el inicio hasta el primer lanzamiento en producción: 2 semanas para la auditoría de datos y el prototipo del modelo, 2-3 semanas para el pipeline de producción y la integración con las plataformas publicitarias, 2-3 semanas para el test A/B y la calibración. Después de eso, se necesita un mes más de observación antes de trasladar todo el presupuesto publicitario a la nueva señal.

Grow2.ai acompaña el proyecto de principio a fin: desde la auditoría de datos hasta el circuito de retrain y la entrega al cliente. Si el equipo no cuenta con un data engineer, aportamos el nuestro durante el período de implementación.