왜 픽셀 하나로는 더 이상 부족한가

메타 픽셀은 사용자의 브라우저가 웹페이지를 로드할 때 발생하는 자바스크립트 호출로 작동합니다. 이 구조는 필연적으로 브라우저 환경에 종속됩니다. 애플이 iOS 14.5부터 도입한 ATT(App Tracking Transparency)는 사용자에게 추적 동의 여부를 직접 묻는데, 2026년 기준 글로벌 평균 옵트인 비율은 15~25% 수준에 그칩니다. 대다수 iOS 사용자가 추적을 거부한다는 뜻이고, 이 상태에서 모바일 사파리 픽셀 추적은 실질적으로 작동하지 않습니다.

여기에 광고차단 확장 프로그램, 브라우저 자체의 추적 방지 기능(ITP 등)까지 겹치면 손실 폭은 더 커집니다. 업계 실측 비교에 따르면 픽셀 클라이언트사이드만 사용할 때 평균 매칭률은 71% 수준인 반면, 서버사이드 포스트백을 함께 적용하면 매칭률이 98% 이상으로 올라갑니다. 같은 트래픽, 같은 캠페인이라도 어떤 경로로 전환을 잡느냐에 따라 광고 플랫폼이 인식하는 성과 자체가 달라진다는 의미입니다.

CAPI는 정확히 무엇을 전송하는가

전환 API(Conversions API, CAPI)는 광고주의 서버, 웹사이트, 앱, CRM 시스템에서 마케팅 데이터를 메타 시스템으로 직접 전송하도록 설계된 서버사이드 전환 추적 솔루션입니다. 브라우저가 아니라 광고주가 관리하는 서버가 메타 서버로 HTTP 요청을 직접 보내는 구조이기 때문에, 사용자의 브라우저 설정이나 쿠키 상태와 무관하게 이벤트가 전달됩니다.

핵심은 픽셀과 CAPI가 경쟁 관계가 아니라 상호 보완 관계라는 점입니다. CAPI는 Purchase, Lead, AddToCart 같은 표준 이벤트와 커스텀 이벤트를 픽셀과 동일하게 지원하며, 서버사이드로 들어온 이벤트는 픽셀·Facebook SDK로 들어온 이벤트와 메타 시스템 내부에서 동일하게 처리됩니다. 즉 CAPI를 도입한다고 픽셀을 걷어내는 게 아니라, 같은 전환을 두 경로로 동시에 잡아 유실률을 서로 보완하는 구조로 가는 것이 표준입니다.

서버사이드 구조가 실제로 방어하는 지점

브라우저 기반 추적이 무너지는 지점은 크게 세 갈래입니다. 첫째는 ITP·쿠키 만료로 인한 fbp/fbc 쿠키 손실, 둘째는 광고차단 확장 프로그램의 스크립트 차단, 셋째는 iOS Safari의 ATT 거부입니다. 서버 간 통신(S2S)은 이 세 갈래 모두를 건너뜁니다. 사용자의 구매 완료 요청이 광고주 서버(예: 결제 완료 처리 서버)에 도달하는 순간, 그 서버가 별도로 메타 서버에 전환 이벤트를 쏘는 구조이기 때문에 브라우저 상태와 무관하게 데이터가 전달됩니다.

다만 이 구조가 전환을 '더 많이 만들어내는' 것은 아닙니다. 실제로는 일어난 전환인데 브라우저 경로로는 메타에 보고되지 못했던 것을 서버 경로로 복구하는 개념입니다. 그래서 CAPI 도입 초기에는 전환수가 갑자기 늘어나는 것처럼 보일 수 있는데, 이는 조작이 아니라 그동안 누락됐던 데이터가 정상적으로 잡히기 시작한 결과입니다.

도입 전 반드시 이해해야 할 전제 조건

CAPI를 붙인다고 자동으로 성과가 개선되는 것은 아닙니다. 픽셀과 CAPI를 동시에 운영하면 같은 사용자 행동이 두 경로로 중복 전송될 위험이 생기고, 이를 방치하면 전환수가 실제보다 부풀려져 오히려 머신러닝 최적화가 왜곡됩니다. 이 문제를 막는 장치가 event_id 기반 중복제거인데, 이 부분은 4강에서 별도로 다룹니다.

또한 CAPI의 효과는 광고주가 보유한 퍼스트파티 데이터의 양과 질에 크게 좌우됩니다. 이메일·전화번호·외부ID 같은 고품질 식별자를 얼마나 정확하게 전송하느냐가 이후 다룰 이벤트 매칭 품질(EMQ) 점수와 직결되기 때문에, CAPI 도입은 곧 자사 CRM·회원 데이터 정비 작업과 함께 가야 하는 프로젝트로 이해하는 편이 정확합니다.