Однажды у нас в CRM появились 3 загадочных клиента. С каждым вёл переговоры отдельный продавец. А потом выяснилось, что эти клиенты — один и тот же человек с одним и тем же имейлом.
Меня зовут Антон Григорьев, я работаю продуктовым дизайнером в финтех-компании и веду телеграм-канал UX Notes. В этой небольшой статье я расскажу, как такое случилось, может ли произойти у вас и о чём стоит дополнительно подумать при проектировании форм регистрации и входа.
Спойлер: это не связано с европейским регламентом по защите данных (GDPR) и правом клиента быть забытым (потребовать от компании удаления всей информации о себе).
Имя пользователя
Адрес электронной почты состоит из локальной части, @ и домена почтовика. Их сочетание позволяет однозначно идентифицировать конкретного получателя почты. В локальную часть попадает имя пользователя почтового сервиса. Например, в адресе anton@gmail.com это имя пользователя «anton».
Стандарт RFC 5322, описывающий формат электронных писем, в локальной части разрешает использовать:
строчные и заглавные латинские буквы,
цифры,
точки (но не в начале или конце и не 2 подряд),
дефисы,
подчёркивания… и, вы удивитесь, много других символов.
Я написал «вы удивитесь», потому что обычно в имени пользователя почтовые сервисы позволяют использовать только перечисленные выше символы (а иногда и того меньше). Поэтому редко можно встретить «+» в адресе электронной почты. Но всё же можно.
Субадресация
Стандарт RFC 5233 описывает практику субадресации (subaddressing). Суть в том, что почтовый сервис при доставке письма может игнорировать то, что в локальной части идёт после определённого символа. Обычно это «+», но могут быть и другие. Субадресацию поддерживают все основные почтовики.
Например, у меня может быть адрес электронной почты anton@gmail.com, но при регистрации на Хабре я укажу anton+habr@gmail.com и всё равно смогу получать письма. Зачем это надо?
1. Борьба со спамом. Оставляя свой имейл в сомнительном месте, можно написать anton+shadyplace@gmail.com и, если на этот адрес начнут приходить письма от нигерийских принцев, можно:
Понять, кто слил данные;
Настроить моментальное удаление писем, приходящих на этот адрес.
2. Сортировка писем. Можно регистрироваться в финансовых продуктах с имейлом anton+finance@gmail.com и настроить фильтр так, чтобы все письма на этот адрес сразу попадали в папку «Финансы».
3. Тестирование продукта QA-инженерами при разработке. Часто для тестирования мало одного пользователя: в продукте взаимодействует несколько ролей, клиенты могут находиться на разных стадиях оказания услуги и так далее. Зачем заводить по ящику для каждого тестового пользователя, постоянно перелогиниваться между ними ради одноразовых кодов, когда ящик может быть один?
Точки, доменные алиасы и регистр
Gmail — единственный из крупных почтовых сервисов игнорирует точки в имени пользователя. То есть письма, отправляемые на anton@gmail.com и an.ton@gmail.com, попадают в один и тот же ящик.
Конечно, этим можно воспользоваться для сортировки почты с определёнными неудобствами и ограничениями: в имя «anton» влезет 16 комбинаций точек, учитывая ограничения RFC 5322. Но в первую очередь фича снижает количество писем, отправляемых не туда из-за опечаток и невнимательности. Знаю человека, которому это спасло однажды много нервов.
У некоторых почтовиков есть несколько доменных имён. Например, Гугл Почта — это и gmail.com, и менее известный googlemail.com. То же самое с yandex.ru и ya.ru, yandex.com, yandex.kz, yandex.by. И так далее. Письма, отправленные на anton@yandex.ru и anton@ya.ru получит один и тот же человек.
И все основные почтовики игнорируют регистр букв в локальной части имейла: что anton@ya.ru, что Anton@ya.ru — всё равно.
Тайна третьей планеты оказалась не такой уж тайной
Выяснилось, что наша форма регистрации ничего этого не учитывает.
Но возник вопрос: надо ли? Если пользователь уже зарегистрирован с адресом anton@gmail.com, надо ли мешать ему зарегистрироваться ещё раз с адресами:
anton+something@gmail.com,
an.ton@gmail.com,
anton@googlemail.com,
Anton@gmail.com.
Понятно, что, если ему потребуется 3 учётных записи в нашем продукте, это не станет непроходимым препятствием. Он просто использует 3 разных ящика.
Но если он просто ошибётся и из-за этого создаст новый аккаунт или не сможет войти в старый? Он может решить, что продукт работает нестабильно (что очень плохо для финтеха). Он может расстроиться, особенно, если в старом аккаунте был какой-то прогресс и контент. Согласно 10 эвристикам Нильсена, хороший интерфейс должен предотвращать ошибки.
И чисто логически: если мы знаем, что 3 разных электронных адреса указывают на один ящик, как-то неправильно создавать с ними разные аккаунты. Например, проблему с дублированием аккаунтов при регистрации через соцсети — решают (см. схему идеальной регистрации Павла Шерера).
Как учесть эти нюансы с имейлами
При регистрации:
Нормализовать имейл: привести буквы к нижнему регистру, взять основной домен почтового сервиса, убрать плюс и всё после него, убрать точки из локальной части для Gmail.
Сравнить с уже существующими в базе нормализованными имейлами.
Если совпадений нет — сохранить и исходный, и нормализованный имейл. Исходный будет отображаться в пользовательском профиле и использоваться для отправки писем. Вдруг человек действительно размечает так почту.
В противном случае — сообщить, что пользователь с таким имейлом уже есть, и предложить войти. Или — что с таким имейлом зарегистрироваться нельзя (если есть требование от безопасников или комплаенса).
При входе:
Не обязательно указывать исходный имейл, поиск всё равно пройдёт по нормализованным.
Если совпадений нет — сообщить, что логин или пароль неверны.
Если совпадение есть и указан корректный пароль — пропустить. Без пароля никто кроме владельца ящика войти не сможет.
При восстановлении пароля:
Не обязательно указывать именно исходный имейл.
Но письмо с инструкцией отправится на исходный. Левый человек этого письма не получит, даже если это странный почтовый сервис, который позволяет разным людям получить адреса anton@domain.com и Anton@domain.com.
Минусы такого подхода:
Пользователи упомянутого выше странного почтового сервиса с имейлами anton@domain.com и Anton@domain.com смогут зарегистрироваться в нашем продукте только один раз. Кто первый — того и тапки. Но это маловероятно, так как такие почтовые сервисы — скорее исключение.
Тестировщикам придётся использовать разные ящики для тестовых аккаунтов, что неудобно. Но можно сделать исключение для имейлов с доменом нашей компании.
Как делают другие
Да почти никак. Вот как популярные продукты воспринимают имейл, который в нормализованном виде совпадает с уже зарегистрированным:
Имейлы | ChatGPT | Notion | Amazon |
+something | ❌ Как новый | ❌ Как новый (отправляет код для подтверждения регистрации) | ❌ Как новый |
Точки и домен gmail.com | ❌ Как новый | ❌ Как новый | ❌ Как новый |
Домен googlemail.com | ❌ Как новый | ❌ Как новый | ❌ Как новый |
Заглавные буквы | ✅ Как уже зарегистрированный (предлагает ввести пароль, чтобы войти) | ✅ Как уже зарегистрированный (отправляет код для входа) | ✅ Как уже зарегистрированный (предлагает ввести пароль, чтобы войти) |
Складывается впечатление, что это не база, а скорее nice to have фича.
Вывод
Такую проверку неплохо иметь, но её внедрение — отдельная задача, требующая ресурсов и разработчиков, и проектировщиков. Популярные продукты, у которых другие периодически подсматривают те или иные решения, с этим не заморачиваются. Так что надо в каждом конкретном случае решать, заниматься этим или нет. Мы, например, посмотрели на эти 3 имейла нашего клиента, исследовали вопрос и добавили задачу в беклог.
В большинстве других продуктов эта статья, вероятно, не вызовет никаких изменений, но проектировщики как минимум смогут этот вопрос поднять и тем самым продемонстрировать команде свой уровень технической эрудиции.
Полезные материалы:
