Почему нельзя просто «переключить» лояльность
У сети уже была лояльность, встроенная в прежнюю учётную систему, — модуль, привязанный к iiko. Стратегически бизнес шёл к тому, чтобы вести собственную программу лояльности независимо от учётной системы: гибче настраивать механики, не зависеть от возможностей чужого модуля, в перспективе полностью отказаться от него. Но резко отключить старую лояльность и запустить новую с нуля означало бы обнулить баланс и уровень каждого действующего пользователя сети в день переключения — то есть создать самому себе волну недовольства в момент, когда лояльность как раз должна укреплять доверие, а не разрушать его.
Перенос профиля при первом входе
Решение — перенос профиля один раз, в момент, когда пользователь сам заходит в новое приложение. Логика такая:
- Пользователь регистрируется или авторизуется в новом приложении — по номеру телефона и коду из смс.
- В этот момент платформа один раз обращается к прежней системе лояльности и забирает оттуда всё, что нужно: баланс бонусов, код карты лояльности, текущий уровень в программе.
- Дальше платформа этого пользователя больше не обращается к прежней системе. Все последующие начисления, списания, пересчёты уровня — целиком на стороне новой платформы.
Для пользователя это выглядит как обычный вход в приложение: он ничего не переносит вручную, не вводит старый код карты, не пишет в поддержку с просьбой восстановить баланс. Перенос происходит один раз и без участия пользователя, кроме собственно входа в приложение.
Публикация как обновление, а не как новый продукт
Отдельная задача — сделать так, чтобы пользователю не нужно было искать новое приложение в сторе и разбираться, зачем оно, если у него уже есть старое. Новое приложение — разработанное полностью с нуля — команда старается публиковать как обновление уже существующей карточки в сторе, а не как отдельный новый продукт. Тогда у пользователя, у которого уже установлено прежнее приложение, в сторе появляется обычное уведомление об обновлении. По факту при установке этого «обновления» пользователь получает совершенно новое приложение, но для него самого разница должна быть незаметна: он открывает знакомую иконку, авторизуется по телефону и коду — и дальше уже работает перенос профиля лояльности, описанный выше.
Что нужно предусмотреть при переносе
Уровень программы лояльности не всегда однозначно редактируем: если пользователю в новой системе вручную выставить более высокий уровень, чем тот, что фактически подтверждён суммой его покупок, платформа в фоне пересчитывает разницу так, чтобы дальнейшая логика работала, как будто пользователь действительно достиг этого уровня сам — то есть перенос не должен создавать несогласованное состояние, которое потом придётся исправлять вручную.
Стоит заранее продумать настройки на уровне страны, если сеть работает в нескольких странах: обменные курсы бонусов между регионами, если они вообще предусмотрены, максимальный процент оплаты заказа бонусами, условия реферальной программы — всё это должно быть перенесено или настроено согласованно с прежней системой, а не задано заново с нуля для каждой страны отдельно. Подробнее о том, как устроена мультирегиональность на уровне всей платформы, — в статье «Мультирегиональная архитектура ресторанной платформы».
Что проверить перед запуском миграции
Прежде чем включать перенос профиля для всех пользователей, стоит явно протестировать несколько граничных сценариев:
- пользователь с нулевым балансом и без уровня — перенос не должен создавать ошибку там, где переносить, по сути, нечего;
- пользователь с максимальным для системы уровнем и большим накопленным балансом — граница шкалы часто и есть та точка, где проявляются округления и лимиты;
- пользователь, который уже начал операцию (например, оформляет заказ) в момент миграции, — важно понять, что происходит с его текущей корзиной и бонусами;
- повторный вход того же пользователя после переноса — система не должна пытаться забрать профиль из старой системы во второй раз.
