По статистике, 30% пользователей покидают приложение при проблемах с входом. Email-верификация — один из критичных узлов. На одном из проектов с 100k DAU каждый третий пользователь не мог залогиниться из-за ошибок верификации. После миграции на Magic Link с fallback OTP конверсия выросла на 25%. Мы часто сталкиваемся с ситуацией, когда письмо с подтверждением не пришло, попало в спам, ссылка истекла или открылась на другом устройстве. Большинство этих проблем решается на этапе проектирования — иначе неизбежны жалобы и потеря клиентов. В этой статье разберём реализацию email-верификации для мобильных приложений с использованием современных подходов.
Два типа верификации и их отличия
Magic Link — письмо со мгновенной ссылкой для авторизации. Никакого пароля. Удобно, но требует, чтобы пользователь имел доступ к email именно на устройстве входа. Подходит для B2B-инструментов, где пользователи часто за компьютером.
Email + OTP-код — письмо с 6-значным кодом, который пользователь вводит в приложении. Больше шагов, но работает без deep link инфраструктуры и подходит для случаев, когда email доступен на другом устройстве.
| Критерий | Magic Link | OTP-код |
|---|---|---|
| Шаги пользователя | 1 клик (если на устройстве) | 5-6 шагов |
| Требуется deep link инфраструктура | Да (Universal/App Links) | Нет |
| Работает при доступе с другого устройства | Требует fallback | Работает напрямую |
| UX | Отличный (мгновенно) | Средний (ручной ввод) |
Magic Link уменьшает количество действий пользователя в 5 раз по сравнению с OTP-кодом (1 клик против 5-6 шагов). 80% пользователей успешно проходят верификацию при первом запросе, если правильно настроены DNS-записи.
Как реализовать deep linking для iOS и Android?
Для Magic Link необходима настройка Universal Links (iOS) и App Links (Android). На iOS требуется файл apple-app-site-association (AASA) на домене по пути https://yourdomain.com/.well-known/apple-app-site-association. iOS загружает его при установке приложения и кэширует.
{ "applinks": { "apps": [], "details": [{ "appID": "TEAMID.com.yourcompany.app", "paths": ["/auth/verify/*"] }] } } Ссылка в письме: https://yourdomain.com/auth/verify/TOKEN. При клике iOS проверяет AASA, открывает приложение через UIApplicationDelegate. Приложение извлекает токен и отправляет на backend.
На Android — assetlinks.json по https://yourdomain.com/.well-known/assetlinks.json. Intent Filter в манифесте:
<intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="https" android:host="yourdomain.com" android:pathPrefix="/auth/verify/"/> </intent-filter> Критичный edge case: пользователь открыл письмо на компьютере и кликнул по ссылке — браузер должен показать страницу с инструкцией «Вернитесь в приложение и введите код». Веб-страница генерирует тот же токен в виде QR-кода или кода для ручного ввода. Пропуск этого сценария — частая ошибка.
Другой edge case: если AASA-файл недоступен при установке (например, ошибка сервера) — Universal Links не работают. Нужен fallback: веб-страница с кнопкой «Открыть в приложении» через Custom URL Scheme (myapp://auth/verify/TOKEN).
Почему email доставляемость критична?
Письмо с кодом в папке «Спам» — смерть для конверсии. Ключевые факторы:
- SPF, DKIM, DMARC — обязательная настройка DNS. Без них Gmail и Outlook агрессивно фильтруют. Подробнее — на Wikipedia (SPF).
- Transactional email провайдер — SendGrid, Postmark, Mailgun, Amazon SES. Не отправляйте через SMTP собственного сервера — IP холодный, репутация нулевая.
- From-адрес — реальный домен, не
noreply@yourdomainбез DMARC. Лучшеhello@yourdomain— меньше спам-триггеров. - Текст письма — без «FREE», «Click here to win», верхнего регистра. Только функциональный текст: «Ваш код для входа: 847293».
TTL токена: 15-30 минут для OTP-кода, 1 час для Magic Link. После использования — токен немедленно инвалидируется (однократное использование). Храним hash токена, не сам токен.
Типичные ошибки и решения
| Ошибка | Решение |
|---|---|
| Письмо в спаме | Настройка SPF/DKIM/DMARC |
| Ссылка не открывает приложение | Проверка AASA/assetlinks |
| Токен использован повторно | Инвалидация после первого использования |
| Cross-device не работает | Fallback веб-страница с QR или кодом |
Как настроить fallback для cross-device сценария
1. На стороне backend при открытии Magic Link на незнакомом устройстве генерируется короткий код. 2. Веб-страница отображает QR-код или 6-значный код. 3. Пользователь вводит код в мобильном приложении. 4. Backend связывает сессию и авторизует.Что входит в работу
- Реализация Magic Link (Universal Links / App Links) с fallback на OTP
- Настройка email-провайдера и DNS (SPF/DKIM/DMARC)
- Обработка cross-device edge cases (веб-страница с QR или code)
- Документация по интеграции (схема deep linking, обработка ошибок)
- Поддержка после запуска: 2 недели мониторинга и фикса багов
Наша команда имеет более 5 лет опыта разработки мобильных приложений и реализовала авторизацию в более чем 50 проектах. После внедрения Magic Link конверсия регистрации выросла в среднем на 25%. Если вы хотите избежать типичных ошибок, свяжитесь с нами для консультации. Сроки: от 1 до 2 недель в зависимости от сложности. Получите консультацию по email-верификации для вашего приложения.