지금 읽는 곳이 API가 대체하려던 기존 방식은 무엇이었나목차
STEP 3 고급·전략 › 3-2. 프로그래매틱 핵심 원리·거시 데이터 분석 › 과목 115 › 레슨 05
기여도 측정을 위한 Attribution Reporting API 엔지니어링: 개인정보 침해 없이 광고 클릭과 자사몰 전환의 인과관계를 일자별 요약 리포트로 받는 법
이 API도 2025년 10월 폐기 발표 대상이라 크롬 144부터 단계적으로 제거되는 중입니다. 지금 전환 추적 인프라의 기준으로 신규 구축할 대상이 아니라는 전제를 먼저 밝히고, 설계 원리를 정리합니다.
핵심요약
- Attribution Reporting API는 서드파티 쿠키 없이 광고 클릭·노출(source)과 전환(trigger)을 매칭하려던 API였다
- 개별 유저 단위 원시 매칭 대신, 이벤트 수준 리포트와 집계형(aggregatable) 리포트 두 형태로 결과를 제공하도록 설계됐다
- 집계형 리포트는 날짜·캠페인 등 차원별 합산 수치에 통계적 노이즈를 더해 개인 역추적을 어렵게 만드는 구조였다
- 이 API 역시 2025년 10월 폐기 발표 대상이라 지금은 개념 학습 자료로만 다룬다
이 API가 대체하려던 기존 방식은 무엇이었나
서드파티 쿠키 기반 기여도 측정은 광고 클릭 시점에 발급된 쿠키 ID를 이후 전환 시점까지 그대로 유지해, 광고 서버가 "이 클릭이 이 전환으로 이어졌다"를 유저 단위로 직접 매칭하는 방식이었습니다. 이 매칭이 정밀할수록 캠페인·소재·키워드 단위의 세밀한 성과 분석이 가능했습니다. 쿠키가 사라지면 이 정밀 매칭의 근거 자체가 사라지므로, Attribution Reporting API는 브라우저가 클릭과 전환을 자체적으로 연결해 요약된 결과만 광고주에게 돌려주는 방식으로 이를 대체하려 했습니다.
소스·트리거 등록은 어떻게 설계됐나
이 API는 광고가 클릭·노출된 시점(source)과 이후 웹사이트에서 전환이 발생한 시점(trigger)을 각각 브라우저에 등록하도록 설계됐습니다. 광고 게재 태그가 클릭 시 소스를 등록하고, 전환 페이지의 태그가 트리거를 등록하면, 브라우저가 내부적으로 두 이벤트를 매칭해 리포트를 생성하는 구조였습니다. 이 매칭 로직 자체가 브라우저 안에서 실행되기 때문에, 광고주 서버는 원본 매칭 로그가 아니라 브라우저가 정리해 보내주는 결과 리포트만 받게 됩니다.
이벤트 수준 리포트와 집계형 리포트는 어떻게 달랐나
이벤트 수준 리포트는 클릭과 전환의 매칭 관계를 비교적 단순한 형태로 알려주되 정보량을 제한한 형태였고, 집계형 리포트는 날짜·캠페인 등 여러 차원으로 나눈 합산 수치에 통계적 노이즈를 더해 제공하는 형태였습니다. 노이즈가 섞인다는 것은 특정 캠페인의 전환 수가 실제보다 조금 더 많거나 적게 집계될 수 있다는 뜻으로, 개별 건별 정밀도보다는 전체 추세 파악에 적합하도록 설계된 절충안이었습니다. 실무자는 이 두 리포트 유형을 목적에 맞게 구분해 활용해야 했습니다 — 세부 유저 단위 분석에는 애초에 쓸 수 없는 구조였습니다.
왜 '일자별 요약'이라는 형태로 귀결됐나
개인 식별 없이도 유의미한 신호를 주려면 분석 단위를 개인이 아니라 집계 단위(날짜·캠페인·매체 등)로 낮춰야 했습니다. 그 결과 Attribution Reporting API가 제공하는 정보는 "누가 전환했는지"가 아니라 "이 날짜, 이 캠페인에서 대략 몇 건이 전환됐는지"를 노이즈를 감안해 추정하는 일자별·차원별 요약 형태로 수렴했습니다. 이는 기존 정밀 매칭 기반 어트리뷰션 모델(라스트클릭, 데이터 기반 어트리뷰션 등)을 그대로 옮겨 쓸 수 없다는 뜻이기도 해서, 광고주들은 리포트 해석 방식 자체를 새로 배워야 하는 부담을 안았습니다.
지금 전환 추적 전략에서 이 개념을 어떻게 참고하나
이 API가 폐기되는 중이므로 신규 구축 대상은 아니지만, "노이즈가 섞인 집계 데이터를 어떻게 해석할 것인가"라는 문제의식은 여전히 유효합니다. 향후 유사한 프라이버시 보호형 측정 기술을 마주치면, 이벤트 단위 정밀 매칭을 기대하지 말고 처음부터 추세 파악용 집계 지표로 활용 범위를 좁혀 설계하는 접근이 필요합니다.
폐기 이후 기여도 측정 업계에 남은 과제
Attribution Reporting API가 폐기되면서, 서드파티 쿠키 기반 정밀 매칭이 당분간 계속 가능해졌다는 점은 실무자에게 다행스러운 소식처럼 보일 수 있습니다. 하지만 서드파티 쿠키 역시 브라우저 확장 프로그램의 차단, iOS 사파리의 자체 추적 제한(7강 참고) 등으로 매칭률이 100%에 도달한 적이 없었다는 사실은 그대로 남습니다. 즉 이 API의 폐기가 곧 '기여도 측정 문제가 다시 쉬워졌다'는 뜻은 아니며, 여전히 서버사이드 이벤트 전송, 퍼스트파티 식별자 활용, 미디어믹스모델링(MMM) 같은 보완 수단을 함께 갖추는 편이 안전합니다.
이 사례가 엔지니어링 조직에 남긴 실무 원칙
이 API처럼 특정 벤더가 주도한 스펙에 맞춰 전환 추적 파이프라인 전체를 새로 구축했던 조직들은, 폐기 발표 이후 그 투자를 되돌리거나 유지보수 없이 방치해야 하는 상황에 놓였습니다. 이런 경험은 향후 유사한 신규 측정 스펙이 등장했을 때, 전체 인프라를 한 번에 전환하기보다 기존 방식과 병행 운영하며 실제 채택률·안정성을 일정 기간 관찰한 뒤 단계적으로 비중을 옮기는 접근이 더 안전하다는 원칙으로 남습니다.