Удаление аккаунта в приложении: что должно исчезнуть кроме профиля

Человек ушёл, но отношения с сервисом почему-то продолжаются

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

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

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

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

Сначала договоритесь, какой именно аккаунт удаляется

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

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

Отделите удаление аккаунта от трёх соседних действий. Выход завершает сеанс на устройстве. Удаление приложения убирает его с телефона. Отмена продления подписки касается будущих платежей. Названия должны описывать именно то, что происходит, без подмены полного удаления временной блокировкой.

Выпишите понятные последствия для своего продукта. Ученик потеряет доступ к истории занятий и отправленным работам? Сможет ли заранее скачать сертификат? Что произойдёт с сообщениями преподавателю? Возможность сохранить нужные материалы полезна, но не должна превращаться в обязательное препятствие для удаления.

Что написать перед последним подтверждением

Вместо общей фразы «Действие необратимо» человеку нужны конкретные сведения. Например: какие данные исчезнут, сохранится ли доступ к купленному курсу, что происходит с подпиской и когда закончится обработка. Если часть записей остаётся по обоснованной причине, это тоже нужно объяснить.

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

Не путайте «Запрос принят» и «Аккаунт удалён». Если на сервере ещё выполняются задачи, сообщение об окончательном успехе будет преждевременным. Лучше сразу объяснить, как человек узнает результат и куда обратиться, если обещанное уведомление не пришло.

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

Требования магазинов задают минимум, но не решают всё за вас

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

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

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

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

Подписку проверяйте отдельно для каждого способа покупки

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

В актуальной документации RevenueCat есть конкретное различие: удаление записи клиента не отменяет автоматически мобильные подписки и подписки Stripe Web Payments, а подписки RevenueCat Billing отменяются сразу. Поэтому обе общие фразы, «подписка всегда отменяется» и «подписка никогда не отменяется», могут оказаться неверными. В приложении нужно описывать именно тот способ покупки, которым воспользовался человек.

*Удаление данных и прекращение регулярных списаний требуют отдельных проверок. Связь между ними зависит от способа оплаты.*

Уточните, где человек действительно купил доступ. Он мог оформить подписку на одном устройстве, а удалять аккаунт с другого. Ссылка на управление подпиской должна вести туда, где оформлена покупка. Выбирать её только по операционной системе текущего телефона нельзя.

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

Покажите, где находятся данные и кто их убирает

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

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

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

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

Что должна видеть команда в админ-панели

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

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

Проверьте и повторный запрос. Человек может дважды нажать кнопку или отправить форму ещё раз, не увидев ответа. Повтор должен безопасно продолжить ту же работу или сообщить её статус. Разработчикам важно предусмотреть это до запуска, потому что нестабильная связь для мобильного приложения — обычная ситуация.

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

Подтверждение личности не должно создавать тупик

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

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

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

Как принять готовую функцию

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

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

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

При обсуждении с Appfyl полезно принести три списка: способы входа, места хранения данных и способы покупки доступа. По ним легче определить объём работы и критерии приёмки. Хорошо сделанное удаление не должно впечатлять количеством экранов. Оно должно спокойно завершать отношения с сервисом на понятных человеку условиях.

Частые вопросы