답변
브라우저 픽셀은 이용자의 브라우저 안에서 실행되는 자바스크립트 조각입니다. 사이트 페이지가 열리거나 장바구니 담기·구매 완료 같은 행동이 일어나면, 그 브라우저가 광고 매체 서버로 '이 사람이 이런 행동을 했다'는 신호를 직접 쏘아 보냅니다. 이 신호가 매체에서 전환으로 집계되고, 동시에 리타겟팅 모수로도 쌓입니다. 붙이기가 쉽다는 게 장점입니다 — 사이트 헤더에 스크립트를 넣거나 GTM으로 태그를 하나 만들면 마케터 선에서 끝납니다. 문제는 그 신호가 브라우저를 거쳐 나간다는 데 있습니다. 사파리를 비롯한 브라우저들이 추적 방지 기능으로 서드파티 쿠키를 차단하거나 쿠키 수명을 짧게 만들어서, 며칠 뒤 돌아온 사람을 같은 사람으로 못 알아보는 일이 생깁니다. 광고 차단 확장 프로그램을 쓰는 이용자에게는 픽셀 스크립트 자체가 로드되지 않습니다. iOS의 앱 추적 투명성(ATT) 정책 이후로는 앱에서 유입된 트래픽의 식별도 제한됩니다. 결과는 하나입니다 — 실제로 일어난 전환보다 매체 리포트 숫자가 적게 잡히는 전환 누락. 매체 대시보드의 구매 수가 자사 주문 관리 화면의 실제 주문 수보다 눈에 띄게 적다면 대개 이 문제입니다. 서버사이드는 그 신호를 브라우저가 아니라 우리 쪽 서버에서 매체 서버로 직접 보내는 방식입니다. 메타에서는 전환 API(Conversions API), 구글 쪽에서는 GTM 서버 컨테이너를 띄우는 서버사이드 태깅이 여기 해당합니다. 주문이 우리 데이터베이스에 실제로 기록된 시점에 서버가 이벤트를 보내니 브라우저 차단이나 확장 프로그램의 영향을 받지 않고, 이메일·전화번호 같은 식별자를 해시 처리해 함께 보내 매체가 사람을 매칭할 확률을 높입니다. 중요한 건 이 둘이 대체 관계가 아니라는 점입니다. 픽셀만 쓰면 누락이 생기고, 서버만 쓰면 브라우저에서만 잡히는 정보(페이지 이동 경로, 클릭 같은 앞단 행동)와 세팅의 편의를 잃습니다. 그래서 실무에서는 같은 전환을 양쪽에서 보냅니다. 그러면 구매 한 건이 두 건으로 잡히는 문제가 생기는데, 이를 막는 장치가 이벤트 ID를 이용한 중복 제거입니다. 브라우저와 서버가 같은 주문에 대해 동일한 고유 ID를 붙여 보내면 매체가 같은 이벤트로 인식해 하나로 합칩니다. 보통 그 주문에서만 유일한 값(주문번호 등)을 씁니다. 메타 이벤트 관리자의 진단 화면에서 중복 제거가 제대로 작동하는지 경고 형태로 확인할 수 있습니다. 난이도와 담당자도 갈립니다. 픽셀은 마케터가 GTM으로 붙일 수 있는 범위지만, 서버사이드는 개발 리소스가 필요합니다. 주문 완료 시점에 서버에서 API를 호출하는 코드를 넣거나, GTM 서버 컨테이너를 클라우드에 띄우고 운영 비용을 계속 부담해야 합니다. 카페24나 쇼피파이 같은 일부 솔루션은 앱·기본 연동 형태로 제공하기도 합니다. 그래서 주니어가 맡게 되는 일은 직접 구현이 아니라, 지금 우리 계정이 픽셀만 쓰는지 서버사이드가 붙어 있는지 확인하고 개발자에게 요청 사항을 정리해 넘기는 쪽입니다. 주니어가 실무에서 밟을 순서는 이렇습니다. 첫째, 메타 이벤트 관리자(또는 GA4 실시간 보고서)에서 지금 어떤 이벤트가 들어오는지 눈으로 봅니다. 둘째, 이벤트별 연결 방식이 브라우저인지 서버인지 둘 다인지 확인합니다. 셋째, 같은 기간의 매체 전환 수와 실제 주문 수를 나란히 놓고 격차를 잽니다. 넷째, 격차가 크면 그 숫자를 근거로 서버사이드 도입을 논의합니다. 다섯째, 도입 시 중복 제거 설정과 개인정보 처리(어떤 값을 해시해 보내는지, 동의를 받았는지)를 함께 확인합니다. 이 순서면 용어를 외우지 않아도 개발자·매체 담당자와 대화가 됩니다.