동의 관리
1) 책임 약관
동의: 자발적이고, 정보에 입각 한, 구체적이고 모호하지 않은 의지 표현; 취소 될 수 있습니다.
법적 근거: 동의는 옵션 중 하나 일뿐입니다 (계약, 법적 근거, 합법적 이익 등). 모델은베이스와 대상을 모두 저장해야합니다.
목적: 원자 이유: 분석, 개인화, 광고, 이메일 _ 마케팅, data _ sharing _ bander _ X.
세분성: 동의는 목표, 채널, 공급 업체, 지역, 데이터 범주별로 저장됩니다.
주제 프로필: 개인, 기기, 가구, 아동 계정 (미성년자를위한 특별 규칙).
2) 동의 수명주기
1. 수집: 배너/CIW, 프로필 설정, API/SDK, 오프라인 채널 (콘택트 센터).
2. 검증: 연령, 지역, 대안의 가용성 ("어두운 패턴" 없이).
3. 옵트 인 이벤트 및 대상에 대한 현재 스냅 샷을 작성하려면 등록하십시오.
4. 배포: 이벤트를 버스에 게시하고 가장자리에 캐시를 업데이트하며 공급 업체와 동기화합니다.
5. 구현: ML 파이프 라인에서 실시간 (게이트웨이/픽셀/SDK), 배치 (ETL/분석) 로 적용됩니다.
6. 변경/취소: 새로운 수집/활성화, 이후 과거 정책 데이터의 "정화" 에 대한 즉각적인 금지.
7. 감사/보고: 처리 시점의 동의 가능성 (언제 어떤 버전의 텍스트).
3) 건축 구성 요소
CMP (Consent Management Platform): UX/관할 지역에 대한 UI/SDK + API 형식 동의 옵션; 텍스트와 버전별로 진실의 원천.
동의 등록 소: 안정적인 동의 상태 및 이벤트 저장소 (추가 전용 저널 + 전류 프로젝션).
동의 PDP/PEP: 정책 결정/집행 지점. PDP는 "가능합니까? "PEP는 해당 솔루션을 API 게이트웨이, ETL, SDK 등에 적용합니다.
동의의 가장자리 캐시: 주변 검사를위한 대기 시간이 짧습니다.
파트너/GPP/IAB 게이트웨이: 로컬 대상을 파트너 신호로 변환하거나 그 반대도 마찬가지입니다.
데이터 리니지 및 태깅: 체인 전체에 동의/기본 플래그가있는 데이터를 표시합니다.
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/edge 렌더링과의 양방향 교환.
파트너/공급 업체: 형식으로 변환 (예: 대상 벡터, 일반 신호 "GPP/TCF"); 실패의 경우-신호 제로/제한 모드.
오프라인 채널: '대상 _ id' 에 대한 후속 검증 및 바인딩으로 연산자에 의한 오디오 동의/체크 박스 기록.
6) 실행: 트래픽이 "절단 된" 위치 및 방법
API 게이트웨이 (PEP) 에서:- 동의없이 엔드 포인트/필드를 차단하십시오 (/프로필/풍부 ,/광고/,/이벤트/트랙).
- 돌연변이 응답/요청: 컷 트래커, 개인화 필드, 식별자.
- 백엔드 요청 (JWT 스탬프 또는 개별 헤더) 에 동의 컨텍스트를 할당합니다.
- 이벤트 변압기는 동의 플래그로 필드를 제거/마스킹합니다.
- 데이터 세트 표시: '데이터 세트. 동의 _ scope = 분석: 부여 된; 광고: 거부되었습니다. '
- 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', 'tex _ hash', 'banner _ id' 유지.
로케일 및 지역: 어떤 텍스트와 어떤 언어가 표시되는지.
처리 당시의 스냅 샷: "왜 광고가 09: 03에 2025-10-15로 게재 되었습니까? ».
불변의 로그: 암호화 이벤트 시그니처가있는 WORM/추가 전용.
9) 특별한 경우
미성년자: 연령 검증, 부모의 동의, 개인 목표 및 마감일.
손님 → 로그인: 익명의 토큰을 계정과 병합; 충돌의 규칙 (가장 엄격한 승리).
다중 장치: 일관된 resync; 해지 할 때-모든 장치에서 푸시 비활성화 된 토큰.
지역 모드: "엄격한" (EU) vs "옵트 아웃" (일부 시장) -CMP 사전 설정 전환.
A/B 테스트: 데이터 실험은 별도의 실험 목표입니다. 개인 데이터가없는 기능적 테스트 만 있습니다.
삭제할 권리: 리콜은 과거 대상 데이터의 삭제/익명화를 유발할 수 있습니다 ("철회시 퍼지" 정책).
10) 반 패턴
모든 것을위한 하나의 "공통" 체크 박스.
텍스트 버전의 부족과 쇼의 확률.
서버 레지스트리없이 쿠키 플래그 만 저장합니다.
ETL/ML/내보내기가 아닌 UI에서만 동의를 적용합니다.
상충되는 진실의 원인 (SDK 단위 백엔드).
어두운 패턴, 동의 부과: 법적 및 평판 위험.
11) 관찰 가능성과 지표
적용 범위: 유효한 동의 토큰이있는 트래픽 비율.
대기 시간 PDP: 주변 결정 시간.
드리프트: SDK와 서버 스냅 샷 간의 불일치.
SLA 취소: 취소 시간 → 완전 비활성화/명확한 시간.
공급 업체 준수-올바른 신호를 가진 파트너 통화의 백분율.
사건: 동의없이 처리하려고 시도하면 전화가 차단됩니다.
대시 보드: "동의 깔때기", 지역/채널 맵, 열 실패 맵.
12) 테스트 및 검증
PDP/PEP 계약 테스트: 목표/지역 조합별 진실 테이블.
카오스/드리프트 테스트: 비 동기식 SDK는 서버를 상태로합니다. TTL 캐시 만료.
CMP 릴리스: 텍스트 및 UX 중립성에 대한 A/B 검증 (어두운 패턴 없음).
E2E 추적: 사용자 취소 이벤트 → 파트너 픽셀 및 파이프 라인으로 보내지 않음.
13) 상호 관련 능력
명칭화/가명: 개인화 전후의 실패 실행.
암호화 및 KMS 토큰/로그 보호.
지리 라우팅: 지역 텍스트/규칙 선택.
관찰 가능성: 개인 데이터가없는 개인 대시 보드; 토큰에 의한 상관 관계 만.
데이터 계보: 각 데이터 세트에서 동의의 각인.
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. 주변, 스트림, 분석 및 ML에 실행이 있습니까?
4. 피드백 및 과거 데이터 정리 정책이 구현 되었습니까?
5. UI/SDK/서버 스냅 샷 및 수지 메커니즘이 일관성이 있습니까?
6. 적용 범위/드리프트/철회 SLA 지표 및보고 설정?
7. 사건 (위반, 불만, 규제 기관) 에 대한 런북이 있습니까?
8. 특별 제도 (어린이, 지역, B2B 파트너) 가 지원됩니까?
결론
동의 관리는 모달 창이 아니라 목표 선언 및 버전 지정 텍스트에서 실시간 및 후속 보고서의 의사 결정 실행에 이르기까지 엔드 투 엔드 아키텍처 기능입니다. 엄격한 데이터 모델, 단일 레지스트리, 모든 계층의 PDP/PEP, 전체 원격 측정 및 청소 절차는 규정 준수를 신뢰할 수있는 플랫폼 인 경쟁 우위로 바꿉니다.