مدیریت رضایت نامه

1) شرایط و محدودیت های مسئولیت

رضایت: بیان داوطلبانه، آگاهانه، خاص و بدون ابهام اراده ؛ ممکن است لغو شود.
مبنای قانونی: رضایت تنها یکی از گزینه ها (قرارداد، مبنای قانونی، منافع مشروع و غیره) است. مدل باید هر دو پایه و هدف را ذخیره کند.
هدف: دلیل اتمی: تجزیه و تحلیل، شخصی سازی، تبلیغات، email_marketing، data_sharing_vendor_X.
دانه بندی: رضایت ها توسط اهداف، کانال ها، فروشندگان، مناطق، دسته های داده ذخیره می شوند.
مشخصات موضوع: فرد، دستگاه، خانواده، حساب کودک (قوانین ویژه برای افراد زیر سن قانونی).

2) چرخه عمر رضایت

1. مجموعه: بنر/CIW، تنظیمات در مشخصات، API/SDK، کانال آفلاین (مرکز تماس).
2. اعتبار سنجی: سن، منطقه، در دسترس بودن جایگزین ها (بدون «الگوهای تاریک»).
3. ثبت نام برای ایجاد یک رویداد انتخاب و عکس فوری فعلی برای اهداف.
4. توزیع: انتشار رویدادها به اتوبوس، به روز رسانی انبارها در لبه، همگام سازی با فروشندگان.
5. پیاده سازی: برنامه در زمان واقعی (دروازه/پیکسل/SDK)، در دسته (ETL/تجزیه و تحلیل)، در خط لوله ML.
6. تغییر/ابطال: ممنوعیت فوری جمعآوری/فعالسازی جدید و متعاقب آن «پاکسازی» دادههای سیاست تاریخی.
7. حسابرسی/گزارش دهی: قابلیت اثبات رضایت در زمان پردازش (چه کسی، چه زمانی، چه نسخه ای از متن).

3) اجزای معماری

CMP (پلت فرم مدیریت رضایت): گزینه های رضایت نامه قالب بندی UI/SDK + API برای UX/حوزه های قضایی ؛ منبع حقیقت توسط متون و نسخه ها.
Registry Consent: یک مخزن قابل اعتماد از ایالت ها و رویدادهای رضایت (مجله فقط ضمیمه + طرح فعلی).
رضایت PDP/PEP: تصمیم گیری/اجرای سیاست. PDP تصمیم می گیرد «آیا ممکن است ؟» "PEP راه حل را برای دروازه API، ETL، SDK و غیره اعمال می کند.
کش لبه رضایت: تاخیر کم برای بررسی محیط.
دروازه شریک/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) پروتکل های سیگنال و توزیع

وب/برنامه/SDK: کوکی/ذخیره سازی محلی/ذخیره سازی امن + چک امضا/یکپارچگی ؛ خودکار مجدد در ورود به سیستم.
سمت سرور: سرصفحه 'X-Consent-Token '/' X-Purposes'، تبادل دو طرفه با رندر SSR/لبه.
شرکا/فروشندگان: ترجمه به فرمت های خود (به عنوان مثال، بردار هدف، سیگنال عمومی «GPP/TCF») ؛ در صورت شکست - سیگنال صفر/حالت محدود.
کانال آفلاین: ضبط رضایت صوتی/چک باکس توسط اپراتور با تأیید بعدی و اتصال به 'subject _ id'.

6) اجرا: کجا و چگونه ترافیک «قطع» می شود

• نقاط انتهایی/فیلدها را بدون رضایت مسدود کنید (/profile/enrich ،/ads/،/events/track).
• جهش پاسخ/درخواست: ردیاب های برش، زمینه های شخصی سازی، شناسه ها.
• زمینه رضایت را به درخواست باطن (تمبرهای JWT یا هدرهای فردی) اختصاص دهید.

• ترانسفورماتور رویداد فیلدها را با پرچم های رضایت حذف/ماسک می کند.
• علامت گذاری مجموعه داده: "مجموعه داده. consent_scope=analytics:granted ؛ تبلیغات: تکذیب شد ".
• در خط لوله 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) موارد خاص

افراد زیر سن قانونی: اعتبار سن، رضایت والدین، اهداف فردی و مهلت.
مهمان → ورود به سیستم: ادغام نشانه ناشناس با حساب کاربری; قوانین در یک درگیری (سخت ترین برنده).
چند دستگاه: resync سازگار ؛ هنگام لغو - نشانه های فشار غیر فعال در تمام دستگاه ها.
حالت های منطقه ای: «سخت» (اتحادیه اروپا) در مقابل «انتخاب کردن» (برخی از بازارها) - تغییر ایستگاه از پیش تنظیم CMP.
تست A/B: آزمایش داده ها یک هدف جداگانه از آزمایش است. بدون آن - فقط تست های عملکردی بدون اطلاعات شخصی.
حق حذف: یادآوری می تواند حذف/ناشناس سازی داده های هدف تاریخی (سیاست «پاکسازی در لغو») را آغاز کند.

10) ضد الگوهای

یک چک باکس «مشترک» برای همه چیز.
عدم وجود نسخه های متنی و قابل اثبات بودن نمایش.
فقط پرچم کوکی را بدون رجیستری سرور ذخیره کنید.
درخواست رضایت فقط در UI، نه در ETL/ML/صادرات.

منابع متناقض حقیقت (SDK ≠ backend)

الگوهای تاریک، تحمیل رضایت: خطرات قانونی و شهرت

11) قابلیت مشاهده و معیارها

Coverage: نسبت ترافیک با یک توکن رضایت معتبر.
PDP تاخیر: زمان تصمیم گیری محیطی.
Drift: عدم تطابق بین SDK و Snapshot سرور.
لغو SLA: زمان لغو → غیر فعال کردن کامل/زمان روشن.
فروشنده انطباق - درصد تماس های شریک با سیگنال صحیح.
حوادث: تلاش برای پردازش بدون رضایت، تماس های مسدود شده.

داشبورد: «قیف رضایت»، نقشه مناطق/کانال ها، نقشه های شکست حرارتی.

12) تست و تایید

تست قرارداد PDP/PEP: جدول حقیقت با ترکیب هدف/منطقه.
تست های هرج و مرج/رانش: SDK غیر همزمان ↔ سرور ؛ انقضای حافظه پنهان TTL.
انتشار CMP: اعتبار A/B از متون و بی طرفی UX (بدون الگوهای تاریک).
ردیابی E2E: رویداد لغو کاربر → بدون ارسال به پیکسل شریک و خطوط لوله.

13) توانایی های مرتبط

ناشناس/pseudonymization: اجرای شکست قبل و بعد از depersonalization.
رمزگذاری و محافظت از KMS Token/Log.
Geo-routing: انتخاب متون/قوانین منطقه ای.
قابلیت مشاهده: داشبورد خصوصی بدون اطلاعات شخصی ؛ همبستگی فقط با نشانه ها.
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/سرور عکس های فوری و مکانیزم resync سازگار است ؟

6. پیکربندی معیارهای پوشش/رانش/لغو SLA و گزارش ؟

7. آیا کتابچه راهنمای حوادث (تخلفات، شکایات، تنظیم کننده) وجود دارد ؟

8. آیا رژیم های خاص (کودکان، مناطق، شرکای B2B) پشتیبانی می شوند ؟

نتیجه گیری

مدیریت رضایت یک پنجره معین نیست، بلکه یک تابع معماری پایان به پایان است: از اعلام اهداف و متون نسخه بندی تا اجرای ماشین تصمیمات در زمان واقعی و گزارش های بعدی. یک مدل داده دقیق، یک رجیستری واحد، PDP/PEP در تمام لایه ها، تله متری کامل و روش های تمیز کردن، انطباق را به یک مزیت رقابتی تبدیل می کند - یک پلت فرم قابل اعتماد.