메타 픽셀이 제대로 작동하는지 확인하는 세 가지 방법

메타 픽셀이 작동하는지는 세 곳에서 확인합니다. 브라우저 확장은 페이지에서 픽셀 코드가 실행됐는지, 개발자도구 네트워크 탭은 facebook.com/tr 로 요청이 실제로 나갔는지, 이벤트 관리자 개요 탭은 메타 서버가 그 요청을 받았는지를 보여줍니다. 셋은 같은 것을 다른 각도에서 보는 게 아니라 서로 다른 단계를 보는 것이라, 하나만 초록이어도 나머지가 죽어 있을 수 있습니다.

1. 브라우저 확장: 코드 실행 여부

크롬 확장 「Meta Ads Data Advisor」를 설치하고 사이트를 엽니다. 예전 이름이 픽셀 헬퍼(Pixel Helper)였고, 이미 설치해 둔 것은 자동으로 업데이트됩니다. 검색은 아직 옛 이름으로 더 많이 들어오는데 같은 물건입니다.

확장 아이콘에 배지가 붙으면 픽셀을 감지한 것이고, 배지가 없으면 그 페이지에 픽셀이 없는 것입니다. 사이드 패널을 열면 픽셀 ID 와 발화한 이벤트, 함께 실린 파라미터가 보입니다. 상태는 색이 아니라 단어로 읽습니다.

이 확장이 보여주지 못하는 것이 둘 있습니다. 서버에서 보내는 전환 API(CAPI) 이벤트는 브라우저를 거치지 않아서 여기 뜨지 않습니다. 버튼 클릭에 붙인 이벤트도 사이트 구조에 따라 감지되지 않을 수 있다고 메타가 문서에 적어 두었습니다. 그래서 확장이 조용하다고 곧 결함은 아닙니다.

2. 네트워크 탭: 요청 발신 여부

확장 없이도 볼 수 있습니다. 브라우저에서 개발자도구(윈도우 F12, 맥 Option+Command+I)를 열고 네트워크(Network) 탭에서 facebook.com/tr 로 필터를 걸고 새로고침합니다.

이 주소가 픽셀의 수신 엔드포인트입니다. 메타 공식 기본 코드의 noscript 태그가 https://www.facebook.com/tr?id={픽셀ID}&ev=PageView&noscript=1 로 되어 있어서 코드 자체가 그 사실을 보여줍니다.

요청 한 건이 이벤트 한 건입니다. 확인할 것은 셋입니다.

• 응답 코드 200
• 요청 파라미터 id 와 내 픽셀 ID 의 일치
• ev 값과 기대한 이벤트 이름(PageView, Lead 등)의 일치

요청이 보이면 코드는 실행됐고 서버로 나간 것입니다. 요청 자체가 없으면 스크립트가 로드되지 않았거나 이벤트가 트리거되지 않은 것이라 확장 단계로 돌아갑니다.

3. 이벤트 관리자 개요 탭: 메타 수신 여부

앞의 둘은 내 브라우저에서 본 것입니다. 메타 쪽에 도착했는지는 이벤트 관리자에서 데이터 소스로 픽셀을 골라 「개요」 탭을 봅니다. 새 PageView 가 보이면 설치가 끝난 것입니다.

바로 안 보이는 것이 정상입니다. 메타 공식 문서는 설치 직후 이벤트가 보이지 않으면 몇 분 기다렸다 새로고침하라고 안내합니다. 전환 API 로 보낸 이벤트는 전송 시작 후 20분 이내에 확인할 수 있다고 별도로 적혀 있습니다.

같은 화면에 「테스트 이벤트」 탭이 있는데 용도가 다릅니다. 이 탭은 도구가 발급한 test_event_code 가 붙은 요청만 보여줍니다. 서버 이벤트를 붙일 때 그 코드를 페이로드에 넣어 도착하는지 보는 용도이고, 평소 방문자의 이벤트에는 그 코드가 없어서 이 탭에 나타나지 않습니다. 개요 탭이 비어 있는데 테스트 이벤트 탭만 보고 있으면 아무것도 안 잡힙니다. 반대로 테스트 코드가 붙은 이벤트도 버려지지 않고 실제 타게팅과 측정에 쓰이니 운영 코드에서는 지워야 합니다.

흔한 오판 세 가지

세 방법을 다 알아도 판정을 틀리는 지점이 있습니다. 앞의 둘은 저희가 직접 틀린 것이고, 셋째는 설정에서 자주 갈리는 것입니다.

자동화 도구로 재면 0건이 나온다

개발자가 픽셀을 검증할 때 자동화 브라우저로 사이트를 열고 facebook.com/tr 요청을 세는 방법을 씁니다. GA4 는 이 방법으로 잘 잡힙니다. 픽셀은 잡히지 않습니다.

2026년 8월 31일, 저희 사이트 오픈 검증에서 스크립트 로드, 픽셀 등록, 설정 수신까지 전부 정상인데 이벤트 로그가 비어 있고 facebook.com/tr 요청이 0건이었습니다. 콘솔 오류도 없었습니다. 픽셀 결함으로 보고 프로브를 여섯 종류 돌린 뒤에야, 광고가 실제로 돌고 있어 발화가 증명된 다른 픽셀을 같은 도구로 찔러 봤습니다. 그것도 0건이었습니다. 픽셀이 아니라 계측기가 장님이었던 것입니다.

9월 8일에 저희가 운영하는 다른 사이트에서 원인을 좁혔습니다. 한 사이트를 조건별로 재면 이렇습니다.

자동화 브라우저 · 기본 UA(HeadlessChrome)

0건

자동화 브라우저 · 실제 크롬 UA 명시

1건

모바일 기기 프로파일 (UA 포함)

1건

메타의 픽셀 스크립트가 자동화 브라우저를 감지하면 이벤트를 조용히 버리는 것으로 보입니다. 메타가 문서로 밝힌 내용은 아니고 위 실측에서 나온 결론입니다. GA4 는 그러지 않기 때문에 「GA 는 되는데 픽셀만 죽었다」로 읽힙니다. 이 착시 때문에 저희는 콘텐츠 보안 정책(CSP)이 원인이라고 오진하고 정책을 통째로 벗겨 다시 재기까지 했습니다. 그래도 0건이었습니다.

판정법은 대조군입니다. 발화가 증명된 픽셀을 같은 도구로 찔러서 그것도 0이면 도구 탓이고, 대조군만 발화하면 진짜 결함입니다. 그리고 사람이 실제 브라우저로 방문한 뒤 개요 탭을 보는 것이 자동화가 대체하지 못하는 최종 확인입니다.

콘솔의 보안 정책 오류가 픽셀 오류로 보인다

실제 브라우저로 열면 콘솔에 Refused to connect ... Content Security Policy 오류가 뜰 때가 있습니다. 픽셀 스크립트가 facebook.com/tr 외에도 sl-<무작위>.ecs.us-east-1.on.aws 나 <무작위>.run.app 같은 호스트로 부가 요청을 보내는데, 사이트의 보안 정책이 그 호스트를 허용하지 않으면 차단됩니다.

2026년 9월 9일 저희가 운영하는 사이트 세 곳에서 확인한 결과, 그 부가 요청은 막혀 있었지만 본선인 facebook.com/tr 은 세 곳 모두 정상 발화했고 서버 전환 API 는 영향이 없었습니다. 호스트가 무작위라 좁게 열 수 없고 *.on.aws 전체를 허용하는 것은 정책의 존재 이유를 깎는 일이라 열지 않기로 했습니다. 콘솔 오류가 있다는 것과 픽셀이 죽었다는 것은 다른 문장입니다. 판정은 facebook.com/tr 과 개요 탭으로 합니다.

브라우저 픽셀과 서버 이벤트를 각각 세면 두 배가 된다

전환 API 를 같이 쓰면 문의 한 건이 브라우저와 서버에서 각각 한 번씩 메타로 갑니다. 메타는 브라우저의 eventID 와 서버의 event_id 가 같고 이벤트 이름도 같을 때만 둘을 하나로 합칩니다. 창은 48시간입니다.

그래서 확장이나 네트워크 탭에서 Lead 가 한 번 보이는데 이벤트 관리자에 두 건으로 잡히면 중복 제거 설정을 봅니다. 반대로 광고 차단기가 켜진 브라우저에서는 대개 픽셀 요청이 나가지 않고 서버 이벤트만 도착하는데, 메타 문서는 전환 API 가 광고 차단기와 로딩 오류의 영향을 픽셀보다 덜 받는다고 적어 두었습니다. 그 경우는 결함이 아니라 서버 경로가 제 몫을 한 것입니다.

우리 점수도 같은 표에 올립니다

이 글의 앞 두 오판은 저희가 2026년 8월 31일, 9월 8일, 9월 9일에 차례로 겪은 것입니다. 8월 31일에는 픽셀 결함으로 오진해 프로브 여섯 종류를 돌렸고, 9월 8일에는 보안 정책을 원인으로 오진해 정책을 벗기고 대조까지 했고, 9월 9일에는 콘솔 오류를 결함으로 볼지 판정해야 했습니다. 앞의 두 날이 첫 번째 오판이고 마지막 날이 두 번째입니다.

세 번 다 마지막 판정은 사람이 실제 브라우저로 방문해 facebook.com/tr 요청과 개요 탭을 보는 것으로 끝났습니다. 그래서 저희 검증 절차에는 「자동화 도구는 배관(주입·로드·등록)까지만 보고, 발화는 사람이 본다」가 적혀 있습니다.

홈페이지를 만든 쪽에 픽셀이 붙어 있다는 말을 들었다면, 위 세 곳 중 어디까지 확인했는지 물어보세요. 확장까지인지, 개요 탭까지인지에 따라 확인의 무게가 다릅니다.