지금 서드파티 쿠키 환경은 정확히 어떤 상태인가

전제를 정확히 잡는 것이 먼저입니다. 구글은 2020년 크롬에서 제3자 쿠키를 단계적으로 폐지하겠다고 발표했으나 2024년 7월 22일 이 계획을 공식 철회하고 지원을 계속 유지하기로 했습니다. 이후 제3자 쿠키 대체 기술로 개발하던 Privacy Sandbox API 10종은 2025년 10월 17일 종료됐고, 크롬 144(2026년 1월)부터 단계적 폐지를 시작해 크롬 150(2026년 7월) 시점 완전 제거를 목표로 한다고 업계 매체들이 전했습니다.

여기서 오해하기 쉬운 지점이 있습니다. 크롬이 유지한다고 해서 측정 환경이 예전으로 돌아간 것은 아닙니다. 애플 사파리와 모질라 파이어폭스는 크롬과 별개로 이미 수년간 기본값으로 제3자 추적 쿠키를 차단해 왔습니다. 즉 브라우저별로 측정 가능 범위가 다른 분절 상태가 이미 기본값이고, 자체 어트리뷰션 모델의 필요는 크롬의 결정과 무관하게 유지됩니다.

자체 모델을 만들기 전에 확정해야 할 것은 무엇인가

자체 어트리뷰션은 알고리즘 문제가 아니라 데이터 문제입니다. 먼저 자사에 실제로 남는 접점을 목록화해야 합니다. GA4 원시 데이터 쪽에는 이벤트 단위로 event_name, event_timestamp, user_pseudo_id, user_id와 유입 정보 필드들이 남고, 매체 쪽에는 캠페인 단위 비용·노출·클릭이 남습니다. 이 둘을 잇는 조인 키가 실제로 존재하는지가 모델 가능성을 결정합니다.

여기서 스키마 특성을 하나 알아두어야 합니다. 최초 접점 어트리뷰션 데이터인 traffic_source 필드는 intraday(스트리밍) 테이블에는 포함되지 않는다고 공식 스키마 문서가 명시합니다. 모델링용 데이터는 일일 테이블 기준으로 구성하고, 실시간 화면은 별도로 두는 것이 안전합니다. 또 이벤트 매개변수와 사용자 속성은 반복 레코드라 key/value 구조를 풀어야 조회되므로, 모델링 쿼리의 첫 단계는 필요한 매개변수만 평탄화한 중간 테이블을 만드는 일이 됩니다.

매체 데이터와 자사 데이터를 어떻게 나란히 둬야 하나

자체 모델의 목적 중 하나는 매체 보고 숫자와 자사 숫자의 차이를 설명하는 것입니다. 메타처럼 자체적으로 클릭·전환을 판정해 보고하는 자기귀속 네트워크는 어트리뷰션 로직과 귀속 모델, 집계 시점이 자사 측정 도구와 달라 수치가 구조적으로 어긋납니다.

그래서 테이블 설계에서 두 숫자를 같은 컬럼에 합치지 않는 것이 원칙입니다. 매체 보고 전환과 자사 측정 전환을 별도 컬럼으로 나란히 두고, 차이율을 지표로 관리합니다. 차이 자체는 사고가 아니며, 차이가 갑자기 변하는 것이 사고 신호입니다. 이 관점으로 두면 논쟁이 "누가 맞느냐"에서 "이번 주에 무엇이 달라졌느냐"로 옮겨갑니다. 서버사이드 수집을 병행한다면 브라우저 쪽 이벤트와 서버 쪽 이벤트의 수집 건수를 함께 대조하는 항목도 같은 테이블에 두는 편이 좋습니다.

모델은 어떤 순서로 만들어야 하나

순서는 단순한 것부터입니다. 첫 단계는 규칙 기반 모델입니다. 마지막 클릭, 첫 클릭, 선형 배분처럼 계산 방식이 명확한 모델을 SQL로 구현합니다. BigQuery 표준 SQL의 SELECT 문 구조는 SELECT, FROM, WHERE, GROUP BY, HAVING 순서를 따르고 WHERE 절은 집계 전에 행 단위로 걸러내므로, 기간과 대상 이벤트를 먼저 좁힌 뒤 사용자별 접점 시퀀스를 만드는 방식으로 짭니다.

두 번째 단계는 검증입니다. 규칙 기반 모델의 결과가 실제 기여를 반영하는지는 모델 자체로는 증명되지 않습니다. 국내 공식 기준이 없는 영역이므로 자사 데이터로 기준선을 세우는 절차가 필요합니다. 최소 4주치 기준선을 확보하고, 한 번에 한 항목만 변경하며, 같은 요일끼리 비교하고, 가능하면 홀드아웃 그룹을 남겨 대조합니다. 이 절차 없이 배분 비율만 바꿔가며 모델을 정교화하면, 숫자는 계속 바뀌는데 어느 쪽이 맞는지는 끝내 알 수 없습니다.

세 번째 단계에서야 매체 협업 환경을 검토합니다. 구글 클라우드는 광고 전용 클린룸과 별개로 BigQuery 위에서 동작하는 범용 데이터 클린룸을 제공하며, 원본 데이터를 이동시키지 않고 안전한 뷰와 분석 규칙으로 공유·분석하게 합니다. 다만 클린룸 계열 환경은 최소 집계 임계값 같은 프라이버시 제약이 있어, 세그먼트를 잘게 쪼갠 분석은 결과가 아예 출력되지 않을 수 있다는 점을 설계에 미리 반영해야 합니다.

비용은 어떻게 통제하나

어트리뷰션 모델은 사용자별 접점 시퀀스를 다루기 때문에 스캔량이 쉽게 커집니다. GA4 Export는 날짜별로 테이블이 분리되는 구조이므로 대상 날짜 범위를 좁히면 스캔 대상 자체가 줄어들고, 이는 구글이 비용 통제 모범사례에서 권장하는 방향과 같습니다.

같은 문서는 쿼리 결과를 단계적으로 구체화하라고 권합니다. 사용자별 접점 시퀀스처럼 여러 리포트가 공통으로 쓰는 중간 결과는 매번 다시 계산하지 말고 테이블로 저장해 재사용하는 방식입니다. 실행 전에는 쿼리 검사기나 드라이런으로 예상 바이트를 확인하고, 청구 바이트 최대값으로 상한을 걸어 사고성 과금을 막습니다. 탐색 목적이라면 쿼리 대신 테이블 미리보기를 쓰라는 권장도 함께 지켜야 합니다. LIMIT는 클러스터링되지 않은 테이블에서 비용을 줄여주지 않기 때문입니다.