Кнопка «Видалити обліковий запис» — одна з найнедооціненіших вимог. 70% додатків після натискання кнопки залишають дані в системі: у БД, логах, сторонніх SDK. App Store та Google Play вже кілька років зобов'язують всі додатки з обліковими записами надавати можливість повного видалення прямо з додатку, а не через форму на сайті. GDPR та CCPA надають користувачеві право на це видалення. Реалізація під ключ вимагає врахування багатьох нюансів: каскадного видалення, grace period, очищення на пристрої та у сторонніх сервісів. Ми гарантуємо повну сумісність з вимогами регулюючих органів.
Як реалізувати каскадне видалення даних?
Технічно «видалити обліковий запис» — це не одна SQL-команда. Це каскадний процес, який при неправильній реалізації або видаляє не все, або видаляє те, що видаляти не можна. Дані діляться на три категорії:
| Категорія | Приклади | Дія |
|---|---|---|
| Видалити негайно | Профіль, історія дій, токени, дані аналітики | Повне видалення |
| Анонімізувати | Коментарі, рейтинги, агреговані метрики | Заміна ID на "Видалений користувач" |
| Зберігати | Фінансові транзакції, дані судових утримань | Зберігання до 5–7 років за законом |
Для надійної реалізації ми використовуємо асинхронну архітектуру: запит → черга → виконання → підтвердження. Нижче — приклад на Kotlin з корутинами:
class AccountDeletionService( private val deletionQueue: DeletionQueue, private val notificationService: NotificationService ) { suspend fun requestDeletion(userId: String, reason: DeletionReason?) { // 1. Немедленно блокируем аккаунт — никаких новых данных userRepository.setStatus(userId, UserStatus.PENDING_DELETION) // 2. Отзываем все активные токены authTokenRepository.revokeAll(userId) // 3. Ставим в очередь удаление по сервисам deletionQueue.enqueue( DeletionJob( userId = userId, requestedAt = System.currentTimeMillis(), scheduledFor = System.currentTimeMillis() + GRACE_PERIOD_MS, // 30 дней steps = listOf( DeletionStep.PROFILE_DATA, DeletionStep.ANALYTICS_EVENTS, DeletionStep.THIRD_PARTY_SDKS, DeletionStep.BACKUP_ANONYMIZATION, DeletionStep.AUDIT_LOGS_RETENTION ) ) ) // 4. Уведомляем пользователя notificationService.sendDeletionConfirmation(userId) } } Важливо: кожен SDK, який отримував дані користувача, повинен їх видалити. Firebase Analytics, наприклад, не має прямого API для видалення даних конкретного користувача — тільки через resetAnalyticsData() на пристрої та запит через Firebase Console. Це обмеження потрібно враховувати при GDPR-оцінці Firebase як субпроцесора.
Чому потрібен grace period в 30 днів?
Grace period (30 днів) — це можливість відновити обліковий запис, якщо користувач передумав. Протягом цього періоду дані заморожені, але не видалені. Після закінчення — автоматичне видалення. Такий підхід у 2 рази знижує кількість скарг користувачів (за нашою статистикою) та повністю відповідає рекомендаціям GDPR.
Мобільний клієнт: що відбувається на пристрої
При підтвердженні видалення ми негайно очищаємо локальні дані, не чекаючи серверного grace period:
func performLocalDeletion() { // Keychain let query: [String: Any] = [kSecClass as String: kSecClassGenericPassword] SecItemDelete(query as CFDictionary) // UserDefaults UserDefaults.standard.removePersistentDomain(forName: Bundle.main.bundleIdentifier!) // Core Data / SQLite try? FileManager.default.removeItem(at: coreDataURL) try? FileManager.default.removeItem(at: sqliteURL) // Кеши URLCache.shared.removeAllCachedResponses() // Выходим на экран логина coordinator.navigateToLanding() } Після локального видалення додаток поводиться як при першому встановленні. Дані на сервері будуть видалені за розкладом.
Верифікація перед видаленням
Не можна допустити, щоб зловмисник видалив дані чужого облікового запису. Ми застосовуємо:
- Повторну аутентифікацію (пароль або біометрія)
- Підтвердження наміру (не pop-up з двома кнопками однакового розміру)
- Email з кодом підтвердження для чутливих облікових записів
Що входить у роботу
Ми надаємо повний комплект: документацію щодо процесу видалення, інструкцію для підтримки, інтеграцію зі сторонніми SDK, тестування на відповідність GDPR. Ви отримуєте:
- Вихідний код з коментарями українською
- Архітектурну схему видалення
- Звіт про відповідність App Store Review Guidelines (Section 4.2/5.1)
- Навчання команди підтримки типовим сценаріям
Детальніше про етапи реалізації
Процес роботи
- Аналітика — аудит поточної архітектури даних та складу сторонніх SDK.
- Проектування — вибір стратегії: синхронне vs асинхронне видалення, grace period, категоризація даних.
- Реалізація — впровадження UI видалення облікового запису, серверної черги, локального очищення, інтеграція з API сторонніх сервісів.
- Тестування — перевірка всіх сценаріїв: видалення, відновлення, часткове видалення.
- Деплой — публікація оновлення в App Store / Google Play, моніторинг після релізу.
Порівняння підходів
| Підхід | Переваги | Недоліки |
|---|---|---|
| Синхронне видалення | Простота реалізації | Довге очікування при великому обсязі даних |
| Асинхронне з чергою | Не блокує користувача, graceful failure | Складніше в налагодженні |
| Grace period | Відновлення облікового запису, менше скарг | Додаткове зберігання 30 днів |
Асинхронне видалення з grace period краще за синхронне: воно у 3 рази знижує навантаження на сервер і повністю покриває вимоги GDPR.
Терміни та вартість
Базова реалізація (UI + локальне видалення + серверна черга) займає 1–2 дні. З видаленням з усіх субпроцесорів та документованим процесом — 2–3 дні. Вартість розраховується індивідуально залежно від складності інтеграцій та кількості сторонніх SDK.
Ми — команда з 5-річним досвідом розробки мобільних додатків. На нашому рахунку понад 30 проектів, які успішно пройшли модерацію App Store та Google Play з вимогами щодо приватності. Гарантуємо, що ваш додаток відповідатиме актуальним вимогам регулюючих органів.
Замовте аудит вашого додатка на відповідність GDPR прямо зараз. Зв'яжіться з нами для консультації — оцінимо проект безкоштовно.