Q. 메타 픽셀, gclid, 전환 API는 각각 뭘 하나요?
메타 픽셀은 웹사이트 방문자 행동을 관찰해 광고 플랫폼 서버로 전송하는 자바스크립트 코드다. gclid나 fbclid 같은 클릭ID는 광고 클릭 한 번마다 발급되는 추적번호로, 나중에 전환이 일어난 자리에서 이 클릭에서 온 사람이 맞는지 맞춰보는 데 쓰인다. 전환 API나 향상된 전환 같은 서버사이드 방식은 브라우저를 거치지 않고 광고주 서버가 플랫폼 서버로 직접 데이터를 보내, 쿠키 차단으로 픽셀이 놓치는 전환을 복구한다.
오늘 바로 쓸 핵심 3줄
- 내 사이트 head에 메타 픽셀 base code와 noscript 태그가 둘 다 들어가 있는지 확인.
- 구글 애즈 자동 태깅이 켜져 있고, Conversion Linker 태그가 심어졌는지 확인.
- 지금 잡고 있는 전환 액션이 실제 비즈니스 목표(구매·리드·계약)와 맞는지 점검.
코드는 심었는데, 그게 뭘 하는지는 아무도 안 알려준다
마케팅 대행사나 광고 플랫폼이 보내는 안내문은 보통 짧다. 이 스크립트를 <head> 태그 안에 넣어달라는 한 줄뿐. 개발자는 그 코드를 복사해 붙여 넣고, 마케터는 그게 픽셀을 심었다는 뜻이라고만 알고 넘어간다.
문제는 그다음이다. 광고 리포트에 찍히는 전환수, 구매 데이터, 이 캠페인이 매출을 얼마나 만들었냐는 질문에 답하려면 그 코드가 정확히 뭘 관찰하고 무엇을 어디로 보내는지 알아야 하는데, 모르면 숫자가 튀어도 원인을 못 짚는다.
그래서 이 글은 세 가지 질문에 순서대로 답하려 한다. 픽셀은 정확히 뭘 하나? gclid 같은 클릭ID는 왜 필요할까? 전환 API나 향상된 전환 같은 서버사이드 방식은 픽셀과 뭐가 다를까? 세 개를 따로 이해하고 나면, 그다음부터는 픽셀 심어달라는 말이 뭘 뜻하는지 안 물어봐도 된다.
픽셀의 정체, 눈에 안 보이는 1×1 이미지 하나
픽셀, 정확히는 트래킹 픽셀이라는 이름은 실제로 아주 작은 이미지에서 나왔다. 웹페이지나 이메일에 심는 가로세로 1픽셀짜리 투명 이미지, 대개 GIF 파일이다. 화면엔 아무것도 안 보이지만, 이 이미지가 로드되는 순간 브라우저가 서버로 요청을 보내고 서버는 그 요청을 기록한다. 다른 이름으로는 pixel tag, web beacon, web bug, clear GIF.
이 방식은 1990년대 web bug라는 이름으로 불리며, 눈에 안 띄게 사용자를 추적하는 기법으로 처음 등장했다. 1997년 쿠키가 표준화된 것과 맞물려 지난 20여 년간 웹 프라이버시 논쟁의 핵심 축이었으니, 지금 쓰는 모든 전환 추적 기술의 뿌리가 여기인 셈이다.
지금의 메타 픽셀은 겉보기엔 1x1 이미지가 아니라 자바스크립트 코드 조각이다. 사이트 방문자가 어떤 행동을 할 때마다 그 행동을 기록해 보내는 작은 함수 라이브러리를 불러오는 방식인데, 코드처럼 보여도 겁먹을 필요는 없다. 구조는 딱 둘로 나뉜다.
base code(스크립트)는 픽셀 ID로 초기화하고 페이지가 열릴 때마다 PageView 이벤트를 자동으로 하나 쏜다. noscript 코드는 자바스크립트가 꺼진 환경을 위한 대체 코드로 이미지 태그 하나로 PageView를 전송하는데, 이게 바로 원조 1x1 픽셀 방식의 흔적이다. 지금도 메타 픽셀 코드 맨 아래 그대로 남아 있으니 한번 스크롤해서 확인해볼 만하다.
브라우저에서 실행된 픽셀 태그가 이벤트를 광고 플랫폼 서버로 보내는 흐름
이벤트(event)는 픽셀이 보고하는 행동 하나, PageView·AddToCart·Purchase 같은 것들을 가리킨다. 파라미터는 그 이벤트에 붙는 세부정보로, Purchase 이벤트라면 결제 금액과 통화, 구매한 상품 번호가 함께 딸려온다. 픽셀은 이렇게 모은 이벤트를 페이스북이 심어둔 쿠키와 대조해 이 방문자가 어느 페이스북 계정과 같은 사람인지 매칭한다.
광고 클릭과 전환을 잇는 가장 단순한 원리
픽셀이 뭘 관찰하는지 알았으니, 이제 그 관찰 결과를 어느 광고 때문에 일어난 일인지 잇는 방법을 봐야 하는데, 구글 애즈의 전환 추적이 가장 기본적인 모델이다.
원리는 이렇다. 고객이 검색 결과나 디스플레이 광고를 클릭하면 그 기기에 임시 쿠키 하나가 심어지고, 고객이 나중에 정해둔 행동, 구매 완료나 폼 제출 같은 걸 하면 사이트에 심은 코드가 그 쿠키를 알아보고 이건 광고에서 온 전환이라고 기록한다.
설정은 딱 두 단계뿐이다. 구글 애즈 계정에서 전환 액션을 만들고, 사이트에 구글 태그(코드 스니펫)를 설치하면 끝. 전화 통화처럼 코드 설치 없이 잡히는 유형도 있지만, 대부분의 전환은 이 두 단계가 기본형이다.
여기서 이해해야 할 건 이거다. 광고 플랫폼은 클릭과 전환이 원래 따로 일어나는 두 사건이라는 걸 안다는 것. 클릭은 광고 서버에서, 전환은 내 사이트에서 일어나니까, 둘을 잇는 다리가 필요하다. 그게 바로 쿠키, 혹은 다음 장에서 다룰 클릭ID다.
이미지: 영수증 반쪽 맞추기, 클릭할 때 반쪽을 주고 전환이 일어나면 나머지 반쪽과 맞춰본다
영수증 반쪽 맞추기에 비유하면 이해가 쉽다. 광고를 클릭하는 순간 영수증을 반으로 찢어 한쪽을 손님 손에 쥐여준다고 생각해보자. 나중에 전환이 일어나면, 손님이 들고 있던 반쪽과 가게가 보관해둔 나머지 반쪽을 맞춰보는데, 두 조각의 찢긴 단면이 정확히 들어맞으면 같은 손님이라는 게 확인된다. 이게 매칭(matching)이다.
클릭마다 발급되는 추적번호, 클릭ID
앞 장의 쿠키는 사실 대부분 클릭ID(click ID)라는 형태로 구현되는데, 광고를 클릭하는 순간 URL 끝에 자동으로 붙는 긴 문자열이다. 구글은 이걸 gclid(Google Click Identifier)라고 부른다.
gclid는 구글 애즈의 자동 태깅(auto-tagging) 설정을 켜두면 자동으로 붙는데, 이 클릭이 어느 캠페인, 어느 광고그룹에서 왔는지에 대한 정보를 인코딩하고 있다.
문제는 이 gclid를 어디에 저장하느냐일 텐데, Conversion Linker라는 태그가 이 값을 랜딩 페이지 URL에서 자동으로 읽어 1st party 쿠키(내 사이트 도메인으로 찍힌 쿠키)와 브라우저 로컬 스토리지에 저장해둔다. 기본 쿠키 이름은 _gcl_aw, _gcl_gs.
왜 굳이 1st party 쿠키로 다시 저장할까? 사파리의 ITP(Intelligent Tracking Prevention, 지능형 추적 방지) 같은 브라우저 정책이 3rd party 쿠키(광고 플랫폼 도메인이 찍힌 쿠키)를 공격적으로 차단하기 시작했기 때문. 3rd party 쿠키가 막히면 광고 플랫폼은 이 사람이 아까 그 광고를 클릭한 사람이라는 걸 브라우저 너머로 기억할 방법이 없는데, Conversion Linker는 브라우저가 훨씬 오래 신뢰하는 1st party 쿠키에 클릭ID를 옮겨 담아 이 문제를 우회한다.
이미지: 클릭ID는 클릭 한 번마다 발급되는 고유 번호표다
실무에서 자주 부딪히는 함정이 하나 있는데, gclid 자체는 만료되지 않지만 이를 담아두는 _gcl_aw 쿠키는 기본값으로 약 90일 뒤 사라진다는 게 여러 마케팅 블로그에 공통으로 나오는 수치다. 다만 이 90일이라는 숫자는 구글 공식 지원 문서에서 이번 조사로 직접 재확인하지는 못했으니, 실무에 쓸 땐 약 90일 정도로만 참고하는 게 정직하다. 오프라인 전환을 가져오려면 이 창이 닫히기 전에 gclid를 업로드해야 한다.
오프라인 전환 매칭은 이렇게 3단계로 돈다. 광고 클릭 시 gclid가 URL에 자동으로 붙고, 사이트 코드가 이를 감지해 쿠키나 리드 폼 숨은 필드에 저장하고, 나중에 실제 계약 같은 오프라인 전환이 일어나면 그 사람의 gclid와 전환 데이터를 구글 애즈에 업로드해 매칭하는 흐름. 여기서 대소문자 함정도 하나 있는데, gclid는 대소문자를 구분하니까 업로드할 때 한 글자라도 틀리면 매칭이 실패한다.
메타 쪽도 구조는 똑같다. fbclid(Facebook Click Identifier)가 광고나 링크 클릭 시 URL에 자동으로 붙고, 메타 픽셀이 이를 _fbc 쿠키(형식은 fb.1.생성시각.fbclid값, 90일 유효)로 옮겨 저장하는 식. 이와 별개로 _fbp 쿠키는 픽셀이 자체적으로 발급하는 방문자 식별자로, 클릭이 아니라 방문 자체에서 생긴다. 둘 다 전환 이벤트가 발생하면 전환 API로 함께 전송돼 매칭 확률을 높이는 역할을 한다.
네이버 광고에도 이런 클릭ID 대응물이 있을까? 있다. NaPm이라는 파라미터가 비슷한 역할을 하는데, 정확히 어떻게 저장되고 얼마나 오래 남는지, UTM(광고 성과를 구분하는 URL 꼬리표)과 어떻게 유실되는지는 심화 실측 글에서 실제로 재보고 정리해뒀다.
클릭ID는 광고 클릭에서 발급돼 URL과 쿠키를 거쳐 전환 시점에 다시 대조된다
브라우저가 이 추적번호를 자꾸 놓치는 이유
지금까지 설명한 구조, 클릭ID를 쿠키에 저장하고 전환 시점에 맞춰본다는 이 구조는 전제가 하나 있다. 브라우저가 그 쿠키를 계속 들고 있어줘야 한다는 전제.
문제는 요즘 브라우저가 그 전제를 계속 깨고 있다는 점인데, 사파리의 ITP는 3rd party 쿠키뿐 아니라 자바스크립트로 심는 1st party 쿠키까지 수명을 짧게 깎고, 광고 차단 프로그램은 픽셀 스크립트 자체가 로드되지 못하게 막는다. 시크릿 모드는 아예 세션이 끝나면 쿠키를 통째로 지워버린다.
여기서 정직하게 밝혀둘 게 있다. iOS 사용자의 몇 퍼센트가 추적에서 빠진다거나 광고 차단 프로그램 사용률이 몇 퍼센트라는 식의 구체적인 수치는, 이번 조사에서 마케팅 대행사 블로그 수준의 2차 자료만 확인됐고 메타나 구글의 공식 발표 수치는 찾지 못했다. 그래서 이 글에는 그 숫자를 넣지 않았다. 확실한 건 정성적인 사실 하나뿐, 브라우저에서 실행되는 픽셀은 구조적으로 일부 전환을 놓친다는 것.
이게 바로 서버사이드 방식이 등장한 이유인데, 브라우저를 아예 거치지 않고 광고주의 서버가 광고 플랫폼의 서버로 직접 데이터를 보내면 브라우저의 쿠키 정책이나 광고 차단 프로그램은 애초에 끼어들 자리가 없어진다.
이미지: 브라우저 정책과 광고 차단이 픽셀 신호를 문 앞에서 되돌려 보낸다
브라우저를 거치지 않는 서버사이드 삼형제
서버사이드 전환 추적은 회사마다 이름이 다르지만 하는 일은 비슷하다. 크게 셋만 알아두면 충분하다. 메타의 전환 API, 구글의 향상된 전환, 구글의 오프라인 전환 가져오기.
브라우저 경로는 쿠키 제한과 광고 차단에 막히지만, 서버 경로는 광고주 서버와 플랫폼 서버가 직접 이어져 막힐 자리가 없다
전환 API(Conversions API, CAPI)는 메타가 제공하는 서버 대 서버 연결이다. 광고주의 서버, 웹사이트, 앱, CRM에서 나온 데이터를 광고주 쪽 서버가 직접 메타 시스템으로 보내는 방식인데, 서버에서 보낸 이벤트는 브라우저 픽셀이 보낸 이벤트와 똑같이 처리되어 측정과 최적화에 쓰인다. 설정은 픽셀 ID 확보, 비즈니스 계정 준비, 액세스 토큰 발급 같은 절차를 거친다.
향상된 전환(Enhanced Conversions)은 구글 쪽 방식인데 메커니즘이 조금 다르다. 서버끼리 이벤트를 주고받는 게 아니라 이메일이나 이름, 주소, 전화번호 같은 고객 개인정보를 SHA-256이라는 해시 알고리즘으로 암호화해 보내면, 구글이 그 해시값을 로그인한 구글 계정과 대조해 매칭하는 순서다.
이미지: 해시는 원본을 못 보여주고 도장 무늬만 대조하는 것과 같다
여기서 해시가 뭔지 짚고 가자. 해시는 원래 데이터를 일정한 규칙으로 뒤섞어 짧은 값으로 바꾸는 일방향 함수인데, 같은 입력을 넣으면 항상 같은 출력이 나오지만 그 출력만 보고 원래 입력을 거꾸로 계산해낼 방법은 없다. 신분증을 보여주는 대신 도장 무늬만 대조하는 것과 비슷하달까. 같은 이메일 주소면 항상 같은 도장 무늬(해시값)가 찍히니 같은 사람이라는 확인은 되지만, 그 무늬만 보고 원래 이메일이 뭐였는지 되짚을 수는 없다.
오프라인 전환 가져오기(Offline Conversion Import)는 앞 장에서 설명한 gclid 매칭 구조, 그 자체라고 보면 된다. 클릭 시 저장해둔 gclid를 실제 오프라인 전환, 계약 체결이나 매장 방문 후 결제가 일어난 시점에 함께 업로드하면 구글이 매칭해준다.
이미지: 브라우저를 거치지 않는 서버 대 서버 경로는 쿠키 정책의 영향을 받지 않는다
| 방식 | 무엇을 보내나 | 매칭 기준 | 대표 용도 |
|---|---|---|---|
| 전환 API(CAPI) | 서버 이벤트(구매·등록 등) 직접 전송 | event_id + 계정 매칭 | 온라인 전환 전반 |
| 향상된 전환 | 해시된 고객 개인정보(이메일 등) | 로그인 구글 계정과 해시 대조 | 웹 전환 + 리드 |
| 오프라인 전환 가져오기 | gclid + 전환 데이터 | gclid 문자열 일치 | 영업이 이어지는 오프라인 계약 |
같은 전환을 두 번 세지 않는 법
브라우저 픽셀과 서버사이드를 같이 켜두면 자연히 생기는 문제가 있는데, 같은 구매 하나를 픽셀도 보고하고 서버도 보고해서 결국 두 번 잡히는 것이다.
메타는 이걸 event_id 기반 중복 제거(deduplication)로 해결한다. 브라우저 픽셀이 보낸 eventID와 전환 API가 보낸 event_id가 같고, 동시에 이벤트 이름(event/event_name)도 같아야 같은 사건으로 판단하니, 두 조건이 다 맞아야 한다.
처리 방식은 단순한 편이다. 두 이벤트가 유의미하게 다르지 않으면 먼저 도착한 걸 남기고 나중 걸 버리는데, 다만 이 중복 제거는 첫 이벤트가 들어온 뒤 48시간 안에 들어온 이벤트에만 적용된다. 그 창을 넘기면 별개의 이벤트로 처리될 수 있으니, 픽셀과 전환 API에 같은 event_id를 실어 보내는 구현이 먼저 되어야 한다.
해시로 가려도 동의는 필요하다
향상된 전환 얘기를 들으면 이런 생각이 들 수 있다. 해시로 가렸으니 개인정보가 아니지 않느냐는 생각. 그런데 그렇지 않다, 해시는 원본을 못 보이게 가리는 장치지 그 값이 누구를 가리키는지까지 지워버리는 장치는 아니기 때문. 특히 전화번호처럼 조합 가능한 범위가 좁은 값은 해시를 걸어도 역으로 특정 인물과 이어붙일 여지가 남고, 한국법상으로도 이런 처리를 거친 데이터는 개인정보가 아닌 게 아니라 가명정보로 다뤄진다.
ad_user_data라는 매개변수로 광고 목적 사용자 데이터 전송 여부를 통제한다. 태그가 개인정보를 수집·전송하도록 설정돼 있어도, 필요한 동의(유럽처럼 동의 배너가 법적으로 필요한 지역이면 실제 동의)가 없으면 향상된 전환은 작동하지 않는다. 2024년 3월부터는 모든 구글 애즈 요청에 이 동의 신호(Consent Mode)를 함께 보내는 게 의무가 됐다.동의가 없는 지역에서는 구글이 통계적 모델링으로 그 공백을 메우는데, 이건 실측 데이터가 아니라 추정으로 채운 값이라는 걸 알고 리포트를 읽어야 한다.
오늘 확인할 것
원리는 여기까지, 이제 내 사이트에 대볼 차례다.
- 픽셀 설치: 내 사이트 head에 메타 픽셀 base code와 noscript 태그가 둘 다 들어가 있나? 개발자 도구 네트워크 탭에서 페이지뷰 요청이 실제로 나가는지 확인.
- 자동 태깅: 구글 애즈 계정에서 자동 태깅이 켜져 있나? 광고를 한 번 클릭해 랜딩 페이지 URL 끝에 gclid가 실제로 붙는지 확인.
- 전환 액션 정의: 지금 잡고 있는 전환 액션이 실제 비즈니스 목표(구매·상담 신청·계약)와 맞아떨어지나? 픽셀만으로 안 잡히는 전환이 있다면 서버사이드 연동을 검토.
그래도 하나만 챙긴다면, 이것.
픽셀은 보고, 클릭ID는 짝을 맞추고, 서버사이드는 브라우저가 놓친 걸 대신 채운다.
시리즈 안내. 이 글은 "디지털 마케팅 분석 입문" 시리즈 5편이다. 세션·쿠키·이벤트 같은 기초 개념은 1편: UTM 파라미터 기초와 GA4 시작하기에서, 픽셀 없이 광고 성과를 잡는 응용 기법은 다크 퍼널 추적법에서, gclid·NaPm이 실제로 어디서 얼마나 새는지 실측한 결과는 심화 편: UTM 추적 실측에서 이어서 다룬다.
근거·출처
- 트래킹 픽셀 정의·역사(2차 자료): Improvado, What Is a Tracking Pixel? · Ryte Wiki, Tracking Pixel
- 메타 픽셀 base code·이벤트 구조(1차): Meta Pixel Documentation · Get Started - Meta Pixel
- 구글 애즈 전환 추적 원리(1차): About conversion measurement
- gclid 정의·Conversion Linker(1차): Google Click Identifier (GCLID) · Conversion linker - Tag Manager Help
- 오프라인 전환 gclid 매칭(1차): Set up offline conversions using GCLID
- fbclid·_fbc·_fbp 파라미터(1차): ClickID and the fbp and fbc Parameters
- 전환 API 개요(1차): Conversions API - Meta for Developers
- 향상된 전환 개요(1차): Enhanced Conversions - Google Ads Help
- event_id 중복 제거 규칙(1차): Deduplicate Pixel and Server Events
- 동의 모드·향상된 전환 동의 요건(1차): About consent mode · Enhanced conversions consent
_gcl_aw 쿠키의 약 90일 만료, iOS 트래킹 제한으로 인한 정확한 손실 수치는 구글·메타 공식 문서에서 직접 확인하지 못해 이 글에 구체 수치로 넣지 않았다. SHA-256 해시가 원본 복원이 불가능한 일방향 함수라는 점은 확인했지만, 좁은 값 공간에서는 해시 처리 후에도 재식별 가능성이 남아 국내법상 개인정보가 아닌 가명정보로 취급된다는 점을 함께 밝힌다.
이 글이 도움이 되었다면 공유해주세요
최신 인사이트
카카오톡 공유 썸네일 안 나올 때 해결법 (Kakao JavaScript SDK 2025)
카카오톡 공유하기에서 썸네일 이미지가 안 나오는 원인과 scrapImage로 KAGE URL을 변환해 해결하는 방법을 단계별로 설명합니다. 지금 확인하세요.
Claude Code 서브에이전트로 CRM 사용자 설명서 20분 만에 완성하는 방법
Claude Code 서브에이전트를 활용해 CRM 코드베이스에서 사용자 설명서와 비주얼 가이드북을 20분 만에 자동 생성한 실전 사례를 공유합니다. 지금 확인하세요.
GEO 생성형 엔진 최적화: 2025년 AI 마케팅 전략 완전 가이드
GEO 생성형 엔진 최적화란 무엇이며 기존 SEO와 어떻게 다른지, 2025년 AI 마케팅 전략의 핵심 실행 방법 5가지를 데이터와 함께 알아보세요.
관련 프로젝트
새 글을 이메일로 받아보세요
마케팅, 분석, 개발 인사이트를 정리해서 보내드려요.