Kelishuvlarni boshqarish

1) Javobgarlik atamalari va chegaralari

Rozilik (consent): ixtiyoriy, xabardor, aniq va bir ma’noli iroda bildirish; bekor qilinishi mumkin.
Huquqiy asos: rozilik - variantlardan faqat bittasi (shartnoma, qonuniy asos, qonuniy qiziqish va h.k.). Model asosini ham, maqsadini ham saqlashi kerak.
Qayta ishlash maqsadi (purpose): atomik sabab: analytics, personalization, ads, email_marketing, data_sharing_vendor_X.
Granulyarlik: roziliklar maqsadlar, kanallar, vendorlar, hududlar, ma’lumotlar toifalari bo’yicha saqlanadi.
Subyekt profili: shaxs, qurilma, uy xo’jaligi, bola hisobi (voyaga yetmaganlar uchun alohida qoidalar).

2) Rozilikning hayot sikli

1. Yig’ish: banner/SMR, profildagi moslamalar, API/SDK, oflayn kanal (aloqa markazi).
2. Validatsiya: yoshi, mintaqasi, muqobillarning mavjudligi («qorong’u namunalarsiz»).
3. Ro’yxatdan o’tish: kelishuv hodisasini yaratish va maqsadlar uchun holatlarni joriy suratga olish.
4. Tarqatish: voqealarni shinaga joylashtirish, edge keshini yangilash, vendorlar bilan sinxronlash.
5. Ijro: real-time (shlyuzlar/piksellar/SDK), batch (ETL/analitik), ML-payplaynlarda qo’llash.
6. O’zgartirish/chaqirib olish: yangi yig’ish/faollashtirishni darhol taqiqlash, keyinchalik siyosat bo’yicha tarixiy ma’lumotlarni «tozalash».
7. Audit/hisobot: ishlov berish paytida rozilikning isbotlanishi (matnning kim, qachon, qanday versiyasi).

3) Arxitektura komponentlari

CMP (Consent Management Platform): UX/yurisdiksiya ostida kelishuv variantlarini formatlovchi UI/SDK + API; matnlar va versiyalar bo’yicha haqiqat manbai.
Consent Registry (reyestr): kelishuv holatlari va hodisalarining ishonchli ombori (append-only jurnali + dolzarb proyeksiya).
Consent PDP/PEP: Policy Decision/Enforcement Point. PDP "mumkin emasmi? ", PEP yechimni API-shlyuzda, ETLda, SDKda va boshqalar qo’llaydi.
Kelishuvlarning edge-keshi: perimetrda tekshirish uchun past latentlik.
Partner/GPP/IAB-shlyuz: mahalliy nishonlarni sheriklik signallariga va orqaga translyatsiya qilish.
Data Lineage & Tagging: ma’lumotlarni rozilik/asos bayroqlari bilan butun zanjir bo’ylab belgilash.

4) Ma’lumotlar modeli (sxemalari)

json
{
"subject_id": "usr_123",
"subject_scope": "user",
"region": "EU",
"legal_basis": {
"analytics": "consent",
"personalization": "consent",
"security": "legitimate_interest",
"contract_core": "contract"
},
"purposes": {
"analytics": {"status": "granted", "version": "v5", "updated_at": "2025-10-31T13:20:10Z"},
"personalization": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"ads": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"email_marketing": {"status": "granted", "channel":"email","updated_at":"2025-10-31T13:22:05Z"}
},
"text_bundle": {"locale":"uk-UA","policy_version":"2025-09"},
"evidence": {"capture_ip":"203. 0. 113. 5","capture_ua":"Chrome/142"}
}

json
{
"event_id": "cse_987",
"subject_id": "usr_123",
"purpose": "personalization",
"previous": "denied",
"current": "granted",
"legal_basis": "consent",
"policy_version": "2025-09",
"captured_at": "2025-10-31T13:21:31Z",
"channel": "web",
"evidence": {
"banner_id": "cmp_v3",
"text_hash": "sha256:...",
"ip": "203. 0. 113. 5",
"ua": "Chrome/142",
"locale": "uk-UA"
}
}

5) Signallar bayonnomalari va tarqatish

Web/App/SDK: rozilik markerini saqlash (cookie/local storage/secure storage) + imzo/yaxlitlikni tekshirish; loginda avto-resink.
Server-side:’X-Consent-Token ’/’ X-Purposes’xedyerlari, SSR/edge-renderingda ikki yo’nalishli ayirboshlash.
Sheriklar/vendorlar: ularning formatlariga translatsiya qilish (masalan, maqsadlar vektori, «GPP/TCF» umumiy signali); rad etilganda - nol signal/cheklangan rejim.
Offlayn kanal: operator tomonidan audio-rozilik/chekbox yozib olinib, keyinchalik «subject _ id» ga ulanadi.

6) Bajarish: trafik qayerda va qanday «kesiladi»

• / profile/enrich ,/ads/,/events/track.
• Javob/soʻrovni oʻzgartirish: trekerlar, shaxsiylashtirish maydonlari, identifikatorlarni kesish.
• Soʻrovga rozilik kontekstini belgilash (JWT-tamgʻalar yoki alohida sarlavhalar).

• Hodisa transformatori rozilik bayroqlari boʻyicha maydonlarni olib tashlaydi/yashiradi.
• Datasetlarni markalash:’dataset. consent_scope=analytics:granted; ads:denied`.
• ML-payplayndagi yozuvlar tegishli roziliklarsiz chiqarib tashlanadi; taqiqlangan maqsadlar uchun trening/faollashtirish o’chiriladi.

7) Psevdokod: shlyuzdagi yechim

python def enforce_consent(request, consent_snapshot):
purpose = map_endpoint_to_purpose(request. path) # /ads/ -> "ads"
basis  = consent_snapshot. legal_basis. get(purpose)
status = consent_snapshot. purposes. get(purpose, {}). get("status", "denied")

if basis! = "consent": # e.g. security/contract - allowed without return ALLOW banner

if status!= "granted":
return DENY # or ALLOW with redaction if degradation is allowed

return ALLOW

8) Versiyalash va isbotlash

Matnning versiyasi:’policy _ version’,’text _ hash’,’banner _ id’.
Lokal va mintaqa: qaysi matn va qaysi tilda koʻrsatilgan.
Qayta ishlash paytidagi rasm: "Nima uchun reklama 2025-10-15 soat 09:03 da namoyish etildi? ».
Yangilanmaydigan jurnal: WORM/append-only.

9) Maxsus seyslar

Voyaga yetmaganlar: yoshni validatsiya qilish, ota-onaning roziligi, alohida maqsadlar va muddatlar.
Mehmon → login: anonim markerni hisobga olish bilan birlashtirish; nizoda qoidalar (eng qattiqlari g’alaba qozonadi).
Multiqurilish: konsistent resink; chaqirib olishda - barcha qurilmalarda tokenlarning push-nogironligi.
Mintaqaviy rejimlar: «qattiq» (EU) vs «opt-out» (ba’zi bozorlar) - CMP presetlarini almashtirish.
A/B-testlar: ma’lumotlar bo’yicha eksperimentlar - experimentation’ning alohida maqsadi; ularsiz - faqat shaxsiy ma’lumotlarsiz funksional testlar.
Olib tashlash huquqi: chaqirib olish maqsad boʻyicha tarixiy maʼlumotlarni olib tashlashni/anonimlashtirishni boshlashi mumkin («purge on revoke» siyosati).

10) Anti-patternlar

Hamma uchun bitta «umumiy» chekbox.
Matnlarning versiyalari va ko’rsatuvning isbotlanishi yo’qligi.
Faqat key-bayroqni server reyestrisiz saqlash.
Rozilik faqat UIda qoʻllaniladi, lekin ETL/ML/eksportda emas.
Haqiqatning ziddiyatli manbalari (SDK ≠ orqa).
Dark patterns, rozilik yuklash: yuridik va obro "-e’tibor xavfi.

11) Kuzatish va metrika

Coverage: roziliklarning valid markeri bilan trafik ulushi.
Latency PDP: perimetrda qaror qabul qilish vaqti.
Drift: SDK va server rasmlari oʻrtasida kelishmovchilik.
Revoke SLA: chaqirib olish vaqti → toʻliq deaktivatsiya/tozalash vaqti.
Vendor Compliance: To’g’ri signal bilan sherik qo’ng’iroqlari foizi.
Incidents: roziliksiz ishlash urinishlari, bloklangan qoʻngʻiroqlar.

Dashbordlar: «rozilik voronkalari», hududlar/kanallar xaritasi, nosozliklar issiqlik xaritalari.

12) Test sinovi va verifikatsiya

PDP/PEP kontrakt testlari: maqsadlar/mintaqalar kombinatsiyalari boʻyicha haqiqiylik jadvali.
Chaos/Drift-testlar: SDK serverning nosinxron holatlari; TTL kesh tugashi.
CMP relizlari: A/B-matnlarning validatsiyasi va UX neytralligi (qorong’u patternlarsiz).
E2E-trassasi: user-revoke hodisasi → sherik piksel va payplaynlarga yuborilmaydi.

13) O’zaro bog’liq qobiliyatlar

Anonimlashtirish/taxalluslashtirish: shaxssizlantirishdan oldin va keyin rad etishlarni bajarish.
Shifrlash va KMS: marker/jurnalni himoya qilish.
Geo-marshrutlash: mintaqaviy matnlar/qoidalarni tanlash.
Kuzatilganlik: PDsiz shaxsiy dashbordlar; Faqat tokenlar bo’yicha korrelyatsiya.
Data Lineage: har bir sanasetda - rozilik izi.

14) Mini-retseptlar

yaml purposes:
analytics:
legal_basis: consent enforcement: redact_fields: [ad_id, gaid, idfa]
personalization:
legal_basis: consent enforcement: deny_endpoints: [/recs/, /profile/enrich]
security:
legal_basis: legitimate_interest enforcement: allow email_marketing:
legal_basis: consent channel: email

event. meta. consent. analytics = granted    denied event. meta. consent. ads    = denied event. meta. legal_basis    = consent    contract    li

on user_revoke(purpose):
mark subject_id + purpose as "purge_pending"
schedule purge jobs over datasets with lineage(purpose)
emit audit_event("purge_started", scope=purpose)

15) Arxitektorning chek-varaqasi

1. Yagona reyestr va oʻzgarmas rozilik jurnali bormi?
2. Hamma joyda maqsadlar belgilanganmi?
3. Perimetrda, oqimlarda, tahlilda va MLda ijro bormi?
4. Tarixiy maʼlumotlarni qayta koʻrib chiqish va tozalash siyosati amalga oshirilganmi?
5. UI/SDK/server rasmlari va resink mexanizmlari kelishilganmi?
6. Coverage/Drift/Revoke SLA metriklari va hisobotlari moslanganmi?
7. Hodisalar (qoidabuzarliklar, shikoyatlar, regulyatorlar) bo’yicha runbook bormi?
8. Maxsus rejimlar (bolalar, hududlar, B2B-sheriklar) qo’llab-quvvatlanadimi?

Xulosa

Kelishuvlarni boshqarish modal oyna emas, balki maqsadlarni deklaratsiyalash va matnlarni versiyalashdan tortib, qarorlarni real vaqtda mashinada bajarish va keyinchalik hisobot berishgacha boʻlgan uzluksiz arxitektura funksiyasidir. Ma’lumotlarning qat’iy modeli, yagona reyestr, barcha qatlamlardagi PDP/PEP, to’laqonli telemetriya va tozalash tartib-taomillari komplayensni raqobatbardosh ustunlikka aylantiradi.