Любой менеджер может сказать вам, что работа с учетными записями и всем, что с ними связано, может быть сложной. Компаниям нелегко контролировать каждый процесс аутентификации, а клиенты в итоге остаются недовольными и больше не возвращаются на ваш сервис, так как просто забыли пароль.
Поэтому Cloudfresh предлагает несколько опций, которые помогут упростить работу с идентификацией. Не имеет значение, где и кто проходит аутентификацию на вашем сервисе — клиенты или внутренние пользователи; на сайте или в приложении. Следующие советы будут полезны в любом случае, если вы работаете с учетными записями.
- Добавьте возможность регистрироваться с помощью сторонних платформ. Другими словами, разрешите использовать сторонних поставщиков удостоверений. Когда пользователь регистрируется и видит возможность идентифицироваться с помощью Google, Twitter или Facebook, более высокая вероятность того, что они используют именно эту опцию для регистрации. Это легче, быстрее и удобнее. Более того, это позволяет компании узнать больше информации о своем клиенте, чем об этом сказало бы просто имя пользователя.
- Разделите для себя опцию идентификации и создания учетной записи. Если во время первой авторизации клиент выбрал войти через Google, в следующий раз он может сделать это через Twitter, и еще через раз будет вспоминать свой пароль от учетной записи на вашем сервисе. Для того чтобы не происходило такой неразберихи, разделяйте опции идентификации и аутентификации.
- Позвольте пользователям создавать как длинные, так и короткие пароли. Многие сайты блокируют возможность создавать слишком длинные или наоборот, слишком короткие пароли. Это может быть обусловлено тем, что, большие пароли могут просто занимать много памяти. А для некоторых мобильных приложений это может быть критично. Поэтому сразу приготовьте поле памяти для паролей ваших клиентов, которые будут простыми и набранными на мобильной клавиатуре или сложными и состоящими из разных символов.
- Не устанавливайте сложные правила для создания имя пользователя. Большинство сайтов и сервисом имеет строгие ограничения для создания так называемых юзернеймов. Например, не менее восьми символов, в которых должны быть заглавные и маленькие буквы, буквы кириллицы, цифры и не должно быть пробелов, символов, и так далее. Пока клиент будет составлять такой пароль, он может быстро передумать регистрироваться на вашем сервисе. Легче и удобнее всего это дать возможность просто использовать свое имя или свой ник. Таким образом, пользователям не нужно будет долго вспоминать, что нужно ввести, чтобы войти на платформу.
- Дайте возможность своим клиентам менять имя пользователя. Исходя из примера в предыдущем совете с длинными именем пользователя, клиенты могут просто создавать новые аккаунты, чтобы не вспоминать доступ к старому. Поэтому правильнее будет просто дать им возможность менять свое имя пользователя. Но вы можете установить для этого определенные ограничения, например менять свой ник не чаще 5 раз в год и так далее.
- Проверяйте личность пользователя. Регистрируясь, клиент часто может указывать свой пароль или свой и-мейл, а ваш сервис должен как можно оперативнее проверить подлинность указанных данных и отправить письмо или короткий код для проверки. Это стоит делать, для того, чтобы убедиться принадлежат ли данные действительно тому человеку, который регистрируется.
- Дайте возможность пользователям удалять свои учетные записи. Во-первых, это предотвратит утечку данных пользователей, в случае не использования учетной записи. Во-вторых, вы не тратите время на разрешения пользователям самостоятельно удалять свою личную информацию. Клиенты самостоятельно управляют своим аккаунтом и решают когда пора удалить свою учетную запись, тем самым защищая свои данные и экономя ваше время.
Рекомендация напоследок
Сделайте использования учетной записи на вашем сервисе безопасной. Например, добавьте функцию сброса пароля, ограничьте попытки входа в личный кабинет, создайте двухфакторную аутентификацию и прочее. Это еще один способ обезопасить данные клиентов и предотвратить проблемы с утечкой информации.
