Retenția datelor
Politicile de retenție îi cer platformei să șteargă automat anumite tipuri de date după ce devin mai vechi decât un număr de zile ales de tine. Prin ele aplici principiul limitării stocării din GDPR în cazul datelor de activitate care își pierd utilitatea în timp. Le găsești în Settings → Retention Policies.
Acces: rolul admin; utilizatorii cu alte roluri pot doar vizualiza pagina.
Cum funcționează retenția
- Nimic nu se șterge pe criteriul vechimii dacă organizația ta nu are o politică pentru tipul respectiv de date. Implicit, nu este configurată nicio politică.
- Fiecare politică se aplică unui singur tip de date și șterge înregistrările mai vechi decât numărul de zile setat în ea. Intervalul permis este de la 30 la 3650 de zile (10 ani).
- Un job în fundal aplică politicile o dată pe zi. Implicit, rulează la 02:00 UTC; programul în vigoare apare la jobul Enforce Retention, pe pagina Background Jobs.
- Când jobul șterge date, adaugă în jurnalul de audit o intrare Enforced Retention, cu tipul de date, numărul de zile și câte înregistrări a șters.
Volumele mari de date expirate nu se șterg
Dacă peste 10.000 de înregistrări de același tip își depășesc limita în același timp, jobul nu șterge niciuna dintre ele și încearcă din nou a doua zi. Un volum de această mărime nu scade de la sine, așa că jobul nu îl șterge niciodată.
Tipurile de date
Pagina afișează câte un card pentru fiecare tip de date. Fiecare card are un comutator, un câmp Delete data older than (days) și o notă What gets deleted. Când activezi un card, numărul de zile pornește de la valoarea sugerată mai jos; implicit, niciun card nu este activat.
| Card | Ce șterge | Vechimea se calculează de la | Zile sugerate |
|---|---|---|---|
| Behavioral Events | Istoricul de activitate al contactelor: mesaje din chat, voturi în sondaje, click-uri pe oferte și evenimente similare. Datele sesiunii live propriu-zise nu sunt afectate. | Momentul salvării evenimentului | 365 |
| Segment Members | Legăturile dintre contacte și segmente. Contactele și segmentele rămân. | Momentul adăugării contactului în segment | 365 |
| Mobile Push Tokens | Token-urile push din aplicația mobilă care nu au mai fost reîmprospătate. Aplicația își reîmprospătează token-ul la fiecare pornire, așa că un token vechi înseamnă de obicei că aplicația a fost dezinstalată sau abandonată. | Ultima reîmprospătare a token-ului | 60 |
| Lead Scores | Scorurile de lead, atât cele per webinar, cât și cele generale. Configurația ta de lead scoring rămâne. | Ultimul calcul al scorului | 365 |
| Email Send Logs | Nu este acceptat ca tip de date pentru retenție (vezi mai jos). | 365 | |
| Push Notification Logs | Nu este acceptat ca tip de date pentru retenție (vezi mai jos). | 365 | |
| SMS Send Logs | Nu este acceptat ca tip de date pentru retenție (vezi mai jos). | 365 | |
| Job Run History | Istoricul rulărilor afișat pe pagina Background Jobs. | Începutul rulării | 30 |
Câteva efecte secundare bune de știut:
- Segment Members: în segmentele bazate pe reguli, un contact care încă îndeplinește regulile este adăugat din nou la următoarea evaluare a segmentului, cu o dată nouă. Politica afectează în principal membrii adăugați manual. Vezi Segmente.
- Lead Scores: scorurile sunt calculate pe baza evenimentelor comportamentale. Dacă toate scorurile unui webinar au fost șterse, iar evenimentele lui comportamentale sunt încă stocate, următoarea rulare a calculului de lead scoring le recalculează. Vezi Lead scoring.
- Job Run History: joburile în fundal sunt comune tuturor organizațiilor de pe platformă, deci acest istoric nu este doar al tău, iar o politică pentru el șterge istoricul pentru toată lumea.
Salvarea politicilor
Salvarea este respinsă
Save trimite întotdeauna toate cele opt carduri, iar trei dintre ele, Email Send Logs, Push Notification Logs și SMS Send Logs, nu sunt acceptate ca tipuri de date pentru retenție. Întreaga salvare este respinsă cu mesajul Failed to save (invalid data_type: email_sends) și nu se salvează nimic, nici măcar modificările făcute pe celelalte carduri. Prin urmare, politicile de retenție nu pot fi create sau modificate din dashboard.
Politicile care există deja pentru organizația ta apar ca activate, cu numărul lor de zile, iar jobul zilnic continuă să le aplice.
Ce nu șterge niciodată retenția
Politicile de retenție pot acoperi doar tipurile de date acceptate de mai sus. Tot restul rămâne până când este eliminat pe altă cale:
| Date | Cum se elimină |
|---|---|
| Contactele, înscrierile și participările, starea actuală a consimțământului | Doar printr-o cerere de ștergere GDPR. Vezi GDPR. |
| Istoricul consimțământului | Niciodată. După o ștergere, este păstrat fără legătura cu contactul. |
| Intrările în funnel-uri, inclusiv atribuirea campaniilor | O cerere de ștergere GDPR sau ștergerea funnel-ului |
| Evidența vizitelor pe landing page-uri | Ștergerea funnel-ului |
| Datele sesiunilor live: mesaje din chat, nume afișate, prezență, voturi în sondaje, reacții, click-uri pe oferte, răspunsuri la feedback | Ștergerea sesiunii sau a webinarului. O ștergere GDPR elimină datele unei singure persoane. Trecerea unei sesiuni în replay sau arhivarea ei nu elimină nimic. |
| Copia chatului fiecărei sesiuni, salvată când sesiunea trece în replay | Ștergerea webinarului. Dacă ștergi doar sesiunea, copia rămâne. |
| Istoricul livrărilor de email și push | O cerere de ștergere GDPR |
| Istoricul livrărilor SMS, evidența mesajelor către segmente | Nu se elimină din dashboard |
| Înrolările în automatizări și istoricul lor | O cerere de ștergere GDPR sau ștergerea automatizării |
| Evidența generărilor cu AI, evidența activității webhook-urilor | Nu se elimină din dashboard |
| Jurnalul de audit și cererile GDPR | Niciodată |
| Fișierele și conținutul media încărcate | Ștergerea elementului căruia îi aparțin |
| Autentificările anonime ale participanților | Flush Anonymous Accounts din Settings → Team Members (vezi Echipă și roluri) |
Backup-urile sunt păstrate conform propriului lor ciclu, așa că datele șterse rămân în backup-uri până când acestea expiră.