Однажды у нас в 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 разных электронных адреса указывают на один ящик, как-то неправильно создавать с ними разные аккаунты. Например, проблему с дублированием аккаунтов при регистрации через соцсети — решают (см. схему идеальной регистрации Павла Шерера).

Как учесть эти нюансы с имейлами

При регистрации:

1. Нормализовать имейл: привести буквы к нижнему регистру, взять основной домен почтового сервиса, убрать плюс и всё после него, убрать точки из локальной части для Gmail.

2. Сравнить с уже существующими в базе нормализованными имейлами.

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

4. В противном случае — сообщить, что пользователь с таким имейлом уже есть, и предложить войти. Или — что с таким имейлом зарегистрироваться нельзя (если есть требование от безопасников или комплаенса).

При входе:

1. Не обязательно указывать исходный имейл, поиск всё равно пройдёт по нормализованным.

2. Если совпадений нет — сообщить, что логин или пароль неверны.

3. Если совпадение есть и указан корректный пароль — пропустить. Без пароля никто кроме владельца ящика войти не сможет.

При восстановлении пароля:

1. Не обязательно указывать именно исходный имейл.

2. Но письмо с инструкцией отправится на исходный. Левый человек этого письма не получит, даже если это странный почтовый сервис, который позволяет разным людям получить адреса anton@domain.com и Anton@domain.com.

Минусы такого подхода:

• Пользователи упомянутого выше странного почтового сервиса с имейлами anton@domain.com и Anton@domain.com смогут зарегистрироваться в нашем продукте только один раз. Кто первый — того и тапки. Но это маловероятно, так как такие почтовые сервисы — скорее исключение.

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

Как делают другие

Да почти никак. Вот как популярные продукты воспринимают имейл, который в нормализованном виде совпадает с уже зарегистрированным:

Складывается впечатление, что это не база, а скорее nice to have фича.

Вывод

Такую проверку неплохо иметь, но её внедрение — отдельная задача, требующая ресурсов и разработчиков, и проектировщиков. Популярные продукты, у которых другие периодически подсматривают те или иные решения, с этим не заморачиваются. Так что надо в каждом конкретном случае решать, заниматься этим или нет. Мы, например, посмотрели на эти 3 имейла нашего клиента, исследовали вопрос и добавили задачу в беклог.

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

Полезные материалы:

• Чек-лист по проектированию регистрации;

• Инструкция: как написать идеальную регистрацию;

• Стандарты RFC 5322 и RFC 5233.