Що насправді таке DSAR

Запит суб'єкта даних на доступ (DSAR) — це момент, коли користувач реалізує права, які GDPR надає йому щодо його персональних даних. Для мобільного видавця цей «суб'єкт даних» — один із ваших гравців чи користувачів, а запит може надійти електронною поштою, через тикет підтримки, відгук у магазині застосунків або форму всередині застосунку. Тригер простий: хтось хоче знати, що ви про нього зберігаєте — або хоче, щоб ви щось із цим зробили.

Важливо, що DSAR не зобов'язаний згадувати GDPR, використовувати слово «DSAR» чи дотримуватися будь-якого шаблону. Однорядкове повідомлення на кшталт «надішліть мені мої дані» чи «видаліть мій акаунт» запускає годинник так само твердо, як офіційний юридичний лист. Вважати дійсними лише запити, що мають офіційний вигляд, — швидкий шлях пропустити строк.

Права, що стоять за запитом

DSAR об'єднують кілька окремих прав, і одне й те саме повідомлення може посилатися більш ніж на одне. Знання того, яке саме, визначає, що вам насправді доведеться зробити.

• Доступ — користувач може попросити копію своїх персональних даних плюс контекст: що ви збираєте, навіщо, із ким ділитеся та як довго зберігаєте.
• Стирання («право бути забутим») — видалення його даних, зокрема копій, переданих рекламним та аналітичним партнерам, із вузькими юридичними винятками.
• Переносність — надані вам дані, повернуті у структурованому, машиночитаному форматі, як-от JSON чи CSV, щоб їх можна було перенести в інше місце.
• Виправлення — корекція неточних чи неповних даних, наприклад неправильної електронної пошти або регіону.

Пов'язані права — заперечення проти обробки та обмеження — часто йдуть поряд із цими, особливо навколо персоналізації реклами, де користувач може відкликати згоду замість того, щоб остаточно видалити акаунт.

Строки суворі

Ви повинні відповісти без невиправданої затримки та протягом одного календарного місяця від отримання запиту. Годинник запускається в день надходження запиту, а не в день, коли хтось у вашій команді його помітить. Ви можете подовжити ще на два місяці для справді складних запитів, але лише якщо повідомите користувача протягом того першого місяця та поясните чому.

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

Побудова масштабованого робочого процесу

Видавці, які спокійно опрацьовують DSAR, перетворили їх на повторюваний процес замість пожежного навчання. Робочий процес, що працює, виглядає так:

• Прийом. Опублікуйте єдиний оголошений канал — форму всередині застосунку або виділену адресу privacy@ — і спрямовуйте все через нього, щоб нічого не загубилося в чергах підтримки.
• Перевірте особу. Підтвердьте, що запитувач володіє акаунтом, але просіть лише те, що вам потрібно. Вимагати скан паспорта для пошуку внутрішньоігрового ID — це саме по собі проблема відповідності.
• Записуйте та проставляйте мітку часу. Зафіксуйте дату надходження негайно; це ваш якір строку.
• Знайдіть дані. Підтримуйте карту даних кожного сховища — вашого бекенду, журналів збоїв, аналітики, рекламних SDK, CRM —, що торкається даних користувача, упорядковану за стабільним ідентифікатором.
• Виконайте & відповідайте. Експортуйте, видаліть або виправте за запитом, поширте видалення на обробників і відповідайте зрозумілою мовою.
• Замкніть цикл. Заархівуйте запит і вашу відповідь як доказ, що ви діяли вчасно.

Поширені пастки

Більшість невдач операційні, а не юридичні. Стежте за цими:

• Забуті сховища даних. Рекламні та атрибуційні SDK, push-провайдери та збирачі звітів про збої — усі зберігають дані користувача. Видалення, що їх пропускає, неповне.
• Надмірний збір під час перевірки, що перетворює запит на приватність на ризик для приватності.
• Сприйняття неформальних повідомлень як не-запитів і дозвіл місяцю спливти.
• Немає доказу згоди. Якщо користувач заперечує, що ви взагалі мали законну підставу обробляти його дані для реклами, ви маєте показати, на що він погодився і коли.

Як CMP робить DSAR керованими

Саме тут ваш рівень згоди виправдовує себе. На DSAR значно легше відповісти, коли ви можете миттєво показати, на що користувач погодився, коли і за яким фреймворком. FlexyConsent — сертифікована Google CMP, що підтримує IAB TCF 2.3 та Google Consent Mode v2 — зберігає для кожного користувача запис згоди та аудиторський слід із міткою часу. Коли надходить запит на доступ, цей запис стає готовою частиною вашої відповіді: прийняті цілі, задіяні постачальники та версія показаного повідомлення. Коли надходить запит на стирання чи заперечення, той самий запис доводить, що ви зупинили персоналізовані рекламні сигнали в правильний момент. Поєднання цієї історії згоди з вашою картою даних перетворює DSAR із метушні на пошук.

Ця стаття — загальна інформація для видавців і не є юридичною консультацією; зверніться до кваліфікованого фахівця щодо вашої конкретної ситуації.

Ключові висновки

• Будь-який запит — хоч би яким неформальним він був — може бути DSAR, а одномісячний, зазвичай безкоштовний строк починається в день його надходження.
• Картографуйте кожне сховище даних, зокрема рекламні та аналітичні SDK, щоб доступ і видалення були справді повними.
• Перевіряйте особу пропорційно та реєструйте кожен запит, щоб довести, що відповіли вчасно.
• Записи згоди та аудиторський слід FlexyConsent дають вам миттєві, захищувані докази для виконання запитів на доступ, стирання та заперечення.