Как Sunlight работал с экспресс-доставкой в рекордные снегопады и какой опыт я извлек
Всем привет, любители экспресс доставки до клиента! Я тут на неделе узнал прикольный кейс при работе с Яндекс Доставкой, который стрелял так, что дорогие оффера Яндекса все таки пробивали первую линию обороны и выбирались как целевые при экспресс доставке до клиентов Sunlight. Я думал, что мы готовы к праздникам а оказалось, что не совсем
Предистория и важная ссылка
Ранее писал СТАТЬЮ (Обязательно к прочтению) по настройке интеграции с Яндекс Доставкой, чтобы при этом не отдать последние трусы за оплату услуг красно-белого коммерса.
Доставка за 16 тыс. рублей и новогодний переполох
По сюжету этой проблемы можно будет снимать ЕЛКИ 13-14-15-16. Наливайте себе чего покрепче, усаживайтесь поудобнее, а мы тем временем погружаемся в Россию 2025 года, месяц декабрь, ближе к новому году.
Пока все люди готовились к новому году, а бренды тем временем были на пике продаж, добрый Дедушка Мороз решил навалить нехило так снега, да столько что коммунальные службы не справлялись с последствиями снегопадов.
При этом где-то в Москва-Сити, в офисе курьерской службы Дедушки Мороза решался вопрос доставки подарков тем, кто хорошо себя вел в 2025 году и тем кто не очень. Уже тогда было понятно - всем подарков не доставить, нужно думать!
Думали-Думали и по итогу придумали:
ДА КАПИТАН! ПОДНЯТЬ СУРЖ! ПОДНЯТЬ ЯКОРЬ СТОИМОСТИ ДОСТАВКИ, ПОЛНЫЙ ГАЗ!
По итогу мы могли видеть стоимость доставки из Москвы в Одинцово за 16 тыс. рублей, сильно? Не то слово)
Как мы то пострадали из-за этого? И в чем проблема?
Вопрос хороший, мы вроде как с вами в прошлой статье рассматривали алгоритм, согласно которому выбирается недорогой оффер, и он не может быть больше чем прибыль с одного изделия. Однако за время работы алгоритма было найдено несколько изъянов.
Проблема: Проверка после создания заказа - фиговое решение
Алгоритм выбора оптимального оффера Яндекса работал на этапе создания заказа в транспортной компании, то есть клиент уже сделал заказ и отдал свои деньги, а мы вместо того чтобы доставить не могли подобрать оффер, так как ни один из них не подходил по цене. Доставка была на столько дорогая, что изделия до 5 тыс рублей просто невыгодно было возить.
Решение: Проверка на Create -> Предпроверка на Check-out
Для решения этой проблемы было принято решение делать проверку офферов на адекватность не на этапе создания заявки в транспортной службе а заранее - на check-out, так мы в момент захода клиента на check-out понимаем стоит ли показывать наличие Экспресс-доставки или нет.
Проблема: Разница между временем захода и созданием заказа в транспортной компании
Ранее данной дельта-разницей с нивелировал, думал что 20-60 минут особой погоды не сделает, но декабрь мне доказал обратное, вот поминутный разбор ситуации:
- 16:30, N Декабря
Клиент заходит на check-out, мы показываем доступность экспресс-доставки, так как есть подходящие оффера
- 17:00, Того же дня
Клиент переходит к оплате заказа, стоимость доставки кратно изменилась так как спрос повысился, но делать нечего, клиент уже сделал заказ
-17:30, Того же дня
Розничная точка собрала заказ, вызываем курьера, спрос вырос еще сильнее, разница между изначальным тарифов и текущим в 2-3 раза выше
Решение: Создание заказа после сборки заказа торговой точкой -> Создание заказа в Яндексе сразу после оплаты заказа. Дополнительная проверка на кнопке "Оплатить"
Дополнительная проверка на кнопке "Оплатить" Работает так:
Есть оффера Яндекса, удовлетворящие требованиям формулы?
- Если есть, то формируем инвойс и даем возможность создать и оплатить заказ.
- Если нет, то пишем выдаем "Параметры доставки изменились, попробуйте снова" при этом доставка Яндексом дизейблится.
Экономия любой ценой даже ценой роста ответа бэкенда на check-out ?
Сколько удалось нам сэкономить деньжат по итогу?
Скажем так, половину своей годовой зарплаты я уже сэкономил компании) За год не сложно посчитать
Всех люблю, целую, обнял приподнял, встретимся на разборе следующих кейсов!
dyadyaSerezha
Крайне сумбурный и неясный текст.
Что значит X в заголовке? Почему всё в именительном падеже? Заголовок статьи это не список тэгов, если что.
Узнал на днях, значит, автор не имел к этому прямого отношения. Но в конце статьи - "я сэкономил компании". Не имел отношения, но сэкономил? А если имел, почему узнал только что? Непонятно.
Кейс стрелял? В каком смысле? Непонятно.
Какую линию обороны? Кто от кого и как оборорялся? Непонятно.
Кто такие мы, которые готовы, но нет? Яндекс? Клиенты? Sunlight? Городские службы? Непонятно.
И так далее...
Это как было и как стало? (опять приходится гадать). Если да, то вообще непонятно, почему заказ создавался только после сборки заказа. Тут вообще смешно - собирается то, чего ещё нет.
Ну и в целом - довольно просто, кажется, иметь индикатор на бэкенде, насколько быстро меняется цена доставки, и выполнять дополнительную проверку на этапе оплаты, только если если этот индикатор включён. Это если дополнительная проверка медленная. А если быстрая, то почему вообще сразу не сделали доп. проверку при оплате? Непонятно.
В общем, непонятно примерно везде.
deliveryman Автор
Знаете, я очень детально ознакомился с вашим комментарием, и если Вы думаете, что "стрелял" и "X" имеют только одно значение, то ваша правда)
deliveryman Автор
Судя по комментарию у вас либо не особо большой опыт в екоме, либо вы не сталкивались с подобными проблемами и решили выдать быструю экспертную оценку.
Давайте подробно разберем все ваши простые предложения:
Ключевой вопрос - иметь индикатор, чтобы что? Чтобы понять когда мне нужно обновлять страницу? Зачем мне иметь этот "индикатор" на беке, когда я могу его аналитически рассчитать и далее раз в какое-то время обновлять? Зачем мне делать постоянно это в фоне, когда могу сделать один раз и в конце? А когда у вас индикатор сработал, вам нужно массово для сотни тысяч пользователей сделать одно и то же действие, вы думали о нагрузке на методы? Вы думали о безотказной работе ключевой страницы сайта?
Я вам гарантирую, что простого решения нет на поверхности, а дальше довольно простых советов ваша идея в современных реалиях большинства компаний, где нет оптимизаций, большого числа микросервисов и возможности держать большой RPS, ваша идея не пройдет
А потому что мы не думали, что цена на услугу доставки может быть в 2 раза больше спустя какие-то 30-40 минут, и решение при котором вы нагружаете проверкой одну из важнейших кнопок сайта - не является безопасным и правильным. Подумайте над пользовательским экраном при ошибке, и что будет с бизнесом, если что-то ляжет)
ПОЧЕМУ НЕ СДЕЛАЛИ РАНЬШЕ?
Вопрос больше философский, потому что если бы все все знали, то и статьи на хабр на других людей не писали бы
dyadyaSerezha
Для начала, из статьи непонятно (и я об этом душно написал), кто такие мы и что за бэкенд там, какие задачи и для кого он делает. Остальное без этой информации обсуждать бессмысленно. И нет, я не советовал обновлять страницу одновременно у всех.