CDP 시대의 ID 그래프 — 쿠키 없이 유저를 어떻게 잇나

쿠키의 종료일을 맞히는 것보다 중요한 일은, 어떤 신호를 어떤 동의와 품질 기준 아래 같은 고객으로 연결할지 운영 규칙을 만드는 것입니다.

1. 쿠키가 끝난 게 아니라, 식별 전제가 달라졌다

오래된 설명은 “Chrome이 3rd party cookie를 없애고, IDFA가 사라진다”는 한 줄로 출발했다. 2026년의 운영자는 이 문장을 그대로 쓰면 안 된다. Google은 2025년 4월 Chrome에 3rd party cookie용 별도 선택 창을 새로 띄우지 않고, 기존 설정에서 사용자가 선택하는 방식을 유지한다고 밝혔다. 시크릿 모드는 계속 3rd party cookie를 기본 차단하지만, Chrome 전체의 일괄 폐기 일정은 현재 전제가 아니다.

Apple의 ATT도 “IDFA가 확률적으로 흐려졌다”는 이야기가 아니다. iOS 14.5 이후 다른 회사의 앱·웹 데이터와 연결해 광고나 측정에 쓰려면 사용자의 추적 허가가 필요하다. 허가하지 않으면 IDFA는 0으로 반환되고, 다른 식별자나 fingerprint로 우회해서도 안 된다.

그러니 ID 그래프의 필요성은 “모든 쿠키가 사라져서”가 아니다. 브라우저·앱·CRM마다 식별 가능 범위와 동의가 달라졌고, 그 차이를 무시한 단일 고객 뷰가 더 위험해졌기 때문이다. Privacy Sandbox 운영 변화와 1st party ID 그래프는 대체 관계가 아니라 서로 다른 층의 문제다.

2. ID 그래프는 사람보다 연결 규칙을 저장한다

ID 그래프를 “한 사람 주위에 식별자를 모은 그림”으로만 이해하면 절반이 빠진다. 운영 가능한 그래프에는 노드와 엣지뿐 아니라 왜 연결했는지가 남아야 한다.

person_id: P-1042
  ├─ member_id: M-1042  [verified_login, 2026-08-20]
  ├─ email_hash: 9f...  [verified_email, consent=ads]
  ├─ first_party_id: W-731  [logged_in_session, expires=2026-09-19]
  └─ app_instance: A-208  [same_account_login, consent=analytics]

각 엣지에는 출처, 관측 시각, 동의 목적, 연결 규칙 버전, 만료 시각이 붙는다. 그래야 “왜 합쳐졌나”, “이 연결을 광고 활성화에도 써도 되나”, “전화번호가 재활용되면 어디까지 끊어야 하나”를 되짚을 수 있다.

2.1 Deterministic matching

검증된 로그인, 이메일 인증, 동일한 CRM 회원번호처럼 설명 가능한 사건으로 잇는다. 강한 근거이지만 정확도 100%는 아니다. 가족이 이메일을 공유하거나, 전화번호가 재활용되거나, 운영자가 두 계정을 잘못 병합할 수 있다. 그래서 “확정”이라는 이름보다 재현 가능한 규칙이라는 성질이 더 중요하다.

2.2 Probabilistic matching

여러 약한 신호로 같은 주체일 가능성을 추정한다.

문제는 점수 자체가 아니라 행동 경계다. 0.82라는 값에 보편적 의미는 없다. 학습 데이터, 시간 창, 기기 공유 패턴이 바뀌면 같은 점수의 오류율도 달라진다. Apple은 타사 앱·웹 추적을 위한 device fingerprinting을 허용하지 않으므로, “IP와 user-agent가 비슷하면 앱 사용자를 합친다”는 규칙은 모델 성능 이전에 정책 경계를 넘을 수 있다.

3. 식별자는 같은 급이 아니다

member_id, IDFA, 브라우저 쿠키, IP를 한 열에 모아 놓으면 모두 문자열처럼 보인다. 하지만 가리키는 대상과 허용 범위가 다르다. 기기 ID를 사람 ID처럼 쓰거나, 해시를 익명화로 오해하는 순간 그래프의 품질과 개인정보 경계가 동시에 무너진다.

특히 IDFA는 “확률적 식별자”가 아니다. 허가된 경우 반환되는 기기 단위 식별자이고, ATT가 허가되지 않으면 사용할 수 없다. 반대로 IP와 user-agent는 관측되더라도 같은 사람이라는 직접 증거가 아니다.

이메일 해시도 오해가 많다. Google의 Customer Match 문서는 이메일의 앞뒤 공백을 제거하고 소문자로 바꾸며, 전화번호는 E.164로 맞춘 다음 SHA-256으로 해시하라고 안내한다. 이 절차는 양쪽 문자열을 같은 방식으로 비교하기 위한 정규화·전송 규약이다. 수집 목적, 동의, 보관 기간을 없애는 익명화 버튼이 아니다.

4. CDP가 ID 그래프를 만드는 네 단계

도구를 먼저 고르면 stitching 설정 화면에서 운영 규칙을 만들게 된다. 순서는 반대다. 데이터 계약, 연결, 프로필 결정, 목적별 활성화를 분리해야 어느 단계가 실패했는지 알 수 있다.

Step 1: Identity ingestion

웹·앱·CRM 사건을 공통 계약으로 받는다. source, observed_at, identifier_type, identifier_value, verification_state, consent_purpose가 최소 단위다. 같은 이메일이라도 “폼에 입력됨”과 “인증 링크를 통과함”은 다른 증거다.

Step 2: Identity stitching

동시에 관측된 식별자를 규칙에 따라 연결한다. 검증 로그인에서 first_party_id=W-731과 member_id=M-1042가 함께 나타났다면 강한 엣지가 된다. 반면 같은 IP에서 5분 안에 관측됐다는 이유만으로 두 회원을 합치지 않는다. 규칙에는 우선순위, 만료, 금지 조건이 필요하다.

Step 3: Resolution

연결된 클러스터에 person_id를 부여하고 충돌을 해결한다. 두 개의 인증 회원 ID가 한 프로필로 모이면 자동 병합보다 격리 큐가 안전하다. 이전 person_id, 새 person_id, 규칙 버전, 병합·분리 시각을 남겨야 과거 리포트도 재현할 수 있다.

Step 4: Activation

분석, 서비스 개인화, 광고 측정, 오디언스 업로드마다 별도 자격 조건을 적용한다. “그래프에 연결됨”과 “광고 플랫폼에 보낼 수 있음”은 같은 상태가 아니다. 목적 동의, 보관 기간, 삭제 상태, 플랫폼 정책을 통과한 프로필만 내보낸다.

아래 네 행은 실제 고객이 아닌 합성 사건이다.

수집 → 정규화·동의 판정 → 연결 규칙 → 프로필 결정 → 목적별 활성화 → 삭제·분리 전파

5. 매칭률 하나로 ID 그래프를 평가하지 않는다

플랫폼 match rate는 업로드한 레코드 중 그 플랫폼이 계정과 연결한 비율이다. Google도 이를 데이터 형식 문제를 진단하는 benchmark로 설명하며 100%를 기대하지 말라고 안내한다. 이 값은 CDP가 두 사람을 잘못 합쳤는지, 동의 없는 키를 섞었는지, 삭제를 빠뜨렸는지 알려주지 않는다.

운영판에는 최소 네 지표가 나란히 있어야 한다.

합성 주간 비교를 보자. 실제 고객이나 회사 수치가 아니다.

이 패턴에서 “광고 플랫폼 매칭률이 떨어졌다”고 결론 내리면 잘못된 팀을 호출한다. 먼저 변경 주의 이메일 정규화, 전화번호 E.164 변환, 동의 필드, API 스키마 배포를 확인해야 한다. 반대로 upload acceptance는 안정적인데 false merge만 오른다면 활성화를 멈추고 연결 규칙을 되돌리는 편이 맞다.

6. 이 API로 실제 무엇을 만들 수 있나: ID 품질 관제판

2026년 7월 문서 기준 Google Data Manager API는 Customer Match·모바일 기기 ID 같은 오디언스와 전환 이벤트를 공통 ingestion API로 보낸다. 새 오디언스 생성부터 멤버 전송, 처리 상태와 diagnostics 확인까지 이어지고, validateOnly로 적용 전 요청을 검사할 수 있다. 기존 Google Ads API에서 옮길 때 주의할 점도 분명하다. Data Manager API는 요청 안의 한 레코드가 잘못되면 전체 요청이 실패하는 fast-fail 방식이다.

이 성질을 이용하면 단순 업로더가 아니라 ID 품질 관제판을 만들 수 있다.

관제판에는 이메일 해시나 전화번호 같은 행 단위 식별자를 복사하지 않는다. 배치 ID, 규칙 버전, 집계 건수, 비율, 오류 코드만 남긴다. 원본 키는 접근 통제된 처리 계층에 머물고, 보고 계층에는 “어디서 얼마나 탈락했는가”만 올라온다.

이 구조가 답하는 질문은 구체적이다.

• 가입 폼 변경 뒤 deterministic coverage가 왜 떨어졌나
• 해시 함수는 같지만 정규화 순서가 달라 upload acceptance가 깨졌나
• 플랫폼 match rate 하락이 원천 데이터 문제인가, 수락 이후의 변화인가
• 삭제 요청이 CRM, CDP, Customer Match에서 같은 배치 안에 반영됐나
• 광고 전환 신호의 연결이 깨졌다면 ID 그래프와 이벤트 중복 제거 중 어디가 원인인가

마지막 질문은 GA4·BigQuery ROAS 파이프라인과 함께 봐야 한다. 오디언스 overlap이나 플랫폼 간 집계 분석이 목적이라면 원시 ID를 한곳에 모으기보다 Data Clean Room 비교의 반출 제한과 최소 집계 기준이 더 맞을 수 있다.

7. 어떤 연결을 어디까지 써도 되는가

ID 그래프 도입 회의에서 “deterministic이냐 probabilistic이냐”부터 묻기 쉽다. 더 나은 질문은 “이 결정이 틀렸을 때 누가 어떤 손해를 보는가”다. 같은 연결도 익명 퍼널 집계에는 쓸 수 있지만, 1:1 가격 제안에는 부족할 수 있다.

다음 네 질문 중 하나라도 답이 없으면 연결 범위를 넓히지 않는다.

1. 이 엣지를 만든 사건과 규칙 버전을 재현할 수 있는가?
2. 이 목적에 필요한 동의와 플랫폼 정책을 통과했는가?
3. false merge·false split을 확인할 독립 감사 표본이 있는가?
4. 삭제·철회가 모든 파생 ID와 활성화 대상으로 전파되는가?

확률 점수가 꼭 필요하다면 먼저 집계 분석에만 쓰고, 임계치별 오류율을 시간에 따라 본다. 검증 로그인처럼 더 강한 사건이 들어왔을 때 과거 추정을 교정할 수 있어야 한다. 사람에게 직접 영향을 주는 메시지와 혜택은 설명 가능한 deterministic 규칙으로 한정하는 편이 낫다.

8. 마치며: 좋은 ID 그래프는 덜 연결할 줄 안다

Chrome의 쿠키 계획이 바뀌었다고 identity 문제가 끝난 것은 아니다. 브라우저와 앱, 로그인과 광고 플랫폼마다 허용되는 연결이 달라졌고, 이제는 그 차이를 숨기는 단일 고객 뷰보다 차이를 기록하는 그래프가 필요하다.

운영 원칙은 세 줄로 남는다.

• 식별자 값과 함께 출처·시각·동의·규칙 버전을 저장한다.
• coverage와 platform match rate만 보지 말고 acceptance, false merge·split, 삭제 지연을 함께 본다.
• API 응답 성공이 아니라 검증한 배치, 처리 diagnostics, 목적별 경계까지 확인한 뒤 활성화한다.

결국 좋은 ID 그래프는 가장 많은 사람을 잇는 시스템이 아니다. 연결할 근거가 약할 때 멈추고, 잘못 이은 관계를 다시 풀 수 있으며, 고객이 철회했을 때 흔적을 끝까지 거둘 수 있는 시스템이다.

참고

• Google Privacy Sandbox, “Next steps for Privacy Sandbox and tracking protections in Chrome” (2025-04-22)
• Apple, “User Privacy and Data Use”
• Google Ads, “About the customer matching process”
• Google Ads, “Customer Match Best Practices”
• Google for Developers, “Data Manager API”
• Google for Developers, “Upgrade Customer Match to the Data Manager API”