Проверять или не проверять — вот в чём вопрос

image

Немало копий поломано в вопросе о том, как следует проверять адрес электронной почты (например, habrahabr.ru/post/175329), но позвольте предоставить вам немного статистики с реального проекта.

Многие захотят спросить, зачем мы её собрали.

Проблема прозаична обычна: в какой-то момент после выпуска аналитик проекта выгрузил статистику по использованию сервиса и понял, что она врет. А врет она потому, что там есть тестовые пользователи, в т.ч. для нагрузочного тестирования. И как оказалось, не все разработчики/тестеры использовали правильную маску для тестовых email. Поэтому, основной задачей было пометить предположительно тестовые email, что и было успешно сделано. Заодно мы получили немного интересной статистики, коей и хотим поделиться.


Итак, есть сервис, который не требует проверки e-mail перед созданием учётной записи. На момент написания поста имеем около 5000 зарегистрированных пользователей. Конечно, отсутствие пробелов, наличие «собаки» и прочие явные ошибки были указаны пользователю ещё на этапе ввода, а потому в базу не попали. Получается, что мы не можем достоверно понять, ошибся ли пользователь в левой части e-mail (нельзя ведь исключать, что он опечатался, но и нельзя быть уверенным, что он это сделал), то её сразу следует отбросить. Что мы имеем после этого — домен, а в домене есть домен верхнего уровня.

Оказывается, более одного процента пользователей ошибаются и используют вместо домена верхнего уровня .com, домен .con, это связано с похожестью данных букв и соседним расположением на клавиатуре. С доменами в зоне .ru такой проблемы не обнаружено. Также по косвенным признакам (левая часть email и другие характеристики) был найден еще как минимум один процент пользователей (от общего числа, а не только в зоне com), заметивших ошибку и исправивших её (т.е. в базе есть два очень похожих аккаунта, один из которых неактивный).

image

Итого, мы имеет как минимум 2 процента неправильных e-mail«ов. Нужно ли что-нибудь делать с этим? Для этого нужно ответить на вопрос,


Чтобы иногда писать ему письма?
Нестрашно, переживем.
Чтобы у пользователя сохранилась история и/или ему не пришлось бы регистрироваться ещё раз?
Скорее всего, тоже переживем.
Чтобы отправить пользователю информацию о заказе и т.п.?
Пользователю придется поволноваться, пока не получит свою покупку или звонка менеджера. Или даже обратиться в техподдержку. Наверное стоит помечать заказы, для которых не удалось доставить письма, и при звонке таким пользователям дополнительно уточнять e-mail.
Чтобы пользователь мог хранить в вашем сервисе полезные вещи?
Вот это уже серьезней, захочет потом войти ещё раз, и не получится. И хорошо если догадается в чем причина. А ведь может зарегистрироваться ещё раз и начать кричать, что данные пропали.
Черный или белый список? Можно проверять домен верхнего уровня на наличие в предопределенном списке, который нужно будет часто обновлять (см., например, habrahabr.ru/company/yandex/blog/180355), или на лету проверять на наличие в data.iana.org/TLD/tlds-alpha-by-domain.txt, или же наоборот отфильтровывать явно опечаточные домены, вроде .con.

Запрещать или разрешать? Стоит ли запрещать регистрацию, если, как нам кажется, введенный пользователем e-mail — неправильный? Мне кажется, что нет, но его нужно предупредить и предложить исправить.

Оффтопик: Меня жутко бесят требования сайтов ввести пароль длиннее 7 символов, и чтобы он содержал буквы разные, цифры и знаки препинания, хотя я знаю, что никогда больше не вернусь сюда. Ах да, вы не можете использовать пароль password, а вот gfhjkm конечно же сгодится. А ведь можно предупредить пользователя, что его пароль слабый и, если он таки его заиспользует, то никакие претензии рассматриваться не будут. Хотя как показывает опыт общения с разными службами они всё равно не будут рассматриваться.

Как это работало в стародавние времена

— Что же здесь написано? — спросил Фродо, который старался прочесть надпись на арке. — Я думал, что знаю письмо эльфов, но это я не могу прочесть.
— Это слова эльфийского языка древности с запада Средиземья, — ответил Гэндальф. — Но они не говорят ничего важного для нас. Вот что они означают: Дверь Дьюрина, повелителя Мории… Скажи, друг, и входи.
— А что значит «скажи, друг, и входи»? — спросил Мерри.
— Это-то ясно, — ответил Гимли. — Если ты друг, скажи условное слово, дверь откроется, и ты сможешь войти.
— Да, — подтвердил Гэндальф. — Эта дверь, вероятно, управляется словом.

<…>

Он вновь подошел к скале и слегка коснулся своим посохом серебряной звезды в середине, под знаком наковальни. Повелительным голосом он сказал:

— Аннон эдхолен, эдре хи аммен!

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

<…>

— Я все-таки ошибся, — сказал Гэндальф, — и Гимли тоже. Мерри, единственный из всех, оказался прав. Открывающее слово все время было написано на арке. Перевод должен был быть такой: скажи «друг» и входи. Я лишь произнес на эльфийском языке слово «друг», и дверь открылась.



Сайт или приложение?
Есть пользователь пользуется сайтом для доступа к сервису, то он с большей вероятностью столкнется с повторным вводом e-mail/пароля (хотя предложения браузеров запомнить пароль стремятся максимально его от этого оградить), чем в случае, если регистрация осуществляется непосредственно на мобильном устройстве: пользователь введет e-mail/пароль один раз и больше никогда :) не будет его вводить. А когда придет пара менять девайс, доступа к старому, чтобы найти ошибочный e-mail, может и не быть.

Так проверять e-mail или нет?
Есть три политики проверки e-mail«а:

  • проверка обязательна, пока пользователь не подтвердит e-mail ничего делать нельзя;
  • проверка необязательна, но часть функционала недоступна, пока пользователь не подтвердит e-mail;
  • проверка отсутствует.


Если у вас сайт, то можно воспользоваться вторым способом, причем ограничивать функционал не обязательно, можно не очень назойливо напоминать. Если же у вас приложение, то можно попробовать ввести гибридный вариант проверки e-mail: пользователю высылается e-mail, если он его не подтвердит в течение недели, приложение может показывать напоминалку с просьбой проверить почтовый ящик или убедиться в правильности e-mail«а.

И в качестве бонуса разрешите представить еще немного статистики:

  1. 65% всех пользователей сервиса зарегистрированы в домене .com;
  2. 41% всех пользователей сервиса использует gmail.com в качестве адреса электронной почты;
  3. 25% всех пользователей сервиса зарегистрированы в домене.ru.
  4. 17% всех пользователей имеют уникальные для данного сервиса домены.


image

© Habrahabr.ru