Келісімдерді басқару

1) Жауапкершілік терминдері мен шекаралары

Келісім (consent): ерікті, ақпараттандырылған, нақты және бір мәнді ерік білдіру; кері қайтарылуы мүмкін.
Құқықтық негіз: келісім - нұсқалардың біреуі ғана (шарт, заңды негіз, заңды мүдде және т.б.). Модель негізін де, мақсатын да сақтауға тиіс.
Өңдеу мақсаты (purpose): атомарлық себеп: analytics, personalization, ads, email_marketing, data_sharing_vendor_X.
Гранулярлығы: келісім мақсаттар, арналар, вендорлар, өңірлер, деректер санаттары бойынша сақталады.
Субъектінің бейіні: адам, құрылымы, үй шаруашылығы, баланың аккаунты (кәмелетке толмағандар үшін ерекше ережелер).

2) Келісімнің өмірлік циклі

1. Жинау: баннер/СМР, профильдегі параметрлер, API/SDK, оффлайн-арна (байланыс орталығы).
2. Валидация: жасы, өңір, баламалардың қолжетімділігі («қараңғы паттерндерсіз»).
3. Тіркеу: мақсаттар үшін күйлерді ағымдағы түсіру және келісім оқиғасын жасау.
4. Тарату: оқиғаларды шина ретінде жариялау, edge кэшін жаңарту, вендорлармен үндестіру.
5. Орындау: real-time (шлюздер/пикселдер/SDK), batch (ETL/аналитика), ML-пайплайндарда қолдану.
6. Өзгеріс/қайтарып алу: жаңа жинауға/белсендіруге дереу тыйым салу, саясат бойынша тарихи деректерді кейіннен «тазарту».
7. Аудит/есептілік: өңдеу сәтіндегі келісімнің дәлелденуі (кім, қашан, мәтіннің қандай нұсқасы).

3) Сәулет компоненттері

CMP (Consent Management Platform): UX/юрисдикцияға келісім нұсқаларын форматтайтын UI/SDK + API; мәтіндер мен нұсқалар бойынша ақиқат көзі.
Consent Registry (тізілім): күй мен келісім оқиғаларының сенімді қоймасы (append-only журналы + өзекті проекция).
Consent PDP/PEP: Policy Decision/Enforcement Point. PDP "мүмкін бе? ", PEP шешімді API-шлюзде, ETL-де, SDK-да және т.б. қолданады.
Edge-кэш келісімдері: периметрде тексеру үшін төменгі жасырындылық.
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) Сигналдардың хаттамалары және таратылуы

Web/App/SDK: келісім маркерін сақтау (cookie/local storage/secure storage) + қолтаңба/бүтіндігін тексеру; логин кезіндегі авто-ресинк.
Server-side: 'X-Consent-Token '/' X-Purposes' хедерлері, SSR/edge-рендеринг кезінде екі бағытты алмасу.
Әріптестер/вендорлар: олардың форматтарына трансляция (мысалы, мақсаттар векторы, «GPP/TCF» жалпы сигналы); істен шыққан жағдайда - нөлдік сигнал/шектеулі режим.
Оффлайн-арна: кейіннен верификациялай және 'subject _ id' -ке байланыстыра отырып, оператордың аудио-келісім/чек-боксты жазуы.

6) Орындау: трафик қайда және қалай «кесіледі»

• Эндпоинттерді/өрістерді келісімсіз бұғаттау (/profile/enrich ,/ads/,/events/track).
• Жауап/сұрауды мутациялау: трекерлерді, дербестендіру өрістерін, сәйкестендіргіштерді кесу.
• Бэкенд сұрауына келісім мәтінін беру (JWT-таңбалар немесе жеке тақырыптар).

• Оқиғалар трансформаторы өрістерді келісім жалаушалары бойынша жояды/бүркемелейді.
• Датасеттердің таңбалануы: 'dataset. consent_scope=analytics:granted; ads:denied`.
• ML-пайплайндағы жазбалар тиісті келісімсіз алынып тасталады; тыйым салынған мақсаттар үшін тренинг/белсендіру өшіріледі.

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) Ерекше кейстер

Кәмелетке толмағандар: жасын валидациялау, ата-ананың келісімі, жеке мақсаттары мен мерзімдері.
Мейман → логин: жасырын таңбалауышты есепке алу арқылы біріктіру; жанжал кезіндегі ережелер (қатаң жеңіске жетеді).
Мультиқұрылым: консистентті ресинк; қайтарып алу кезінде - барлық құрылғылардағы токендердің push-мүгедектігі.
Аймақтық режимдер: «қатаң» (EU) vs «көтерме-шығу» (кейбір нарықтар) - CMP пресеттерін ауыстырып қосу.
A/B-тесттер: деректердегі эксперименттер - experimentation жеке мақсаты; онсыз - тек дербес деректерсіз функционалдық тестілер.
Жою құқығы: Пікір мақсаты бойынша тарихи деректерді жоюға/жасырын етуге бастамашы болуы мүмкін («purge on revoke» саясаты).

10) Қарсы үлгілер

Барлығына бір «жалпы» чек-бокс.
Мәтіндер нұсқаларының және көрсетілімнің дәлелденуінің болмауы.
Тек cookie жалаушасын серверлік тізілімсіз сақтау.
Келісімді тек UI-де ғана қолдану, бірақ ETL/ML/экспортта емес.
Қайшылықты ақиқат көздері (SDK ≠ бэкенд).
Dark patterns, келісімді таңу: заңды және беделді тәуекелдер.

11) Бақылау және метрика

Coverage: келісімдердің валидті таңбалауымен трафик үлесі.
Latency PDP: периметрде шешім қабылдау уақыты.
Drift: SDK мен сервер суреті арасындағы сәйкессіздік.
Revoke SLA: қайтарып алу уақыты → толық өшіру/тазалау уақыты.
Vendor Compliance: дұрыс белгісі бар серіктестік қоңыраулар пайызы.
Incidents: келісімсіз өңдеу әрекеттері, бұғатталған қоңыраулар.

Дашбордтар: «келісім құйғыштары», өңірлер/арналар картасы, істен шығулардың жылу карталары.

12) Тестілеу және верификация

PDP/PEP келісімшарттық тестілері: мақсаттар/өңірлер комбинациялары бойынша ақиқаттылық кестесі.
Chaos/Drift-тесттер: SDK серверінің синхронды емес жай-күйлері; TTL кэшінің аяқталуы.
CMP релиздері: A/B-мәтіндер валидациясы және UX бейтараптығы (қараңғы үлгісіз).
E2E-трассировка: user-revoke → оқиғасы серіктес пиксельдер мен пайплайндарға жіберілмейді.

13) Өзара байланысты қабілеттер

Анонимдеу/бүркеншік атау: анонимдеуге дейін және одан кейін бас тартуды орындау.
Шифрлау және KMS: маркерлерді/журналды қорғау.
Geo-бағыттау: аймақтық мәтіндерді/ережелерді таңдау.
Бақылануы: ПДн-сіз жеке дашбордтар; тек белгілер бойынша корреляция.
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, толыққанды телеметрия және тазалау процедуралары комплаенсті бәсекелестік артықшылыққа - сенетін платформаға айналдырады.