Один клик вместо десяти: как мы избавились от сложной сети подтверждений в рассылках. Часть 1
Привет, это Ксюша Василенко, проджект-менеджер в коммуникациях Т—Ж и Бизнес-секретов.
Мы помогаем медиа распространять контент и связываться с пользователями с помощью коммуникаций. Сейчас это рассылки, пуши и попапы для медиа Т—Ж в вебе и двух приложений: Т—Ж и Учебника. С их помощью мы напоминаем о новых курсах Учебника, регистрируем людей на конференции, проводим опросы, приглашаем на исследования, сообщаем о новинках и проводим тесты для повышения бизнес-метрик.
В этом тексте я расскажу, как мы полностью перепридумали путь пользователя при регистрации и подписках в Журнале. С самого начала у нас был план, и все пошло не по нему.
Нужно больше подтверждений
Год назад коммуникации использовались в ограниченном числе сценариев: в основном мы возвращали людей на сайт и в приложения. Пользователю достаточно было зарегистрироваться и подтвердить подписку раз, чтобы получать наши письма. При появлении новой рассылки мы просто добавляли еще один пользовательский сценарий, как если бы она была единственной.
Но число рассылок росло, и для каждой из них пользовательский сценарий мог как-то отличаться. Вдобавок росло и число точек подписки — это могли быть формы внутри статьи, в подвале, на отдельной странице, — и каждая предполагала отдельный сценарий.
В какой-то момент мы потеряли контроль над этой системой и лишь заполняли пробелы новыми заплатками-сценариями и костылями. Чем больше их становилось, тем труднее нам было поддерживать систему, а пользователю — работать с Т—Ж:
Мы знали почту зарегистрированных пользователей, но зачем-то просили ввести ее повторно при новой подписке.
Мы просили подтверждать уже подтвержденную почту каждый раз, когда пользователь подписывался на что-то новое.
Активные пользователи Т—Ж не могли контролировать свои подписки: не знали, на что они подписаны и где это посмотреть.
Все это снижало конверсии в подписку и нагружало поддержку вопросами от читателей. Чтобы облегчить всем жизнь и стабильно растить базу пользователей, мы решили реализовать единый и простой флоу для регистрации и подписки.
Что в коробке?
В Т—Ж всеми действиями пользователя управляет бэкенд — соцплатформа. Она отвечает за авторизацию, подписки, баны и многое другое. Для отправки рассылок мы используем сервис «Майндбокс» — это CDP-платформа, которая закрывает все маркетинговые и аналитические потребности коммуникаций. Пользователь совершает действие в Журнале, которое обрабатывает соцплатформа, и она же передает информацию в «Майндбокс». После этого «Майндбокс» отправляет нужную коммуникацию.
Например, вот что происходит под капотом, когда пользователь впервые регистрируется в Журнале:
- Он вводит почту для регистрации.
- Бэк проверяет, есть ли эта почта в соцплатформе.
- Платформа передает имейл пользователя в «Майндбокс».
- «Майндбокс» проверяет, есть ли пользователь с таким имейлом в базе.
- Если нет, то заводит карточку клиента с действиями: зашел на страницу Журнала, запросил код для регистрации, отправка письма с кодом авторизации
- Код формируется со стороны соцплатформы и отдается в «Майндбокс».
- «Майндбокс» отправляет письмо с кодом на почту пользователя.
Это лишь один сценарий, и причем довольно простой. А их, как я уже говорила, было множество. Вся система работала как-то так:
Пользователь мог подписаться из любого места в Журнале: из фичера, лендинга подписок, плейсмента в статье и попапа, страницы рассылок. В зависимости от места подписки, количества подписок и статуса пользователя действовала своя логика. А еще иногда читатели пользовались разными формами входа — по электронной почте, через «Одноклассники» или Гугл, по номеру телефона, T‑ID — и либо выглядели для нас как отдельные люди, либо информация о способе входа не долетала до «Майндбокса».
Пока я работала над задачей, запретили регистрацию и авторизацию через зарубежные платформы. С одной стороны, стало меньше кейсов и совпадений, с другой — это создало новые проблемы: как теперь быть с такими пользователями?
Скажу честно: я очумела — если не сказать иначе. Просто на то, чтобы понять, что происходит в нашей системе, ушел целый квартал. И это была даже не половина того, что предстояло сделать.
Создаем «каракури»
Наша платформа была тесно связана с «Майндбоксом», и, чтобы привести систему в порядок, нужно было разделить зоны ответственности. Мы свели все наши сотни сценариев к 14 кейсам и отдали разработке. Разработчики составили рабочие предложения (RFC), и… ничего не произошло. Начались долгие сеансы коллективных медитаций на RFC, где команды рассматривали разные варианты решений, но не приходили к реализации.
В какой-то момент возникшая пауза начала пугать: на носу был конец года, фриз на разработку, непонятны были ни объемы задач, ни когда их начнут решать. К счастью, в Журнале есть опытный бэкендер (Ваня, привет!), который создавал соцплатформу и отлично разбирался в логике «Майндбокса».
Результатом стало нечто, что в Японии могли бы назвать «каракури» — сложное, но изящное техническое решение, которое делало работу всей системы простой.
Многочисленные транзакции между нашей платформой и «Майндбоксом» ушли в прошлое: все, что можно решить самостоятельно, мы передали соцплатформе. В итоге вместо клубка пользовательских путей Т—Ж получил ровный однонаправленный поток информации:
Параллельно мы с дизайнерами составили новый UX-флоу пользователя: экраны взаимодействия с читателем, лендинги, письма. Также приготовили абсолютно новую фичу — управление подписками в профиле пользователя в Журнале.
К середине декабря 2023 расписали эпики для работы над единой регистрацией и подпиской и управление подписками в профиле, готовые макеты, тексты ошибок и писем. О том, что пошло не так при попытке распутать наш клубок регистраций и как это повлияло на 2 млн пользователей, расскажу во второй части статьи. А для самых нетерпеливых читателей показываю на тигре: