Пароль повторить: javascript — Зачем нужно поле повторного пароля при регистрации?
Содержание
Поле с паролем / Хабр
Поля для ввода паролей в браузере встречаются в разных случаях:
- при регистрации;
- на форме логина;
- пароль для чего-то абстрактного.
Каждый раз всплывают одни и те же проблемы и возникает необходимость в одинаковых шаблонных фичах. Чтобы облегчить эту рутинную задачу, я сделал js-библиотеку, которую можно конфигурировать под разные случаи — о ней и будет этот пост.
Что не так с тем, что существует?
Чем же нас не устраивает <input type="password" />
?
Ваш •••••• всегда скрыт. Это раздражает. Раздражает тем больше, что нельзя просто так взять и поменять тип поля с password на text, поэтому приходится что-то изобретать. Времени на такую мелочь, как пароль, редко когда выделяют много, поэтому изобретается чаще всего велосипед.
В случае формы логина, пароль, возможно, и нет смысла показывать. С регистрацией же всё сложнее. Не все используют хранилки паролей, многие вводят пароль «руками». Его можно ввести неправильно, для этого обычно добавляют второе поле с паролем. Однако же, это издевательство над пользователем не спасает от случая, когда выбрана неправильная раскладка. Кроме того, если пользователь хочет куда-то сохранить введённый аж два раза пароль, он не может этого сделать. Некоторые вообще после проверки пароля очищают его (предполагая, что пользователь введёт его снова и на этот раз уж точно придумает такой, как надо):
когда вы делаете так, где-то снова убивают котёнка
Многие сайты, порталы,… валидируют пароли по своим правилам (например, что в нём должны быть цифры и буквы одновременно и длина не менее 10 символов). Таким образом, разработчик будет уверен, что пользователь не введёт что-то вроде «123». Идея здравая. Как же это выглядит на практике? Вот так:
будь мужиком, покажи свой большой пароль
Что это? Рейтинг скиллов нажимания на клавиши? Для чего тут вообще цвет, зачем мне надо знать какой-то процент? Есть даже такой плагин (осторожно тыкайте, кажется, сайт лёг):
nakedpassword. com
Если пароль по каким-либо причинам система считает слабым, всё, что я хочу увидеть — что мне ещё ввести, чтобы он вам наконец подошёл. Никаких оценок я видеть не желаю. Нет цифр, а вы их требуете ввести — так и напишите мне: введи цифру. Я уже ввёл цифру и теперь не хватает длины? Спрячьте сообщение о том, что там должны быть цифры, я это уже осознал.
Пожалуй, самый ужасный вариант (я побоялся кликнуть на ссылку more):
регистрация на одном очень известном сайте
Окей, предположим, что пользователь таки дожал до ста. Чтобы он был более счастлив, результат обычно никто и не скрывает: пусть гордится своим достижением на протяжении всего процесса заполнения формы регистрации! Он заполнил всю форму и… забыл пароль. Теперь он хочет его скопировать (например, чтобы сохранить куда-то себе). Ой: а как?
кстати, я долго думал, что не так с моим паролем, почему сообщение не исчезает
Пароли вводят не только при регистрации. Пароли вводят ещё для других людей (например, в админке надо редактировать пароль к какому-то скрипту у партнёра или что-то в таком же духе). В таких случаях обычно добавляют кнопочку генерации пароля, которая избавит оператора от необходимости что-то придумывать (при этом, останется возможность ввести своё).
Очевидно, что надо иметь возможность как-то скопировать сгенерированный пароль, для этого поле с паролем в самом простом случае делается обычным текстовым полем. Зашёл отредактировать другую настройку на той же страничке — увидел пароль. Показал настройку на проекторе — все увидели пароль. Не очень удобно (но времени нет, поэтому пока так и останется, всё равно ж это внутренняя админка):
пароль с генератором
Решаем проблемы
Так как разные из фич надо добавлять часто и реализация их — не всегда простая задача, я написал плагин для jQuery (вообще это js-библиотека, не требующая наличия jQuery, но для краткости буду называть плагином), который позволяет сделать поле с паролем более дружелюбным. Что в нём есть и для чего это надо?
Кнопка отображения пароля
Она позволяет показать пароль, когда он нужен, скопировать, изменить, проверить его и скрыть снова. Пароль по желанию разработчика может быть скрыт или показан, как при создании поля, так и в любой момент:
скрыть-показать пароль
Замечу, что в IE10 тоже сделали нечто подобное (правда пароль нельзя скопировать и надо держать кнопку мышки нажатой, чтобы видеть или редактировать пароль открытым текстом):
кнопка, которую добавляет IE10
Генерация
Чтобы добавить возможность сгенерировать пароль, можно показать кнопку (есть и подсказка, когда пользователь долго думает над паролем):
кнопка-генератор
Пароль получится подходящий именно под те правила, какие задумал разработчик. Если пользователь сгенерировал пароль, он автоматически отображается текстом.
Проверка пароля
«Сила» пароля оценивается по нескольким параметрам:
- длина (чем меньше, тем слабее):
- входжения символов: есть ли цифры, буквы, другое. Что именно, задаётся разработчиком в виде паттерна (например, abCD23):
- проверка на стоп-лист (например, даже если «qwerty» или «p@ssw0rd» могут казаться алгоритму сложными паролями, на самом деле это не так). Проверяем топ 10 самых-самых, плюс то, что захочет разработчик:
В результате получим какую-то суммарную оценку. Сравним её с «порогом прохождения» и покажем совет: добавь в свой пароль цифры (или буквы, или символы). Таким образом, получается нечёткий алгритм проверки: подойдёт как короткий пароль «p@S5», так и длинный, но где нет (например) цифр. Можно не заставлять пользователя вводить @#$, если он хочет большой пароль из букв и цифр, и наоборот.
В сообщении пользователь увидит именно то, чего не хватает в пароле.
Если поле не в фокусе
, значит, пользователь хочет пока заняться другими задачами. Нет необходимости показывать ему ошибки в пароле, силу пароля или что-то ещё: покажем просто, что он или неправильный, или недостаточно надёжный (а если всё хорошо — хватит поля со звёздочками). Остальное увидит, когда предпримет попытку исправить:
поле не в фокусе: с ошибкой и без ошибки
Совместимость
Так случилось, что фичи были нужны иногда и там, где не было jQuery. Поэтому он написан на «чистом» js: из-за этого получилось чуть больше кода, чем могло бы быть. Плагин дружит с jQuery и Bootstrap-ом, работает на большинстве современных и не очень браузеров (даже в IE6). Изменений в вёрстке не требуется, поэтому в случае отключённого js ничего не сломается: пользователь увидит обычное поле type=password.
Умеет показывать сообщения на 8-ми разных языках, в зависимости от локали браузера:
мнение плагина о пароле «qwerty» на испанском языке
Каждую кнопку, фичу или сообщение об ошибке можно избирательно отключить или переопределить.
Демка тут, там же описание API.
Возможно, плагин будет полезен кому-то ещё, поэтому исходник выложен на github, если надо — пользуйтесь где угодно.
Прекратите спрашивать с меня подтверждение / Хабр
Задрало.
Настолько плотно прижилась кругом эта дрянь, что и не встретить уже человеческого отношения к себе, как к пользователю.
Дублирование элемента подразумевает существенную важность вводимой в него информации.
Что такого важного в пароле? Что самое страшное случится, если при регистрации ввести его неверно?
Коллапс, повсеместный конец света, газа и горячей воды?
С учётом того, что пароль обычно присылают на указанный e-mail, — ничего страшного: ошибся, получился плохой — поменяю, лень менять — найду в письме.
Не прислали — всегда могу сменить, был бы исправный e-mail.
Видели ли вы случаи дублирования полей ввода иной информации?
«Имя / Имя», «О себе / О себе». Не встречалось?..
Ах да — e-mail. Ещё один пережиток и традиция, но даже он важнее пароля.
Указать неверный e-mail гораздо более чревато, нежели придумать «некрасивый» пароль.
Но требовать вводить его дважды — ещё больший бред, нежели пароль.
Тут нужно чуть свернуть с темы пароля и коснуться дублирования на примере e-mail.
Давно ли вы вводили последний раз основной e-mail руками?
Если разработчик формы не стал мудрствовать лукаво и дал полю формы «стандартное» имя «email» — адрес наверняка подскажет браузер.
Даже если ввели руками, вводите ли второй раз руками?
Повышается ли внимательность ввода при дубле? Наоборот: вводишь и материшь разработчика, его родственников и канарейку.
Думаешь: «ладно, вобью быстро руками» и тут же опечатываешься, вводя второй раз. Знакомо?
Потрачено время, нервы, толку — ноль.
Что пишет тебе форма «повышенной юзабильности» когда значения дублированных полей не совпали?
Правильно — «не совпадает».
Удивила, блин. Помогла.
Вот теперь сиди, ищи где и чего ты не так вбил. Где правильное значение? Где опечатка?
Нашёл? Вбивай по-новой, или копируй правильный вариант.
В e-mail ещё можно разглядеть ошибку, а пароль они скрыли, заботясь обо мне — вбивай оба снова, авось рука не дрогнет.
Пароль скрывают.
Кругом шпионы, всем страшно нужны мои пароли.
Хорошо, подкормим паранойю и оставим скрытие пароля по умолчанию, дабы не нервировать непривычным поведением годами выдрессированного пользователя.
Но дайте же мне увидеть, что я ввёл, если у меня за спиной никто не стоит и пять камер не направлены мне в монитор!
Чего хотят от меня добиться, делая две вещи: скрывая вводимое значение и предлагая вводить его дважды?
Улучшить сложность пароля? Чёрта с два.
Перед человеком ставят задачу ввести сложную, а я надеюсь вы используете сложные пароли, последовательность. Вслепую. Дважды.
Подготовка к сапёрному ремеслу, не иначе.
Придумать в такой ситуации сложный пароль нереально. Вернее, придумать — реально более чем, повторить и запомнить нереально.
Что вынуждает либо вводить давно придуманный и используемый пароль, либо придумывать его в ином месте — например, текстовом редакторе — и копировать в поле.
Ну, либо пользоваться менеджером паролей и копировать оттуда, в два места.
Разработчики формы проверяют моё умение копировать текст в поля?
Помогло скрытие? Нет, набивали в редакторе и копировали.
Увеличилась сложность? Нет, вбивал вслепую попроще, чтобы не ошибиться.
Хорошо, может таким образом повышается внимательность при вводе пароля?
Ну да, когда ты вводишь его с третьего раза — поневоле будешь внимателен и пару раз сотрёшь наполовину введённое, чтобы не увидеть снова гадкую надпись про несовпадение полей.
А для чего внимательность? Чёрт подери, это всего лишь пароль! Моё имя и список увлечений важнее!
Ни одна из предполагаемых выгод не оправдалась.
Фарс.
«Как у всех».
В итоге, на совершенно некритичную вещь можно потратить до нескольких минут и закончить регистрацию не в довольном расположении духа, предвкушая выгоду от сервиса, а чертыхаясь и проклиная всё на свете, пять раз задумавшись, надо ли оно тебе и какой идиот это делал.
Много ли нужно, чтобы кардинально изменить ситуацию?
Нет:
1. убрать дублирование поля;
2. дать возможность увидеть введённое значение.
Всё! Никаких нервов, сложные пароли, довольные процедурой регистрации пользователи.
Это же очень просто, даже работы становится чуть меньше — не нужно сверять два значения.
Товарищи, думайте о пользователях. Тестируйте формы на данных, отличных от «111» и «222», вам же самим потом подобным пользоваться.
Благодарю, перенёс в пользовательские интерфейсы.
Необходимо ли поле «повторить пароль» на странице регистрации?
спросил
Изменено
10 лет, 5 месяцев назад
Просмотрено
44к раз
Возможный дубликат:
Почему мы должны спрашивать пароль дважды при регистрации?
При разработке новой и упрощенной страницы регистрации я поспорил с коллегой о необходимости поля «повторить пароль».
Мы разработали процесс регистрации таким образом, чтобы пользователь автоматически входил в систему после завершения процесса проверки электронной почты. Таким образом, по крайней мере на начальном этапе пользователю не нужно будет вводить свой пароль. Поэтому пользователь будет «подтверждать» пароль только при входе во второй раз, если мы опустим поле «повторить пароль».
У нас есть опция «восстановления пароля», так что в худшем случае пользователь может пройти через этот процесс, если он неправильно набрал пароль при регистрации. Но опять же, как часто вы ошибаетесь при вводе пароля?
Кажется, даже крупные игроки не согласны с тем, какой способ лучше…
Не нужно повторно вводить пароль:
- Facebook (хотя они требуют повторного ввода электронной почты)
- Дропбокс
Необходимо повторно ввести пароль:
- Yahoo
- Реддит
Это необходимо?
- пароль
11
Я не специалист по пользовательскому интерфейсу, но думаю, что во многих случаях это не нужно. Конечно, по моему собственному опыту, я редко ввожу пароль неправильно. Лучшее решение — вообще не иметь пароля. Используйте один из постоянно растущего числа провайдеров аутентификации (например, OpenId, Google, Facebook, Twitter и т. д.). Зачем пользователю нужен еще один пароль для вашего приложения или сайта?
Технические пользователи вашего приложения будут использовать генератор паролей и/или механизм хранения. Пользователи, не разбирающиеся в технических вопросах, будут использовать один из любимых одноразовых паролей, которые они используют для множества разных сайтов/приложений. Лучше просто интегрироваться с системой аутентификации, которую они уже используют. Также могут быть другие преимущества для вашего приложения, такие как интеграция в Google Apps, если вы используете аутентификацию Google.
Если вы решите потребовать от пользователя предоставить новый пароль для вашего приложения, то, по крайней мере, не очищайте поле пароля при ошибке ввода формы. Нет ничего более раздражающего, чем очистка поля пароля из-за того, что вы допустили ошибку в какой-то другой части формы. Вы исправляете ошибку, повторно отправляете, а затем снова возникает ошибка, потому что пароль отсутствует. Это сводит меня с ума. Если вас беспокоит повторение пароля пользователя в HTML, не делайте этого. Есть много других вариантов. Зашифруйте его в форме, запомните его в состоянии сеанса, используйте тупой пароль в HTML. Как бы то ни было, просто не заставляйте пользователя вводить его снова!
8
У Microsoft есть довольно изящный способ решить эту проблему: флажок «Скрыть пароль» (подключение к WiFi в Windows 7 и, я думаю, в Vista). Я действительно думаю, что это лучшее из обоих миров.
Лично у меня нет людей, заглядывающих мне через плечо 24/7; и большинство пользователей тоже. Кроме того, вы можете ввести пароль и просто снять маску/маску, чтобы ненадолго проверить его.
1
Это не обязательно, особенно если у вас есть способ его сбросить. Могу поспорить, что многие люди все равно используют вырезание и вставку. Я склонен думать, что подписаться на что-либо должно быть как можно проще. JMHO.
11
Вопрос сводится к тому, «сколько стоит ошибочный пароль». В некоторых системах эта стоимость высока, и поэтому они просят вас перепечатать. Например, если вы настраиваете учетную запись у (не бесплатного) интернет-провайдера, то невозможность доступа к вашей учетной записи, вероятно, связана с выполнением целого ряда шагов проверки идентификации с технической поддержкой.
Благодаря большому количеству бесплатных онлайн-систем стоимость ошибочного ввода пароля невелика. Если вы ошиблись при вводе пароля в Твиттере, самое худшее, что может случиться, это то, что вам придется создавать учетную запись во второй раз. Точно так же, если вы опечатались в Facebook, и у них есть ваша электронная почта, вы можете запросить сброс пароля, поэтому они дважды запрашивают вашу электронную почту, а не ваш пароль.
Поскольку большинство систем переходят ко второму типу, а не к первому, повторения пароля будут происходить реже.
1
Да, иногда. Почему? Потому что иногда вы не проверяете данные пользователя при регистрации, а это означает, что если он забудет свой пароль, ему будет сложнее снова разрешить ему доступ.
Reddit и Yahoo не проверяют адреса электронной почты (вообще), поэтому важнее, чтобы пользователь не забыл свой пароль. Вот почему у них есть два ящика для пароля.
Twitter и Facebook не предоставляют пользователям полный доступ, если они не подтвердили свой адрес электронной почты. Поскольку они хотят, чтобы их пользователи были проверены, в идеале важнее правильно указать их контактные данные, чем их пароль.
Надеюсь, это ответ на ваш вопрос!
Вы когда-нибудь создавали файл архива, защищенный паролем.
при создании защищенного паролем файла архива с помощью winrar есть одна опция «показать пароль». Если вы отметите эту опцию, вам не нужно повторно вводить пароль.
Потому что, когда пароль не виден, высока вероятность того, что пользователь может ошибиться.
и он в конечном итоге с неправильным паролем.
Большинство пользователей не являются инженерами-программистами.
Я отказываюсь от маскированных полей пароля. Если пользователь видит то, что он пишет, он лучше запоминает это (визуальное принуждение), он может видеть, есть ли опечатки, нет необходимости перепечатывать его, и мое личное мнение заключается в том, что это менее стрессово для пользователя. пользователь.
14
Смысл запроса пользователя на ввод пароля дважды заключается в том, чтобы убедиться, что в его пароле нет случайных орфографических ошибок. Если вы пропустите этот шаг и они напишут что-то неправильно, им придется пройти через весь процесс восстановления/изменения пароля, который может занять некоторое время в зависимости от требований безопасности/способностей пользователя.
Я лично считаю, что всего одному пользователю, которому приходится проходить восстановление пароля из-за лишнего символа/отсутствующего символа/и т. д., слишком много. Особенно, когда повторный ввод пароля является таким простым шагом. Конечно, некоторые люди будут копировать и вставлять первое во второе, но это их вина. Я сделал все возможное, чтобы помочь пользователю избежать этой проблемы.
6
Это во многом субъективно и во многом зависит от того, как устроен ваш процесс регистрации. Если электронная почта подтверждена и у вас есть надежный процесс «восстановления пароля», я бы посоветовал, вероятно, нет.
Если у вас есть полный контроль над пользовательским интерфейсом (т. е. не в Интернете), вы также можете рассмотреть возможность предоставления пользователю возможности видеть, что он печатает (а-ля это)
1
Так что я думаю, как и почти всегда, ответ: это зависит от обстоятельств.
Как уже говорили другие: если вы не собираетесь отправлять пароль обратно пользователю или сделать восстановление очень простым, то наличие двойного пароля может быть эффективным способом избежать ошибок пользователя (в частности, опечаток). Я несколько раз становился жертвой опечаток; Я думаю, что с требованием заглавных букв количество опечаток увеличивается, но у меня нет ничего, кроме моего собственного анекдотического свидетельства, чтобы доказать это.
Я не думаю, что вы должны принимать это решение, основываясь на предполагаемой стоимости: если мне нужно создать новую учетную запись, я больше не получаю предпочитаемое имя/имя пользователя и получаю какое-то странное цифровое дополнение, которое само по себе становится трудным для запоминания. Кроме того, предполагаемая стоимость для любого из нас, вероятно, будет ниже, чем для среднего пользователя.
Мне очень нравится метод iPhone, который показывает мне только последний введенный символ. Он довольно хорошо справляется с запутыванием и предоставляет информацию в нужном количестве людям, которые, вероятно, вводят пароли в общественных местах.
Я все еще использую двойной пароль, я бы предпочел ошибаться в сторону ограничения ошибок пользователя; это не так плохо, как двойное электронное письмо.
Сначала я подумал, что «если ваши пользователи не очень сообразительны, поле повторного пароля поможет им избежать ошибок». Но, с другой стороны, пользователи, не разбирающиеся в компьютерах, могут быть ужасно сбиты с толку вторым полем. В конце концов, в реальном мире не существует повторяющихся полей.
Я думаю, что лучший вариант, но более сложный в реализации, это не повторять, а включать поле «не маскировать мой пароль».
1
Я работал над проектом, в котором пользователям не нужно было повторять пароль. Однажды мы получили гневное электронное письмо от пользователя, который утверждал, что мы отображаем его пароль — открытым текстом — в правом верхнем углу.
Выяснилось, что при регистрации он ввел свой пароль, а потом не отрываясь перешел на следующее поле и повторил свой пароль. За исключением того, что поле было «Имя».
Он не был глуп и не был невнимателен. Он демонстрировал то, к чему мы, дизайнеры, должны стремиться: привыкание. Это похоже на турбо-переключатель в голове пользователя, за исключением того, что вы не всегда можете контролировать вещи на высокой скорости.
Есть как минимум две сломанные вещи здесь
- Прежде всего необходимо создать учетную запись (используйте openid, google и т.д.)
- Использование паролей для аутентификации (пока нет реального решения)
1
Хороший вопрос! Я думал о двух идеях:
Начните с сокрытия пароля. Дайте парню кнопку-переключатель, которая будет отображать/скрывать пароль в том виде, в каком он его ввел до сих пор.
Тайм-аут отображения может сработать: создайте кнопку, которая покажет пароль примерно на полсекунды, а затем снова скроет его.
В обоих случаях пользователь вводит пароль только один раз. И он видит сообщение (не обязательно приглашение, но, возможно, оно должно быть) показать и проверить пароль перед отправкой. В качестве резервной копии всегда (я думаю) есть электронная почта парня для сброса пароля.
— пет
Нет не надо.
Это зависит от того, насколько важна безопасность веб-сайта, какое впечатление о безопасности вы создаете у пользователя и насколько строги ваши требования к паролю.
Для веб-сайтов, которые требуют, чтобы пароли содержали определенные шаблоны/цифры/буквы, лучше всего, чтобы пользователь повторил пароль, поскольку мой опыт показывает, что они создают новый пароль . Поэтому то, что они думают, они напечатали, может не совпадать с тем, что они ввели.
Для развлекательных веб-сайтов действительно важна безопасность? Скорее всего нет, и вы можете иметь дело с нажми и беги пользователь зарегистрируйся. Таким образом, сокращение усилий и времени помогает улучшить число конверсий при регистрации.
Для сайтов, предлагающих платные услуги, пользователь уже принял/завершил решение о покупке. Регистрация — это всего лишь процесс, который им необходимо выполнить, чтобы получить доступ к сервису. Двойные подсказки помогают укрепить доверие к тому, что они могут получить доступ к этой услуге, за которую они заплатили, позже. Никто не хочет сбрасывать свой пароль для чего-то, за что они заплатили $$.
Следует ли использовать «Подтверждение пароля» в своих формах?: Пример
Мы добились увеличения числа конверсий форм на 56,3 %, удалив пункт «Подтвердить пароль», не повлияв при этом на скорость сброса пароля.
Следует ли заставлять пользователя подтверждать пароль при заполнении формы? Те, кто поддерживает «ДА», утверждают, что это позволяет избежать ненужных звонков в службу поддержки, когда пользователь неправильно набрал и впоследствии неправильно ввел свой пароль. Со стороны «НЕТ» спор заключается в том, что требование вносит ненужные трения в форму, что снижает коэффициент конверсии. Банда «НЕТ» также утверждает, что пользователи обычно копируют и вставляют свой пароль для подтверждения, поэтому просьба подтвердить не имеет никакого значения для количества неправильно введенных паролей. Кроме того, в крайнем случае всегда есть опция «Забыли пароль».
Есть твердые мнения по этой теме, поэтому мы подумали, что сможем внести свой вклад в дебаты, повторно открыв одно из наших предыдущих исследований по этой теме. Это происходит из тех дней, когда наше программное обеспечение для аналитики форм было известно как Formisimo, а не Zuko (отсюда и другой брендинг), и основано на нашей регистрационной форме.
На первый взгляд регистрационная форма Formisimo выглядела довольно просто:
Регистрационная форма до изменений
Однако мы заметили, что более четверти отказов приходится на поле «Подтвердить пароль». Хотя это было не самое худшее поле для отказов (многие ушли после того, как сосредоточились только на первом поле «Имя»), оно вызвало тревогу — если пользователи зашли так далеко, почему бы не заполнить форму?
Итак, чтобы пройти тест, учиться и совершенствоваться, мы решили попробовать некоторые изменения. Мы использовали функцию «Подтвердить пароль» только из-за смутного ощущения, что это лучшая практика. У нас не было твердой гипотезы, основанной на данных, чтобы включить ее в первую очередь.
Для полного раскрытия информации мы одновременно внесли несколько других изменений:
- Удалили цифру «1» в левом верхнем углу, поскольку это означало, что было несколько шагов регистрации, которых не было. Следующая страница (то есть страница «2») была страницей подтверждения.
- Изменение текста вверху на более ориентированное на действие «Начните отслеживать свои формы».
- Изменение цвета кнопки призыва к действию на более ярко-оранжевый вариант.
Новая форма
Теперь мы знаем, что профессиональные тестировщики A/B среди вас будут кричать на нас, что мы должны были вносить только одно изменение за раз, чтобы быть уверенными в выводах. Вы правы, но так было в то время, и мы не можем вернуться назад и изменить это сейчас.
Результаты проверки:
- На 14,3% больше посетителей начали заполнять форму после перехода на страницу
- A Увеличение на 35,5% доли тех, кто начал заполнять форму, заполнив ее
- A Уменьшение количества исправлений в форме на 23,9%
- A Увеличение общего числа конверсий на 56,3%
- Количество запросов на сброс пароля на пользователя оставалось стабильным на уровне 10%
Этот тест в целом прошел для нас явно успешно.