Привет, Хабр! Я — Марина Заботина, аккаунт-директор в диджитал-продакшене Далее. Сегодня рассказываю о том, как увеличивали долю онлайн-покупок на термальном курорте ЛетоЛето и уменьшали количество очередей в кассах. Приготовьтесь, будет много схем.

Мы работаем с термальным курортом ЛетоЛето, который находится в Тюмени (советую там побывать). И у них возникла потребность в оптимизации процесса покупки билетов на курорт. У курорта уже был сайт, команда клиента проделала большой путь в digital. Но оставались некоторые сложности в UX, и они были связаны с кодом: сбой регистрации пользователей, невозможность использовать накопленные баллы в программе лояльности для оплаты билетов. Ошибки приводили к тому, что клиенты отказывались от онлайн-покупок и приходили за билетами в офлайн-кассы. Плюс была большая нагрузка на поддержку.

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

Чтобы справиться со сложностями, мы оптимизировали интеграции и код системы. Рассказываем, как это было. 

Какие системы участвуют в процессе регистрации и как происходит взаимодействие

Мы начали с аудита процесса регистрации и покупки билетов и выяснили, какие системы участвуют в процессе и как они взаимодействуют:  

• Бэкенд. Реализует внутреннюю логику работы веб-приложения, обеспечивает взаимодействие с базами данных и внешними сервисами. 

• TNG. Система управления программой лояльности. Выполняет операции с бонусным счетом клиента при покупке билетов: накопление или списание бонусов, показывается баланс. 

• BARS. Система продажи билетов. Рассчитывает финальную стоимость заказа и формирует запросы к банку-эквайеру на генерацию страницы оплаты. 

Взаимодействие трех систем: бэкенда, TNG (система лояльности) и BARS (система продажи билетов) происходило следующим образом.

Когда пользователь регистрировался на сайте, бэкенд отправлял запрос на регистрацию такого пользователя TNG. TNG, в свою очередь, инициировала создание аккаунта на стороне BARS. Если заказ оформлял пользователь-участник программы лояльности, BARS отправлял в TNG запрос и получала информацию о количестве баллов у этого аккаунта. Далее рассчитывался размер скидки, количество баллов, которые можно списать, и отправлялись данные эквайеру для создания страницы оплаты. 

Баллы, начисленные после покупки, рассчитывались в бэкенд-системе. Эти данные бэкенд отправлял в TNG для учета в профиле пользователя. Так зарегистрированный клиент копил баллы, повышал грейд, увеличивал скидку на билеты и так далее.   

Какие сложности выявили и как их исправляли

Связь между тремя системами последовательно выстраивается в режиме реального времени. Регистрация профиля в бэкенде и последующее создание аккаунта в TNG или BARS не происходит мгновенно. Если в процессе «протягивания» профиля через три системы случится ошибка на любом из этапов, аккаунт в одной из систем создать не получится. 

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

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

Сбой при регистрации новых пользователей

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

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

Создание аккаунтов новых пользователей происходило на стороне бэкэнд-системы, которая затем передавала данные в TNG и BARS для создания профилей. Реализация была выстроена таким образом, что самой системе не было понятно, завершился ли процесс регистрации полностью. Случаи сбоев не всегда учитывались. Порой система пыталась повторить процедуру создания и связывания профилей при новой попытке входа пользователя в аккаунт.

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

Также нашли решение для проверки регистрации — она должна завершаться созданием профиля пользователя не только в TNG, но и в BARS. Создали задачу на проверку текущего статуса процесса: если аккаунт пользователя в BARS не создан, система пытается выполнить регистрацию с интервалом в несколько миллисекунд. Общее время попыток ограничили тридцатью минутами. 

В админку бэкенда вывели статусы, которые показывают, произошло ли создание и связка аккаунтов в трех системах. Если нет — администратор в ручном режиме перезапустит процедуру. В этом случае баллы за первую регистрацию не потеряются — они автоматически появятся в профиле TNG-системы. А баллы за саму покупку можно подгрузить в ручном режиме.  

Множественные профили и невозможность использовать баллы

Случались ситуации, когда система не «узнавала» участников программы лояльности из-за чего они не могли использовать баллы. При попытке клиента войти в аккаунт, сайт возвращал ошибку о том, что такой пользователь не зарегистрирован. Если человек регистрировался заново с теми же учетными данными, доступа к баллам он все равно не получал. При создании новой записи, связь со старым аккаунтом терялась. 

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

Мы стали выяснять, отвечает ли за эту ошибку TNG или причина в другом. Оказалось, что в ЛетоЛето был собственный бизнес-процесс, в ходе которого сотрудники  импортировали данные в TNG напрямую из базы данных, а не через API. Это и приводило к дублированию аккаунтов. Менять бизнес-процесс клиент не мог, поэтому нужно было решать проблему в текущих ограничениях. 

Для этого мы встроили алгоритм проверки множественных профилей и их валидации. Если по API-запросу из TNG вместо одного профиля получаем несколько, ищем среди них валидный. Создали набор маркеров, по которым отличаем дубль профиля от настоящего: наличие бонусного счета, истории покупок, грейдов и так далее. Находим такой профиль, остальные инвалидируем. Если подходящих профилей оказывается больше одного, то в качестве валидного используем первый созданный. 

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

Цены и финальный расчет стоимости 

Данные о ценах на билеты хранились в стороннем API (BARS) и локально — на сайте ЛетоЛето в специальной секции тарифов. Туда их добавляли контент-менеджеры 

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

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

Чтобы уберечь клиента от возможных рисков и оптимизировать бизнес-процесс, мы предложили использовать для расчета билетов и покупки только данные из мастер-системы, то есть BARS. 

Разработали новый алгоритм и подготовили демо-версию, чтобы продемонстрировать его ЛетоЛето. В процессе тестирования столкнулись с критичным ограничением, которого не было в документации. После запроса на итоговый расчет стоимости в BARS создавался финальный объект заказа с итоговым вариантом цены. Пересчитать или вернуть его к предыдущему состоянию было невозможно. А нам требовались промежуточные вычисления. 

Например, пользователь добавил билеты в корзину, нажал «Оплатить», а потом вспомнил, что у него есть баллы в системе лояльности. Возвращается к заказу, логируется на сайте — система должна учесть баллы и пересчитать стоимость билетов. Такую операцию с существующим на тот момент API BARS произвести было нельзя. 

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

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

Что еще мы сделали

Помимо упомянутых пунктов, мы также сделали еще два важных шага:

1. Настроили отправку приобретенных билетов в CMS и на почту пользователя.

2. Для корректной работы Битрикс24 оптимизировали количество клиентских заявок. Теперь они обрабатываются быстрее и бронирование проходит без сбоев. 

За счет корректной работы сервисов выросла производительность — интерфейс быстро загружается и на покупку билетов уходит всего 5 минут. 

Что дала оптимизация интеграций

• Помимо поиска и исправления ошибок, мы учли предыдущий опыт и построили прозрачную систему логирования. Теперь логируется весь процесс заказа: на каком этапе находится, что сейчас происходит, где произошел сбой и почему. Информация пишется в отдельный лог. Если что-то идет не так, можно посмотреть и выяснить причину. Что важно и приятно, после нашей оптимизации интеграций таких ошибок пока не возникало. 

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

• Технические доработки напрямую повлияли на лояльность пользователей: клиенты ЛетоЛето успешно накапливают баллы, не сталкиваются со сложностями при регистрации и входе на сайт. Сами процессы регистрации и покупки билетов стали корректнее с точки зрения бэкенда.