서버사이드 전환 API와 브라우저 픽셀의 전환수가 서로 다르게 잡힐 때 어느 쪽을 기준값으로 삼아야 하는가

브라우저 픽셀은 사용자의 브라우저에서 이벤트를 보냅니다. 그래서 광고 차단기, 추적 거부, 쿠키 수명 제한, 페이지 이탈 같은 이유로 일부가 도달하지 못합니다. 전환 API는 광고주 서버에서 메타로 직접 보내므로 브라우저 환경의 영향을 받지 않습니다. 두 경로가 같은 주문을 보더라도 도달률이 다르니 숫자는 애초에 어긋납니다.

여기에 사파리의 추적 방지 정책이 겹칩니다. ITP는 자바스크립트로 만든 퍼스트파티 쿠키의 수명을 최대 7일로 제한하고, 광고 클릭 파라미터가 붙어 들어온 세션에서 만들어진 쿠키는 24시간으로 더 짧게 제한합니다. 브라우저 쪽 수집이 구조적으로 불리한 이유입니다.

서버 쪽 전환수가 더 크다면 대개 정상입니다. 브라우저에서 유실된 이벤트를 서버가 채우고 있는 상태입니다. 반대로 브라우저 쪽이 더 크다면 이상 신호입니다. 주문 완료 페이지가 새로고침·뒤로가기로 여러 번 열려 픽셀이 반복 발화하고 있거나, 단일 페이지 구조에서 화면 전환마다 이벤트가 다시 발동하고 있을 가능성이 높습니다.

두 값을 더한 수가 자사 주문 건수보다 크다면 중복 제거가 실패하고 있는 것입니다. 이때는 어느 쪽을 기준으로 삼느냐를 고민할 게 아니라 중복부터 잡아야 합니다.

픽셀도 전환 API도 결국 매체에 보고하기 위한 신호입니다. 매출을 확정하는 곳은 쇼핑몰 주문 데이터베이스이고, 최종적으로는 정산 데이터입니다. 매체 숫자를 기준값으로 삼으면 기여 기간이 바뀌거나 매체 정책이 바뀔 때마다 회사의 매출 인식이 함께 흔들립니다.

실무 감사 체크리스트도 같은 방향입니다. 사이트 전체 트래킹 코드를 매핑하고, 매체가 집계한 전환수를 주문·고객 데이터와 대조해 오차율을 산출하고, 모든 전환 이벤트에 고유 거래 ID를 부여하고, 매체별 중복 제거 설정을 확인하라고 정리합니다. 대조의 축이 항상 자사 데이터라는 뜻입니다.

픽셀과 전환 API가 같은 주문을 보낼 때는 두 이벤트에 같은 event_id를 실어야 메타가 하나로 합칩니다. 이벤트 관리자의 진단 탭에는 중복 제거된 이벤트 비율이 표시되고, 비율이 낮거나 event_id 형식에 문제가 있으면 경고가 뜹니다. 여기가 첫 확인 지점입니다.

서버 이벤트 자체가 잘 도착하는지는 이벤트 관리자의 테스트 이벤트 도구로 봅니다. 브라우저 확장 프로그램인 Pixel Helper는 클라이언트 단만 보여주기 때문에 서버 이벤트는 감지하지 못합니다. 이 도구로 아무 문제가 안 보인다고 해서 전환 API가 정상이라는 근거는 되지 않습니다.

전환 API만으로도 이벤트 전송은 됩니다. 다만 브라우저 쪽에서만 자연스럽게 수집되는 정보가 함께 사라집니다. 그래서 두 경로를 함께 쓰고 중복만 제거하는 구성이 일반적으로 권장됩니다. 유지 비용이 부담이라면 전환 API 구현 방식부터 다시 볼 수 있습니다. 원클릭 설정은 손이 거의 안 가지만 이벤트·파라미터를 고를 수 없고, 쇼핑몰 솔루션 연동은 토글 하나로 끝나며, 직접 구현은 통제 폭이 가장 넓은 대신 리소스가 듭니다.

솔루션 연동을 쓴다면 점검 항목이 하나 더 있습니다. 카페24는 메타 채널 설정을 마치면 픽셀과 전환 API가 함께 구성되는데, 액세스 토큰이 만료되면 전환 API 전송과 카탈로그 업데이트가 동시에 멈춥니다. 어느 날 갑자기 서버 전환이 0이 됐다면 토큰부터 확인하는 것이 빠릅니다.

운영 규칙은 두 줄이면 충분합니다. 매출과 ROAS의 확정 숫자는 자사 주문·정산 데이터로 계산하고, 매체 리포트는 소재·타겟 간 상대 비교와 알고리즘 학습용 신호로만 씁니다. 그리고 자사 데이터와 매체 데이터의 비율을 주 단위로 기록해, 그 비율이 흔들릴 때만 태그를 들여다봅니다. 이렇게 해두면 매체가 기여 정책을 바꿔도 회사 숫자는 그대로 유지됩니다.