Кросс-продажи в сфере электронной коммерции: техническое руководство по дополнительным продажам в Интернете

В этой статье я опишу относительно простой метод запуска функции перекрестных продаж (товары, предлагаемые покупателю в дополнение к товарам в корзине) в электронной коммерции, например в продуктовых магазинах или службах доставки еды. успешно реализовано в мобильном приложении «Много Лосося». Это базовая рекомендательная система совместной фильтрации, которая сочетает в себе подходы на основе пользователей и элементов и может использоваться в различных проектах электронной коммерции, особенно с большим количеством SKU, для предоставления широкого спектра рекомендаций.

Много Лосося, основанная в 2018 году, представляет собой сеть из 50+ кухонь-призраков и 250+ кухонь на вынос, а также зонтичный бренд для нескольких концепций блюд. Наше уникальное преимущество — 30-минутная доставка свежеприготовленных блюд. Мы быстро расширяемся и недавно преодолели отметку в 100 000 активных пользователей в месяц, а валовой ежемесячный доход превысил 100 млн рублей.

Большинство наших заказов мы делаем онлайн, треть из которых поступает через наше собственное мобильное приложение, а две трети — из служб доставки. Приложение является важным компонентом нашего продукта, потому что оно является одной из первых точек контакта, что, наряду с нашим обслуживанием и самой едой, способствует лучшему обслуживанию клиентов.

Архитектура

Это решение полностью построено на облачных сервисах Яндекса, но его также можно построить на AWS, поскольку в нем также есть все необходимые сервисы. Я обозначаю сервисы с точки зрения нотации AWS для удобства пользователей AWS, что также должно быть понятно многим пользователям YC.

* Управляемая MongoDB * Лямбда-функция * Шлюз API * Облачный DNS * Мобильная серверная часть (вычислительное облако)

Упрощенная архитектура выглядит следующим образом:

1. Пользователи размещают заказы через мобильное приложение. В системе ERP создаются и обрабатываются заказы.
2. Затем заказы копируются в хранилище данных во время процесса ETL один раз в день ночью. Каждый заказ включает информацию о заказанных продуктах, а также идентификатор клиента.
3. Процедуры SQL рассчитывают пользовательские предпочтения и сходство продуктов. Более подробное описание расчета приведено ниже. Вычисление дает две коллекции в MongoDB со следующей структурой:

коллекция userPref

Телефон. Мы используем «телефон» в качестве идентификатора пользователя.

* связанные блюда * id: ID связанного блюда * классифицировать * Дата последнего обновления. Дата и время последнего пересчета

 
 **Example of a document:**

коллекция productSimilarity

• идентификатор блюда
• похожие блюда
• id: идентификатор связанного блюда.
• рейтинг
• lastUpdateDate: дата и время последнего пересчета.

Пример документа

1. Когда пользователь обновляет корзину, приложение отправляет запрос функции Lambda. Запрос включает идентификатор пользователя (телефон) и список идентификаторов товаров, которые в данный момент находятся в корзине.
2. Lambda извлекает связанные блюда из коллекции productSimilarity для каждого блюда в корзине и связанные блюда по данному телефону из коллекции userPref.
3. Алгоритм лямбда затем объединяет эти списки связанных блюд в один и отправляет его обратно в мобильное приложение в виде списка рекомендаций. В корзине приложение отображает карточки товаров.

Алгоритм

Настройки пользователя

Мы внедрили пользовательские настройки на основе взвешенной истории продаж, при этом приоритет отдавался недавним продажам. Рассмотрим следующую произвольную историю продаж пользователя:

| Продукт | Продажи | Когда | Коэффициент времени (1 в месяц) | Взвешенные продажи | |----|----|----|----|----| | А | 1 | в этом месяце | 1 | 1 | | Б | 1 | в этом месяце | 1 | 1 | | С | 4 | 1 месяц назад | 0,5 | 2 | | А | 4 | 1 месяц назад | 0,5 | 2 | | Б | 3 | 4 месяца назад | 0,25 | 0,75 |

Пользователь купил продукт B и продукт C четыре раза. Однако, поскольку большая часть продаж продукта B произошла четыре месяца назад, мы отдаем приоритет более поздним продажам продукта C. Товары сортируются по общему объему продаж, который представляет собой сумму продаж каждого продукта.

| Продукт | Общий взвешенный объем продаж | Рейтинг | |----|----|----| | А | 3 | 1 | | Б | 1,75 | 3 | | С | 2 | 2 |

В приведенном выше примере подразумевается, что пользователь предпочитает продукт A продукту C и продукт C продукту B.

Сходство товаров

Количество заказов, в которых присутствовали пары товаров, используется для расчета схожести товаров. Результат рассчитывается отдельно для каждого месяца, причем приоритет имеют самые последние месяцы. В результате мы ранжируем похожие продукты для каждого продукта и сохраняем их в MongoDB, где идентификатор продукта является индексом для коллекции.

Рекомендация

Полученный список рекомендуемых товаров объединяет предпочтения пользователей и похожие товары и сортирует их в соответствии с некоторой стратегией, то есть сортировкой по возрастанию по рангу. В результате мы просто объединяем все связанные списки товаров и сортируем их. Мы вычисляем средний рейтинг для повторяющихся продуктов. Вот пример:

1. Предположим, теперь у пользователя есть корзина с двумя товарами — А и Б.
2. Lambda выбирает документ из коллекции productSimilarity для продукта A. Связанные блюда: C (ранг 1), D (ранг 2) и E (ранг 3);
3. Lambda выбирает документ из коллекции productSimilarity для продукта B. Связанными блюдами являются F (ранг 1), G (ранг 2) и H (ранг 3);
4. Lambda выбирает документ из коллекции userPref для данного телефона. Связанные блюда: D (ранг 1) и H (ранг 2);
5. Все связанные блюда объединяются, а для повторяющихся блюд вычисляется средний рейтинг. В результате получается список C (ранг 1), D (ранг 1,5), E (ранг 3), F (ранг 1), G (ранг 2) и H (ранг 2,5).
6. После сортировки список C, F, D, G, H и E возвращается в приложение.

Результат

Метрики или как измерить результат

Для измерения эффективности перекрестных продаж мы выбрали следующие показатели:

1. Средняя стоимость заказа (СЗО) для заказов, включавших блюда с перекрестными продажами, была выше, чем для заказов без них. Общая сумма всех продуктов в заказе является стоимостью заказа, то есть суммой, которую клиент платит за заказ. Таким образом, эта метрика показывает, платят ли клиенты больше за заказы, включающие блюда с перекрестными продажами. Это ключевой показатель, потому что увеличение AOV — это именно то, что мы ожидаем от перекрестных продаж.

2. Доля товаров, добавленных из раздела перекрестных продаж, в общем количестве проданных товаров. Это вторичный показатель, на который сильно влияет характер продаваемых товаров, а также стратегия перекрестных продаж. Рассмотрим интернет-магазин электроники, который продает недорогие аксессуары, такие как чемоданы и зарядные кабели, к более дорогим товарам в корзине, таким как смартфоны и ноутбуки. В этом случае многие добавки могут быть перекрестно проданы одному основному товару, и показатель может превышать 50%. Хотя наш пример не включает широкий спектр дополнений, этот показатель демонстрирует, как перекрестные продажи влияют на окончательную структуру корзины.

3. Процент заказов, содержащих блюда с перекрестными продажами. Это еще один второстепенный показатель, который показывает "популярность" перекрестных продаж или то, как часто клиенты покупают рекомендуемые товары.

Фактические результаты

Приведенный ниже набор данных содержит данные об обезличенных заказах, собранные с декабря 2022 года по январь 2023 года в одном из городов присутствия МногоЛососи.

https://github.com/alexchrn/cross-sell/blob/main/orders .csv

Набор данных собран из различных источников, включая AppMetrica (события добавления в корзину) и систему ERP (статусы заказов и платежей, скидки и суммы платежей).

Структура набора данных:

* номер заказа. Уникальный идентификатор заказа * number_of_cross_sell_dishes. Количество блюд, добавленных из раздела кросс-продаж. * положение дел. Последний известный статус заказа. * статус платежа. Последний известный статус платежа * число_очков. Количество бонусных баллов, снятых за заказ. 1 балл равен 1 рублю. * сумма_скидки. Скидка в рублях, без учета бонусных баллов. * сумма_платежа. Сколько клиент заплатил за заказ * создан в. Дата и время создания заказа * appmetrica_device_id. Уникальный идентификатор устройства * имя_версии_приложения. Версия приложения * общее_количество_блюд. Общее количество блюд в заказе * has_cross_sell_dish. Содержит ли заказ блюда, добавленные из перекрестных продаж. Это поле рассчитывается на основе number_of_cross_sell_dishes.

Итак, вот значения показателей (полученные из приведенного выше набора данных с использованием Python).

Доля блюд, добавленных из раздела перекрестных продаж, в общем количестве купленных блюд – 3,97%

Процент заказов, содержащих блюда с перекрестными продажами – 10,46%

AOV заказов, которые включали блюда с перекрестными продажами, по сравнению со AOV заказов, которые не включали:

Как видно, заказы с блюдами с перекрестными продажами имеют более высокий AOV с разницей в 565 руб. Среднее количество блюд в таких заказах также выше, что логично, учитывая, что единственная цель перекрестных продаж — побудить покупателя добавить в корзину больше блюд.

Существенна ли разница в 565? Мы можем использовать t-тест, чтобы увидеть, является ли эта разница случайной. В библиотеке Python scripy есть метод для этого. Это проверка нулевой гипотезы о том, что две независимые выборки имеют одинаковые средние (ожидаемые) значения (1).

Таким образом, p-значение, или вероятность того, что нулевая гипотеза верна, чрезвычайно низка, и мы отвергаем нулевую гипотезу даже при уровне значимости 99%. Другими словами, почти наверняка заметная разница в средней стоимости заказа не случайна, а заказы с дополнительными обедами приносят больший доход.

Заключение

Перекрестные продажи могут быть эффективным инструментом для увеличения средней стоимости заказа даже при использовании простых методов совместной фильтрации. Его также относительно легко реализовать с технической точки зрения благодаря бессерверным сервисам AWS и других облачных провайдеров, как показано в этой статье.

Связанные материалы:

1. https://docs.scipy.org/doc/scipy/reference /generated/scipy.stats.ttest_ind.html