درخواست‌های دسترسی موضوع داده (DSAR) طبق GDPR: راهنمای ناشران موبایل
DSAR واقعاً چیست
یک درخواست دسترسی موضوع داده (DSAR) لحظه‌ای است که کاربر حقوقی را که GDPR بر داده‌های شخصی او اعطا می‌کند، اعمال می‌کند. برای یک ناشر موبایل، آن «موضوع داده» یکی از بازیکنان یا کاربران شماست و درخواست می‌تواند از طریق ایمیل، تیکت پشتیبانی، نظر در فروشگاه برنامه یا فرم درون‌برنامه‌ای برسد. محرک ساده است: کسی می‌خواهد بداند چه چیزی درباره او نگه می‌دارید — یا می‌خواهد روی آن اقدامی انجام دهید.
نکته حیاتی این است که یک DSAR نیازی به ذکر GDPR، استفاده از واژه «DSAR» یا پیروی از هیچ الگویی ندارد. یک پیام تک‌خطی مانند «داده‌هایم را برایم بفرست» یا «حسابم را حذف کن» ساعت‌شمار را به همان استواری یک نامه حقوقی رسمی آغاز می‌کند. تلقی فقط درخواست‌های با ظاهر رسمی به‌عنوان معتبر، راهی سریع برای از دست دادن مهلت است.
حقوق پشت درخواست
DSARها چندین حق متمایز را در خود جای می‌دهند و یک پیام واحد ممکن است بیش از یکی را فراخواند. دانستن اینکه کدام کدام است، تعیین می‌کند که واقعاً چه باید بکنید.
- دسترسی — کاربر می‌تواند نسخه‌ای از داده‌های شخصی خود به‌علاوه زمینه را بخواهد: چه جمع‌آوری می‌کنید، چرا، با چه کسی به اشتراک می‌گذارید و چه مدت نگه می‌دارید.
- پاک‌سازی («حق فراموش‌شدن») — حذف داده‌هایشان، شامل نسخه‌های منتقل‌شده به شرکای تبلیغاتی و تحلیلی، مشروط به استثنائات قانونی محدود.
- قابلیت انتقال — داده‌هایی که به شما داده‌اند، بازگردانده‌شده در قالبی ساختاریافته و قابل‌خواندن توسط ماشین مانند JSON یا CSV تا بتواند به جای دیگری منتقل شود.
- اصلاح — تصحیح داده‌های نادرست یا ناقص، برای مثال یک ایمیل یا منطقه اشتباه.
حقوق مرتبط — اعتراض به پردازش و محدودسازی — اغلب در کنار اینها حرکت می‌کنند، به‌ویژه پیرامون شخصی‌سازی تبلیغات که در آن کاربر ممکن است رضایت را پس بگیرد به‌جای حذف کامل حسابش.
مهلت‌ها سخت‌گیرانه‌اند
باید بدون تأخیر بی‌مورد و ظرف یک ماه تقویمی از دریافت درخواست پاسخ دهید. ساعت‌شمار از روزی که درخواست می‌رسد آغاز می‌شود، نه روزی که کسی در تیم شما متوجه آن می‌شود. می‌توانید برای درخواست‌های واقعاً پیچیده دو ماه دیگر تمدید کنید، اما تنها در صورتی که ظرف همان ماه اول به کاربر اطلاع دهید و دلیل را توضیح دهید.
پاسخ‌ها معمولاً رایگاناند. تنها زمانی می‌توانید هزینه معقولی دریافت کنید یا درخواست را رد کنید که آشکارا بی‌اساس یا افراطی باشد و بار اثبات آن بر دوش شماست. برای بیشتر ناشران فرض ایمن این است: رایگان و ظرف سی روز. از دست دادن این بازه دقیقاً همان نوع کوتاهی است که تنظیم‌کنندگان هنگام ارزیابی جریمه‌ها به آن اشاره می‌کنند.
ساخت گردش‌کاری که مقیاس‌پذیر است
ناشرانی که DSARها را با آرامش مدیریت می‌کنند، آنها را به فرایندی تکرارپذیر تبدیل کرده‌اند نه یک مانور آتش‌نشانی. یک گردش‌کار عملی این‌گونه است:
- دریافت. یک کانال واحد و اعلام‌شده منتشر کنید — یک فرم درون‌برنامه‌ای یا یک آدرس اختصاصی privacy@ — و همه‌چیز را از طریق آن مسیریابی کنید تا چیزی در صف‌های پشتیبانی گم نشود.
- هویت را تأیید کنید. تأیید کنید که درخواست‌کننده مالک حساب است، اما فقط آنچه نیاز دارید بخواهید. مطالبه اسکن گذرنامه برای جستجوی یک شناسه درون‌بازی خودش یک مشکل انطباق است.
- ثبت و زمان‌گذاری کنید. تاریخ ورود را بلافاصله ثبت کنید؛ این لنگر مهلت شماست.
- داده را پیدا کنید. نقشه‌ای از داده‌های هر انباره — backend شما، گزارش‌های خرابی، تحلیل، ادتبلیغاتی SDKها، CRM — که داده کاربر را لمس می‌کند، با کلید یک شناسه پایدار نگه دارید.
- اجرا & پاسخ. طبق درخواست صادر، حذف یا تصحیح کنید، حذف‌ها را به پردازنده‌ها منتشر کنید و به زبان ساده پاسخ دهید.
- حلقه را ببندید. درخواست و پاسخ خود را به‌عنوان مدرکی بر اقدام به‌موقع بایگانی کنید.
دام‌های رایج
بیشتر شکست‌ها عملیاتی‌اند، نه حقوقی. مراقب اینها باشید:
- انباره‌های داده فراموش‌شده. SDKهای تبلیغات و انتساب، ارائه‌دهندگان push و گزارش‌گرهای خرابی همگی داده کاربر را نگه می‌دارند. حذفی که از آنها صرف‌نظر کند، ناقص است.
- جمع‌آوری بیش از حد هنگام تأیید، که یک درخواست حریم خصوصی را به یک ریسک حریم خصوصی تبدیل می‌کند.
- تلقی پیام‌های غیررسمی به‌عنوان غیردرخواست و اجازه دادن به سپری شدن ماه.
- نبود مدرک رضایت. اگر کاربری مناقشه کند که شما هرگز مبنای قانونی برای پردازش داده‌هایش برای تبلیغات نداشته‌اید، باید نشان دهید با چه چیزی و چه زمانی موافقت کرده است.
چگونه یک CMP، DSARها را قابل‌مدیریت می‌کند
اینجاست که لایه رضایت شما ارزش خود را ثابت می‌کند. پاسخ به یک DSAR وقتی بسیار آسان‌تر است که بتوانید فوراً نشان دهید کاربر به چه چیزی، چه زمانی و تحت کدام چارچوب رضایت داده است. FlexyConsent — یک CMP تأییدشده توسط Google با پشتیبانی از IAB TCF 2.4 و Google Consent Mode v2 — در وب‌سایت شما برای هر بازدیدکننده زیر یک کلید تصادفی یک سابقه رضایت با مهر زمانی نگه می‌دارد. وقتی درخواست دسترسی می‌رسد، این سابقه بخشی از پاسخ شماست: دامنه، تصمیم (پذیرفته، ردشده یا بخشی پذیرفته)، محل گرفتن آن و اینکه Global Privacy Control اعمال شده یا نه؛ با این کلید می‌توانید آن را دانلود یا پاک کنید. جفت کردن آن تاریخچه رضایت با نقشه داده شما یک DSAR را از یک هرج‌ومرج به یک جستجو تبدیل می‌کند.
این مقاله اطلاعات عمومی برای ناشران است و مشاوره حقوقی نیست؛ برای وضعیت خاص خود با یک متخصص واجد شرایط مشورت کنید.
نکات کلیدی
- هر درخواستی — هر چقدر هم غیررسمی — می‌تواند یک DSAR باشد و مهلت یک‌ماهه و معمولاً رایگان از روزی که می‌رسد آغاز می‌شود.
- هر انباره داده را، از جمله SDKهای تبلیغات و تحلیل، نقشه‌برداری کنید تا دسترسی و حذف واقعاً کامل باشد.
- هویت را متناسب تأیید کنید و هر درخواست را ثبت کنید تا پاسخ به‌موقع را اثبات کنید.
- سوابق رضایت FlexyConsent به شما کمک می‌کند به درخواست‌های دسترسی و پاک‌سازی در وب‌سایت خود پاسخ دهید: می‌توانید یک سابقه را با کلید آن دانلود یا پاک کنید.