ניהול הסכמה
1) תנאים ומגבלות אחריות
הסכמה: התנדבות, מידע, ביטוי ספציפי וחד משמעי של רצון; עלול להישלל.
בסיס משפטי: הסכמה היא רק אחת האפשרויות (חוזה, בסיס משפטי, אינטרס לגיטימי וכו '). הדגם חייב לאחסן גם את הבסיס וגם את המטרה.
מטרה: סיבה אטומית: אנליטיקה, התאמה אישית, פרסומות, email_marketing, data_sharing_vendor_X.
גרנולריות: קונסולות מאוחסנות על ידי מטרות, ערוצים, ספקים, אזורים, קטגוריות מידע.
פרופיל הנושא: אדם, מכשיר, בית, חשבון ילדים (כללים מיוחדים לקטינים).
2) אופן חיים מוסכם
1. אוסף: באנר/CIW, הגדרות בפרופיל, API/SDK, ערוץ לא מקוון (מרכז מגע).
2. אימות: גיל, אזור, זמינות של חלופות (ללא ”דפוסים אפלים”).
3. הירשמו כדי ליצור אפשרות של אפשרות בחירה וצילום נוכחי עבור מטרות.
4. הפצה: פרסום אירועים לאוטובוס, עדכון מטמונים על קצה, סנכרון עם ספקים.
5. יישום: יישום בזמן אמת (שערים/פיקסלים/SDK), בצרור (ETL/analytics), ב-ML-צינורות.
6. שינוי/שלילה: איסור מיידי על איסוף/הפעלה חדשה, לאחר מכן ”טיהור” של נתוני מדיניות היסטוריים.
7. ביקורת/דיווח: מתן הסכמה בעת העיבוד (מי, מתי, איזו גרסה של הטקסט).
3) רכיבים ארכיטקטוניים
CMP (פלטפורמת ניהול הסכמה): UI/SDK + API פורמט אפשרויות הסכמה עבור UX/תחום שיפוט; מקור האמת בטקסטים ובגרסאות.
Registry: מאגר אמין של מדינות הסכמה ואירועים (append-only journal + arregation).
PDP/PEP: Policy Decision/Operation Point. PDP מחליט "האם זה אפשרי? PEP מיישם את הפתרון לשער API, ETL, SDK וכו '.
מטמון קצה של קונסולים: לינה נמוכה לבדיקה היקפית.
שער Partner/GPP/IAB: תרגום של מטרות מקומיות לאותות שותפים ולהיפך.
Lineaging & 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"}
}
אירוע הסכמה (append-only):
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: עוגייה/אחסון מקומי/אחסון מאובטח + חתימה/בדיקת שלמות; התחברות אוטומטית.
Server-side: כותרות 'X-Consent-Token '/' X-Toites', החלפה דו כיוונית עם SSR/Edge rendering.
שותפים/ספקים: תרגום לפורמטים שלהם (לדוגמה, וקטור מטרה, אות כללי GPP/TCF); במקרה של כישלון - אפס אות/מצב מוגבל.
ערוץ לא מקוון: הקלטה של הסכמת שמע/תיבת צ 'ק על ידי האופרטור עם אימות מאוחר יותר וקשירה ל- "subject _ id'.
6) הוצאה להורג: היכן וכיצד התנועה ”נחתכת”
על שער API (PEP):- בלוק נקודות קצה/שדות ללא הסכמה (/פרופיל/העשרה ,/מודעות/,/אירועים/רצועה).
- תגובה/בקשה מוטציה: גששים חתוכים, שדות התאמה אישית, מזהים.
- הקצאת הקשר הסכמה לבקשה האחורית (בולי JWT או כותרות בודדות).
- שנאי האירוע מסיר/מסכה שדות על ידי דגלי הסכמה.
- סימון נתונים: 'נתונים. consent_scope=analytics:granted; מודעות: נדחו.
- ב-ML-pipeline, רשומות ללא הסכמות מתאימות נפסלות; מבטל אימונים/הפעלה למטרות אסורות.
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? ».
יומן בלתי ניתן לשינוי: תולעת/אפנד-רק עם חתימת אירוע קריפטו.
9) מקרים מיוחדים
קטינים: אימות גיל, הסכמה הורית, מטרות אישיות ומועדים.
התחברות אורחים: מיזוג אסימון אנונימי עם חשבון; חוקים בסכסוך (הכי נוקשים מנצחים).
ריבוי התקנים: resync עקבי; כאשר מבטלים אסימונים בכל המכשירים.
מצבי פעולה אזוריים: "נוקשה" (EU) נגד "opt-out' (כמה שווקים) - החלפת CMP מראש.
מבחני A/B: ניסויי נתונים הם מטרה נפרדת לניסויים; בלי זה - רק בדיקות פונקציונליות ללא נתונים אישיים.
זכות למחיקה: חזרה יכולה לעורר מחיקה/אנונימיות של נתוני יעד היסטוריים (”טיהור על ביטול”).
10) אנטי דפוסים
קופסת צ 'קים אחת לכל דבר.
מחסור בגרסאות טקסט ובהתמדה של המופע.
לאחסן רק את דגל העוגיות ללא רישום השרת.
יישום הסכמה רק ב UI, לא ב ETL/ML/יצוא.
מקורות סותרים של אמת (SDK backend).
דפוסים אפלים, הסכמה כופה: סיכונים משפטיים ומוניטין.
11) יכולת תצפית ומדדים
כיסוי: הפרופורציה של תנועה עם אסימון הסכמה תקף.
זמן החלטה היקפית.
סחיפה: אי התאמה בין SDK וצילום שרת.
ביטול SLA: שלילת זמן = ביטול מלא/זמן פנוי.
ציות ספק - אחוז של שיחות שותף עם האות הנכון.
אירועים: ניסיונות לעבד ללא הסכמה, שיחות חסומות.
לוחות מחוונים: ”משפכי הסכמה”, מפת אזורים/ערוצים, מפות אי ספיקה תרמית.
12) בדיקות ואימות
מבחני חוזה PDP/PEP: טבלת אמת לפי צירופי מטרות/אזור.
בדיקות כאוס/דריפט: SDK לא סינכרוני קובע שרת ↔; תפוגה של מטמון TL.
CMP משחרר: אימות A/B של טקסטים ונייטרליות UX (ללא תבניות אפלות).
E2E התחקות: אירוע ביטול משתמש = אין שליחה לפיקסלים שותפים וצינורות.
13) יכולות משולבות
אנונימיות/פסאודונימיזציה: ביצוע של כשלים לפני ואחרי דה-פרסונליזציה.
הצפנה והגנה של KMS Token/Log.
ניתוב גיאו: בחירת טקסטים/חוקים אזוריים.
תצפית: לוחות מחוונים פרטיים ללא נתונים אישיים; מתאם באסימונים בלבד.
שושלת נתונים: בכל נתונים - הטבעת הסכמים.
14) מתכונים קטנים
מדיניות מטרה הצהרתית (דוגמא ל-YAML):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. האם יש הוצאה להורג בהיקף, בנחלים, באנליטיקה ובאם-אל?
4. משוב ומדיניות ניקוי מידע היסטורית מיושמת?
5. האם מנגנוני UI/SDK/שרת מתאימים?
6. סיקור/דריפט/ביטול מדדי SLA ודיווח?
7. האם יש פנקס על אירועים (הפרות, תלונות, רגולטור)?
8. האם משטרים מיוחדים נתמכים (ילדים, אזורים, שותפים B2B)?
מסקנה
ניהול הסכמות אינו חלון מודאלי, אלא פונקציה ארכיטקטונית מקצה לקצה: החל בהצהרת מטרות וכלה בהעברת טקסטים ועד ביצוע מכונות בזמן אמת ודיווח לאחר מכן. מודל נתונים קפדני, רישום יחיד, PDP/PEP על כל השכבות, טלמטריה מלאה ונהלי ניקוי הופכים ציות ליתרון תחרותי - פלטפורמה אמינה.