En este artículo, describiré un método relativamente simple para lanzar una función de venta cruzada (productos ofrecidos a un cliente además de los que están en el carrito) en el comercio electrónico, como comestibles o servicios de comida a domicilio, que implementamos con éxito en la aplicación móvil "Mnogo Lososya". Este es un sistema de recomendación de filtrado colaborativo básico que combina enfoques basados en el usuario y en el artículo y se puede utilizar en una variedad de proyectos de comercio electrónico, particularmente aquellos con una gran cantidad de SKU, para proporcionar una amplia gama de recomendaciones.  Mnogo Lososya, fundada en 2018, es una cadena de más de 50 fantasmas y más de 250 cocinas para llevar, así como una marca paraguas para múltiples conceptos de platos. Nuestro único punto de venta es la entrega en 30 minutos de comidas recién preparadas. Nos hemos estado expandiendo rápidamente y recientemente superamos 100k MAU de aplicaciones con más de 100M RUB en ingresos brutos mensuales.  La mayoría de nuestros pedidos se realizan en línea, un tercio proviene de nuestra propia aplicación móvil y los otros dos tercios provienen de los servicios de entrega. La app es un componente importante de nuestro producto porque es uno de los primeros puntos de contacto que, junto con nuestro servicio y la comida en sí, contribuye a una mejor experiencia del cliente.   Arquitectura  Esta solución se creó completamente en los servicios de Yandex Cloud, pero también podría construirse en AWS porque también tiene todos los servicios necesarios. Estoy designando servicios en términos de notación de AWS para la comodidad de los usuarios de AWS, lo que también debería ser claro para muchos usuarios de YC.  MongoDB administrado  función lambda  Puerta de enlace API  DNS en la nube  Backend móvil (nube informática)  La arquitectura simplificada se ve así:   Los usuarios realizan pedidos a través de la aplicación móvil. En el sistema ERP, los pedidos se crean y procesan.  Luego, los pedidos se copian en el almacén de datos durante un proceso ETL una vez al día por la noche. Cada pedido incluye información sobre los productos solicitados, así como el identificador del cliente.  Los procedimientos SQL calculan las preferencias del usuario y la similitud del producto. A continuación se proporciona una descripción más detallada del cálculo. El cálculo produce dos colecciones en MongoDB con la siguiente estructura:   colección de preferencias de usuario    Utilizamos “teléfono” como identificador de usuario. Teléfono:  Platos relacionados  id: ID de un plato relacionado  rango  Última Fecha de Actualización. Fecha y hora del último recálculo     Ejemplo de un documento:   productoColección de similitud  platoId  Platos relacionados  id: ID de un plato relacionado  rango  lastUpdateDate: fecha y hora del último recálculo     Ejemplo de un documento  Cuando un usuario actualiza el carrito, la aplicación envía una solicitud a la función Lambda. La solicitud incluye el identificador de usuario (teléfono) y una lista de identificadores de productos que se encuentran actualmente en el carrito.  Lambda extrae platos relacionados de la colección productSimilarity para cada comida en el carrito y platos relacionados por teléfono dado de la colección userPref.  Luego, el algoritmo lambda combina estas listas de platos relacionados en uno y lo envía a la aplicación móvil como una lista de recomendaciones. En el carrito, la aplicación presenta tarjetas de productos.   Algoritmo   Preferencias del usuario  Implementamos las preferencias de los usuarios en función del historial de ventas ponderado, con prioridad en las ventas recientes. Considere el siguiente historial de ventas del usuario arbitrario:   Producto   Ventas   Cuando   Coeficiente de tiempo (1/meses)   Ventas ponderadas   A   1   este mes   1   1   B   1   este mes   1   1   C   4   Hace 1 mes   0,5   2   A   4   Hace 1 mes   0,5   2   B   3   hace 4 meses   0,25   0,75  El usuario compró el producto B y el producto C cuatro veces. Sin embargo, debido a que la mayoría de las ventas del producto B se realizaron hace cuatro meses, damos prioridad a las ventas más recientes del producto C. Los productos se ordenan por ventas totales ponderadas, que son la suma de las ventas ponderadas de cada producto.   Producto   Ventas totales ponderadas   Rango   A   3   1   B   1,75   3   C   2   2  El ejemplo anterior implica que el usuario prefiere el producto A al producto C y el producto C al producto B.   Similitud del producto  El número de pedidos en los que había pares de productos se usa para calcular la similitud del producto. El resultado se calcula por separado para cada mes, teniendo prioridad los meses más recientes. Como resultado, clasificamos productos similares para cada producto y los almacenamos en MongoDB, donde la identificación del producto es un índice para la colección.   Recomendación  La lista de recomendaciones de productos resultante combina las preferencias del usuario y productos similares y los ordena de acuerdo con alguna estrategia, que es una clasificación ascendente por rango. Como resultado, simplemente combinamos todas las listas de productos relacionados y las ordenamos. Calculamos el rango promedio para los productos que se repiten. Aquí hay un ejemplo:  Supongamos que un usuario ahora tiene un carrito con 2 productos: A y B;  Lambda selecciona un documento de la colección productSimilarity para el producto A. Los platos relacionados son C (rango 1), D (rango 2) y E (rango 3);  Lambda selecciona un documento de la colección productSimilarity para el producto B. Los platos relacionados son F (rango 1), G (rango 2) y H (rango 3);  Lambda selecciona un documento de la colección userPref para el teléfono dado. Los platos relacionados son D (rango 1) y H (rango 2);  Todos los platos relacionados se combinan y, para los platos duplicados, se calcula la clasificación media. La lista resultante es C (rango 1), D (rango 1,5), E (rango 3), F (rango 1), G (rango 2) y H (rango 2,5).  Después de ordenar, la lista es C, F, D, G, H y E, y regresa a la aplicación.   Resultado   Métricas o cómo medir el resultado  Elegimos las siguientes métricas para medir la eficiencia de la venta cruzada:    de los pedidos que incluían platos de venta cruzada fue más alto que el AOV de los pedidos que no lo incluían. La suma total de todos los productos en el pedido es el valor del pedido, que es cuánto paga el cliente por el pedido. Por lo tanto, esta métrica indica si los clientes pagan más por pedidos que incluyen platos de venta cruzada. Esta es la métrica clave porque el aumento en AOV es exactamente lo que esperamos de la venta cruzada. El valor de pedido promedio (AOV)    . Esta es una métrica secundaria que está fuertemente influenciada por la naturaleza de los productos vendidos, así como por la estrategia de venta cruzada. Considere una tienda de comercio electrónico de productos electrónicos que realiza ventas cruzadas de suplementos de bajo costo, como maletas y cables de carga, con artículos más caros en el carrito, como teléfonos inteligentes y computadoras portátiles. Muchos complementos se pueden vender de forma cruzada a un artículo principal en este caso, y la métrica puede superar el 50 %. Aunque nuestro ejemplo no incluye una amplia variedad de suplementos, esta métrica demuestra cómo la venta cruzada afecta la estructura final del carrito. Porcentaje de bienes agregados de la sección de venta cruzada en el total de bienes vendidos    . Esta es otra métrica secundaria que muestra la "popularidad" de la venta cruzada, o con qué frecuencia los clientes compran productos recomendados de venta cruzada. Porcentaje de pedidos que contienen platos de venta cruzada   Resultados actuales  El conjunto de datos a continuación contiene datos de pedidos impersonales recopilados desde diciembre de 2022 hasta enero de 2023 en una de las ciudades de operaciones de MnogoLososya.   https://github.com/alexchrn/cross-sell/blob/main/orders.csv  El conjunto de datos se compila a partir de una variedad de fuentes, incluida AppMetrica (eventos de agregar al carrito) y el sistema ERP (estados de pedidos y pagos, sumas de descuentos y pagos).   Estructura del conjunto de datos:  Solicitar ID. Un identificador único de un pedido  número_de_platos_de_venta_cruzada. El número de platos que se han añadido desde la sección de venta cruzada.  estado. El estado del último pedido conocido.  estado de pago. El último estado de pago conocido  puntos_número. El número de puntos de bonificación que se han retirado en un pedido. 1 punto equivale a 1 rublo.  descuento_sum. El descuento en rublos, sin incluir puntos de bonificación.  pago_sum. Cuánto pagó un cliente por un pedido  Creado en. Fecha y hora de creación de un pedido  appmetrica_dispositivo_id. Identificador de dispositivo único  app_version_name. Version de aplicacion  número_total_de_platos. El número total de platos en un pedido  has_cross_sell_dish. Si un pedido contiene platos añadidos de venta cruzada. Este campo se calcula a partir de number_of_cross_sell_dishes.  Así que aquí están los valores de las métricas (derivados del conjunto de datos anterior usando python).  El porcentaje de platos agregados de la sección de venta cruzada en el total de platos comprados:    3.97%  El porcentaje de pedidos que contienen platos de venta cruzada:    10,46%  AOV de pedidos que incluían platos de venta cruzada en comparación con AOV de pedidos que no:   Como se puede observar, los pedidos con platos de venta cruzada tienen un AOV mayor con una diferencia de 565 RUB. La cantidad promedio de platos en dichos pedidos también es mayor, lo cual es razonable si se tiene en cuenta que el único objetivo de la venta cruzada es incentivar al cliente a agregar más platos a su carrito.  ¿Es significativa la diferencia de 565? Podemos usar una prueba t para ver si esta diferencia se debe al azar. La biblioteca Python scripy tiene un método para esto. Esta es una prueba para la hipótesis nula de que 2 muestras independientes tienen valores promedio (esperados) idénticos (1).   Por lo tanto, el valor p, o la probabilidad de que la hipótesis nula sea verdadera, es extremadamente bajo y rechazamos la hipótesis nula incluso al nivel de significancia del 99%. En otras palabras, es casi seguro que la notable diferencia en el valor medio de los pedidos no es una coincidencia, y los pedidos con comidas de venta cruzada generan más ingresos.   Conclusión  La venta cruzada puede ser una herramienta eficaz para aumentar el valor medio de los pedidos, incluso con técnicas sencillas de filtrado colaborativo. También se puede implementar con relativa facilidad desde un punto de vista técnico, gracias a los servicios sin servidor de AWS y otros proveedores de la nube, como se muestra en este artículo.  Materiales relacionados:   https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ttest_ind.html

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Download free Tech Leaders Productivity Report!

La venta cruzada en asuntos de comercio electrónico: una guía técnica para aumentar las ventas en línea

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

El modelo Bitcoin UTXO, impulsando un ecosistema único

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Telegram: el puente de Crypto Island hacia el continente

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

El modelo Bitcoin UTXO, impulsando un ecosistema único

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Telegram: el puente de Crypto Island hacia el continente

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps