애플 사파리(Safari) PCM(Private Click Measurement) 프레임워크 대응: iOS 및 맥 OS 생태계 내 웹 광고 기여도 측정 한계와 매칭 룰 준수

구글의 Attribution Reporting API는 정책 반전 끝에 2025년 10월 폐기가 발표돼 크롬 144부터 제거되는 중입니다(5강 참고). 반면 애플의 PCM은 2021년 도입 이후 정책 방향이 흔들리지 않고 그대로 유지되고 있습니다. 애초에 애플은 서드파티 쿠키를 사파리에서 오래전부터 기본 차단해왔기 때문에, 구글처럼 '쿠키 폐지 여부를 두고 정책을 뒤집을' 대상 자체가 없었던 셈입니다. 이 때문에 사파리·iOS·맥OS 생태계를 다루는 실무자에게는 PCM이 구글의 실험적 API들보다 훨씬 오래, 훨씬 안정적으로 마주하게 될 제약 조건입니다.

PCM은 클릭 데이터를 서버로 보내지 않고 기기에서만 처리·저장한 뒤, 이후 전환이 발생하면 그 매칭 결과를 쿠키 없는 전용 프라이빗 브라우징 모드로 전송합니다. 이 과정에서 리포트 전송 시점이 24~48시간 사이에서 무작위로 지연되도록 설계돼 있어, 실무자는 실시간(당일) 전환 리포트를 기대할 수 없습니다. 캠페인 최적화 알고리즘이 즉각적인 신호를 필요로 하는 구조라면, PCM만으로는 충분한 속도의 피드백을 받기 어렵다는 점을 사전에 감안해야 합니다.

PCM이 다루는 범위는 웹-투-웹(사파리 내 사이트 간 클릭→전환), iOS 앱-투-웹(iOS 앱에서 클릭해 웹사이트로 이동 후 전환) 두 가지입니다. 이 범위 밖의 매칭(예: 앱-투-앱 전환, 실시간 세밀한 유저 단위 분석)은 PCM의 설계 목적에서 벗어납니다. 또한 리포트는 제한된 정보량(low entropy)만 담도록 설계돼, 구글 애즈·메타처럼 정밀 매칭 기반의 세밀한 기여도 리포트와 동일한 해상도로 비교하면 안 됩니다. 이 구조적 차이를 모르고 '왜 사파리 유입 전환은 이렇게 적게 잡히나'라고 판단하면, 실제로는 정상 작동 중인 것을 장애로 오인할 수 있습니다.

PCM은 광고 링크에 정해진 속성(클릭 소스 식별자 등)을 정확히 붙이고, 전환 페이지에서도 그에 대응하는 규칙을 정확히 지켜야 브라우저가 매칭을 시도합니다. 이 요구 조건은 6강에서 다룬 '엄격 검증형 API'의 특성과 동일한 패턴을 따릅니다 — 규칙을 일부만 지키면 일부만 작동하는 게 아니라, 정확히 지키지 못하면 해당 매칭 자체가 성립하지 않는 구조입니다. 따라서 사파리 유입 캠페인을 운영할 때는 링크 속성·전환 페이지 설정을 배포 직후 반드시 검증하는 절차가 필요합니다.

애플은 PCM을 자사 전용 기능에 그치지 않고 W3C Privacy Community Group에 제안해 다른 브라우저와 함께 웹 표준으로 만드는 작업을 진행 중이라고 공식 밝혔습니다. 이 흐름이 실제로 다른 브라우저의 채택으로 이어진다면, 지금 사파리 대응 차원에서 익혀둔 PCM의 설계 원리(온디바이스 처리, 지연 리포트, 제한된 정보량)가 다른 브라우저 대응에도 그대로 재사용될 가능성이 있습니다. 반대로 구글 Privacy Sandbox처럼 채택이 부진하면 사파리에 국한된 특수 케이스로 남을 수도 있습니다 — 이 진행도는 W3C Privacy CG 저장소에서 주기적으로 재확인이 필요한 미확인 영역입니다.

크롬·엣지처럼 서드파티 쿠키가 유지되는 브라우저와, 애초에 서드파티 쿠키를 기본 차단해온 사파리는 같은 캠페인 안에서도 서로 다른 측정 신뢰도를 갖게 됩니다. 크롬 트래픽은 쿠키 기반 정밀 매칭을 계속 활용할 수 있는 반면, 사파리 트래픽은 PCM의 제한된 정보량·지연 리포트 특성 때문에 구조적으로 낮은 해상도의 데이터만 얻을 수 있습니다. 이 차이를 하나의 통합 대시보드에서 동일한 신뢰도로 합산해버리면, 실제로는 브라우저별로 데이터 품질이 다른데도 마치 동일한 정밀도의 성과처럼 보이는 착시가 생길 수 있습니다. 리포트를 설계할 때는 최소한 브라우저·OS 단위로 데이터 출처를 구분해 표기하는 편이 안전합니다.

iOS 앱 광고와 사파리 웹 광고를 함께 운영하는 조직이라면, 앱 쪽은 애플의 앱 추적 투명성(App Tracking Transparency, ATT) 정책과 SKAdNetwork 같은 별도 체계를 따르고, 웹 쪽은 PCM을 따르는 이중 구조가 됩니다. 두 체계는 설계 목적(온디바이스 처리, 지연 보고)은 비슷하지만 세부 규칙과 리포트 형식이 다르므로, 앱과 웹의 기여도 데이터를 하나의 규칙으로 억지로 통합해 해석하면 오류가 생기기 쉽습니다. 두 체계를 별도 트랙으로 다루고, 통합이 필요하면 각 체계의 리포트 신뢰 구간을 먼저 이해한 뒤 상위 수준(예: 채널별 예산 배분)에서만 합산하는 접근이 안전합니다.