Çfarë është në të vërtetë një DSAR

Një Kërkesë e Aksesit të Subjektit të të Dhënave (DSAR) është momenti kur një përdorues ushtron të drejtat që GDPR i jep mbi të dhënat e tij personale. Për një botues celular, ai “subjekt i të dhënave” është një nga lojtarët ose përdoruesit tuaj, dhe kërkesa mund të arrijë me email, biletë mbështetjeje, vlerësim në dyqanin e aplikacioneve ose formular brenda aplikacionit. Shkaktari është i thjeshtë: dikush dëshiron të dijë çfarë mbani për të — ose dëshiron që ju të veproni për të.

Thelbësore është se një DSAR nuk ka nevojë të përmendë GDPR-në, të përdorë fjalën “DSAR,” ose të ndjekë ndonjë shabllon. Një mesazh me një rresht si “më dërgo të dhënat e mia” ose “fshi llogarinë time” e nis orën po aq fort sa një letër ligjore formale. Trajtimi i vetëm kërkesave që duken formale si të vlefshme është një mënyrë e shpejtë për të humbur një afat.

Të drejtat pas kërkesës

DSAR-të grumbullojnë disa të drejta të dallueshme, dhe i njëjti mesazh mund të thërrasë më shumë se një. Të dish cila është cila përcakton se çfarë duhet të bësh në të vërtetë.

• Aksesi — përdoruesi mund të kërkojë një kopje të të dhënave të tij personale plus kontekstin: çfarë mbledhni, pse, me kë e ndani, dhe sa kohë e mbani.
• Fshirja (“e drejta për t’u harruar”) — fshirja e të dhënave të tij, përfshirë kopjet e kaluara te partnerët e reklamave dhe analitikës, subjekt i përjashtimeve të ngushta ligjore.
• Transportueshmëria — të dhënat që ju ka dhënë, të kthyera në një format të strukturuar, të lexueshëm nga makina si JSON ose CSV që të mund të lëvizin diku tjetër.
• Korrigjimi — korrigjimi i të dhënave të pasakta ose të paplota, për shembull një email ose rajon i gabuar.

Të drejtat e lidhura — kundërshtimi ndaj përpunimit dhe kufizimi — shpesh udhëtojnë bashkë me këto, veçanërisht rreth personalizimit të reklamave ku një përdorues mund të tërheqë pëlqimin në vend që ta fshijë krejtësisht llogarinë e tij.

Afatet janë të rrepta

Duhet të përgjigjeni pa vonesë të panevojshme dhe brenda një muaji kalendarik nga marrja e kërkesës. Ora nis ditën që arrin kërkesa, jo ditën që dikush në ekipin tuaj e vëren. Mund të zgjasni me dy muaj të tjerë për kërkesa vërtet komplekse, por vetëm nëse i tregoni përdoruesit brenda atij muaji të parë dhe shpjegoni pse.

Përgjigjet janë normalisht falas. Mund të vendosni një tarifë të arsyeshme ose të refuzoni vetëm kur një kërkesë është dukshëm e pabazuar ose e tepruar, dhe barra e provimit të kësaj bie mbi ju. Për shumicën e botuesve supozimi i sigurt është: falas, dhe brenda tridhjetë ditëve. Humbja e dritares është pikërisht lloji i lëshimit që rregullatorët tregojnë kur vlerësojnë gjobat.

Ndërtimi i një rrjedhe pune që shkallëzohet

Botuesit që i trajtojnë DSAR-të me qetësi i kanë kthyer ato në një proces të përsëritshëm në vend të një stërvitjeje zjarri. Një rrjedhë pune funksionale duket kështu:

• Pranimi. Publikoni një kanal të vetëm, të reklamuar — një formular brenda aplikacionit ose një adresë të dedikuar privacy@ — dhe rrugëzoni gjithçka përmes tij që asgjë të mos humbasë në radhët e mbështetjes.
• Verifikoni identitetin. Konfirmoni që kërkuesi e zotëron llogarinë, por kërkoni vetëm atë që ju duhet. Të kërkosh një skanim pasaporte për të kërkuar një ID brenda lojës është vetë një problem pajtueshmërie.
• Regjistroni dhe vendosni vulë kohore. Regjistroni menjëherë datën e mbërritjes; ky është spiranca juaj e afatit.
• Gjeni të dhënat. Mbani një hartë të dhënash të çdo depoje — backend-i juaj, regjistrat e rrëzimeve, analitika, SDK-të e reklamave, CRM — që prek të dhëna përdoruesi, e renditur sipas një identifikuesi të qëndrueshëm.
• Plotësoni & përgjigjuni. Eksportoni, fshini ose korrigjoni sipas kërkesës, përhapni fshirjet te përpunuesit, dhe përgjigjuni në gjuhë të qartë.
• Mbyllni ciklin. Arkivoni kërkesën dhe përgjigjen tuaj si dëshmi se vepruat në kohë.

Kurthet e zakonshme

Shumica e dështimeve janë operacionale, jo ligjore. Kini kujdes nga këto:

• Depo të harruara të dhënash. SDK-të e reklamave dhe atribuimit, ofruesit e push-it, dhe raportuesit e rrëzimeve të gjithë mbajnë të dhëna përdoruesi. Një fshirje që i anashkalon ato është e paplotë.
• Mbledhja e tepërt gjatë verifikimit, duke e kthyer një kërkesë privatësie në një rrezik privatësie.
• Trajtimi i mesazheve joformale si jo-kërkesa dhe lënia që muaji të kalojë.
• Asnjë provë pëlqimi. Nëse një përdorues kundërshton që ju ndonjëherë keni pasur një bazë ligjore për të përpunuar të dhënat e tij për reklama, duhet të tregoni çfarë ka pranuar dhe kur.

Si e bën një CMP të menaxhueshme DSAR-të

Këtu e fiton vlerën shtresa juaj e pëlqimit. Një DSAR është shumë më e lehtë për t’u përgjigjur kur mund të tregoni menjëherë çfarë ka pranuar një përdorues, kur, dhe nën cilën kornizë. FlexyConsent — një CMP e certifikuar nga Google që mbështet IAB TCF 2.3 dhe Google Consent Mode v2 — ruan një regjistër pëlqimi dhe gjurmë auditimi me vulë kohore për çdo përdorues. Kur mbërrin një kërkesë aksesi, ai regjistër bëhet një pjesë e gatshme e përgjigjes suaj: qëllimet e pranuara, shitësit e përfshirë, dhe versioni i njoftimit të treguar. Kur mbërrin një kërkesë fshirjeje ose kundërshtimi, i njëjti regjistër provon se i ndaltë sinjalet e reklamave të personalizuara në momentin e duhur. Çiftëzimi i atij historiku pëlqimi me hartën tuaj të të dhënave e kthen një DSAR nga një rrëmujë në një kërkim.

Ky artikull është informacion i përgjithshëm për botuesit dhe nuk është këshillë ligjore; konsultohuni me një profesionist të kualifikuar për situatën tuaj specifike.

Përfundimet kryesore

• Çdo kërkesë — sado joformale — mund të jetë një DSAR, dhe afati njëmujor, zakonisht falas, nis ditën që mbërrin.
• Hartoni çdo depo të dhënash, përfshirë SDK-të e reklamave dhe analitikës, që aksesi dhe fshirja të jenë vërtet të plota.
• Verifikoni identitetin në mënyrë proporcionale dhe regjistroni çdo kërkesë për të provuar se u përgjigjët në kohë.
• Regjistrat e pëlqimit dhe gjurma e auditimit të FlexyConsent ju japin dëshmi të menjëhershme e të mbrojtshme për të plotësuar kërkesat e aksesit, fshirjes dhe kundërshtimit.