თანხმობის მართვა

1) პასუხისმგებლობის ტერმინები და საზღვრები

თანხმობა: ნებაყოფლობითი, ინფორმირებული, კონკრეტული და ერთმნიშვნელოვანი ნება; შეიძლება გაიხსენოთ.
იურიდიული საფუძველი: თანხმობა მხოლოდ ერთი ვარიანტია (ხელშეკრულება, იურიდიული საფუძველი, ლეგიტიმური ინტერესი და ა.შ.). მოდელმა უნდა შეინახოს როგორც საფუძველი, ასევე მიზანი.
დამუშავების მიზანი: ატომური მიზეზი: analytics, personalization, ads, email _ marketing, data _ sharing _ vendor _ X.
შეზღუდვა: თანხმობები ინახება მიზნების, არხების, მოვაჭრეების, რეგიონების, მონაცემთა კატეგორიების მიხედვით.
საგნის პროფილი: ადამიანი, მოწყობილობა, ოჯახი, ბავშვის ანგარიში (სპეციალური წესები არასრულწლოვნებისთვის).

2) ცხოვრების თანხმობის ციკლი

1. კოლექცია: ბანერი/SMR, პროფილის პარამეტრები, API/SDK, ოფლაინ არხი (საკონტაქტო ცენტრი).
2. სავალდებულო: ასაკი, რეგიონი, ალტერნატივის ხელმისაწვდომობა („ბნელი შაბლონების“ გარეშე).
3. რეგისტრაცია: თანხმობის ღონისძიების შექმნა და სახელმწიფოების მიმდინარე სურათი მიზნებისათვის.
4. განაწილება: მოვლენების ავტობუსში გამოქვეყნება, ქეშის განახლება edge- ზე, სინქრონიზაცია ვენდორებთან.
5. შესრულება: გამოყენება რეალურ დროში (კარიბჭეები/პიქსელები/SDK), batch (ETL/ანალიტიკა), ML- ში.
6. ცვლილება/მიმოხილვა: ახალი შეგროვების/გააქტიურების დაუყოვნებელი აკრძალვა, ისტორიული პოლიტიკის მონაცემების შემდგომი „გაწმენდა“.
7. აუდიტი/ანგარიში: თანხმობის დადასტურება დამუშავების დროს (ვინ, როდის, ტექსტის რომელი ვერსია).

3) არქიტექტურული კომპონენტები

CMP (Consent Management Platform): UI/SDK + API, UX/იურისდიქციის ქვეშ თანხმობის ფორმატის ვარიანტები; ჭეშმარიტების წყარო ტექსტებსა და ვერსიებში.
Consent Registry (რეესტრი): სახელმწიფოსა და თანხმობის მოვლენების საიმედო საცავი (append-only ჟურნალი + შესაბამისი პროექცია).
Consent PDP/PEP: Policy Decision/Enforcement Point. PDP გადაწყვეტს "შესაძლებელია? ", PEP იყენებს გადაწყვეტილებას API კარიბჭეზე, ETL- ში, SDK- ში და ა.შ.
Edge-cesh თანხმობა: დაბალი ლატენტობა პერიმეტრის შესამოწმებლად.
Partner/GPP/IAB კარიბჭე: ადგილობრივი სამიზნეების გადაცემა პარტნიორობის სიგნალებში და პირიქით.
Data Lineage & Tagging: მონაცემების ეტიკეტირება თანხმობის/ბაზის დროშებით მთელ ჯაჭვში.

4) მონაცემთა მოდელი (სქემები)

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) სიგნალის პროტოკოლები და განაწილება

ვებ/App/SDK: თანხმობის მარკერის შენახვა (ქუქი-ფაილების/ადგილობრივი სცენა) + ხელმოწერა/მთლიანობის შემოწმება; მანქანა-მიმღები ლოგინზე.
Server side: headers 'X-Consent-Token '/' X-Purposes', ორმაგი გაცვლა SSR/edge randering.
პარტნიორები/გამყიდველები: გადაცემა მათ ფორმატებში (მაგალითად, მიზნების ვექტორი, ზოგადი სიგნალი „GPP/TCF“); წარუმატებლობის შემთხვევაში - ნულოვანი სიგნალი/შეზღუდული რეჟიმი.
Offline არხი: აუდიო თანხმობის/ჩეკბოქსის ჩაწერა ოპერატორის მიერ, რასაც მოჰყვა გადამოწმება და მითითება 'subject _ id'.

6) შესრულება: სად და როგორ „იშლება“ ტრაფიკი

• endpoints/ველების დაბლოკვა თანხმობის გარეშე (/profile/enrich ,/ads/,/events/track).
• მუტაცია პასუხი/მოთხოვნა: გაჭრა ტრეკერები, პერსონალიზაციის ველები, იდენტიფიკატორები.
• მიანიჭეთ თანხმობის კონტექსტი ზურგჩანთების მოთხოვნაზე (JWT სტიგმები ან ინდივიდუალური სათაურები).

• მოვლენების ტრანსფორმერი წაშლის/ნიღბავს მინდვრებს თანხმობის დროშების მიხედვით.
• Datasets- ის მარკირება: 'dataset. consent_scope=analytics:granted; ads:denied`.
• ML paypline გამორიცხავს ჩანაწერებს შესაბამისი თანხმობის გარეშე; გამორთულია ტრენინგი/გააქტიურება აკრძალული მიზნებისათვის.

7) ფსევდო კოდი: გამოსავალი კარიბჭეზე

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) ვერსიები და მტკიცებულებები

თანხმობის ტექსტის ვერსია: შეინახეთ 'policy _ version', 'text _ hash', 'banner _ id'.
ლოკალი და რეგიონი: რომელი ტექსტი და რომელ ენაზე არის ნაჩვენები.
სურათი დამუშავების დროს: პასუხის გაცემის შესაძლებლობა "რატომ აჩვენეს რეკლამა 2025-10-15 09:03 საათზე? ».
უცვლელი ჟურნალი: WORM/append-only მოვლენების კრიპტოვალუტით.

9) სპეციალური შემთხვევები

არასრულწლოვნები: ასაკის შესაბამისობა, მშობლების თანხმობა, ინდივიდუალური მიზნები და ვადები.
სტუმარი - ლოგინი: ანონიმური მარკერის შერწყმა ანგარიშით; წესები კონფლიქტის დროს (მკაცრი გაიმარჯვებს).
მულტიმედია: კომპოზიციური რეციკი; გაწვევისას - ყველა მოწყობილობაზე ნიშნების ინვალიდობა.
რეგიონალური რეჟიმები: „მკაცრი“ (EU) vs „opt-out“ (ზოგიერთი ბაზარი) - CMP პრესეტების გადართვა.
A/B ტესტები: ექსპერიმენტები მონაცემებზე - ექსპერიმენტაციის ცალკეული მიზანი; ამის გარეშე - მხოლოდ ფუნქციური ტესტები პერსონალური მონაცემების გარეშე.
მოცილების უფლება: მიმოხილვამ შეიძლება დაიწყოს ისტორიული მონაცემების ამოღება/ანონიმიზაცია სამიზნეზე (პოლიტიკა „რევოლუცია“).

10) ანტი შაბლონები

ერთი „ზოგადი“ ჩეკბოქსი ყველაფრისთვის.
ტექსტების ვერსიების არარსებობა და შოუს დადასტურება.
მხოლოდ ქუქი-დროშის შენახვა სერვერის რეესტრის გარეშე.
თანხმობის გამოყენება მხოლოდ UI- ში, მაგრამ არა ETL/ML/ექსპორტებში.
ჭეშმარიტების კონფლიქტური წყაროები (SDK).
Dark patterns, თანხმობის დაწესება: იურიდიული და რეპუტაციის რისკები.

11) დაკვირვება და მეტრიკა

Coverage: ტრეფიკის წილი თანხმობის წამყვან ნიშანთან.
Latency PDP: გადაწყვეტილების მიღების დრო პერიმეტრზე.
დრიფტი: შეუსაბამობა SDK- სა და სერვერის სურათს შორის.
Revoke SLA: გაწვევის დრო სრული დეაქტივაციის/გაწმენდის დრო.
Vendor Compliance: პარტნიორობის პროცენტი სწორი სიგნალით.
Incidents: დამუშავების მცდელობები თანხმობის გარეშე, დაბლოკილი ზარები.

დაშბორდები: „თანხმობის ძაბვები“, რეგიონების/არხების რუკა, უარი თერმული ბარათები.

12) ტესტირება და გადამოწმება

PDP/PEP ხელშეკრულების ტესტები: სიმართლის ცხრილი მიზნების/რეგიონების კომბინაციაში.
Chaos/Drift ტესტები: SDK არაინქრონული სახელმწიფოები - სერვერი; TTL ქეში.
CMP გამოშვებები: A/B ტექსტები და UX ნეიტრალიტეტი (მუქი ნიმუშების გარეშე).
E2E ტრეკერი: მომხმარებლის როკის მოვლენა - პარტნიორი პიქსელებში და პლიინებში გაგზავნის არარსებობა.

13) ურთიერთდაკავშირებული შესაძლებლობები

ანონიმიზაცია/ფსევდონიზაცია: უარი თქვას ანონიმურობის მიღებამდე და მის შემდეგ.
დაშიფვრა და KMS: მარკერების/ჟურნალების დაცვა.
Geo მარშრუტიზაცია: რეგიონალური ტექსტების/წესების არჩევანი.
დაკვირვება: პირადი დაშბორდები PDN- ის გარეშე; კორელაცია მხოლოდ ნიშნებით.
Data Lineage: თითოეულ თარიღს აქვს თანხმობის კვალი.

14) მინი რეცეპტები

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) არქიტექტორის ჩეკის სია

1. არსებობს ერთი რეესტრი და უცვლელი თანხმობის ჟურნალი?
2. ყველგან არის მიზნები ატომური და ვერსიონირებადი?
3. არსებობს შესრულება პერიმეტრზე, ნაკადებში, ანალიტიკასა და ML- ში?
4. განხორციელდა ისტორიული მონაცემების გაწმენდის მიმოხილვა და პოლიტიკა?
5. შეთანხმებულია UI/SDK/სერვერის სურათები და მიმღები მექანიზმები?
6. არის განლაგებული მეტრიკა Coverage/Drift/Revoke SLA და მოხსენებები?
7. არის ინციდენტების შესახებ runbook (დარღვევები, საჩივრები, რეგულატორი)?
8. მხარს უჭერს სპეციალური რეჟიმები (ბავშვები, რეგიონები, B2B პარტნიორები)?

დასკვნა

თანხმობის მართვა არ არის მოდალური ფანჯარა, არამედ დასრულებული არქიტექტურული ფუნქცია: მიზნების გამოცხადებიდან და ტექსტების ვერსიიდან დაწყებული, რეალურ დროში გადაწყვეტილებების მანქანების შესრულებამდე და შემდგომ მოხსენებებში. მკაცრი მონაცემთა მოდელი, ერთი რეესტრი, PDP/PEP ყველა ფენაზე, სრულფასოვანი ტელემეტრია და დასუფთავების პროცედურები შესაბამისობას კონკურენტულ უპირატესობად აქცევს - პლატფორმა, რომელსაც ენდობა.