Безопасность данных Google Play и конфиденциальность App Store: как заполнить без догадок

Форму заполняет один человек, а ответы знает вся команда

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

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

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

Начните со сборки, которую действительно собираетесь выпускать

Слова «мы используем Firebase» недостаточно. Под этим названием могут скрываться разные подключённые продукты, параметры и отправляемые сведения. Для начала попросите разработчика указать версию приложения, список встроенных библиотек и работающих интеграций. SDK — это готовая библиотека, которую добавляют, например, для аналитики или оплаты.

Отдельно отметьте различия между iOS и Android. Команда могла включить диагностику только на одной платформе или подключить разные способы входа. Ещё один источник различий — настройки, которые меняются без обновления приложения. Если маркетолог может включить новый сбор данных удалённо, это тоже часть картины.

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

Пройдите путь пользователя и запишите, что уходит с устройства

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

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

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

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

Не путайте четыре разных обещания

Политика конфиденциальности объясняет правила обработки данных. Сведения на странице магазина показывают их в структуре Apple или Google. Системное разрешение открывает приложению доступ к конкретной возможности телефона. Согласие относится к определённой обработке и зависит от её контекста и применимых требований.

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

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

App Privacy и Data safety нельзя заполнять как перевод одной формы

У платформ разные определения и структура вопросов. Apple отдельно рассматривает связь данных с человеком и использование для отслеживания. Само слово «аналитика» ещё не означает, что нужно одинаково ответить на все вопросы об отслеживании: важно, что именно делает ваш сервис и с чем связывает сведения.

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

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

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

Проверьте SDK отдельно от собственных функций

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

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

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

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

Посмотрите поведение до выбора и после отказа

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

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

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

Переносите ответы в консоль вместе с подтверждениями

В App Store Connect откройте сведения о выбранном приложении и раздел App Privacy. В Play Console найдите раздел контента приложения и форму Data safety. Названия в интерфейсе зависят от языка, поэтому ориентируйтесь на назначение раздела, а не на скриншот старой инструкции.

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

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

При несоответствии ищите причину, а не удобную формулировку

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

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

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

Сделайте следующий релиз проще

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

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

Для обсуждения подготовки приложения с Appfyl можно начать с короткого брифа. Укажите, что уже работает и какие сервисы подключены. Это запрос на обсуждение проекта, а не автоматическая проверка соответствия правилам.

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