Как мы делали клубную программу Спортмастера13.06.2019 14:47

Если вы чаще раза в год ходите в наши магазины за спорттоварами или одеждой, скорее всего, у вас есть наша клубная карта (синяя, серебряная или золотая). Меня зовут Максим, я заместитель директора департамента разработки, внедрения и сопровождения ПО, и в этом посте мы с коллегами расскажем про становление клубной программы Спортмастера, про коллекцию собранных нами в процессе граблей и про то, чем наша клубная программа отличается от привычных скидочных карт других торговых сетей.

Тогда

На дворе стоял 2004-й год. Что было — клубная программа у Спортмастера и доллар по 27 рублей. Чего не было — нормального интернета на местах и стабильных каналов связи у магазинов.

В те годы мы сами написали систему лояльности, которая могла нормально вести учёт бонусных баллов каждого пользователя. Но так как магазинов у нас уже тогда было много, в отличие от мощностей для обработки данных, вся наша база данных бонусов умещалась в одном файле, который просто рассылался по магазинам и обслуживался локально, а изменения за день возвращались обратно. Кстати, именно это стало первопричиной того, что бонусы можно тратить только на следующий день после покупки, а не требования бизнеса и обеспечение возврата клиентов — в течение суток всё это просто не успевало обновиться и пересчитаться как следует.
Иными словами, в то время бонусы могли начать действовать и вообще день на пятый — пока эта таблица с рассчитанными заново бонусами дойдет до всех магазинов.

Работали сами карточки довольно просто — на каждой карте просто накапливалось определенное число бонусов, которые её владелец мог радостно и с чувством потратить. То есть для базы это выглядело просто, грубо говоря, одна карта — одна циферка. С золотыми картами было немного сложнее — там кроме циферки с бонусами были ещё и сервисные баллы. Это когда ты купил велик, а через полгода захотел подтянуть цепь, проверить тормоза, звонок стал не так греть душу и отпугивать прохожих и прочее (или поточить коньки к новому сезону и поправить сноуборд, например).

При этом начисление бонусов проводилось мощностями решения на базе естественного интеллекта — у нас был специальный сотрудник, который писал селекты и делал выборки, потом начислял в специальной табличке бонусы, а система подтягивала эту табличку. И да, если этот человек вдруг решил чуток поболеть или что ещё — некоторые покупатели могли остаться без бонусов в эти нелёгкие дни.

Само собой, для бизнеса такая ситуация была довольно затратна, да и вообще — опасна и непредсказуема, и бизнес хотел перевести систему на нормальные (автоматические) рельсы.

Сначала мы решили изучить рынок. Поняли, что есть несколько прекрасных систем с большими возможностями и ценниками, эти возможности превосходящими. Причём с такой системой лицензирования, по которой предполагалось собирать мзду не просто за использование мощностей или за сам софт, а за каждого активного пользователя в такой бонусной системе. Что не могло не радовать авторов системы. Но печалило наш бизнес.

Второй проблемой было ещё и то, что с ростом клиентской базы и количества магазинов сложилась ситуация, когда всё более и более здоровенную базу надо было пересылать во всё большее и большее количество магазинов. И в один прекрасный день эта база просто перестала пролезать через имеющиеся каналы связи. Обсчитывалась по всем магазинам в короткий промежуток времени она тоже с большим скрипом.

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

И тогда Александр Афанасьев (ныне IT-директор другой компании) придумал, как всё это можно сделать самим, не покупая сторонний софт. Собрал от бизнеса ряд требований к этой системе с их стороны и прописал новые возможности. Сначала просто в виде приятных фич — к примеру, теперь бонусы это не просто одна цифра, а целая сложная система. Можно давать человеку бонусы на день рождения, можно отдельно дать бонус только на лыжи и связанные с ними товарные позиции, можно предложить бонусы только на товары бренда Columbia и в определенные периоды времени — и всё это комбинировать, комбинировать, комбинировать.

К счастью, развитие сети достигло того момента, когда интернет таки уже появился почти везде, и можно было вывести решение в онлайн. То есть схема работы стала такой — есть магазин со стабильным сетевым каналом, он по сети обращается в базу за остатком (а в базе теперь всё самое свежее и вкусное), забирает остаток бонусов из базы и работает уже с ним. И все это, пока покупатель радостно общается с приветливым продавцом.

Третьей проблемой было проведение операций по сгоранию бонусов. У нас же как — ты можешь весь год задорно копить баллы, но 1 марта они всегда вероломно сгорают, если ты не успел их потратить.

Первая версия системы (под названием CARDS) могла их нормально учитывать, но вот когда она переходила в режим бонусосжигательного завода, начинались проблемы. Ведь сжигание бонусов — это полноценный проход по всей базе с изменениями. Учитывая размер базы, это могло занять дня 3–4. Причем в процессе она жутко тормозила и тупила, из-за чего иногда сжигание бонусов прерывали, и получалось, что в каком-то магазине у камрада Петрова, зашедшего за новыми шариками для пинг-понга, бонусы ещё есть, а у Сидорова, зашедшего за новым великом, уже, к сожалению, нет.

Новая версия системы

Мы сделали прототип где-то за 3–4 дня, потом пару дней потестили его на живых чеках. Оказалось, что система вполне себе работоспособна, и можно использовать её для генерации разных условий бонусов и формирования текстов коммуникаций.

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

Взаимодействие с ними проходило примерно так:

провайдер понимал, что перед ним крупный клиент, и начинал радоваться
крупный клиент в виде нас уточнял, осилит ли провайдер на самом деле такие рассылки
провайдер говорил, что осилит, само собой
провайдер получал задание на рассылку огромного количества СМС за короткий промежуток времени и принимал решение прилечь отдохнуть

Так вот, о прототипе. В принципе всю систему было решено сильно отреинженирить, потому что изначально она была заточена только под учёт бонусов, а не под работу онлайн, поэтому она ожидаемо перестала справляться с отдачей. Причём падала она, само собой, в моменты высокой нагрузки. То есть в самое вкусное для магазина время — Новый год, 8 марта, 23 февраля и прочие приятные даты.

Падает система —> падает настроение у бизнеса —> падает настроение у всех.

Вдвоем с коллегой мы переписали систему по следующему принципу.

Компонент 1. Препроцессинг, максимально оперативно отдающий магазинам ответ.
Компонент 2. Процессинг, тот самый магический ящик, сложно и хитро начисляющий бонусы на товарные чеки.
Компонент 3. Маркетинг, собирающий всё это воедино и формирующий тексты коммуникаций.

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

В новой версии система просто хранит бонусы каждого клиента в базе, но в какой-то момент времени перестаёт считать их активными. То есть теперь бонусы есть всегда, но каждый — со своим периодом активности. Что, кстати, позволило вводить более точные и более срочные акции и кампании.

Старая система фактически просто вела учёт карточек и бонусов на этих карточках. Новая система ставит в приоритет не карточку, а именно аккаунт человека. Мы можем идентифицировать его по номеру телефона (эта штука у нас работает с самого старта, мы были одними из первых, кто внедрил авторизацию по номеру телефона).

Дополнительной фичей новой системы стали так называемые товарные бонусы, это работает вот так:

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

Мы показали этот прототип в работе бизнесу. Бизнес дал добро.

Писать систему мы начали 1 марта, внедрили в работу 27 октября 2013 года (писали вдвоём, да). На самом деле, плановой датой поставки было 1 сентября, но не успевал главный контрагент системы — розничные магазины. Магазины не успевали по ряду своих причин, плюс не у всех обновили кассовое ПО (а обновлять кассовое ПО в масштабах довольно крупной сети — это та ещё боль). Поэтому отложили, дождались их, и запустились 27 октября.

Идеология системы

Заложили главную идею — ни магазин, ни кассовое ПО больше не работают с логикой бонусов. Магазин теперь просто отправляет корзину покупателя в Центр, Центр всё это дело обрабатывает, отдаёт магазину расчёт по бонусам.

Сейчас бонусы размазываются так:

Прежде всего, бонусы размазываются по всему чеку равномерно, на все товарные позиции. Это и полезно для аналитики, и помогает в случае возврата товара.
Ввели понятие приоритета бонусов. Бонусы есть товарные, есть бонусы на дни рождения, у которых срок действия короткий, есть регулярные (самые живучие). Поэтому мы сначала списываем именно специфичные бонусы. То есть пришёл человек за лыжами — мы спишем прежде всего бонусы, которые у него есть именно на лыжи. А то получится, что пришёл он за лыжами, мы списали регулярные бонусы. Через неделю придёт за курткой, а мы ему — Мужик, у тебя только бонусы на лыжи есть. Хочешь лыжи? То же самое с покупками в периоды дня рождения, сначала списываем их, а потом — регулярные.
Разносим бэкофисные операции и фронт. Теперь магазины, приходящие с запросами, никак не влияют на работу и производительность сервиса, начисляющего бонусы, и наоборот

В общем, удалось забороть все старые проблемы, а вместо новых проблем добавить новых возможностей.

Вместо бэклога у нас была вот такая тетрадь Александра.

Запуск новой версии системы

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

Звучит неплохо, но на деле упирается в пару ограничений.

Во-первых, из-за большого количества магазинов (1200+) мы должны были успеть всё сделать за 3 часа. Пока один магазин в полночь в одном часовом поясе закрывается, в другом совсем иное время, а тут ещё и плюс круглосуточные магазины. В общем, чтобы сконвертировать все данные из старой системы, скормить новой, запуститься на трёх серверах сразу — 3 часа.

Подводные камни были вот такие:

Система врубалась сразу на всей сети. Если всё везде хорошо — всё работает по всей сети. Если что-то падает — да, падает по всей сети.
Новая система при включении должна содержать в себе все данные, которые были в старой системе на момент закрытия магазинов и выдачи самого свежего бонуса. Мы запускались на 4 страны разом. БД была более терабайта и хранила сотни миллиардов записей.
В 23.00 мы должны были выключить систему. Сконвертировать всё. Залить в новую систему. Включить всё. При этом всё должно работать.

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

Что немного отличалось от задуманной цифры в 3 часа.

Тогда мы решили сначала сделать препроцессинг, который хранил в себе остатки. Поднимали главный сервак, он связывался с магазинами. При этом он не знал, что система поднялась ещё не вся, а мы в это время доблестно накатывали всё остальное.

Но всё равно, такой объём данных на стандартных машинах в установленный срок сделать не получалось.

И тут надо отметить Oracle Exadata. Ребята из Oracle сделали специальную железку, которая прекрасно работает с её же БД, да ещё и на флеш-дисках. В общем, было принято волевое решение использовать Exadata. С её помощью на тестах мы осилили сделать всё нужное за 2 часа вместо 9 и поняли — надо брать.

Так как мы ребята дотошные, в процессе настройки и работы мы выгребли кучу багов и завалили саппорт Оракла с запасом. Например, был один занятный баг — из-за ошибки во внутренней обработке запроса Oracle стал усиленно потреблять TEMP. Мы это вовремя заметили, и накинули ему еще TEMP«овых файликов, было очень интересно, когда же он нажрется. Но поскольку железяка оказалась очень толковой и знающей свое дело, она с чувством употребила 3 Тб TEMP за 10 минут, поняла, что больше нет, и ушла на покой. Пришлось придумывать обходы.

С одной стороны, было круто, что всё в плане конвертации у нас сделалось за 2 часа. С другой стороны, во всём процессе чистой конвертации 2 часа, а мы планировали ещё и:

перезалить все данные с серверов старой системы на exadata, потому что она дико быстро всё считает.
сконвертировать данные из старых структур в новые.
залить всё это сконвертированное добро на три разных сервера.

В каждой БД при этом находилась куча полезной служебной инфы типа тех же индексов, которые могли помочь при перестройке, но мы забили на это и решили перестроить всё заново уже на боевых серверах.

Подготовка

Мы готовились вовсю. Мы спали на работе. Мы увешались не только скриптами, но и множеством метрик.

В 23.00 каждый день мы запускали процесс и следили за метриками. Вносили нужные правки, в итоге настроили всё так, что вообще ничего не могло пойти не так.

Ясное дело, именно в день запуска что-то пошло не так.

К нашей чести, косяк был не на нашей стороне. Где-то тупо моргнула сеть. То есть сидишь себе такой, настраиваешь всё, чтобы комар не только носа не подточил, но даже не успел подумать об этом — и кто-то где-то просто дёргает не тот кабель.

Всё равно первый сервак мы успели запустить вовремя. Общим дедлайном было 5 утра, к этому времени все серваки должны быть бодры и веселы, потому что первые магазины на Дальнем Востоке открываются в 10 по их времени.

Итого последний сервак запустился в 11 утра. Но так как мы строили систему таким образом, что всё было изолировано, всё заработало нормально.

Сейчас

Сейчас над клубной системой работают 14 разработчиков и 8 аналитиков. Учитывая все плюшки, которыми мы её обвешали, это уже давно не просто карточка, которая даёт вам определённое число бонусов, доступных к трате в магазинах.

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

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

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

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

Благодарный клиент может в этот момент вспомнить, что он хотел купить ещё и носочки, и просит добавить их в чек. Само собой, добавление носочков (или чего угодно) требует полного пересчёта заново.

Но и с этим мы тоже разберемся. А в одном из будущих постов мы расскажем вам историю создания сайта Спортмастера.