Нет, вам не нужно машинное обучение. Вам нужен SQL

Некоторое время назад я опубликовал серию твитов об использовании традиционных инструментов вместо новомодных и сложных технологий.

Твиты зашли неплохо и попали на HackerNews. Последствием такой мини-популярности стала интересная дискуссия. Одни согласились со мной, а другие назвали это глупостью и бредом. Ну, в интернете тоже случаются перестрелки.

Я не пытаюсь убедить вас использовать свой подход. Скорее я хочу подробнее объяснить, что именно имелось в виду в первоначальном выступлении в Twitter.

Годы проходят, и вы наблюдаете появление некоторых интересных технологий и концепций: машинное обучение, блокчейн, искусственный интеллект, виртуальная реальность, дополненная реальность и т. д. — в то время как некоторые прежние технологии уходят на задний план. Сегодня несложно услышать о разработке каких-то фантастических продуктов на блокчейне. Я видел блокчейн-сервисы для электронной коммерции, социальных сетей и недвижимости. Список можно продолжить. Я слышу слова: чтобы вам быстрее и раньше закрыть раунд финансирования, нужно использовать слово «блокчейн», даже если оно не имеет отношения к проекту.

Некоторое время назад в тренде были машинное обучение и искусственный интеллект. Каждый новый стартап занимался ML/AI. Не дай бог запустить проект без упоминания AI. Серьёзно, ты правда в бизнесе? Но вообще так быть не должно. Одной из технологий, которую я до сих пор высоко ценю, является SQL (Structured Query Language). Эта более чем 40-летняя технология сегодня так же актуальна, как и в 1974 году. Хотя за эти годы она несколько изменилась, но это такая же мощь, как и раньше.

Я всю жизнь работаю в IT, а большую часть карьеры провёл в электронной коммерции — и своими глазами видел, как эта технология помогала росту и масштабированию бизнеса. Мы использовали её для выявления интересной информации в собранных данных. Данные включают в себя в том числе потребительское поведение, характер покупок и привычки. Эта технология позволила предсказать, какой товар держать на складе, а какой нет. Она позволила предоставить сервис лучшего качества и вернуть клиентов. Позвольте рассказать, как мы это сделали — можете использовать наш опыт.

Всегда весело слышать от основателей и потенциальных основателей стартапов, что они хотят использовать AI/ML для лучшего удержания клиентов и повышения их пожизненной ценности [суммарная прибыль или убыток от конкретного потребителя за период сотрудничества с ним — прим. пер.]. На самом деле им вообще не нужно машинное обучение или какая-то другая из этих причудливых технологий. Правильно написанный SQL — вот всё, что им нужно. В прежней жизни я писал SQL-запросы, чтобы извлечь ценную информацию и идеи из созданных данных. Однажды мы хотели найти «клиентов недели», чтобы поздравить и наградить их. Такой простой и неожиданный жест по отношению к клиентам всегда приводит людей в восторг и превращает их в евангелистов. Нередко можно увидеть сообщения в социальных сетях типа «Ничего себе, Konga только что наградила меня купоном на ₦2000 как клиента недели. Не ожидал такого. Спасибо, ребята, вы лучшие».

Это оказалось более эффективно, чем тратить деньги на рекламу. Не поймите меня неправильно, традиционная реклама имеет место, но ничто не сравнится с рекомендацией от надёжного друга. Удивительно, но получить такую информацию оказалось довольно просто. Никакая причудливая технология не нужна, кроме старого доброго SQL. Чтобы выявить клиента недели, мы написали SQL-запрос, который находит в таблице заказов запись с самой большой корзиной заказов за неделю. Получив эту информацию, мы отправляем клиенту письмо с благодарностью и прикладываем небольшой купон/ваучер. Угадайте, что происходит дальше? 99% этих людей становятся постоянными клиентами. Мы никогда не нуждались в ML. Просто написали элементарный SQL-запрос — и получили эту информацию.

Однажды нужно было восстановить связь с клиентами, которые прекратили делать покупки. Поскольку этим занимался я, то написал SQL-запрос, который выбирал всех клиентов с датой последней покупки 3 месяца или более. Опять же, запрос удивительно простой. Получив эту информацию, отправляем по электронной почте симпатичное письмо: «Мы скучаем по вам, возвращайтесь, и вот ваш купон на Х найр» [денежная единица Нигерии — прим. пер.]. Эффективность отклика всегда была больше 50%. И всегда шквал сообщений в социальных сетях. На мой взгляд, эти две стратегии были и остаются намного эффективнее, чем тратить на рекламу в Google и Facebook.

Такой же подход мы применили к рассылкам новостей. Зачем рассылать общую рассылку, если можно попытаться персонализировать её? Решение? Я написал SQL-запросы для проверки содержимого корзины и извлечения отдельных элементов. Из этих элементов мы смогли сгенерировать бюллетень и таргетировать соответствующий контент. Скажем, человек купил пару обуви, солнцезащитные очки и книгу. В рассылке для него мы покажем обувь, солнцезащитные очки и книги. Это гораздо более уместно, чем посылать случайные вещи. Зачем посылать письмо с молокоотсосом мужчине, который только что купил пару кроссовок? Это даже не имеет смысла. Типичный уровень просмотра (open rate) большинства маркетинговых писем составляет от 7 до 10%. Но когда мы хорошо справлялись с работой, то видели показатель в районе 25−30%.

Это втрое выше отраслевого стандарта. Ещё одна приятная особенность этих писем — то, что мы обращались к людям по именам. Никаких «уважаемый клиент». Только «дорогой Селестин», «дорогой Омин» и так далее. Это придаёт всему оттенок человечности. Показывает наше участие. Всё благодаря старому доброму SQL, а не какому-то причудливому машинному обучению.

Мы помогли клиентам, которые по каким-то причинам не завершили заказы. Если они добавили товар в корзину, то имели намерение его купить. Чтобы помочь им с завершением заказа, я написал скрипт SQL, связал его с заданием CRON, и эта комбинация рассылала электронные письма клиентам, чьи корзины последний раз обновлялись в течение 48 часов или более. Угадай, что произошло? Это сработало. Мы отслеживали письма и сделали вывод, что люди действительно возвращались по ссылкам из них. Опять же, SQL-запрос оказался очень простым. Он выбирал непустые корзины с временем последнего обновления 48 часов или больше. Запустили ежедневный CRON на 2 часа ночи — время меньшей активности и трафика. Клиенты просыпаются и видят в почте напоминание о своей забытой корзине. Речь о повторном вовлечении клиентов. Ничего особенного, просто SQL, Bash и CRON.

Так как оплата по факту по-прежнему популярна, SQL опять пригодился. Если клиент отменяет заказы три раза подряд, он помещается в отдельный список «особого предупреждения». При следующем заказе ему звонят и спрашивают, действительно ли нужен заказ. Таким образом мы экономим время и нервы. Для таких клиентов оплату по факту вообще можно отключить, оставив только оплату по карте. В электронной коммерции логистика стоит дорого, поэтому есть смысл сосредоточиться на серьёзных клиентах. Нам не нужен ML или какой-то причудливый AI для этой проблемы. Опять же, достаточно хорошо написанного SQL.

Для заказов, не доставленных в обещанное время согласно SLA, мы тоже использовали SQL-запросы. Выбирались заказы с состоянием «Не доставлено» и датой заказа равной или более 7 дней, так как это стандартный срок доставки. Задание CRON отправляло письма и SMS таким клиентам. Понятно, что клиенты не апплодировали стоя. Но мы хотя бы заверили, что нам не наплевать и мы работаем над решением проблемы. Ничто так не раздражает, как задержка заказа.

Это конкретное решение также значительно повлияло на NPS [индекс потребительской лояльности — прим. пер.]. Опять же, старые добрые SQL и Bash.

Бонус: Sift Science удивительно хорошо предотвращает фрод. Но SQL тоже можно использовать. Если человек пытается расплатиться с трёх разных карт и эти карты отвергаются одна за другой, происходит что-то неладное. Первое и очевидное, что нужно сделать — временно заблокировать его учётную запись. Вы избавите от большой головной боли потенциальных владельцев карт. Не нужно хранить данные карты, просто регистрируйте в БД попытку проверки карты для определённого номера заказа. Для выявления таких очевидных вещей не требуется ML, а только хорошо написанный SQL.

Машинное обучение и искусственный интеллект — хорошие технологии. Во всяком случае, Amazon доказал эффективность своего бизнеса. Но если у вас маленький интернет-магазин с 1000−10000 клиентов, то можно обойтись SQL. Кроме того, специалисты по ML/AI стоят недёшево.

Буду рад услышать, что вы думаете.

Автор: m1rko

Источник