고객 식별 통합

식별자는 어떻게 하나의 고객으로 연결되나요?

Adobe Identity Service 문서는 온라인·오프라인 필드를 식별자로 지정하고 네임스페이스 사이의 공통 값으로 데이터 조각의 관계를 만든다고 설명합니다. Adobe Identity Service 구현 문서 이메일, 전화번호, 로그인 ID처럼 같은 형식이라도 출처와 의미가 다르면 별도 네임스페이스가 필요합니다. 하나의 잘못된 연결이 광고 대상뿐 아니라 고객센터 기록과 삭제 요청 범위까지 바꿀 수 있으므로 식별자별 신뢰도와 연결 근거를 나중에 되짚을 수 있게 저장하고 연결 규칙이 바뀌면 기존 그래프에 미치는 영향과 권리 요청 처리 범위를 다시 검증합니다.

로그인처럼 명확한 연결은 결정적 규칙으로, 기기·행동 유사성은 확률적 규칙으로 다룰 수 있습니다. 확률 점수는 동일인 사실이 아니라 모델의 추정입니다.

매핑표는 어떤 역할을 하나요?

AWS Entity Resolution 문서는 소스와 대상 식별자를 ID 매핑 테이블로 연결해 조인하는 절차를 설명합니다. AWS Entity Resolution 문서 매핑 제공자가 개입하면 원천 데이터, 변환 규칙, 매핑 갱신·삭제 책임을 계약에서 확인합니다. 매핑 해제 이력도 같은 방식으로 남깁니다.

정확도는 어떻게 계산하나요?

검증 표본 1,000쌍 중 시스템이 같은 고객이라고 연결한 300쌍을 사람이 검토해 270쌍이 맞았다면 정밀도는 270÷300=90%입니다. 실제 같은 고객 400쌍 중 270쌍만 찾았다면 재현율은 67.5%입니다. 정밀도만 높이려고 연결을 거의 하지 않거나 재현율만 높이려고 과도하게 합치지 않습니다.

동의와 권리 요청은 어떻게 반영하나요?

한 식별자에서 광고 거부나 삭제 요청이 들어오면 그래프에 연결된 다른 ID까지 어느 범위로 전파할지 정합니다. 서로 다른 목적의 데이터는 한 고객으로 연결할 근거가 있는지 확인하고, 민감한 속성을 추론하는 규칙은 별도 위험평가와 전문가 검토를 거칩니다.

오결합을 줄이려면 무엇을 기록하나요?

규칙 버전, 입력 필드, 정규화 방법, 임계값, 검증 표본, 정밀도·재현율, 수동 해제 절차를 남깁니다. 고객센터가 "두 계정이 합쳐졌다"는 신고를 받았을 때 연결 근거를 찾고 되돌릴 수 있어야 하며, 그래프 크기만을 성공 지표로 삼지 않습니다.

자주 묻는 질문

이메일이 같으면 같은 사람인가요?

공용·가족 이메일과 재활용 주소가 있을 수 있어 항상 같다고 단정할 수 없습니다. 계정 맥락과 추가 검증이 필요합니다.

확률적 식별은 개인정보 처리가 아닌가요?

개인을 구별하거나 연결하려는 식별자와 추정값은 개인정보 판단 대상이 될 수 있습니다. 모델 사용 자체가 적용을 면제하지 않습니다.

식별 통합률이 높을수록 좋은가요?

오결합이 늘면 고객 경험과 권리 처리에 문제가 생깁니다. 통합률과 함께 정밀도, 재현율, 이의 제기 건수를 봐야 합니다.

출처와 확인 범위

1. Implementation guide for Identity Service · Adobe Experience Platform · 확인 2026-10-27

   여러 네임스페이스의 식별자를 연결해 고객 그래프를 만드는 구조를 설명합니다.

   확인 범위: 제품 문서이며 연결 결과가 항상 동일인이라는 사실을 보장하지 않습니다.

2. AWS Entity Resolution in AWS Clean Rooms · Amazon Web Services · 확인 2026-10-27

   식별자 매핑표를 이용한 연결 절차를 설명합니다.

   확인 범위: 특정 서비스 구현이며 오결합, 동의, 처리 근거를 대신 검증하지 않습니다.

함께 이해할 용어

이 용어를 적용하는 실무 가이드