Создайте учетную запись, затем проверьте (или проверьте, затем создайте учетную запись)

Ответ 1

Лично я вижу проблему, которая может быть неудобной для пользователя:

Когда большинство людей регистрируется на веб-сайте, они ожидают, что им придется ответить на несколько вопросов, потратить некоторое время на ознакомление с часто задаваемыми вопросами и условиями обслуживания, а затем потратить еще немного времени на создание некоторых предварительных аспектов их профиля.

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

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

Мне также не нравится неотъемлемая импликация такой схемы:

• Традиционный поток: "О, хорошо, вы заполнили наши формы, просто дайте нам адрес, чтобы отправить вам правильную проверку". Пользователь здесь просто ждет, чтобы завершить то, что по сути дела сделано.

• Первичный поток: "О, это вы. Ну, подождите некоторое время, и мы отправим вам приглашение, если хотим вас". Здесь, с другой стороны, пользователь остается в неопределенности подсознательной неопределенности, пока не получит ваше сообщение.

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

Ответ 2

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

Требуется ввести адрес электронной почты, чтобы начать использовать сайт, кажется драконовским и ограничительным и раздражающим. Меня просят дать что-то в качестве первого шага, возможно, возможно (может быть?) Получить что-то ценное в будущем.

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

Знаете ли вы, почему я впервые создал эту учетную запись StackOverflow? Поскольку, когда я хотел внести свой ответ, я мог щелкнуть по логотипу Google на странице входа и немедленно начать использовать сайт. Нет имени пользователя, пароля, имени, имени, DOB или другого B.S.

Знаете ли вы, почему я никогда не создавал учетную запись экспертов Exchange? Поскольку в первый раз, когда я попытался получить ответ, мне было предложено ввести номер кредитной карты, платежный адрес и номер телефона. Прежде чем я смог даже попробовать, что сайт мог предложить, мне пришлось что-то отдать.

Дело в том, что барьеры для входа заставляют ваш сайт сосать. Создание учетной записи должно быть максимально простым и безболезненным. Возможность доступа к сайту сразу после заполнения формы регистрации на одной странице, а CAPTCHA - потрясающе, даже если доступ к другим функциям ограничен, пока проверка электронной почты не будет завершена. Возможно, я даже скажу вам свой DOB и любимый цвет, если он откроет больше возможностей.

Ответ 3

Лично я не вижу в этом проблемы - это вопрос выбора. Я думаю, что ключевой момент заключается в том, чтобы дать пользователю понять, что они должны

1) введите свой адрес электронной почты 2) дождитесь подтверждения электронной почты, прежде чем они смогут перейти к шагу 3 3) зарегистрируйтесь для учетной записи.

Он потенциально удаляет количество данных, удерживаемых пользователем и время, потраченное пользователем, если им нужно только ввести единую информацию (свой адрес электронной почты), прежде чем заполнять оставшуюся нужную информацию.

Лично я бы сохранил стандарт, чтобы пользователи не путались. Объем работы одинаковый - получите имя пользователя/пароль/адрес электронной почты - дождитесь, пока пользователи нажмут на ссылку, прежде чем смогут войти на ваш сайт.

Ответ 4

Итак, сколько раз вы могли бы использовать ссылку для отправки по электронной почте?

Если только один раз, пользователь не может создать учетную запись, если он закроет браузер, прежде чем выбрать имя пользователя.

Если несколько раз, многие люди могут создавать учетные записи, используя одну и ту же ссылку. Публикация этой ссылки и использование функции восстановления пароля могут быть приятным фишинговым трюком.

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

Ответ 5

Я мог видеть, что этот метод несколько проще - когда пользователь нажимает ссылку подтверждения в своем письме, вы отправляете их в форму со скрытым предварительно сгенерированным номером идентификатора, а затем назначаете ему имя пользователя и пароль. Пустые учетные записи с просто и id и никакой другой информацией легко периодически отфильтровываются, и вы не сохраняете какие-либо детали до тех пор, пока учетная запись не будет успешно создана.

Однако, вероятно, причина, по которой большинство сайтов собирают имя пользователя и пароль перед электронной почтой, вы получаете от пользователя вложенные средства, прежде чем запрашивать более личную информацию. Учетная запись создана - теперь просто проверьте свою электронную почту. Другой способ попросить адрес электронной почты сначала, а второй - даже если функционально это одно и то же, перцептивно это не так. Кроме того, преимущество стандартного "потока" заключается в том, что пользователи знают, чего ожидать - следующие соглашения означают, что пользователи чувствуют, что знают, что происходит, и не путаются или не теряют интерес.

Ответ 6

Я хочу поделиться некоторыми соображениями о втором подходе.

Прежде всего, он очень похож на систему приглашения, но это НЕ то же самое.

• Вы должны разрешить отправлять более одного запроса на регистрацию для одного адреса электронной почты. Если вы этого не сделаете - потенциальный пользователь может случайно его удалить, и повторить процедуру не будет. Если вы позволите, чтобы некоторые сердитые чуваки могли использовать это как инструмент для спама (отправляйте как можно больше писем на один (возможно, даже более) адрес электронной почты. Представьте себе, как бы вы, компания или сайт, искали человека, получившего 10k запросов на регистрацию...

• Стандартный способ имеет одно серьезное преимущество: он позволяет резервировать имя пользователя без подтверждения электронной почты (пользователь может захотеть зарегистрироваться, но не хочет или не имеет доступа к серверу/учетной записи электронной почты).

• Вы ДОЛЖНЫ учитывать, что ваш сервер может задерживать отправку электронной почты довольно долго. Возможные причины: нехватка памяти, DoS-атак, сбой почтового сервера и т.д. Если вы выбираете первый подход к электронной почте, и пользователь не получает эту почту через 5 минут (по какой-либо причине), 3 из 4 потенциальных пользователей будут курс вашей компании/сайта и никогда не завершайте регистрацию.

Существует причина, почему он называется стандартным способом, так как рассматривается множество мелких деталей.

Ответ 7

Оба подхода в порядке: но если вы собираетесь отложить создание учетной записи, тогда вам нужно будет вставить все необходимые данные в URL-адрес - дату истечения срока действия, имя пользователя, пароль и адрес электронной почты, а затем зашифровать его все, чтобы предотвратить несанкционированное вмешательство - что делает его довольно большим.

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

Ответ 8

Вот мои проблемы с этим подходом.

Доставка по электронной почте не гарантируется и может быть медленной. Если пользователь не сразу получает адрес электронной почты, он может не завершить процесс регистрации. Что делать, если они ошибочно используют свой адрес электронной почты или если адрес электронной почты отмечен как СПАМ?

Ответ 9

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

Проблема в том, что чаще пользователи не получают подтверждение по электронной почте.

Когда это происходит, они часто забывают о сайте и не возвращаются.

То, что я делаю, - это повторить отправку подтверждения по электронной почте через некоторое время, скажем, одну неделю. Часто они получают второе электронное письмо, и вы в конечном итоге восстанавливаете зарегистрированного пользователя, который в противном случае был бы потерян.

На самом деле, я повторяю отправку электронного письма с подтверждением один раз в неделю, пока пользователь не подтвердит или не пропустил через 30 дней после попытки регистрации.

Даже если пользователь не подтвердит через 30 дней, я не удаляю учетную запись. Часто пользователь снова пытается зарегистрироваться. Затем я снова отправлю ему подтверждение учетной записи еще раз и попрошу пользователя связаться с сайтом, если он не получит его снова.

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

Ответ 10

Я бы предложил второй вариант. Позвольте пользователям убедиться, нажав ссылку в своем письме. Затем они могут выбрать предпочтительное имя пользователя и пароль. Я надеюсь, что имена пользователей уникальны на сайте.

Было бы полезно в ситуации, когда некоторые пользователи забывают проверять ссылку в своих письмах в течение длительного времени, и поэтому их имена пользователей заблокированы. Другие не могут выбирать эти имена пользователей (пока эта запись не будет удалена позже). Также это может уничтожить спамеров от выбора собственных имен пользователей и блокировки их для использования другими.

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

Ответ 11

На самом деле есть некоторые сайты, которые это делают.

• Вы вводите свою почту
• вы получаете проверка почты с первоначальной пароль и контрольная ссылка
• после того, как вы нажмете ссылку, в которой ваша учетная запись активным вы направляетесь в форму с дополнительные данные (полное имя и т.д.) но вы можете пропустить их и заполнить их в любое время в будущем.

Этот минимальный процесс регистрации поможет вам избежать потери потенциальных клиентов, которые не хотят беспокоиться о заполнении многих форм и предоставлении данных, прежде чем они действительно понадобятся.

Ответ 12

В чем дело, это удобство для пользователя. Если единственная причина для них - проверить их электронную почту, чтобы проверить учетную запись, тогда это может показаться неудобством. Вместо этого система генерирует для них пароль, посылает их по электронной почте и инструктирует их проверять электронную почту, чтобы получить свой пароль. Вы можете разрешить им изменять пароль после входа в систему, если они захотят. Этот метод также помогает убедиться, что "сильные" пароли там изначально.