Как 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 😂
Сколько удалось нам сэкономить деньжат по итогу?
Скажем так, половину своей годовой зарплаты я уже сэкономил компании) За год не сложно посчитать
Всех люблю, целую, обнял приподнял, встретимся на разборе следующих кейсов!
