Привет, Хабр! В крупных и не очень компаниях перед разработчиками нередко ставят задачу создать качественную реферальную программу, которую просто настроить, а также программу лояльности. Сейчас хотелось бы поговорить о втором случае - есть хороший кейс компании Grow Food, сервиса доставки здоровой еды по подписке.
У компании возникла необходимость построить собственную программу лояльности, которая позволила бы повысить заинтересованность пользователя в продукции и вовлечь его в процесс создания заказов, получения доставок, в частности, путем достижения определенных уровней и получения наград. Эта статья как раз о том, как программа была реализована и из каких элементов состояла, а также с какими проблемами пришлось столкнуться в процессе работы.
Базовая концепция программы лояльности
Понятно, что прежде, чем начать работать над созданием программы, идею нужно было оформить в четкую концепцию, согласно которой и нужно было вести процесс разработки. Идея состояла из нескольких элементов:
Бонусы - виртуальные средства, которыми можно оплатить часть заказа. Средства начисляются за разные действия пользователя. Ну и на базе начисления и трат бонусов строятся уровни лояльности.
Уровни лояльности. Клиент движется от уровня к уровню в зависимости от количества полученных доставок. Чем их больше, тем более активное продвижение и тем больше пользователь получает наград, бонусов и привилегий.
Привилегии. Есть разовые ачивки - например, по достижению Silver-уровня автоматически начисляется 500 бонусов, которые можно использовать в каком-то из заказов в качестве скидки. Есть пассивные ачивки - это, например, процент кэшбека. Так, если стандартный кэшбек составляет 10%, то, скажем, клиент, достигший Silver-уровня, получает по 1% к кэшбеку на каждый заказ. На одним из последних уровней это уже дополнительно 5-7% кэшбека, что весьма ощутимо. Клиентам предлагаются и награды, включая бесплатная доставка в течение часа и бесплатная замена блюда в том случае, если пользователь решил что-то поменять в заказе.
Возможность оплаты бонусами. Это еще одна пассивная привилегия. Которая позволяет полностью оплачивать заказ бонусами, без оплаты его деньгами.
Механика сгорания - все уровни программы лояльности не выдаются клиенту навечно. Они могут сгореть, если пользователь надолго прекращает работу с сервисом. Но “сгорания” можно отложить на месяц. Плюс есть два несгораемых статуса которые остаются с клиентом навсегда, то есть ниже определенного уровня он не может упасть.
Что касается всех прочих элементов программы лояльности, то вот скрин, где показана структура уровней и бонусы для каждого из них.
Это только часть возможностей, которые хотелось реализовать. Пока хотелось бы показать, как двигался процесс разработки программы.
Время, команда и алгоритм
Забегая наперед, стоит сказать, что с момента появления идеи о необходимости внедрения программы лояльности до ее релиза прошло месяцев 10, плюс после еще около пары месяцев команда вносила мелкие правки и добавления.
Над программой работала команда из пяти человек: бэкенд-разработчик, фронтенд-специалисты (два человека, на iOS и Android), тестировщик, дизайнер и продакты.
Что касается бэкенда, то реализовано все на базе основной части системы, монолита, который внутри компании называют админка. Это ядро системы, которое объединяет в единое целое заказы, доставки, финансы, все, что связано с биллингом и скидками и клиентам.
Кроме того, это еще и СRМ-система, которая обеспечивает работу логистики и колл-центра. Эта система буквально "обвешана" API для прочих систем. Так, внутри нее был написан отдельный сервис, который управляет бонусами - распределяет, сжигает, рассчитывает и т.п.
С фронтендом все просто, так как для клиента доступны мобильные приложения написанные на нативных для платформ языках Kotlin и Swift, для Android и iOS соответственно. Для Web версии программа лояльности не доступна, для доступа к ней необходимо установить мобильное приложение.
Что касается разработки программы, то алгоритм можно считать относительно универсальным - его может использовать и почти любая другая компания, которой нужна программа лояльности или определенная функция/возможность.
Бизнес-проектирование. На этом этапе продукт-оунер описывает, как все должно работать. Он рассказывает о целях программы и проводит сравнение с аналогичными программами других компаний. Важно отметить, что сюда входят драфт-дизайн, подбор нейминга с маркетингом, расчеты разны показателей и моделей, включая финансовые. Вот так выглядел план проведения этого этапа:
Ресерч. Сюда добавили брейншторм, первичную аналитику похожих кейсов других компаний, проведение кастдева с продактами.
Целеполагание и финансовая оценка. Здесь анализ сценариев, их детальное целеполагание, оценка метрик, возможного прироста в деньгах.
Решение о целесообразности проекта на базе предыдущего пункта.
Описание бизнес-логики изменений.
Верификация идеи и проекта.
Оценка рисков.
Проектирование технических изменений в платформах.
План “разгона”. Добавление ключевых метрик по этапам.
Список задач в жире и апдейт роадмапа.
Кстати, решение что-то менять началось с того, что сразу несколько крупных игроков, включая "Яндекс", перешли с прямых скидок на кэшбек. Стало ясно, что это новый долгоиграющий тренд, в который нужно было попасть. Важность тренда в том, что это отложенная скидка. Она по факту позволяет экономить деньги на прямых скидках и повышать уровень возврата клиентов. Дело в том, что у клиентов всегда на счету есть какие то деньги и это стимулирует его вернуться и сделать еще один заказ.
Развитие бонусной системы. Главный смысл этапа бонусной системы в том, что это, как правило, фундамент, поверх которого строится программа лояльности. В данном случае даже этот “фундамент” был написан с нуля. Мы выбросили всю старую систему бонусов и написали заново. Причина - старая система была очень сложная, с минимумом настроек. Более того, она не отвечала требованиям по функционалу и скорости работы. В целом, проще было написать новую, чем привести в порядок то, что было. Для начала мы добавили не особо развернутую программу бонусов. Далее же к ней подключилась уже и программа лояльности, которая дала возможность развиваться всей бонусной системе. Пользователи получили возможность копить бонусы, а также получать дополнительные плюшки.
Проработка дизайна и механики сформировавшейся концепции. В данном случае над ней работали специалисты по UI, которые вместе с оунером продумали весь путь пользователя по программе лояльности, а далее - сформировали дизайн. По результатам обсуждения сформировали табличку из 28 пунктов, в каждом из которых обсуждали определенные проблемы, предлагали решение и назначали исполнителя. Пример ниже.
Техническое проектирование. На этом этапе мы максимально подробно продумываем и расписываем такие моменты, как хранение данных, сущности и их связи, маршруты, новые API и доработка старых. Кроме того, описываем логику внутренних сервисов, а также тонкости взаимодействия фронтенда с бэкэндом. Затем - пишем тестовые кейсы для удобства тестирования. В финале “нарезаем” все это на задачи, оцениваем их и распределяем по спринтам. То есть, это классический agile процесс.
Тестирование и релиз. Программа лояльности постепенно "раскатывается" по разным сегментам аудитории в процессе тестирования, после чего выпускается уже полноценный релиз для всех. Готовые части программы лояльности включались в состав приложений и открывались на тестовые группы. Первыми участниками тестов были сотрудники компании, большинство - пользователи Grow Food.
Важный момент - часть программы лояльности, первые три уровня, мы делали как отдельный релиз и затем обкатывали. Кроме того, был отдельный релиз с анимацией получения нового уровня - нужно было протестировать ее на разных устройствах, чтобы убедиться, что все работает, как и задумывалось. Что касается текущей программы, то готова версия в iOS, через пару недель будет готова и версия для Android.
Что насчет проблем?
Без них, конечно, не обошлось, хотя, к счастью, большинство удалось решить достаточно быстро.
Не стоит забывать об аналитике. Формат хранения данных - его пришлось изменить несколько раз. Наиболее важный момент в процессе создания формата - нужды аналитиков и BI. Изначально интересы бизнес-аналитики упустили и виду, поэтому чуть позже пришлось все менять, поскольку для аналитики требуется подробная информация.
Тут стоит чуть подробнее описать нашу внутреннюю кухню. Основные сущности в наших системах это клиент, который может иметь несколько заказов. Последовательные заказы объединенные в цепочку это подписка. Внутри каждого заказа есть несколько доставок, внутри каждой из них - несколько дней питания, в каждом дне питания есть несколько приемов (завтрак обед и т д). Ну а в каждом дне питания одно или несколько блюд - именно то что клиент будет кушать.
Основной учетной единицей в наших системах является “доставка” - конкретный объем товара который привозится к клиенту. Именно к этой сущности привязан весь учет. учет товара, стоимостей, чеков и прочего. В тоже время клиент в основном оперирует понятием заказ, именно его видит клиент в приложении, именно за него клиент платит и именно на заказ клиент тратит заработанные бонусы.
Так вот, в рамках технического проектирования мы не достаточно качественно провели этап согласования архитектуры хранения с командой BI. Это произошло из-за того что в рамках тех проектирования мы уточняли многие аспекты бизнес проектирования (можем ли мы так сделать как придумал дизайнер, а все ли будет хорошо и тд), схема данных постоянно менялась.
Итоговая схема согласованная со всеми заинтересованными отделами включала в себя таблицы где отдельно хранились начисления бонусов, из перемещения с указанием причины (списание или сгорание) с привязкой к номеру доставки, а также таблицы с агрегированными данными вроде текущего баланса бонусов по клиенту, суммы бонусов к ближайшему сгоранию и прочее.
При этом изменения пришлось вносить поэтапно, таким образом, чтобы не ломать всю базу аналитики, что было совсем не просто решить.
В результате учет движения бонусов построен очень гибко. Он позволяет отвечать даже на такие сложные вопросы, как: “Сколько блюд с рыбой съел клиент когда находился в статусе Gold и какова средняя оценка таких блюд”. Также можно рассчитать в рублях, сколько было потрачено на всех клиентов получивших привилегию бесплатной доставки в часовой интервал в зависимости от региона доставки.
В целом, ошибка классическая, но тем не менее. Решение - сначала финализировать требования и убедиться в их выполнимости, затем уже, не пропуская этапы проектирования, выполнять работы.
Хранение данных и расчет цен. Бесплатная замена блюда на определенном уровне пользователя. Казалось бы, несложная функция, которую можно без проблем добавить. Но нет, как оказалось, она связана с рядом других компонентов, некоторые из которых были весьма глубоко "закопаны". Приходилось в поиске решения дергать других разработчиков их команды, просить их поддержки. В итоге методом проб и ошибок удалось разобраться, сделав вполне рабочий механизм добавления бесплатной замены.
Это одна из самых сложных в реализации фичей, которая связана с особенностями построения наших систем. Так как у нас не хранится совсем в явном виде финальный состав заказа пользователя. Он вычисляется каждый раз как текущее основное меню, поверх которого применяется список замен пользователя. Грубо говоря, пользователь видит базовое меню, и свои замены в нем,а мы храним именно эту разницу, а не меню в пользователя целиком.
Второе - для каждого пака и лотка есть несколько цен. Они могут меняться как в случае даты заказа, так и даты питания. Один и тот же лоток может иметь как минимум четыре цены. Кроме того, есть еще и внутренние наценки. Так, если лоток является стандартным меню, это одна цена. Если лоток был заменен пользователем на уникальный, то его стоимость будет чуть выше, поскольку собрать сто одинаковых коробок это одна цена, а пятьдесят уникальных коробок - другая. Разница в цене невелика, но она есть.
Все это реализовать на практике было сложно, плюс пришлось очень тщательно все тестировать, чтобы не сломать все цены одним неосторожным движением.
Ядро системы. Ядро лежит в основе всего, но некоторые возможности "закопаны" так глубоко, что при разработке новой функции приходится в этой глубине рыться. Причем разные части системы написаны разными людьми, так что приходится тратить немало времени на случай внедрения подобных изменений.
Кроме того, в начале работы не предполагалось, что какие-то возможности мы будем менять в будущем. Поэтому часть элементов ядра были жестко прописаны - и для того, чтобы их в итоге изменить, пришлось изрядно поработать.
Пример - модуль, который отвечает за стоимость логистических операций. Так, доставка заказа в отдаленный регион Подмосковья будет стоит дороже, чем доставка в удобный пригород Питера. Все логистические фичи разрабатывались отдельной командой. Программа лояльности дает новые возможности и требует изменений в логистике. Например, клиент может сделать заказ в удобный ему часовой интервал бесплатно. Мы решили призвать разработчика из сторонней команды и попросили его встроить модуль. Мы разъяснили все детали и он сделал все достаточно быстро. Но, конечно, ему пришлось адаптироваться какое-то время, изучая особенности системы.
Тестирование и релизы. После того, как все вроде бы подготовили, наступил черед тестирования. Мы решили запускать новый функционал поэтапно, на часть пользователей, а не всех сразу. И это было правильно, поскольку сразу же обнаружились казусы.
Так, возникла проблема с учетом истории старых пользователей. Нам было нужно учитывать историю тех клиентов, которые ранее активно пользовались услугами компании. Каждому такому клиенту хотелось присвоить уровень лояльности, который соответствует прошлым заслугам. Еще мы просчитывали "жизни" - так, если клиент не пользуется сервисом больше 30 дней, то для него история работы с сервисом обнуляется. Все эти моменты нужно было учесть и просчитать. Но сделать это было не так просто, поэтому мы создали отдельную команду, которая занимается анализом истории заказов пользователей с изменением их статуса в системе.
Причем из-за особенностей подсчета количества заказов некоторым клиентам был ошибочно присвоен "высший" статус в истории заказов с максимальными скидками. После обнаружения ошибки ее быстро исправили.
Сам процесс старта программы лояльности, состоит из нескольких честве, мы начисляем, во-первых бонусы, ачивки и т.п., во-вторых, требуется оповещение пользователей - это задача отдела маркетинга. Также нужно учитывать нагрузку на систему и производить запуск не в пиковые часы - проводили это ночью, чтобы не нагружать систему лишними действиями. Ну а раз ночью - то пришлось отключить часть уведомлений, чтобы клиентам посреди ночи не стали приходить sms о начислении бонусов.
Релиз и выкатка - это сотрудничество разных отделов, для каждого из которых собственные задачи и тут важно поддерживать высокий уровень коммуникации.
В качестве вывода
Путь, который выбран для разработки программы лояльности в этом кейсе, конечно, не единственный. Тем не менее, он оказался достаточно эффективным. Вот основные выводы, которые можно сделать, оценив проделанную работу.
Во-первых, мы убедились в том, что все идеи, которые заложены в бизнес-проектировании, сработали. Так, предположение, что это увеличит приток пользователей, они будут делать более "длинные заказы", будет возврат пользователей и т.п. это все сработало. LT на дистанции в квартал вырос на 20% у контрольной группы. Это самый важный бизнес-итог, мы внедрили идею, которая просто работает.
Во-вторых, у нас получилась, фактически, модульная платформа, которую можно легко расширять и модифицировать. Ближайшее, что планируем реализовать - разные партнерские бонусы. Так, по достижению определенного уровня пользователь будет получать подарки и привилегии в других сервисах. Это легко встраиваемая в новую платформу фича. Кроме того, в платформу можно встраивать дополнительные функции и возможности, включая, например, передачу бонусов другу на день рождения.
В-третьих, так как во время разработки программы лояльности пришлось работать со многими частями системы, мы переделали и модифицировали многие модули, включая ценообразование, учет и т.п. Так, систему учета мы изменили таким образом, что BI-аналитика смогла без проблем работать с этими данными. Это хороший референс для дальнейшей работы. То же самое касается и межкомандных взаимодействий. Мы поняли, как усиливать и расширять команду при помощи разработчиков из других команд. Кроме того, мы получили и дополнительные компетенции, так, процессы, связанные с релизами, колоссально улучшились именно благодаря выкатке платформы. С точки зрения разработчиков - это крайне важно.
В целом, это все, о чем хотелось бы рассказать. Если у вас есть собственные соображения, советы, опыт - давайте обсудим все в комментариях.