Je něco zvláštně působivého na tom, když po letech otevřete Duolingo a ono vám přesně připomene, jak dlouho jste tam nebyli. „Neprocvičovali jste 3277 dní.“ Je to chytré. Zapamatovatelné. Ale z pohledu ochrany osobních údajů také dost problematické. Tenhle článek se zaměřuje na problém jednoho tvůrce na sociální síti LinkedIn.
Protože podle General Data Protection Regulation (GDPR) to vyvolává zásadní otázku: Proč má společnost Vaše data i po téměř deseti letech neaktivity?
Iluze retence: engagement vs. právní povinnost
Moderní aplikace (včetně Duolinga) excelují v návrhu retence:
návykové smyčky (habit loops)
streaky (řetězce aktivit)
mikro-odměny
práce se ztrátovou averzí
Tyto mechanismy vytvářejí aktivní uživatele. Zároveň ale tiše ospravedlňují držení neaktivních uživatelů mnohem déle, než je přípustné.
Z produktového pohledu je neaktivní uživatel „Někdo, koho můžeme znovu aktivovat.“
Z pohledu GDPR: „Někdo, u koho možná už nemáme právní základ pro zpracování.“
A právě tady většina firem selhává.
Realita GDPR: omezení uložení není volitelné
Zásada omezení uložení (čl. 5 odst. 1 písm. e) GDPR) je velmi přímočará:
Osobní údaje nesmí být uchovávány déle, než je nezbytné pro účel, pro který byly shromážděny.
Ne „dokud nespustíme kampaň“.
Ne „pro případ, že se vrátí“.
Ne „až se k tomu dostaneme“.
Nezbytné znamená nezbytné.
Jaký je tedy účel u Duolinga?
poskytování služby výuky jazyků
sledování pokroku
vedení uživatelského účtu
Pokud se uživatel nepřihlásil 9 let, tento účel už zjevně není naplňován.
V tu chvíli:
účel zaniká
právní základ slábne nebo mizí
data se mění v riziko pro společnost
Rozpor mezi růstem a compliance
Příklad Duolinga dobře ukazuje typický problém:
Jak uvažují growth týmy?
„Máme miliony neaktivních uživatelů → příležitost!“
Jak by se mělo uvažovat:
„Máme miliony neaktivních uživatelů → riziko.“
A realita?
Growth spustí re-engagement kampaň
Compliance reaguje (pokud vůbec existuje)
Výsledek: e-maily místo mazání.
Cena „pro jistotu“ uchovávaných dat
Mnoho firem stále vnímá data jako aktivum. GDPR to tak nevidí.
I když nejvyšší pokuta (např. 1,2 miliardy € pro Meta) souvisela s předáváním dat, vymáhání pravidel retence teprve sílí.
Proč je retence riziková:
žádný účel → žádný právní základ
žádné mazání → trvající porušení
velké objemy dat → násobené riziko
stará data → obtížně obhajitelná při kontrole i zabezpečitelná z pohledu incidentů
Neaktivní uživatelé nejsou neutrální. Jsou to potenciální porušení ve velkém měřítku.
Dark patterns, o kterých se nemluví
E-mail od Duolinga je emocionálně zarámovaný:
smutná sova
ztracený streak
pocit, že o něco přicházíte
Tyhle taktiky působí na psychologickou stránku uživatele.
Co pod tím ale třeba rozumět:
1. Společnost stále zpracovává vaše osobní údaje dlouho po skončení smysluplného vztahu.
2. Nejde o zlý úmysl. Je to systémový problém.
3. Selhání retence obvykle nevzniká z úmyslu, ale z:
chybějících retenčních politik
slabé správy dat
dominance produktových rozhodnutí nad právními
Jak by to mělo být správně?
1. Definovat retenci na úrovni funkcí
Každá funkce musí odpovědět:
jaká data používá
jak dlouho jsou potřeba
Např.:
streak → expirace po určité době neaktivity
pokrok → po čase anonymizace
2. Automatizované mazání
Ne: „Smažeme to někdy.“
Ale:
pravidelné mazací doby
časovače neaktivity (např. 12–24 měsíců dle účelu)
kaskádové mazání (uživatel → všechna data)
3. Postupná retence před smazáním
Například:
6 měsíců neaktivity → připomenutí
12 měsíců → upozornění
18 měsíců → deaktivace účtu
24 měsíců → smazání nebo anonymizace
Transparentní a předvídatelné.
4. Oddělit analytiku od identity
Pro dlouhodobé insighty:
ponechat agregovaná/anonymní data
mazat identifikovatelná data
Nepotřebujete:
„Jan, neaktivní od 2016“
Stačí: „uživatelé odcházejí po X dnech“
5. Udělat z mazání produktovou funkci
Například:
„Byli jste dlouho neaktivní. Vaše data smažeme za 30 dní.“
„Chcete si je zachovat? Přihlaste se.“
„Chcete export? Klikněte zde.“
To je retence postavená na důvěře.
Závěr
Problém není Duolingo. Problém je, že většina firem optimalizuje návrat uživatelů a ignoruje jejich „odchod z dat“. Ale podle GDPR musí mít každý uživatelský příběh i konec. Protože pokud systém dokáže někoho evidovat po 3277 dnech…měl by také vědět, kdy na něj zapomenout.
