Recomendaciones Documentación

Engine

bundle_scoring

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Puntúa pares candidatos de bundle de productos por lift de coocurrencia, soporte y precio sugerido de descuento.

Calcula la coocurrencia de productos por pares entre transacciones (soporte, confianza, lift), precia el descuento del bundle escalado por el lift y rankea los candidatos con un score compuesto 0-100 (40% lift, 35% soporte, 25% descuento).

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

cross_sell

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Matriz de coocurrencia de productos: soporte, confianza y lift para pares de cross-sell.

¿Por qué? Descubre qué productos se compran juntos con frecuencia, al estilo market basket analysis, y entrega una matriz de pares ordenados por lift, con soporte y confianza direccional para cada par. En la práctica, alimenta recomendaciones de producto, layout de tienda, armado de bundles y campañas de cross-sell y upsell.

¿Cómo? Cada transacción forma un conjunto de productos, y el engine cuenta las frecuencias individuales y de pares para calcular soporte, confianza (en ambas direcciones, A hacia B y B hacia A) y lift, donde un lift mayor que 1 indica asociación positiva. Los pares se filtran por soporte y confianza mínimos y se ordenan por lift descendente hasta el top N.

Origen Las métricas de reglas de asociación tienen su origen en el trabajo de Agrawal y Srikant (1994), "Fast Algorithms for Mining Association Rules", presentado en la 20.ª conferencia VLDB.

Literatura de referencia

• Agrawal, R. & Srikant, R. (1994). "Fast Algorithms for Mining Association Rules." Proceedings of the 20th VLDB Conference.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

dynamic_pricing

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Recomendación de precio óptimo a partir de regresión log-log de elasticidad-precio.

¿Por qué? Calcula el precio óptimo por producto a partir de la elasticidad de la demanda, sustentando una fijación de precios dinámica basada en datos. Entrega el punto de precio que maximiza ingreso o ganancia, además de una clasificación de elasticidad por producto, en lugar de ajustes por intuición.

¿Cómo? Ajusta una regresión log-log, ln(Q) = α + β·ln(P), donde β representa la elasticidad-precio de la demanda. Luego predice la demanda para una grilla de precios candidatos y optimiza el ingreso R = P × Q(P) o la ganancia π = (P - C) × Q(P) sobre esos escenarios.

Origen La fundamentación proviene de la literatura de estrategia de precios consolidada por Nagle y Müller (2017) en "The Strategy and Tactics of Pricing" (Routledge).

Literatura de referencia

• Nagle, T. T. & Müller, G. (2017). "The Strategy and Tactics of Pricing." Routledge.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

price_monitor

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Monitoreo competitivo de precios: PPI, tendencia, volatilidad, detección de guerra de precios y alertas de variación entre sitios.

Agrupa observaciones de precio por producto y sitio en orden cronológico, calcula el Índice de Posición de Precio de cada sitio contra el promedio del mercado, clasifica la tendencia de precio (declining/rising/stable), señala guerras de precios a partir de caídas alternadas entre sitios y levanta alertas cuando la variación de precio de un sitio excede el umbral.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

price_sensitivity

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Correlación precio-demanda por producto y proxy de dirección de elasticidad.

¿Por qué? Mide la sensibilidad al precio de cada producto a partir de la relación entre precio y cantidad vendida, clasificándolo como highly_elastic, moderately_elastic o inelastic. Sirve para identificar qué productos toleran ajustes de precio y cuáles exigen cautela, orientando estrategias de precios y promociones.

¿Cómo? Para cada producto, calcula la correlación de Pearson entre precio y cantidad y el coeficiente de variación del precio, estimando la elasticidad vía aproximación log-lineal (elasticity = r * (CV_qty / CV_price)). La clasificación usa el valor absoluto de la correlación: highly_elastic si |r| > 0.7, moderately_elastic si |r| > 0.4, inelastic en caso contrario, y los productos con una única observación reciben r = 0.0 y clasificación inelastic.

Origen El concepto de elasticidad de la demanda se remonta a Marshall (1890) en "Principles of Economics", y su aplicación a la estrategia de precios sigue a Nagle y Müller (2017) en "The Strategy and Tactics of Pricing" (Routledge).

Literatura de referencia

• Marshall, A. (1890). "Principles of Economics."
• Nagle, T. T. & Muller, G. (2017). "The Strategy and Tactics of Pricing." Routledge.

Parámetros (params)

Esta engine no recibe params: envía solo data[].

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

product_basket

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Análisis de canasta de compras: itemsets frecuentes Apriori y reglas de asociación (soporte/confianza/lift).

¿Por qué? Identifica combinaciones de productos comprados juntos con frecuencia, yendo más allá de pares aislados mediante la minería de itemsets frecuentes. Es fundamental para decisiones de layout de tienda, promociones conjuntas y recomendaciones de producto.

¿Cómo? Un algoritmo al estilo Apriori realiza una búsqueda por niveles para encontrar itemsets frecuentes por encima del soporte mínimo. A partir de ellos genera reglas de asociación evaluadas por soporte, confianza y lift para medir la relevancia de cada regla.

Origen El método deriva del algoritmo Apriori de Agrawal y Srikant (1994), descrito en "Fast Algorithms for Mining Association Rules", presentado en la conferencia VLDB.

Literatura de referencia

• Agrawal, R. & Srikant, R. (1994). "Fast Algorithms for Mining Association Rules." VLDB.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

recommend

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Engine híbrida de recomendación: filtrado colaborativo SVD con aceleración dedicada y fallbacks por contenido y popularidad.

¿Por qué? Sistema de recomendación híbrido que combina personalización y diversidad, ofreciendo lo mejor de ambos mundos entre collaborative filtering y filtrado basado en contenido. Soporta recomendaciones user-to-items e item-to-items, evitando listas repetitivas y ampliando el descubrimiento de productos.

¿Cómo? La factorización matricial por TruncatedSVD cubre el lado colaborativo, mientras que TF-IDF con similitud de coseno cubre el lado de contenido, todo con aceleración dedicada. Los scores de ambos enfoques se combinan con pesos configurables y un re-ranking por Maximal Marginal Relevance (MMR) garantiza diversidad en la lista final.

Origen El método une la factorización matricial para sistemas de recomendación descrita por Koren, Bell y Volinsky (2009) en "Matrix Factorization Techniques for Recommender Systems" con el re-ranking por diversidad MMR propuesto por Carbonell y Goldstein (1998) en "The Use of MMR, Diversity-Based Reranking for Reordering Documents" (SIGIR).

Literatura de referencia

• Koren, Y., Bell, R. & Volinsky, C. (2009). "Matrix Factorization Techniques for Recommender Systems."
• Carbonell, J. & Goldstein, J. (1998). "The Use of MMR, Diversity-Based Reranking for Reordering Documents." SIGIR.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

recommend_items

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Recomendaciones por filtrado colaborativo vía factorización de matriz SVD (usuario-ítem o ítem-ítem).

¿Por qué? Genera recomendaciones de ítems por collaborative filtering, descubriendo patrones latentes de preferencia que no son observables directamente en el historial de interacciones. Soporta recomendaciones user-based e item-based, sirviendo para personalizar vitrinas y listas de sugerencias.

¿Cómo? La matriz de interacciones usuario-ítem se descompone por TruncatedSVD en factores latentes de baja dimensionalidad. La similitud de coseno entre los vectores de factores encuentra ítems o usuarios semejantes, y la reconstrucción parcial de la matriz genera los scores de predicción.

Origen La técnica sigue la factorización matricial para sistemas de recomendación descrita por Koren, Bell y Volinsky (2009) en "Matrix Factorization Techniques for Recommender Systems", publicado en la revista Computer, 42(8).

Literatura de referencia

• Koren, Y., Bell, R. & Volinsky, C. (2009). "Matrix Factorization Techniques for Recommender Systems." Computer, 42(8), 30-37.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

recommend_similar_items

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Recomendaciones ítem a ítem: colaborativa (SVD+coseno) o por contenido, con aceleración dedicada opcional.

¿Por qué? Recomendación item-to-item de alto desempeño, ideal para secciones del tipo "clientes que compraron X también compraron Y" incluso en catálogos grandes. Entrega un ranking top-N de ítems similares para cada ítem del catálogo.

¿Cómo? La factorización matricial por TruncatedSVD, con aceleración dedicada, proyecta los ítems en un espacio latente. La similitud de coseno entre los vectores de features en ese espacio genera el ranking de los ítems más cercanos.

Origen La técnica sigue la factorización matricial para sistemas de recomendación descrita por Koren, Bell y Volinsky (2009) en "Matrix Factorization Techniques for Recommender Systems", publicado en la revista Computer, 42(8).

Literatura de referencia

• Koren, Y., Bell, R. & Volinsky, C. (2009). "Matrix Factorization Techniques for Recommender Systems." Computer, 42(8), 30-37.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

uplift_model

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Modelado de uplift T-Learner: efecto individual de tratamiento, segmentación de Radcliffe y Qini/AUUC.

¿Por qué? Mide el impacto incremental real de campañas e intervenciones sobre el comportamiento del cliente, respondiendo quién solo convierte si es impactado. Entrega el efecto individual del tratamiento (ITE) por cliente y una clasificación en segmentos de uplift: persuadibles, sleeping dogs, lost causes y sure things, dirigiendo la inversión hacia donde realmente cambia el resultado.

¿Cómo? Sigue el enfoque T-Learner: entrena modelos Random Forest separados para los grupos de tratamiento y control y calcula ITE = P(Y=1|X, T=1) - P(Y=1|X, T=0). La calidad del modelo se evalúa con la curva Qini y el AUUC (Area Under Uplift Curve).

Origen El enfoque se basa en los metalearners para la estimación de efectos heterogéneos de tratamiento propuestos por Künzel y coautores (2019) en "Metalearners for Estimating Heterogeneous Treatment Effects using Machine Learning", publicado en PNAS.

Literatura de referencia

• Künzel, S. R. et al. (2019). "Metalearners for Estimating Heterogeneous Treatment Effects using Machine Learning." PNAS, 116(10), 4156-4165.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.

Engine

upsell_suggestions

Grupo

recommendations

Auth

X-TENANT-KEY | Authorization: Bearer

Entrada

JSON inline (data[]) o archivo .json/.csv/.parquet vía multipart/form-data

Modos

asíncrono (202) · ?sync=true (200) · ?dry_run=true (200, efímero)

Propósito

Sugerencias de upsell rankeadas por lift de reglas de asociación, confianza o margen.

¿Por qué? Genera sugerencias de upsell identificando los productos de mayor valor que suelen acompañar compras existentes. Aumenta el ticket promedio con ofertas que tienen sentido para el cliente, ordenadas por lift, confianza o margen.

¿Cómo? Reglas de asociación al estilo Apriori calculan la frecuencia de co-compra entre pares de productos. El ranking es multi-criterio, combinando lift, confianza y margen adicional, y un filtro de relevancia garantiza que el producto sugerido tenga precio o margen superior.

Origen Las reglas de asociación tienen su origen en el trabajo de Agrawal, Imielinski y Swami (1993), "Mining Association Rules Between Sets of Items in Large Databases", presentado en la conferencia SIGMOD.

Literatura de referencia

• Agrawal, R., Imielinski, T. & Swami, A. (1993). "Mining Association Rules Between Sets of Items in Large Databases." SIGMOD.

Parámetros (params)

Columnas de data[]

Respuesta

En modo asíncrono (por defecto), 202 Accepted con {"process_uuid", "result_url"}; el resultado sale en GET /api/v1/results/{process_uuid}. Con ?sync=true o ?dry_run=true la respuesta es 200 con el resultado inline (y 504 con el process_uuid si el worker no responde a tiempo).

Errores

• 403 - la engine no está en allowed_engines de tu suscripción.
• 413 - subida por encima de max_upload_mb.
• 422 - engine desconocida o inactiva en el catálogo.
• 429 - cuota diaria (max_jobs_per_day) o por minuto excedida.

La validación es fail-fast: un envío rechazado no tiene ningún efecto secundario.