Персональные данные в мобильном приложении: SDK, аналитика, push и требования 152-ФЗ

Полный практический разбор для разработчиков и владельцев приложений — что собирает ваш SDK, как это регулируется и что изменилось в 2024–2025 годах

Почему это важно именно сейчас

Российский рынок мобильных приложений растёт: миллионы людей пользуются банковскими, ретейловыми, медицинскими и развлекательными приложениями каждый день. За этим ростом скрывается колоссальный объём персональных данных — имён, телефонов, геолокаций, поведенческих паттернов, — которые собирают встроенные SDK аналитики, рекламные трекеры и сервисы push-уведомлений.

Долгое время разработчики и владельцы приложений относились к 152-ФЗ формально: размещали шаблонную политику конфиденциальности на сайте и считали задачу выполненной. В 2024–2025 годах ситуация изменилась кардинально. Штрафы выросли в десятки раз, появилась уголовная ответственность за грубые нарушения, а требования к локализации данных ужесточились до прямого запрета на первичный сбор на зарубежных серверах [1].

Эта статья — для тех, кто разрабатывает, владеет или эксплуатирует мобильные приложения в России: CTO, продакт-менеджеров, юристов, DPO-офицеров и технических директоров. Здесь мы разберём, что конкретно собирают популярные SDK, как это квалифицируется по 152-ФЗ, какие изменения вступили в силу в 2024–2025 годах и что нужно сделать прямо сейчас, чтобы не получить многомиллионный штраф.

Что такое персональные данные в контексте мобильного приложения

Статья 3 152-ФЗ определяет персональные данные как «любую информацию, относящуюся прямо или косвенно к определённому или определяемому физическому лицу» [2]. На практике это означает гораздо более широкий круг данных, чем принято думать.

В мобильном приложении к персональным данным относятся:

• Регистрационные данные: имя, email, номер телефона, дата рождения.
• Технические идентификаторы: IDFA (Identifier for Advertisers) на iOS, GAID (Google Advertising ID) на Android — оба считаются персональными данными, поскольку позволяют идентифицировать конкретное устройство и его владельца [3].
• Геолокация: координаты GPS, данные о ближайших Wi-Fi точках — особенно чувствительная категория, поскольку позволяет восстановить маршруты и паттерны поведения человека.
• Push-токены: уникальный токен устройства для отправки push-уведомлений в сочетании с профилем пользователя является персональным идентификатором.
• Поведенческие данные: история действий в приложении, время сессий, нажатые кнопки — при связке с профилем пользователя это ПДн.
• Финансовые данные: история покупок, реквизиты платёжных методов.
• Биометрия: данные Face ID, отпечатки пальцев — специальная категория ПДн с повышенными требованиями защиты [4].

Важно понимать: даже если приложение не требует регистрации, а собирает только «анонимные» технические данные (IDFA/GAID плюс история поведения), регулятор с высокой вероятностью признает это персональными данными — поскольку такая связка позволяет однозначно идентифицировать пользователя [3].

Как SDK собирает данные: разбор по инструментам

Аналитические SDK

Аналитика — первый и самый распространённый источник утечки ПДн из мобильных приложений. Разработчики подключают SDK фактически в первые дни работы над проектом, зачастую не задумываясь о том, что именно и куда уходит.

Google Firebase Analytics по умолчанию собирает рекламные идентификаторы устройств (на Android — GAID, на iOS — IDFA или IDFV если пользователь отказал в доступе к IDFA), а также применяет технологии, аналогичные cookie [5]. Данные отправляются на серверы Google за пределами России.

Yandex AppMetrica — российский аналог, хранящий данные на серверах в России. SDK собирает идентификаторы устройств, информацию о сессиях, событиях, crash-репорты. При этом AppMetrica позволяет отключить отправку статистики до получения согласия пользователя: данный механизм рекомендован для соблюдения 152-ФЗ [6].

AppsFlyer, Adjust — системы мобильной атрибуции, используют IDFA, GAID, IMEI и другие идентификаторы для сопоставления установок приложений с рекламными кликами [7]. По умолчанию данные уходят за рубеж.

Проблема заключается в том, что большинство западных SDK работают по принципу «opt-out»: данные начинают собираться с момента первого запуска приложения, ещё до того, как пользователь что-либо принял или подтвердил. По требованиям 152-ФЗ, базирующегося на принципе «opt-in» (сначала согласие, потом обработка), такая схема является нарушением [2].

Рекламные идентификаторы: IDFA и GAID

IDFA (Identifier for Advertisers) — уникальный идентификатор устройства iOS, используемый для таргетированной рекламы и атрибуции. После выхода iOS 14.5 в 2021 году Apple ввела обязательный запрос через механизм App Tracking Transparency (ATT): теперь приложение обязано запросить явное разрешение пользователя, прежде чем получить доступ к IDFA [8].

GAID (Google Advertising ID) — аналог для Android. Исторически был менее ограниченным, чем IDFA: пользователь мог отказаться от персонализированной рекламы в настройках, но по умолчанию идентификатор был доступен всем приложениям. Google работает над внедрением Privacy Sandbox для Android, аналогичного механизму ATT от Apple [9].

С точки зрения российского законодательства, использование IDFA и GAID для рекламной атрибуции без соответствующего согласия пользователя является обработкой ПДн без правового основания — нарушение ч. 1 ст. 6 152-ФЗ [2].

Push-уведомления: не только техническое разрешение

Push-уведомления создают распространённое юридическое заблуждение: владельцы приложений полагают, что разрешение на уведомления, которое iOS или Android запрашивает при первом запуске, является достаточным согласием для любой коммуникации. Это не так.

Технические разрешения операционной системы («Разрешить уведомления?») регулируют только возможность показа уведомлений на экране устройства. Они никак не охватывают:

• сбор push-токена как персонального идентификатора;
• передачу push-токена третьим сторонам (FCM/APNs и далее — сервисам рассылки);
• использование поведенческих данных для персонализации содержимого уведомлений;
• сегментацию пользователей для маркетинговых рассылок.

Каждое из этих действий требует самостоятельного правового основания по 152-ФЗ [2]. Маркетинговые push-рассылки, основанные на сегментации по поведению пользователя, подпадают под определение обработки ПДн в маркетинговых целях и требуют отдельного согласия.

Кроме того, популярные сервисы рассылки push (Firebase Cloud Messaging от Google, OneSignal) хранят данные за рубежом, что с 1 июля 2025 года является нарушением требования о первичном сборе ПДн на российских серверах [10].

Ключевые требования 152-ФЗ для мобильных приложений

Статус оператора и уведомление Роскомнадзора

Любая компания или индивидуальный предприниматель, чьё приложение собирает персональные данные пользователей, автоматически становится оператором ПДн по смыслу ст. 3 152-ФЗ [2]. Обязанность оператора — до начала обработки данных уведомить Роскомнадзор (РКН) через портал Госуслуг или сайт ведомства и быть включённым в реестр операторов ПДн [4].

С 30 мая 2025 года штраф за неуведомление РКН о начале обработки ПДн составляет от 100 000 до 300 000 рублей для организаций [11]. Неуведомление о факте утечки — от 1 до 3 млн рублей [11].

Правовые основания для обработки

Статья 6 152-ФЗ устанавливает исчерпывающий перечень оснований для обработки ПДн [12]. Для мобильного приложения наиболее применимы:

• Согласие субъекта (п. 1 ч. 1 ст. 6) — для аналитики поведения, маркетинговых рассылок, использования рекламных идентификаторов.
• Исполнение договора с пользователем (п. 5 ч. 1 ст. 6) — для базовой функциональности приложения: регистрации, авторизации, обработки покупок.
• Законный интерес (п. 7 ч. 1 ст. 6) — ограниченно применимо, не охватывает рекламу.

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

Требования к согласию: что изменилось в 2025 году

Согласие на обработку ПДн по ст. 9 152-ФЗ должно быть «конкретным, предметным, информированным, сознательным и однозначным» [4]. Это означает, что:

• Согласие не может быть вшито в текст оферты или пользовательского соглашения — с 1 сентября 2025 года (ФЗ № 156-ФЗ от 24.06.2025) оно оформляется отдельным документом [13].
• Заранее проставленные галочки не являются согласием.
• Молчание или бездействие пользователя не является согласием [4].
• Пользователь должен иметь возможность отозвать согласие в любой момент — оператор обязан прекратить обработку в течение 30 дней [4].

В контексте мобильного приложения это означает: при первом запуске приложение должно до начала любой аналитической или рекламной активности SDK показать пользователю специальный экран с конкретным описанием того, какие данные будут собираться, с какой целью и кому передаваться. Пользователь должен активно подтвердить согласие нажатием кнопки — не «Продолжить» и не «Принять условия», а именно «Я соглашаюсь на обработку персональных данных» с возможностью не соглашаться и продолжить пользоваться приложением (в части основного функционала).

Локализация данных: новые жёсткие требования с 1 июля 2025 года

Это изменение стало, пожалуй, самым болезненным для разработчиков мобильных приложений. Федеральный закон № 23-ФЗ от 28.02.2025 ввёл новую редакцию ч. 5 ст. 18 152-ФЗ: запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ с использованием баз данных, находящихся за пределами России, не допускаются [10].

До этого изменения существовала юридическая «серая зона»: компании могли хранить данные за рубежом, если параллельно вели «основную» базу в России. С 1 июля 2025 года именно первичный сбор данных — момент, когда информация впервые записывается в базу данных, — должен происходить на российском сервере [14].

На практике это означает следующее:

• Firebase Realtime Database и Firestore, серверы которых расположены в США и Европе, в стандартной конфигурации нарушают 152-ФЗ [15].
• Google Analytics для мобильных приложений — аналогично.
• AppsFlyer, Adjust и другие западные MMP (Mobile Measurement Partners) — аналогично.
• Даже если данные потом копируются в российскую базу, нарушение уже состоялось в момент первичной записи за рубежом [14].

Штрафы за нарушение требований о локализации: от 1 до 6 млн рублей за первое нарушение, от 6 до 18 млн рублей — за повторное [16].

Передача данных третьим лицам: поручение обработки

Когда приложение передаёт данные пользователей третьей стороне (SDK-провайдеру, сервису рассылок, рекламной сети), это квалифицируется как поручение обработки ПДн по ч. 3 ст. 6 152-ФЗ [12]. Поручение обязательно должно быть оформлено договором, в котором прописаны: перечень передаваемых данных, цели обработки, обязанность соблюдать конфиденциальность и обеспечивать безопасность данных.

На практике это означает, что компании, встраивающие в приложение сторонние SDK, обязаны заключить договоры с каждым SDK-провайдером — с Firebase, с AppMetrica, с сервисами рассылки push. Типовые пользовательские соглашения SDK-провайдеров могут не удовлетворять этому требованию.

Типичные нарушения в мобильных приложениях

Инициализация SDK до получения согласия

Наиболее массовая ошибка: аналитические SDK инициализируются в методе Application.onCreate() или AppDelegate.didFinishLaunchingWithOptions() — то есть в момент запуска приложения, до того как пользователь увидит какой-либо экран. В результате данные об устройстве, IDFA/GAID, информация об установке улетают на серверы SDK-провайдера ещё до получения согласия.

Решение: откладывать инициализацию аналитических SDK до получения явного согласия пользователя. AppMetrica, например, поддерживает создание «библиотеки с отключённой отправкой статистики» до получения разрешения [6].

Отсутствие отдельного согласия на маркетинговые push

Распространённый сценарий: пользователь разрешает push-уведомления через системный диалог iOS/Android, после чего начинает получать маркетинговые рассылки. Никакого отдельного согласия на обработку ПДн в маркетинговых целях при этом не получено.

С точки зрения 152-ФЗ, отправка персонализированных маркетинговых уведомлений — это обработка ПДн в целях, отличных от исполнения договора. Для неё требуется отдельное, конкретное согласие [2].

Недостаточная политика конфиденциальности

Типичная политика конфиденциальности мобильного приложения содержит общие фразы: «Мы собираем данные для улучшения сервиса». Согласно ч. 4 ст. 9 152-ФЗ, в согласии/политике должны быть указаны: конкретный перечень ПДн, цели обработки, перечень действий с данными, срок действия согласия и порядок его отзыва, а также сведения обо всех третьих лицах, которым передаются данные [4]. Каждый SDK-провайдер должен быть перечислен явно.

Использование Google Analytics / Firebase без локализации

После вступления в силу новой редакции ч. 5 ст. 18 152-ФЗ использование Google Analytics для Firebase или Firebase Realtime Database без предварительной первичной записи в российскую базу данных является прямым нарушением. Роскомнадзор использует систему «Ревизор» для отслеживания серверов, на которые уходит трафик из российских приложений [15].

Трансграничная передача без уведомления РКН

Если приложение легально передаёт данные за рубеж (например, для работы с иностранными партнёрами), необходимо уведомить РКН о трансграничной передаче в соответствии со ст. 12 152-ФЗ и убедиться, что страна-получатель обеспечивает адекватную защиту ПДн [2].

Новые штрафы 2025 года: цифры и примеры

Федеральный закон № 420-ФЗ от 30.11.2024 кардинально переработал ст. 13.11 КоАП РФ. Ключевые изменения, вступившие в силу 30 мая 2025 года [11]:

Утечка данных 1 000–10 000 человек: штраф для организации — 3–5 млн руб. Утечка 10 000–100 000 человек — 5–10 млн руб. Утечка более 100 000 человек — до 15 млн руб. Утечка биометрических данных — 15–20 млн руб.

Повторная утечка — оборотный штраф: от 1% до 3% годовой выручки компании. Расчётный минимум — 20 млн руб., максимум — 500 млн руб. [17].

Обработка данных без согласия (базовый состав, ч. 1 ст. 13.11 КоАП): для организаций — 150 000–300 000 руб., при повторном нарушении — до 500 000 руб. [11].

Нарушение уведомления об утечке: организации — от 1 до 3 млн руб. [17].

Уголовная ответственность. В 2024 году в УК РФ введена ст. 272.1: незаконные действия с ПДн могут повлечь уголовное наказание, вплоть до лишения свободы на срок до 10 лет при наличии отягчающих обстоятельств [1].

Для масштаба: крупный e-commerce с 5 млн пользователей, допустивший утечку базы, рискует оборотным штрафом от 20 до 500 млн руб., если это повторное нарушение. Это уже не административная «мелочь», а бизнес-риск уровня системной угрозы.

Как выстроить соответствие 152-ФЗ в мобильном приложении: пошаговый подход

Шаг 1. Инвентаризация SDK и потоков данных

Первым делом необходимо составить полный перечень всех SDK, встроенных в приложение, и зафиксировать для каждого: какие данные собирает, на какие серверы отправляет, есть ли возможность отложить инициализацию до получения согласия. Этот процесс называется Data Flow Mapping (картирование потоков данных) и является обязательным элементом GDPR (европейского аналога 152-ФЗ), а в российской практике — критически необходимым шагом для оценки рисков.

Для каждого SDK задайте три вопроса: (1) Где физически хранятся данные — в России или за рубежом? (2) Есть ли договор поручения обработки с SDK-провайдером? (3) Упомянут ли данный SDK в политике конфиденциальности с указанием передаваемых данных?

Шаг 2. Архитектура «согласие до инициализации»

Спроектируйте приложение так, чтобы до отображения экрана согласия все аналитические и рекламные SDK были деинициализированы или заблокированы. Это требует изменений в архитектуре приложения, но является единственным способом соответствовать принципу opt-in, требуемому 152-ФЗ.

На iOS используйте механизм ATT (App Tracking Transparency) в связке с собственным экраном согласия на ПДн. На Android аналогичный механизм нужно реализовать самостоятельно, поскольку встроенного системного запроса на уровне 152-ФЗ там нет.

Шаг 3. Переход на российские SDK или локализованные решения

Проведите ревизию западных SDK и замените их на российские аналоги там, где это возможно:

• Вместо Firebase Analytics → Yandex AppMetrica (серверы в России, поддерживает отложенную инициализацию).
• Вместо Firebase Cloud Messaging → RuStore Push или российские облачные сервисы рассылки.
• Вместо Google Analytics → собственная аналитика на российском хостинге или AppMetrica.

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

Шаг 4. Разработка и обновление документации

Разработайте корректный пакет документов, включающий: политику конфиденциальности с перечислением всех SDK и третьих лиц; отдельные формы согласия на обработку ПДн для каждой цели (аналитика, маркетинговые рассылки, персонализированная реклама); договоры поручения обработки со всеми SDK-провайдерами; внутренний регламент обработки ПДн.

Механизм отзыва согласия должен быть реализован в интерфейсе приложения, а не только «по запросу на email» — пользователь должен иметь возможность управлять согласиями непосредственно в настройках приложения.

Шаг 5. Уведомление Роскомнадзора

Подайте уведомление о начале обработки ПДн через портал РКН или Госуслуги. После внесения в реестр операторов обязательно поддерживайте актуальность сведений — при изменении перечня обрабатываемых данных или SDK-провайдеров необходимо подавать уведомление об изменениях.

Шаг 6. Регулярный аудит и мониторинг

Ключевая проблема соответствия 152-ФЗ состоит не в том, чтобы один раз всё настроить, а в том, чтобы поддерживать соответствие в динамике. Разработчики регулярно добавляют новые SDK, обновляют версии (которые могут изменить поведение по умолчанию), запускают новые маркетинговые кампании с новыми каналами сбора данных. Каждое такое изменение потенциально создаёт новый риск нарушения.

Специфика отдельных категорий приложений

Финансовые приложения (банки, финтех)

Обрабатывают данные, связанные с финансовыми операциями, — категория повышенной чувствительности. Банковские приложения дополнительно регулируются требованиями Банка России (ГОСТ Р 57580.1). Особое внимание — к биометрическим данным (Face ID для входа в приложение) и передаче данных скоринговым системам.

Медицинские и фитнес-приложения

Данные о состоянии здоровья являются специальной категорией ПДн по ст. 10 152-ФЗ — для их обработки требуется письменное согласие и повышенный уровень защиты [2]. Приложения, синхронизирующиеся с Apple Health или Google Fit, автоматически работают со специальными категориями данных.

Детские приложения

При работе с несовершеннолетними согласие на обработку ПДн должно быть получено от родителей или законных представителей. Таргетированная реклама в отношении детей с использованием их ПДн противоречит как 152-ФЗ, так и этическим стандартам. Сбор данных о несовершеннолетних через SDK аналитики без родительского согласия — потенциально уголовно наказуемое действие.

E-commerce приложения

Хранят историю покупок, адреса доставки, платёжные данные. Особое внимание — к передаче данных курьерским службам и маркетплейсам (договоры поручения обязательны), а также к использованию данных истории покупок для персонализированной рекламы.

Ошибки, которые дорого обходятся

Игнорирование «технических» SDK. Многие владельцы приложений считают, что SDK для мониторинга краш-репортов (Crashlytics, Sentry) или аналитики производительности не собирают ПДн. Это неверно: crash-репорты содержат стектрейсы с идентификаторами устройств, данными о версии ОС и нередко — фрагментами пользовательских данных из памяти.

Копирование чужой политики конфиденциальности. Шаблонные политики не учитывают специфику конкретного приложения — перечень SDK, цели обработки, фактических получателей данных. Регулятор при проверке легко обнаруживает несоответствие между фактической работой приложения и заявленным в политике.

Отсутствие договора с разработчиком. Если приложение разрабатывает сторонняя компания, отношения с ней по поводу ПДн должны быть урегулированы договором. Разработчик имеет доступ к базам данных, поэтому по смыслу 152-ФЗ является «обработчиком» ПДн — а значит, с ним необходим договор поручения.

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

Тренды: куда движется регулирование

Ужесточение требований продолжится

Поправки к законодательству о ПДн не остановились: уже в 2025–2026 годах обсуждается введение уголовной ответственности за грубую халатность, повлёкшую массовые утечки. Роскомнадзор прогнозирует усиление плановых и внеплановых проверок [18].

Централизованный учёт согласий через Госуслуги

Ожидается, что в 2026 году начнётся формирование правовой базы для централизованного учёта согласий через федеральную ГИС (Госуслуги): пользователи смогут видеть, кому они давали согласие, и отзывать его онлайн [18]. Для бизнеса это означает необходимость интеграции с государственными системами учёта согласий.

Privacy-by-design как стандарт

Лучшие практики всё больше сдвигаются от «соответствия по документам» к «приватности по дизайну» (privacy-by-design): архитектурные решения на этапе разработки, которые минимизируют объём собираемых данных и обеспечивают контроль пользователя. Принцип минимизации данных, закреплённый в ст. 5 152-ФЗ [2], должен быть встроен в разработку, а не добавляться «постфактум» через юридические документы.

Импортозамещение в инструментах аналитики

Требование локализации фактически стимулирует переход на российские инструменты. AppMetrica занимает устойчивые позиции; активно развивается экосистема RuStore; появляются отечественные MMP. В среднесрочной перспективе разрыв между функциональностью западных и российских инструментов будет сокращаться.

Что делать прямо сейчас

Если ваше приложение уже в production, следующие действия необходимо выполнить немедленно:

Первое — инвентаризация: составьте карту всех SDK и зафиксируйте, куда уходят данные. Это займёт день, но даст полную картину рисков.

Второе — локализация: проверьте, какие SDK отправляют данные на зарубежные серверы в момент первичного сбора. Каждый такой SDK — потенциальный штраф от 1 до 18 млн руб.

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

Четвёртое — документация: обновите политику конфиденциальности с указанием всех SDK-провайдеров и перечислением передаваемых данных. Заключите договоры поручения обработки.

Пятое — уведомление: зарегистрируйтесь в реестре операторов ПДн Роскомнадзора, если ещё не сделали этого.

Шестое — регулярный контроль: выстройте процесс, при котором каждое добавление нового SDK и каждое обновление приложения проходит через чекпойнт соответствия 152-ФЗ.

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

Как «Пятый фактор» помогает контролировать ПДн в корпоративных системах

Для компаний, которые не только ведут мобильное приложение, но и оперируют большим числом корпоративных систем — CRM, базами данных, 1С, AD/LDAP, — задача соответствия 152-ФЗ не ограничивается приложением. ПДн пользователей хранятся и в backend-базах, и в аналитических хранилищах, и в почте, и в интеграциях.

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

Пятый фактор — это on-prem платформа для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах (БД, хранилища, почта, AD/LDAP, CRM, 1С, API). Ключевая особенность: решение работает с метаданными, структурой и агрегатами, не передавая и не сохраняя «сырых» значений ПДн — то есть само по себе не становится источником дополнительного риска.

Результат: живая «карта ПДн» компании с указанием, где и какие данные хранятся, кто их владелец и что изменилось. Это позволяет раньше замечать новые риски — новые поля, новые интеграции, новые источники, — пока они не превратились в инцидент. Аудит, который раньше занимал недели, превращается в процесс с понятными нарушениями, владельцами и статусами.

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

Источники

[1] Изменения в 152-ФЗ о персональных данных в 2025 году — https://ezybrand.ru/blog/izmeneniya-v-152-fz-v-2025-godu/

[2] Федеральный закон от 27.07.2006 N 152-ФЗ «О персональных данных» (ред. от 24.06.2025) — https://www.consultant.ru/document/cons_doc_LAW_61801/

[3] Таргетинг на мобильные приложения с помощью идентификаторов IDFA или AAID — https://support.google.com/authorizedbuyers/answer/3221407?hl=ru

[4] Персональные данные в организации: обработка, защита, ответственность — https://astral.ru/aj/elem/personalnye-dannye-s-1-marta-2023-goda/

[5] Сбор данных — Firebase (справка Google) — https://support.google.com/firebase/answer/6318039?hl=ru

[6] AppMetrica Яндекс — что это и как ею пользоваться — https://yagla.ru/blog/marketing/appmetrica-yandeks--chto-eto-i-kak-eyu-polzovatsya--2108m94955/

[7] AppsFlyer Help Center glossary — https://support.appsflyer.com/hc/en-us/articles/360000732237-AppsFlyer-Help-Center-glossary

[8] iOS 14.5+: Back to basics guide — Adjust — https://www.adjust.com/blog/ios-14-5-back-to-basics-guide/

[9] Все, что вам нужно знать об отключении GAID — AppsFlyer — https://www.appsflyer.com/ru/blog/mobile-marketing/gaid-deprecation/

[10] Локализация–2025: новые правила сбора данных. Хабр — https://habr.com/ru/companies/cloud4y/articles/949628/

[11] Персональные данные: новые штрафы с 30 мая 2025 года — КонсультантПлюс — https://www.consultant.ru/legalnews/28492/

[12] Статья 6. Условия обработки персональных данных — КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/

[13] Согласие на обработку персональных данных: новые требования с 1 сентября 2025 — Контур — https://kontur.ru/articles/1577

[14] Хранение персональных данных за границей: что разрешено, что запрещено и как соблюсти локализацию в 2025 году — https://b-152.ru/hranenie-personalnyh-dannyh-za-granicej

[15] Новые требования РКН в 2025: как пройти проверку и избежать штрафов за локализацию — vc.ru — https://vc.ru/legal/2149867-novye-trebovaniya-rkn-2025-kak-izbezhat-shtrafov-za-lokalizatsiyu-dannyh

[16] Локализация и трансграничная передача персональных данных. Что изменилось с 1 июля 2025 года? — https://comply.ru/tpost/c43ezsout1-lokalizatsiya-i-transgranichnaya-peredac

[17] Увеличение штрафов за нарушение законодательства о персональных данных с 30 мая 2025 — https://it-pnk.ru/news/uvelichenie-shtrafov-pd/

[18] 152-ФЗ о персональных данных: требования закона для бизнеса в 2026 году — Клерк — https://www.klerk.ru/blogs/roskom24/674017/

[19] Как Роскомнадзор стал проверять мобильные приложения — Cossa — https://www.cossa.ru/trends/139001/

[20] Статья 9. Согласие субъекта персональных данных — КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_61801/6c94959bc017ac80140621762d2ac59f6006b08c/