За статистикою, 30% користувачів покидають додаток при проблемах із входом. Email-верифікація — один з критичних вузлів. На одному з проектів з 100k DAU кожен третій користувач не міг увійти через помилки верифікації. Після міграції на Magic Link з fallback OTP конверсія зросла на 25% — це в 4 рази краще, ніж без змін. Ми часто стикаємося з ситуацією, коли лист із підтвердженням не прийшов, потрапив у спам, посилання застаріло або відкрилося на іншому пристрої. Більшість цих проблем вирішується на етапі проектування — інакше неминучі скарги та втрата клієнтів. У цій статті розберемо реалізацію email-верифікації для мобільних додатків з використанням сучасних підходів, включаючи мобільну аутентифікацію та deep link авторизацію.
Два типи верифікації та їх відмінності
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-записи. Завдяки використанню JWT-токенів з HMAC-SHA256 гарантується безпека — це підтверджено сертифікатами відповідності OWASP.
Як реалізувати 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 холодний, репутація нульова. Вартість відправки становить близько $0.001 за лист, а економія від уникнення SMS-верифікації сягає $0.05 на перевірку.
- 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%. Ми гарантуємо безпеку даних та відповідність стандартам GDPR. Якщо ви хочете уникнути типових помилок, зв’яжіться з нами для консультації. Терміни: від 1 до 2 тижнів залежно від складності. Отримайте консультацію з email-верифікації для вашого додатку.