Как добиться высокого уровня внедрения ключей доступа при их создании

В этой статье представлено подробное руководство о том, как повысить уровень внедрения ключей доступа (passkey) и особенно уровень их создания за счет оптимизации процессов создания ключей доступа с помощью своевременных напоминаний (nudges). Мы ответим на следующие вопросы:

• Каковы лучшие практики для пользовательских подсказок, чтобы максимизировать создание ключей доступа?
• Как компаниям эффективно стимулировать пользователей к массовой регистрации ключей доступа?

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

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

Организации получают существенное повышение безопасности и снижение затрат, например, уменьшение количества сбросов паролей и сокращение использования OTP, только тогда, когда ключи доступа достигают высокого уровня принятия и становятся основным методом входа для большинства пользователей. Следовательно, лучшие практики для пользовательских подсказок, подсказок после входа в систему и A/B-тестирования играют решающую роль в достижении этих целей. Компании, нацеленные на масштабный переход пользователей с паролей на ключи доступа и стремящиеся к уровню входа по ключам доступа в 50–80 %, активно занимаются созданием ключей доступа.

Эти стратегии вовлечения пользователей в использование ключей доступа соответствуют рекомендациям FIDO Alliance на Passkey Central, где FIDO Alliance подчеркивает необходимость стимулирования принятия ключей доступа пользователями в корпоративной среде. Хотя преимущества на высоком уровне хорошо понятны, реальная проблема часто заключается в повышении метрик успешности входа по ключам доступа, например, в эффективном увеличении охвата ключами доступа различных устройств, внедрении лучших практик подсказок после входа и организации непрерывного обучения пользователей для регистрации ключей доступа.

Например, явный подход Amazon к повышению принятия ключей доступа — посредством масштабных экспериментов и итеративных улучшений UX — позволил ускорить вход в систему в шесть раз, заметно снизив возврат к паролям и повысив удовлетворенность пользователей. Аналогичным образом сегментация Microsoft по профилям и устройствам, а также более 2,5 миллиардов входов по ключам доступа в Google, демонстрируют их приверженность активному использованию, а не простому наличию ключей доступа:

Короче говоря, стимулирование принятия ключей доступа пользователями в корпоративной среде гораздо важнее, чем просто включение этой функции. Пользователи редко сами ищут новые методы входа в систему. Вы должны убедиться, что оптимизация процессов входа по ключам доступа, своевременные напоминания о регистрации и постоянное A/B-тестирование подсказок являются частью плана. Благодаря таким стратегиям вовлечения и аналитике ключей доступа организации могут преодолеть критические пороги, полностью заменить пароли ключами доступа и в полной мере воспользоваться преимуществами безопасности, финансов и пользовательского опыта будущего без паролей.

Подпишитесь на наш Passkeys Substack, чтобы получать новости.

Подписаться

Поощрение пользователей к настройке ключей доступа, часто называемое созданием ключей доступа (passkey creation), регистрацией ключей доступа (passkey enrollment) или «регистрацией ключа доступа», является основой любой попытки повысить уровень их принятия и увеличить частоту использования. На практике существует множество подсказок и процессов для напоминаний о регистрации ключей доступа, но не все они одинаково эффективны. Ниже представлен обзор распространенных подходов, а также объяснение того, почему лучшие практики подсказок после входа в систему широко считаются наиболее результативными.

Это не замена подсказкам после входа (это применимо только к части входов и зависит от поддержки ОС/браузера/менеджера паролей), но это мощное дополнение. Технические подробности реализации, примеры кода и скриншоты смотрите в нашей статье об автоматическом обновлении до ключей доступа. Относительно поддержки платформ, эффективности и стратегических соображений смотрите нашу статью Conditional Create.

При выборе места для внедрения напоминаний о ключах доступа учитывайте эти выводы, основанные на опыте крупных корпоративных внедрений:

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

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

Консенсус и ключевые выводы

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

• Conditional Create (Автообновление) — это дополнительная функция с минимальным трением, которая может избавить от явных подсказок пользователей, входящих в систему с помощью сохраненного автозаполнения паролей на поддерживаемых платформах.

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

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

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

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

• Многочисленные эксперименты и подходы: Amazon тестировала различные процессы после входа («T1», «T2», «T3»), чтобы выяснить, какие подсказки для пользователей работают лучше всего. Некоторые автоматически открывали диалог создания ключа доступа, тогда как другие отображали простой экран «Настройте свой ключ доступа» с двумя вариантами на выбор: «Да, создать ключ доступа» или «Нет, продолжить использовать пароли».

• Ускорение входа в 6 раз: Благодаря итеративному A/B-тестированию и корректировкам в реальном времени они добились того, что вход в систему стал до шести раз быстрее для тех, кто перешел на ключи доступа, что значительно сократило случаи возврата к паролям.

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

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

• Сегментация по профилям и устройствам: Внутреннее внедрение в Microsoft систематически было нацелено на различные группы пользователей (руководители, разработчики, рядовые сотрудники) и конкретные платформы (Windows, macOS, iOS, Android). Они показывали подсказки о ключах доступа после входа, адаптированные к рабочему процессу каждого сегмента.

• Поэтапное внедрение: Измерив успех на ранних этапах, Microsoft неуклонно наращивала обязательное использование ключей доступа на последующих этапах. Организация также измеряла «уровень принятия ключей доступа» для каждой волны, корректируя текст пользовательского интерфейса или логику возврата к старым методам, если конверсия падала.

• Поощрение охвата: Как только пользователь настраивал ключ доступа на одном устройстве, при последующих входах с новых устройств ему предлагалось: «Добавить ключ доступа здесь?», чтобы ключи доступа стали повсеместными в среде пользователя.

• Масштабное A/B-тестирование: Имея более 2,5 миллиардов входов с помощью ключей доступа, Google вкладывает значительные средства в A/B-тестирование подсказок о ключах доступа. Часто они сравнивают сообщения, ориентированные на удобство («Больше не нужно вводить пароль»), с сообщениями, ориентированными на безопасность («Защитите свою учетную запись с помощью ключа доступа»), чтобы понять, что находит больший отклик.

• Процессы повторной аутентификации: Google также использует подсказки при повторной аутентификации (например, когда пользователи изменяют конфиденциальные настройки), чтобы напомнить им о ключах доступа: «Хотите делать это быстрее? Создайте ключ доступа прямо сейчас».

• Напоминания на разных устройствах: Поскольку Менеджер паролей Google синхронизирует ключи доступа между устройствами, подход после входа в систему часто включает короткое уведомление об удобстве использования на нескольких платформах, укрепляя идею «создай один раз, используй везде».

• Язык безопасности в сравнении с удобством: Intuit, создатель QuickBooks и TurboTax, тестировала такие сообщения, как «Вход с защитой от фишинга» (акцент на безопасности) в сравнении с «Быстрый вход без пароля» (акцент на простоте использования). Они обнаружили, что определенные сегменты (особенно финансовые специалисты) были больше мотивированы безопасностью, тогда как другие — удобством.

• Постоянное тестирование на пользователях: Имея очень разнообразную аудиторию — от владельцев малого бизнеса до рядовых налогоплательщиков — Intuit постоянно дорабатывала формулировки, макет пользовательского интерфейса и время появления подсказки. Они выяснили, что появление подсказки вскоре после входа в систему обеспечивает гораздо более высокий уровень принятия ключей доступа.

• Регулярные напоминания: Для пользователей, которые изначально пропустили процесс создания ключа доступа, Intuit создала подсказку «второго шанса», которая появлялась через короткий промежуток времени — стратегия, которая еще больше увеличила итоговый уровень создания.

Давайте посмотрим и резюмируем общие черты этих крупных внедрений:

Помимо этих продуктовых тактик, современные платформы также поддерживают Conditional Create (автоматическое обновление до ключей доступа) для обновления части входов с автозаполнением пароля до ключей доступа с минимальным взаимодействием с пользователем. См. Conditional Create.

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

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

Основная проблема в стимулировании первоначального внедрения ключей доступа заключается в поиске правильного сообщения. Организации должны четко определить, обращаться ли к комфорту и удобству пользователей или сосредоточиться в первую очередь на повышенной безопасности. Например, Google добилась массового успеха с помощью простых подсказок, ориентированных на удобство, таких как «Быстрый вход без паролей», которые нашли сильный отклик у обычных пользователей. В отличие от этого, Intuit определила, что профессионалы, особенно в сфере финансов, более позитивно реагируют на сообщения, ориентированные на безопасность, такие как «Защитите свою учетную запись от фишинга». Идеальное сообщение будет сильно зависеть от демографии ваших целевых пользователей и их конкретных потребностей или приоритетов, что подчеркивает важность обширного A/B-тестирования для определения наиболее эффективного языка.

Тестирование вариантов этих сообщений позволяет измерить, какой из них находит наибольший отклик и дает самые высокие показатели принятия. Не менее важно управлять частотой подсказок: первоначальные напоминания необходимы, но последующие напоминания должны быть тщательно сбалансированы. Такие компании, как Amazon, наблюдали резкое снижение показателей принятия после слишком большого количества повторяющихся подсказок за короткий промежуток времени. Широко распространенная лучшая практика — позволить пользователям легко пропускать подсказки, но возобновлять настройку ключа доступа после периода ожидания, например, через 30 дней.

Решение о том, автоматически ли запускать процесс регистрации после входа в систему, также существенно влияет на уровень принятия. Автоматические триггеры на мобильных устройствах доказали свою высокую эффективность: Amazon отметила повышение уровня принятия на 30–50 % благодаря интуитивно понятному характеру биометрических взаимодействий. Однако автоматические подсказки при регистрации должны быть продуманы во избежание недовольства пользователей, особенно на десктопных платформах, где ручной запуск, как правило, более эффективен и менее навязчив.

Достижение широкого внедрения ключей доступа предполагает не только регистрацию пользователями их первого ключа доступа, но и систематические подсказки расширить охват на другие устройства; это также снижает вероятность блокировки учетной записи. Проактивный обмен сообщениями помогает обеспечить беспрепятственную аутентификацию независимо от устройства пользователя, значительно повышая безопасность и обеспечивая удобство. Например, если пользователь сначала регистрирует ключ доступа в Windows, а затем входит в систему через Android-устройство с помощью резервных вариантов, система должна четко предложить: «Настройте ключ доступа здесь, чтобы в следующий раз не вводить пароль».

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

В гибридных сценариях входа, включающих кросс-устройственную аутентификацию (CDA), предложите пользователям сразу после успешной аутентификации сохранить нативные ключи доступа локально, что повысит удобство в будущем. Например, после завершения CDA через смартфон для авторизации сеанса Windows четко предложите пользователю: «Добавьте ключ доступа прямо на это устройство, чтобы в следующий раз не использовать телефон».

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

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

Одним из эффективных методов является первоначальное отслеживание добровольного принятия, что позволяет пользователям ознакомиться с использованием ключей доступа. После того как пользователи несколько раз успешно войдут в систему с помощью ключей доступа, вы можете постепенно отключать методы входа на основе пароля, четко сообщая об этом переходе заблаговременно. Например, прямо сообщите пользователям: «Со следующего месяца пароли больше не будут приниматься; пожалуйста, убедитесь, что ваш ключ доступа активен».

Тщательный мониторинг статистики вовлеченности пользователей также помогает настроить обязательный переход. Если пользователи неоднократно отклоняют подсказки о регистрации, усильте свое сообщение, возможно, удалив опцию «Пропустить» после определенного порога, или переведите сообщение в разряд обязательных действий, как показано в реализации Microsoft выше. Однако всегда предоставляйте безопасные резервные механизмы, такие как аппаратные ключи безопасности, для пользователей, которые сталкиваются с реальными техническими ограничениями или проблемами совместимости.

Четкое донесение преимуществ, таких как защита от фишинга и взлома учетных записей, укрепляет понимание пользователями необходимости обязательного внедрения ключей доступа (что отличается от упрощенного обмена сообщениями, когда это все еще необязательно). Сообщения типа «Ключи доступа помогают нам сохранять вашу учетную запись в безопасности — пароли скоро будут отменены» подчеркивают необходимость и ценность этого перехода, повышая уверенность пользователей в принятии ключей доступа как нового стандарта аутентификации.

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

Ниже приведено подробное описание, четко согласованное с предоставленной блок-схемой:

flowchart TD
    A[Пользователь входит в систему] --> B{Есть ли уже у пользователя ключ доступа?}

    %% Shared nodes
    Z[Ключ доступа создан]
    CD[Период ожидания 30 дней]

    %% Primary flow: create first passkey
    B -->|Нет| P0[Основной процесс]
    P0 --> P1{Пароль автозаполнен?}
    P1 -->|Да| CC[Попытка Conditional Create]
    CC --> P2{CC успешен?}
    P2 -->|Да| Z
    P2 -->|Нет| P3{Десктоп или мобильный?}
    P1 -->|Нет| P3

    P3 -->|Десктоп| D1
    P3 -->|Мобильный| M1

<CustomBanner type="BuyVsBuildGuide" />

    subgraph Desktop [Основной процесс: Десктоп]
        direction TB
        D1[Подсказка 1] --> D2{Принять?}
        D2 -->|Да| DZ[Готово]
        D2 -->|Нет| D3[Подсказка 2] --> D4{Принять?}
        D4 -->|Да| DZ
        D4 -->|Нет| D5[Подсказка 3] --> D6{Принять?}
        D6 -->|Да| DZ
        D6 -->|Нет| DCD[Период ожидания]
    end

    subgraph Mobile [Основной процесс: Мобильный]
        direction TB
        M1[Авто-подсказка 1] --> M2{Принять?}
        M2 -->|Да| MZ[Готово]
        M2 -->|Нет| M3[Подсказка 2] --> M4{Принять?}
        M4 -->|Да| MZ
        M4 -->|Нет| M5[Подсказка 3] --> M6{Принять?}
        M6 -->|Да| MZ
        M6 -->|Нет| MCD[Период ожидания]
    end

    DZ --> Z
    MZ --> Z
    DCD --> CD
    MCD --> CD

    %% Secondary flow: additional devices / recovery
    B -->|Да| S0[Второстепенный процесс]
    S0 --> S1[Новое устройство или вход по резервному методу]
    S1 --> S2{Пароль автозаполнен?}
    S2 -->|Да| SCC[Попытка Conditional Create]
    SCC --> S3{CC успешен?}
    S3 -->|Да| Z
    S3 -->|Нет| S4[Добавить ключ доступа здесь?]
    S2 -->|Нет| S4
    S4 --> S5{Принять?}
    S5 -->|Да| Z
    S5 -->|Пропустить 3 раза| CD

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

• Есть ли у пользователя уже ключ доступа?

  • Если нет (ноль ключей доступа), пользователи направляются на Основной экран.

  • Если да (один или несколько ключей доступа), пользователи переходят на адаптированный Второстепенный экран.

На Основном экране подход к регистрации зависит от платформы устройства пользователя:

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

• Процесс на десктопе
  На десктопах, если Conditional Create не применяется, подсказка о создании ключа доступа является ручной:

  • Первая подсказка: Пользователи явно выбирают Принять или Пропустить создание ключа доступа.

    • Если они Принимают, ключ доступа создается немедленно.

    • Если они Пропускают, они столкнутся со Второй подсказкой при следующем входе.

  • Вторая подсказка предлагает еще один шанс, снова явно прося пользователя Принять или Пропустить.

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

    • Если они снова Пропускают, они получают Третью подсказку во время последующего сеанса.

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

• Процесс на мобильном устройстве использует более динамичный подход:

  • Первоначально подсказка о создании ключа доступа запускается автоматически из-за интуитивно понятного характера мобильной биометрической регистрации.

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

    • Если пользователи Пропускают первую автоматическую подсказку, процесс переключается на ручную Вторую подсказку при их следующем входе.

  • При Второй подсказке (ручной) пользователи снова явно выбирают Принять или Пропустить.

    • Если они Принимают, создание ключа доступа проходит успешно.

    • Если снова пропускают, предлагается Третья подсказка во время последующего сеанса.

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

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

Для пользователей, у которых уже есть хотя бы один ключ доступа, вторичные подсказки фокусируются на расширении охвата ключами доступа на нескольких устройствах или операционных системах, чтобы устранить зависимость от резервных методов:

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

• После успешного входа с помощью резервного метода (пароль, OTP или вход CDA на основе QR-кода) пользователи видят четкую подсказку на Второстепенном экране для конкретного устройства, предлагающую им создать дополнительный ключ доступа. Пример сообщения может включать: «Настройте ключ доступа здесь, чтобы пропускать пароль на этом устройстве».

  • У пользователей снова есть возможность Принять или Пропустить.

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

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

Описанная блок-схема представляет собой надежный базовый план для реализации эффективной стратегии регистрации ключей доступа после входа в систему. Хотя описанные шаги — такие как разграничение десктопного и мобильного опыта, тщательное управление частотой подсказок и предоставление четких путей после повторяющихся пропусков — отражают проверенные лучшие практики, наблюдаемые при крупномасштабных внедрениях такими компаниями, как Amazon, Microsoft и Google, важно подчеркнуть, что базы пользователей значительно различаются. То, что исключительно хорошо работает в одном сценарии, может дать разные результаты в другом из-за различной демографии пользователей, предпочтений устройств и организационных контекстов.

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

Детальное отслеживание Уровней принятия ключей доступа и других важных KPI предоставляет ценную информацию о том, какие части вашего процесса успешны или испытывают трудности. Например, анализ точек отсева в процессе регистрации может выявить, считают ли пользователи подсказки слишком навязчивыми, запутанными или несвоевременными. Вот наша рекомендация по метрикам для отслеживания:

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

Правильная реализация лучших практик по созданию ключей доступа с A/B-тестированием, постепенным внедрением, Conditional Create и обработкой крайних случаев в более чем 100 комбинациях ОС/браузеров требует месяцев инженерной работы. Corbado обеспечивает наблюдаемость и аналитику внедрения поверх вашего существующего стека идентификации, поэтому вы можете запуститься за считанные дни, а не месяцы, сохранив при этом аутентификацию полностью внутри компании. Наши SDK и компоненты созданы на основе проверенных лучших практик от крупных внедрений, таких как Amazon, Google и Microsoft, и усовершенствованы реальными данными из масштабных реализаций, таких как VicRoads.

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

• Почему этот пользователь трижды пропустил подсказку о ключе доступа?
• Какие комбинации ОС/браузеров имеют наибольший отсев?
• Срабатывает ли Conditional Create на самом деле или беззвучно дает сбой?
• Как принятие ключей доступа соотносится с первым напоминанием в сравнении с повторными?

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

Corbado предоставляет встроенную наблюдаемость аутентификации, специально созданную для процессов создания ключей доступа. Для получения полного обзора метрик аутентификации помимо ключей доступа ознакомьтесь с нашим руководством по аналитике аутентификации:

Один и тот же дашборд, разные истории в зависимости от того, кто спрашивает:

SDK от Corbado автоматически реализуют все лучшие практики создания, включая Conditional Create, подсказки после входа в систему и регистрацию на нескольких устройствах:

Когда регистрация не удается, Corbado дает вам инструменты, чтобы понять почему:

• Таймлайн отладки для каждого пользователя: Воспроизведите путь регистрации по сеансам и устройствам.
• Интеллектуальная классификация ошибок: Отличайте информационные ошибки от критических сбоев.
• Обнаружение фрагментации менеджеров паролей: Выявляйте конфликты между Dashlane, 1Password и нативными менеджерами браузера.
• Обнаружение аномалий: Немедленные оповещения при неожиданном падении показателей регистрации.

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

Ключи доступа стали революционным методом аутентификации, обеспечивая более быстрый, простой и безопасный вход в систему по сравнению с традиционными учетными данными. Однако простое предложение ключей доступа не гарантирует, что пользователи их примут. Организации должны стратегически разрабатывать подсказки о ключах доступа, проводить A/B-тестирование сообщений и адаптировать процессы к различным устройствам, чтобы повысить уровень принятия ключей доступа свыше 50 % — порога, при котором пароли становятся действительно заменимыми. В этом руководстве были рассмотрены базовые знания, начиная от понимания того, почему внедрение важнее базовой реализации, и заканчивая подробным описанием конкретных тактик напоминаний (после входа в систему в сравнении со страницей настроек, ограничения частоты, автоматическое создание на мобильных устройствах и т. д.), на которые опираются крупные технологические компании для достижения успеха.

• Каковы лучшие практики для пользовательских подсказок о ключах доступа? Наиболее эффективные подсказки появляются сразу после успешного входа пользователей в систему, используя их настрой на аутентификацию. Сообщения должны четко подчеркивать либо удобство («Быстрый вход, без паролей»), либо безопасность («Защитите свою учетную запись от фишинга»), что определяется посредством строгого A/B-тестирования. Напоминания также должны уважать автономию пользователя, включая периоды ожидания после неоднократных пропусков, чтобы свести к минимуму разочарование.

• Как стимулировать принятие ключей доступа пользователями в корпоративной среде? Успешное корпоративное внедрение в значительной степени опирается на структурированные, поэтапные подходы в сочетании с непрерывной аналитикой. Организации должны отслеживать ключевые показатели эффективности (например, уровень принятия ключей доступа, успешность создания), дорабатывая свои стратегии на основе пользовательских данных. Поощрение регистрации ключей доступа на нескольких устройствах и перевод ценных сегментов на обязательное использование ключей доступа необходимы для достижения желаемого порога принятия в 50–80 %.

Если ваша организация планирует масштабное развертывание и стремится к лидирующим в отрасли показателям внедрения, мы в Corbado будем рады помочь вам. Наша платформа для предприятий предоставляет сложную аналитику, A/B-тестирование и адаптированные пути пользователей для обеспечения оптимального внедрения ключей доступа.

О Corbado

Corbado — это Passkey Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →