서드파티 쿠키가 꺼진 뒤, 전환 측정을 다시 세우는 법

애플과 구글을 비롯한 주요 브라우저·플랫폼이 서드파티 쿠키 지원을 순차적으로 중단하고 있다. Safari의 ITP와 Firefox의 ETP는 이미 크로스사이트 트래킹을 차단하는 쪽으로 정리됐고, Chrome도 단계적 지원 중단과 Privacy Sandbox 대체 기술 제공을 병행하는 중이다. 최신 일정과 API 범위는 계속 바뀌므로 실제 적용 시점에는 최신 정보를 다시 확인해야 한다.

서드파티 쿠키가 하던 일, 그리고 왜 막히는가

서드파티 쿠키는 사용자가 방문한 도메인과 다른 제3자 도메인이 설정하고 읽는 쿠키다. 크로스사이트 트래킹, 리타게팅, 멀티채널 어트리뷰션이 이 위에서 돌아갔다. 반면 퍼스트파티 쿠키는 방문 중인 동일 도메인이 설정·읽는 쿠키로 세션 유지·기본 분석·사용자 설정 정도에 쓰인다.

정책이 바뀌는 배경은 기술이 아니라 규제다. GDPR, ePrivacy, CCPA/CPRA 같은 규제가 동의관리(CMP), 목적 제한, 데이터 최소화, 보존 기간 관리를 요구하면서, 브라우저·플랫폼 단의 집계·비식별 처리에 대한 의존도가 자연스럽게 높아졌다. 애플은 Safari ITP와 iOS의 ATT(App Tracking Transparency), SKAdNetwork로 앱 전환을 집계 형태로만 노출하고, 구글은 Chrome의 서드파티 쿠키 폐기 로드맵과 함께 Attribution Reporting API·Protected Audience API·Topics API 등 Privacy Sandbox 제안을 진행 중이다.

이 변화가 마케팅에 미치는 영향은 직접적이다. 리타게팅과 크로스사이트 빈도 제어가 어려워지고, 라스트클릭 바이어스가 심화될 가능성이 있다. 매체 간 전환 연결성이 약해지면서 멀티터치 어트리뷰션이 관측할 수 있는 범위 자체가 줄고, 그만큼 증분실험·MMM·보정모델 같은 모델 기반 접근에 의존하는 비중이 커진다.

대체 스택은 한 가지가 아니라 조합이다

퍼스트파티 데이터 수집·정합화(CDP), 서버사이드 태깅, 로그인 기반 ID, 데이터 클린룸, 프라이버시 샌드박스 API, 컨텍스트 타게팅. 이 여섯 가지를 혼합 운용하는 것이 현재 실무의 기본형이다. CMP로 목적별 동의를 수집·전파하고, 비동의 구간은 집계·익명 처리로 대체한다. 동시에 태그 관리, 데이터 계보(Lineage), 보존·삭제 정책, 테스트 샌드박스와 데브옵스 파이프라인 같은 운영 거버넌스가 뒷받침돼야 하는데, 여기서 운영 편의와 규제 준수는 계속 트레이드오프 관계에 있다. 지문채취(fingerprinting) 같은 대체 식별자 남용은 지양해야 한다.

전환 측정부터 다시 짠다

웹에서는 퍼스트파티 이벤트 수집과 서버사이드 태깅으로 신뢰도와 지속성을 확보하고, UTM·클릭ID의 보존·정합성을 관리한다. Chrome 환경이라면 Attribution Reporting API를 검토해 집계 보고서 기반으로 전환을 추정하고, Meta 같은 플랫폼별 AEM을 병행한다. 앱에서는 iOS가 ATT 동의 기반 측정과 SKAdNetwork 집계 리포트를, 안드로이드는 Privacy Sandbox on Android 파일럿을 각각 검토 대상으로 둔다. 공통적으로는 지역·시간 기반 증분실험(PSA 전환)과 MMM을 병행해 관측 손실을 보정하고, 채널·캠페인별로 측정 전략을 이원화한다.

타게팅 쪽에서는 리타게팅이 로그인 기반(회원) 오디언스 중심으로 옮겨가고, 해시 이메일·전화번호 같은 일방향 해시로 안전하게 매칭한다. Protected Audience API처럼 오디언스 보관과 경매를 브라우저 내부에서 수행하는 방식도 검토 대상이다. 컨텍스트 타게팅은 페이지·앱의 카테고리·키워드·신호로 세그먼트를 구성하는 방식이고, Topics API를 병행하면서 저빈도·니치 주제는 퍼스트파티 시그널로 보완한다. 데이터 클린룸은 광고주와 퍼블리셔가 익명·집계 형태로 공동 분석·매칭을 수행하는 방식으로, 쿼리 가드레일과 출력 최소 k-익명성을 지켜야 하며 LTV 분석·중복 제거 리치 계산·코호트 성과 진단에 쓰인다.

퍼스트파티 데이터 파이프라인은 수집(CMP 연동으로 목적별 동의 캡처, 웹/앱 SDK 이벤트 스키마 표준화) → 전송·처리(서버사이드 태깅으로 벤더 호출을 서버에서 대행, 레이트 리밋·재시도·데드레터 큐 운영) → 저장·활용(데이터 웨어하우스·데이터레이크 적재, ID 해석으로 단일 고객 보기 생성, 모델링·액티베이션 연계) 순으로 구성한다.

⤢✕

어느 쪽을 먼저 손댈지는 트레이드오프로 정한다

접근법	성능	확장성	일관성	안정성	운영 편의
퍼스트파티 데이터 + 서버사이드 태깅	높음(신호 품질 우수)	높음(클라우드 네이티브)	중~높음(스키마 관리 필요)	높음(재시도/큐잉)	중간(인프라 운영 필요)
Privacy Sandbox(API 기반)	중간(집계 한계)	높음(브라우저 스케일)	중간(브라우저별 차이)	중~높음(플랫폼 보호)	중간(스펙 학습 필요)
데이터 클린룸	중간(쿼리 제한)	중~높음(벤더 의존)	높음(가드레일)	높음(보안·거버넌스)	낮음(전문성·비용)
컨텍스트 타게팅	중간(정밀도 제한)	높음(매체 전반)	높음(쿠키 비의존)	높음(정책 영향 적음)	높음(도입 용이)
로그인 기반 식별(해시)	높음(지속성 우수)	중간(가입률 제약)	높음(명시적 매칭)	중~높음(동의·보안 필수)	중간(UX·온보딩 필요)

서버사이드 태깅은 데이터 품질과 제어성을 끌어올리는 대신 인프라 비용과 운영 복잡도를 늘린다. 로그인 기반 식별은 정확성과 지속성을 확보하지만 가입 전환·UX 부담이 따라온다. 클린룸은 규제 친화적이고 협업이 가능한 대신 쿼리 제한과 비용, 전문성 요구가 크다. 어느 하나로 전부를 대체하기보다, KPI 영향 범위가 큰 채널부터 조합을 골라 붙이는 편이 현실적이다.

도입은 진단(쿠키·태그 인벤토리, 서드파티 의존도, KPI 영향 범위 파악, CMP 동의 신호 전파 여부 점검) → 설계(1P 이벤트 스키마, ID 전략, 서버사이드 아키텍처, AR API·SKAdNetwork·AEM·실험·MMM을 조합한 측정 믹스) → 구현(태그 거버넌스, 서버사이드 프록시, 레이트 리밋·백오프·모니터링, 스키마 밸리데이션) → 검증(A/B 홀드아웃으로 전환 추정 오차 검증, 리프트 테스트, 브라우저·OS 매트릭스별 커버리지·지연·오류율 모니터링) → 운영(SLA·알림, 샘플링·압축을 통한 비용 최적화, 규제·브라우저 정책 업데이트 트래킹, 벤더 계약·DPA·전이적 이전 요건 재검토) 순서로 밟는다.

이 전환이 자리 잡으면 측정 커버리지·지연·오류율을 관리 가능한 수준으로 되돌릴 수 있고, 전환 데이터의 수집률이 안정되면서 CPA/CAC·ROAS·증분 리프트 같은 핵심 지표가 모델 기반으로나마 신뢰성을 회복한다. 규제 준수와 브랜드 신뢰가 올라가고 벤더 종속도 완화되지만, 그 대가로 데이터 파이프라인의 보안·거버넌스 부담과 조직 내 데이터 역량 요구는 함께 올라간다. 브라우저·플랫폼 정책과 표준이 계속 바뀌는 영역이라, 전면 전환보다는 PoC → 파일럿 → 점진 확산 순서로 움직이는 편이 안전하다.