📖 약 18분 읽기

서버 전환 연동을 검토하다 보면 가장 먼저 막히는 지점은 정보 자체가 아니라 정보의 형태입니다. 매체마다 공식 문서가 따로 있고, 문서마다 용어가 다르고, 국내 블로그 글들은 작성 시점이 제각각이라 서로 다른 결론을 내놓습니다. 네이버가 서버 전송을 지원한다고 쓴 글도 있고, 지원하지 않는다고 쓴 글도 있습니다. 카카오 Conversion API가 모든 광고 상품에 적용된다고 설명하는 글도 눈에 띕니다.

이런 혼선 속에서 담당자가 할 수 있는 가장 확실한 일은 공식 문서를 하나씩 열어 확인한 날짜를 남기고, 확인하지 못한 부분은 비워 두는 것입니다. 이 글은 국내외 광고 매체 열 곳의 전환 API 지원 범위를 그 원칙 그대로 정리한 표입니다.

비교는 다섯 가지 기준으로만 봅니다

첫 번째는 브라우저 픽셀 지원 여부입니다. 스크립트를 삽입해 브라우저에서 이벤트를 쏘는 방식이 아직도 가장 널리 쓰이지만, 브라우저 정책이 바뀌면 데이터가 끊기기 쉽다는 한계가 있습니다. 두 번째는 서버 전송 지원 여부입니다. 서버에서 직접 전환 이벤트를 보내면 브라우저 차단의 영향을 덜 받지만, 매체가 서버 전송용 API를 공식적으로 열어 두었는지가 먼저 확인돼야 합니다.

세 번째는 적용 가능한 광고 상품입니다. 같은 매체라도 광고 상품별로 지원 범위가 다른 경우가 있어서, 이 부분을 생략하면 실제로는 쓸 수 없는 기능을 쓸 수 있다고 오해하게 됩니다. 네 번째는 전송 가능한 식별자입니다. 이메일, 전화번호, 광고 클릭 ID처럼 매체가 요구하는 값이 서로 다르고, 해시 처리 여부도 매체마다 규정이 다릅니다. 다섯 번째는 중복 제거 방식입니다. 픽셀과 서버 전송을 함께 쓰면 같은 전환이 두 번 집계될 위험이 있는데, 이를 막는 방법이 매체별로 다르기 때문에 반드시 확인해야 하는 항목입니다.

국내 매체: 네이버·카카오·당근·토스는 어디까지 왔나

네이버는 검색광고(SA) 프리미엄로그분석과 성과형디스플레이광고(GFA) 전환추적 모두 wcslog.js 스크립트를 설치하는 브라우저 기반 방식으로 안내되어 있습니다. 공식 가이드 어디에도 서버-투-서버 방식에 대한 언급이 없습니다. 그래서 네이버에 대해 서버 전송이 없다고 단정하기보다는, 공식 문서에 안내가 없다고 표현하는 것이 정확합니다. 문서에 없다는 사실과 기능이 없다는 사실은 다르기 때문입니다.

카카오는 이 지점에서 눈에 띄는 진전을 보입니다. Conversion API를 서버-투-서버 방식으로 제공하며, 전송 가능한 식별자는 해시 이메일(hem), 해시 연락처(hpn), 모바일 광고 ID(adid), 카카오 클릭 ID(kclid) 네 가지입니다. 이메일과 연락처는 SHA256으로 해시해서 전달해야 하고, 생년월일이나 주소, 내부 고객번호, 계정 ID, 주민등록번호처럼 회원을 직접 식별할 수 있는 정보는 전송할 수 없습니다. 다만 현재 적용 범위는 카카오톡 모바일 비즈보드와 디스플레이 광고에 한정되어 있고, 향후 확대될 예정이라고 안내되어 있을 뿐입니다. 카카오의 모든 광고 상품에 적용된다고 설명하는 자료가 있다면 그 부분은 걸러서 봐야 합니다. 픽셀이나 SDK와 함께 쓸 경우 중복 처리는 카카오 내부 알고리즘이 담당합니다.

당근은 공식 전환 추적 가이드에서 웹 스크립트 삽입과 모바일 앱 트래커(MAT) 연동 두 가지만 안내하고 있습니다. 서버 전송 방식에 대한 언급은 찾을 수 없었습니다. 명시된 이벤트는 ViewContent, AddToCart, Purchase 등입니다. 토스는 토스 픽셀, 즉 스크립트 기준으로 안내됩니다. 전환 코드는 토스애즈 대시보드에서 광고 계정마다 발급받아야 하고, SDK 스크립트는 async나 defer 없이 이벤트 코드보다 먼저 로딩되어야 한다는 조건이 붙습니다. 이 역시 공식 가이드에 서버 전송 방식 안내는 없습니다.

해외 매체: 메타·구글·틱톡·엑스·크리테오의 서버 전송 방식

해외 매체로 넘어가면 서버 전송 자체는 대부분 지원되지만, 세부 규정이 매체마다 꽤 다르다는 점이 눈에 들어옵니다. 메타는 Conversions API를 제공하며, 고객 정보 매개변수 중 em, ph, fn, ln, db, ge, ct, st, zp, country는 해시가 필수입니다. external_id는 해시가 권장되는 수준이고, client_ip_address와 client_user_agent, fbc, fbp 등은 해시하지 않고 그대로 전달합니다. 중복 제거는 픽셀의 eventID와 API의 event_id가 이벤트 이름과 함께 일치할 때 작동하며, 첫 이벤트 수신 후 48시간 이내 도착한 이벤트만 대상이 되고 그중 먼저 받은 이벤트가 남습니다.

구글은 향상된 전환과 오프라인 전환 가져오기를 통해 서버에서 전환을 보낼 수 있고, 식별자는 해시 처리해서 전달합니다. 중복 제거는 거래 ID(transaction ID)를 기준으로 하는데, 같은 전환 액션에 같은 거래 ID가 두 번 들어오면 두 번째 값은 집계에서 빠집니다. 이 거래 ID는 백엔드에서 건별로 동적으로 생성해야 하며, 기간 제한은 공식 문서에 명시되어 있지 않습니다.

틱톡은 Events API를 제공하는데, 픽셀과 API 양쪽에 동일한 event_id를 보내야 중복 제거가 작동합니다. 첫 이벤트로부터 5분 이후 48시간 이내에 도착한 이벤트가 병합·제거 대상이 되고, 먼저 받은 이벤트가 기록으로 남습니다. 엑스(X)는 Conversion API를 픽셀 없이도 쓸 수 있다는 점이 특징입니다. 식별자는 X 클릭 ID(twclid, 해시 불필요), 이메일(SHA256 필수), 전화번호(E.164 표준, SHA256 필수), IP 주소, User Agent이며 이 중 최소 하나는 필수로 전달해야 합니다. IP 주소와 User Agent는 단독으로는 쓸 수 없고 다른 식별자와 함께 보내야 합니다.

크리테오는 성격이 조금 다릅니다. 서버로 보내는 경로 자체는 있지만, 규격이 공개되어 있지 않습니다. 크리테오 도움말의 전환 이벤트 안내는 이벤트를 “OneTag 또는 S2S”로 넘기라고 적고 있어 서버 전송 경로의 존재는 확인됩니다. 그런데 크리테오 개발자 문서는 Marketing Solutions, Retail Media, Retailer Integration 세 묶음으로 되어 있고, 그 어디에도 광고주가 전환을 서버로 보내는 API의 엔드포인트나 매개변수 규격이 공개되어 있지 않습니다. 파트너 연동 문서들이 Criteo Conversions API(Events API라고도 부릅니다)를 다루기는 하지만, 이용하려면 크리테오에 직접 요청해 승인을 받아야 한다고 안내합니다. 오프라인 전환을 올리는 별도 프로그램 역시 크리테오 승인을 전제로 하며, 개인 식별자를 최소 하나 포함할 것, 전환 발생 후 30일 안에 올릴 것 같은 조건이 붙습니다. 그래서 이 표에서는 크리테오를 “경로는 있으나 공개 규격 없음, 승인 필요”로 적고 세부 항목은 비워 둡니다. 실제로 검토하신다면 계정 담당자에게 규격 문서를 요청하는 것이 첫 단계입니다.

새로 등장한 채널, ChatGPT(OpenAI Ads)는 어디까지 지원하나

광고 매체 목록에 새로 이름을 올린 ChatGPT(OpenAI Ads)는 측정 픽셀과 Conversions API를 모두 제공합니다. 픽셀은 랜딩 페이지 URL에서 oppref 값을 자동으로 받아 퍼스트파티 쿠키 __oppref에 저장하는 방식으로 동작하므로, 이 값을 따로 설정할 필요가 없습니다. 중복 제거는 픽셀 ID와 이벤트 이름, event_id 조합을 키로 삼아 먼저 받은 이벤트를 채택하고 이후 들어오는 중복 이벤트는 무시하는 방식입니다.

표를 어떻게 읽고 우선순위를 정할까

표를 앞에 두고 나면 자연스럽게 다음 질문이 생깁니다. 열 개 매체를 한 번에 다 붙일 수는 없으니, 어디부터 손을 대야 할까요. 원칙은 단순합니다. 서버 전송이 이미 공식적으로 열려 있는 매체부터 검토하고, 그중에서도 광고비 비중이 큰 곳을 먼저 붙이는 순서입니다.

메타와 구글처럼 서버 전송 지원 범위가 넓고 문서가 안정적인 매체는 우선순위를 앞에 둘 수 있습니다. 반면 카카오처럼 지원 범위가 특정 광고 상품에 한정된 경우에는, 실제로 그 상품을 집행하고 있는지를 먼저 확인한 뒤 순서를 정해야 합니다. 지원 범위를 오해하고 먼저 붙였다가 실제로는 적용되지 않는 상품이었다는 사실을 뒤늦게 알게 되는 경우를 막기 위해서입니다. 크리테오처럼 규격이 공개되어 있지 않은 매체는, 붙이는 작업보다 계정 담당자에게 규격과 이용 조건을 받아 두는 일이 먼저입니다.

지원되지 않는 구간은 무엇으로 메우나

표에서 서버 전송이 미지원 혹은 공개 규격 없음으로 표시된 구간이 실제 구축 과정에서는 더 중요한 부분입니다. 네이버, 당근, 토스처럼 스크립트 기반으로만 안내되는 매체는 태그 관리 정확도로 데이터 품질을 지켜야 합니다. 태그가 잘못된 위치에 설치되거나 이벤트 조건이 틀리면 애초에 서버 전송 여부와 무관하게 데이터 자체가 흔들리기 때문입니다. 그래서 이 구간에서는 태그를 심는 것보다 심은 태그를 꾸준히 검수하는 작업이 더 큰 비중을 차지합니다. 당근처럼 앱 환경에서 MAT 연동만 안내되는 구간은 모바일 앱 트래커 연동으로 대응하는 방법이 현재로서는 유일하게 문서화된 경로입니다.

결국 표에서 미지원으로 표시된 칸을 어떤 대안으로 메우는지가 실제 구축의 핵심입니다. 지원되는 매체는 API 연동 작업으로 해결되지만, 지원되지 않는 매체는 태그 설계와 검수 체계로 데이터 품질을 지켜야 하고, 이 두 가지 작업은 성격이 완전히 다릅니다. 하나의 표에 열 개 매체를 나란히 놓고 보면 이 차이가 명확하게 드러납니다.

확인 방법과 재확인을 권하는 이유

이 정리에 담긴 사실은 모두 2026년 9월 1일과 2일 각 매체의 공식 문서에서 확인한 내용입니다. 네이버 광고 웹 전환 추적 스크립트 가이드, 카카오비즈니스 Conversion API 안내, 당근 비즈스쿨 전환 추적 가이드, toss ads 광고주 가이드, 메타 개발자 문서의 Conversions API 매개변수와 중복 제거 문서, 구글애즈 고객센터의 거래 ID 안내, 틱톡 광고 고객센터의 이벤트 중복 제거 안내, X Ads API 웹 전환 문서, OpenAI Ads 측정 픽셀 문서, 그리고 크리테오 도움말의 전환 이벤트 안내와 크리테오 개발자 문서 색인입니다.

다만 광고 매체의 정책은 자주 바뀌는 편이라, 이 글을 참고해 실제 연동을 진행하기 전에는 해당 매체의 최신 공식 문서를 다시 확인하는 것을 권합니다. 특히 카카오처럼 적용 범위가 확대될 예정이라고 안내된 항목이나, 크리테오처럼 규격이 공개되어 있지 않아 담당자를 거쳐야 하는 항목은 시간이 지나면서 내용이 바뀔 가능성이 있습니다. 확인하지 못한 부분을 추정으로 메우지 않고 확인한 만큼만 적는 편이, 나중에 잘못된 전제 위에서 연동 작업을 진행하는 것보다 낫다고 판단했습니다.