전환 API 연동, 데이터 유실 줄이는 법

전환 API(CAPI)란 무엇이고 왜 필요한가

전환 API(Conversion API, CAPI)는 웹사이트나 앱에서 발생한 이벤트 데이터를 브라우저를 거치지 않고 서버에서 서버로 직접 전송하는 연동 방식입니다. 기존의 광고 픽셀(웹 브라우저에 심는 추적 스크립트)만으로는 광고 차단 프로그램, 브라우저의 쿠키 정책, 인앱 브라우저 환경 등에서 이벤트가 유실되는 일이 잦아지면서, 이를 보완하기 위해 등장한 서버 사이드 트래킹 기술입니다.

브라우저 기반 픽셀의 구조적 한계

픽셀은 사용자의 브라우저와 쿠키를 거쳐 광고 플랫폼 서버로 데이터를 전송합니다. 이 과정에서 광고 차단 확장 프로그램(애드블록), 브라우저의 추적 방지 기능(ITP 등), 사용자의 쿠키 삭제, 네트워크 오류 등 여러 지점에서 데이터가 끊길 수 있습니다. 특히 모바일 인앱 브라우저나 개인정보 보호가 강화된 브라우저 환경에서는 픽셀 신호가 아예 도달하지 못하는 경우도 있습니다.

서버 간 직접 전송이 주는 안정성

전환 API는 브라우저를 경유하지 않고 자사 서버가 광고 플랫폼 서버로 이벤트를 직접 전송하므로, 브라우저 정책 변화나 광고 차단 도구의 영향을 상대적으로 덜 받습니다. 다만 전환 API가 픽셀을 완전히 대체하는 개념은 아니며, 두 방식을 함께 운영할 때 서로 다른 경로에서 발생하는 유실을 상호 보완할 수 있습니다.

데이터 유실이 실제로 발생하는 주요 원인

전환 API를 도입했는데도 데이터가 여전히 새는 경우, 원인은 크게 두 갈래로 나뉩니다.

구조적으로 피할 수 없는 자연 유실

• 광고 차단 확장 프로그램이 설치된 브라우저
• 애플 ATT(App Tracking Transparency) 등 앱 추적 동의 거부
• 서드파티 쿠키 차단 브라우저 정책
• VPN·프록시 사용으로 인한 IP·지역 정보 왜곡

이런 유실은 연동 설정을 아무리 잘해도 100% 막을 수는 없습니다. 다만 전환 API를 픽셀과 병행하면, 픽셀에서 놓친 이벤트를 서버 쪽에서 잡아낼 확률이 높아집니다.

연동 설정 실수로 생기는 유실

• 이벤트 이름·파라미터가 픽셀과 서버 API 간에 불일치
• 필수 매칭 파라미터(이메일 해시, 전화번호 해시 등) 누락
• 이벤트 발생 시각과 서버 전송 시각의 시간차가 너무 큼
• 테스트 이벤트 코드가 운영 환경에 남아 있어 데이터가 검증 도구로만 흘러감

일부 사례에서는 픽셀 단독 운영 시 전환 데이터의 15~30% 가량이 누락된다는 보고도 있습니다(해외 리테일 업계 사례 기준). 정확한 손실률은 업종·트래픽 환경마다 다르므로, 자사 데이터를 직접 비교 검증하는 과정이 필요합니다.

유실을 줄이는 실전 체크리스트

fbp·fbc 파라미터를 놓치지 않기

fbp는 브라우저 쿠키에 저장되는 고유 식별값으로 사용자의 브라우저 환경을 구분하고, fbc는 광고 클릭과 전환을 연결하는 값입니다. 이 두 파라미터를 서버 이벤트 전송 시 함께 넘기지 않으면, 픽셀 이벤트와 서버 이벤트가 별개의 이벤트로 중복 집계되거나 광고 기여도 분석이 부정확해질 수 있습니다.

이벤트 중복 제거(Deduplication) 설정

같은 전환(예: 구매 완료)이 픽셀과 전환 API 양쪽에서 동시에 전송되면 광고 플랫폼은 이를 두 건으로 잡을 위험이 있습니다. 이를 막으려면 이벤트마다 고유한 event_id를 부여하고, 픽셀과 서버 이벤트가 동일한 event_id를 공유하도록 구현해야 합니다. 대부분의 광고 플랫폼은 event_id가 같으면 중복 이벤트로 자동 인식해 하나로 처리합니다.

구분	픽셀(브라우저)	전환 API(서버)
전송 경로	브라우저→쿠키→광고 서버	자사 서버→광고 서버
광고 차단 영향	영향 받음	영향 적음
구현 난이도	스크립트 삽입 위주로 비교적 단순	서버 개발 리소스 필요
권장 운영 방식	단독 사용 지양	픽셀과 병행 설치 권장

서버사이드 태깅과 함께 설계하기

왜 서버사이드 태깅과 묶어서 봐야 하나

전환 API는 결국 ‘어느 서버가 이벤트를 언제, 어떻게 정제해서 보내는가’의 문제이기 때문에, 서버사이드 태깅 서버(예: GTM 서버 컨테이너)를 함께 구성하면 이벤트 정제·파라미터 매핑·중복 제거 로직을 한곳에서 관리할 수 있어 유지보수가 훨씬 수월해집니다. 서버사이드 태깅 전환을 처음 검토한다면 서버사이드 태깅 GTM 마이그레이션 가이드를 함께 참고하면 도움이 됩니다.

연동 후 반드시 확인해야 할 것

1. 광고 플랫폼의 이벤트 관리자 도구에서 픽셀·서버 이벤트가 각각 정상 수신되는지 확인
2. 동일 전환 이벤트의 중복 집계 여부를 이벤트 매칭 품질 지표로 점검
3. 매칭 품질 점수(이메일·전화번호 해시 매칭률)를 주기적으로 모니터링
4. 테스트 이벤트 코드를 운영 배포 전 반드시 제거

자주 묻는 질문

Q. 전환 API만 설치하고 픽셀은 제거해도 되나요?

권장하지 않습니다. 픽셀과 전환 API는 서로 다른 경로에서 데이터를 수집하기 때문에, 한쪽만 운영하면 그 경로에서만 발생하는 유실을 보완할 수 없습니다. 대부분의 광고 플랫폼은 두 방식을 함께 설치하는 것을 공식적으로 권장합니다.

Q. 중복 이벤트가 계속 잡히는데 원인이 뭔가요?

가장 흔한 원인은 픽셀과 서버 이벤트에 서로 다른 event_id가 부여되는 경우입니다. 동일한 전환 행위라면 픽셀과 서버 양쪽에 완전히 동일한 event_id 값을 전달해야 광고 플랫폼이 중복으로 인식해 하나로 합쳐 처리합니다.

Q. 매칭 품질 점수는 어떻게 확인하나요?

대부분의 광고 플랫폼은 이벤트 관리자(또는 이벤트 매니저) 도구 안에 매칭 품질 지표를 제공합니다. 이메일·전화번호·외부 ID 등 해시 파라미터가 얼마나 정확히 매칭되는지를 점수로 보여주며, 점수가 낮으면 파라미터 누락이나 해시 처리 오류를 먼저 점검해야 합니다.

Q. 데이터 유실률을 정확히 측정하려면 어떻게 해야 하나요?

픽셀 단독 전환 수와 전환 API 포함 전환 수를 같은 기간으로 비교해 격차를 확인하는 방법이 가장 기본적입니다. 다만 업종·트래픽·디바이스 구성에 따라 차이가 크므로, 외부 통계를 그대로 적용하기보다 자사 데이터로 직접 비교하는 것이 정확합니다.

Q. 전환 API 연동에 개발 리소스가 얼마나 필요한가요?

서버 환경과 기존 인프라에 따라 편차가 큽니다. 이미 서버사이드 태깅 서버를 운영 중이라면 이벤트 전송 로직 추가 수준으로 비교적 빠르게 구현할 수 있지만, 처음부터 서버 환경을 구축해야 한다면 개발·검증 기간을 넉넉히 확보하는 것이 안전합니다.