증상은 이렇습니다. 이벤트 관리자(Events Manager)에 주문 시스템이나 CRM이 일치시킬 수 없는 Purchase나 Lead가 표시됩니다. 한 광고주는 트래픽 광고에서 하루 동안 구매 105건이 생겼는데 스토어 주문은 0건이었다고 보고했습니다(스토어 플랫폼 커뮤니티 스레드, 2023년 12월 25일 시작, 광고주 보고). 이런 차이는 일어나지 않은 이벤트나 추적 버그를 가리킵니다. 실제 부정 행위는 주문이나 리드가 존재하므로 차이를 남기지 않고, 나중에 환불 요청(차지백)이나 연락이 닿지 않는 리드로 드러납니다. 봇과 무효 트래픽이 애초에 Meta 광고에 어떻게 도달하는지는 Meta 광고 부정 클릭 가이드부터 읽어 보세요.
확인 방법. 광고 계정에서 테스트는 하지 않았습니다. Meta의 동작은 2026년 11월 12일에 읽은 Meta for Developers 페이지에서, 광고주 사례는 날짜가 있는 커뮤니티 스레드에서 가져왔습니다.
가짜 Meta 픽셀 이벤트는 어떻게 만들어지나요?
의심스러운 이벤트의 원인은 세 가지입니다. 일어나지 않은 이벤트(스크립트나 헤드리스 브라우저가 픽셀을 발생시킴), 실제 이벤트를 만드는 진짜 부정 행위(카드 테스트 주문 등), 추적 버그(중복 설치, 잘못 실행되는 설정 규칙, 남아 있는 test_event_code)입니다. 하나의 질문으로 대부분 분류됩니다. 주문 시스템이나 CRM에 기록이 있나요? 기록이 없고 자신의 페이지에서 이벤트가 재현되면 버그, 기록이 없고 재현되지도 않으면 일어나지 않은 이벤트, 부정 기록이 있으면 실제 부정 행위입니다.
Meta의 최신 문서는 이벤트 저장소를 데이터 세트라고 부릅니다. Meta 픽셀은 브라우저 이벤트를, Meta 전환 API는 서버 이벤트를 데이터 세트로 보내고, 이벤트 관리자는 둘 다 보여 줍니다. 픽셀은 ID가 페이지 소스에 그대로 드러나는 공개 스크립트입니다. Meta는 Purchase를 “구매가 이루어졌거나 결제 과정이 완료되었을 때”로 정의하고, 이 이벤트에는 currency와 value가 필수라고 안내합니다(Meta 픽셀 레퍼런스). 이 호출 어디에도 구매가 실제로 일어났다는 증거는 없습니다.
일어나지 않은 이벤트. 픽셀을 실행할 수 있는 스크립트라면 어떤 금액으로든 fbq('track', 'Purchase')를 호출할 수 있습니다. 헤드리스 브라우저는 눈에 덜 띄게 같은 일을 하며, 사람이 일으킬 이벤트를 발생시킵니다.
실제 부정 행위. 도용된 카드로 결제를 완료하는 카드 테스트 봇은 실제 주문을 만들므로 Purchase도 실제 이벤트입니다. 한 판매자는 올해 5월, 봇이 같은 상품을 수백 개 주문해 픽셀에 영향을 줬다고 보고했습니다(스토어 플랫폼 커뮤니티 스레드, 2026년 5월 16일 시작, 광고주 보고). 스토어 쪽 대응은 이커머스 부정 클릭 방지 글에서 다룹니다.
추적 버그. 흔한 원인은 중복 픽셀 설치, 새로고침할 때마다 다시 실행되는 구매 완료 페이지, 운영 환경에 남은 test_event_code, 깨진 중복 제거 키, 잘못된 페이지에서 Purchase를 실행하는 설정 규칙입니다. 맨 위에서 인용한 구매 105건 스레드에는 2026년 10월에 달린 답변이 있는데, 페이지 조회를 Purchase 이벤트로 바꾸는 ‘Event Setup Tool’(이벤트 설정 도구) 규칙이 있는지 확인해 보라고 제안했습니다(광고주 보고).
Meta 쪽 버그. 한 판매자는 금액이 0인 구매가 집계를 부풀린다고 보고했고, 2025년 2월 20일에 2월 8일부터 11일 사이 코드 배포에서 생긴 Meta 쪽 버그를 Meta가 수정했으며 이후 되돌려졌다고 적었습니다(스토어 플랫폼 커뮤니티 스레드, 2025년 2월 10일 시작, 광고주 보고).
Meta는 왜 가짜 이벤트에 맞춰 최적화하나요?
저희의 해석입니다. Meta의 게재는 사용자가 보고하는 전환에서 학습하므로, 가짜 Purchase나 Lead는 가짜와 비슷한 방문을 더 찾도록 가르칩니다.
가치 최적화에서는 두 번째 왜곡이 더해집니다. 0달러나 딱 떨어지는 금액의 Purchase가 이어지면 구매자 한 명이 가져온다고 시스템이 생각하는 금액이 흐트러지는데, 이것도 저희의 해석입니다.
이벤트 관리자의 어디에서 가짜 이벤트가 보이나요?
이벤트 관리자는 이벤트 수, 연결 방법, 중복 제거율을 보여 주며, Meta가 문서화한 데이터 점검은 형식이 잘못된 데이터를 표시할 뿐 Meta 픽셀 가짜 이벤트를 표시하지는 않습니다. 차이가 있는 지점을 찾는 데 쓰고, 원인은 다른 곳에서 확인하세요.
- ‘Overview’(개요). Meta는 ‘Overview’가 “중복 제거되기 전에 받은 이벤트 수”를 보여 주고, “‘Connection Method’(연결 방법) 아래에서 해당 이벤트를 보낸 채널을 볼 수 있다”고 설명합니다(설정 확인, Meta for Developers). 하루 단위의 Purchase 수를 결제된 주문과 비교하세요.
- ‘Event Details’(이벤트 세부정보). ‘Overview’에서 열 수 있으며, ‘Event Deduplication’(이벤트 중복 제거) 탭에서 “각 이벤트 소스에서 중복 제거된 이벤트의 비율”과 각 중복 제거 키가 쓰이는 빈도를 보여 줍니다(같은 페이지).
- Dataset Quality API. Meta의 Dataset Quality API는 “value 또는 currency 매개변수가 없거나 유효하지 않은” 이벤트, “Meta 픽셀의 IP와 일치하지 않는” 클라이언트 IP 주소, “실제 이메일이 아닌 같은 임시 이메일을 공유하는” 이벤트를 점검합니다(Dataset Quality API, Meta for Developers). 이것은 형식 점검입니다. 봇, 스팸, 부정 행위 점검을 설명한 Meta 페이지는 찾지 못했으므로, 형식이 올바른 가짜는 이 점검을 모두 통과합니다.
- ‘Test Events’(이벤트 테스트). Meta가 안내하는 경로는 이벤트 관리자, 데이터 소스, 해당 픽셀, ‘Test Events’ 순이며, test_event_code 매개변수와 함께 보낸 서버 이벤트가 여기에 나타납니다(전환 API 사용하기).
- 이벤트 매칭 품질(EMQ). EMQ는 이벤트의 고객 정보가 Meta 계정과 얼마나 일치할 수 있는지를 보여 줄 뿐(전환 API 모범 사례), 이벤트가 부정인지는 보여 주지 않습니다. Meta는 EMQ가 “1에서 10까지의 점수로 매겨지며” “이벤트 매칭 품질 점수 6.0 이상을 목표로 하라”고 권장합니다(설정 확인).
Meta가 아니라 저희의 해석입니다. 리드 수가 늘어나는데 리드 이벤트의 EMQ가 떨어진다면 리드를 확인하세요. 지어낸 연락처는 실제 계정과 일치할 수 없기 때문입니다. 양식이 필드 전달을 멈춘 경우에도 EMQ는 떨어집니다.
가짜 이벤트인가요, 추적 버그인가요?
대부분의 패턴에는 무해한 설명과 악의적인 설명이 모두 있으며, 보통 한 가지 확인으로 어느 쪽인지 가려집니다.
| 패턴 | 보통 버그인 경우 | 일어나지 않았거나 실제 부정 행위인 경우 | 가려 주는 확인 |
|---|---|---|---|
| 주문 ID가 없는 Purchase | 설정이 주문 ID를 전달하지 않음 | 일어나지 않음: 실제 Purchase에는 주문 ID가 있음 | 각 이벤트의 타임스탬프를 주문과 대조 |
| 상품 페이지 URL에서 발생한 Purchase | 페이지를 새로고침할 때마다 실행됨 | 일어나지 않음: 재현되지 않고 일치하는 주문도 없음 | 네트워크 패널을 연 채로 페이지 새로고침 |
| 딱 떨어지거나 0인 금액 | 규칙이 고정 금액이나 빈 금액을 보냄 | 일어나지 않음: 금액이 어떤 상품과도 맞지 않음 | 금액을 가격표와 주문에 비교 |
| 브라우저 전용 이벤트, 서버 쌍둥이 없음 | 서버가 일부 이벤트만 보냄 | 일어나지 않음: 서버는 실제 Purchase를 모두 보냄 | ‘Overview’에서 연결 방법 비교 |
| 소유하지 않은 도메인에서 온 이벤트 | 해당 도메인이 스토어 미리보기나 테스트 세션임 | 일어나지 않음: 해당 도메인이 비즈니스와 무관함 | 픽셀 설정의 도메인 검토 |
| 한 방문자가 몇 초 안에 보낸 같은 Lead 다수 | 양식이 두 번 제출됨 | 실제 부정 행위: 봇이 양식을 제출했으므로 CRM 기록이 있음 | 리드를 CRM 기록과 타임스탬프에 대조 |
| AddToCart 급증, InitiateCheckout은 일정 | 규칙이 페이지 조회 때 AddToCart를 실행함 | 일어나지 않음: 자동화된 방문이 장바구니 담기를 클릭함 | 급증분을 소스, 페이지, 시간대별로 묶기 |
| 수가 정확히 두 배 | 설치 두 곳이 실행되거나 중복 제거 키가 다름 | 거의 어느 쪽도 아님: 두 배는 설정을 가리킴 | ‘Event Deduplication’ 탭 읽기 |
| 새 스토어나 새 캠페인에서 급증 | 설정을 아직 테스트 중임 | 일어나지 않음: 자동화된 방문이 새 사이트를 탐색함 | 주문과 테스트 날짜에 비교 |
| EMQ는 떨어지는데 수는 증가 | 양식이 필드 전달을 멈춤 | 실제 부정 행위: 새 리드가 지어낸 연락처를 가짐 | CRM에서 새 리드 검토 |
| 운영 환경에서 test_event_code가 붙은 이벤트 | 코드를 제거하지 않았음 | 거의 어느 쪽도 아님: 남은 코드는 설정 오류 | 서버 페이로드에서 test_event_code 검색 |
광고주들은 스토어 플랫폼 커뮤니티 스레드에서 이런 패턴 몇 가지를 보고했습니다.
- 고정 금액 Purchase. 2021년 10월 17일에 시작된 스레드는 가짜 99달러 구매를 제목으로 하며, 상품 페이지에서 발생한 브라우저 전용 Purchase 이벤트를 설명합니다. 이후 답변에 따르면 Meta 지원팀은 해당 이벤트가 파트너 연동을 통해 설정된 것임을 확인할 수 있었습니다.
- 새 스토어. 한 판매자는 스토어를 연 지 이틀 뒤 가짜 장바구니 담기, 결제, 구매 이벤트를 봤고(2020년 11월 25일 시작), 다른 판매자는 개설한 지 15일 미만의 스토어 두 곳에서 같은 일을 봤습니다(2022년 10월 19일 시작).
- 알 수 없는 도메인. 한 판매자는 트래픽 권한에서 스토어 미리보기 하위 도메인을 포함해 약 40개를 발견했고, 한 답변은 테스트 세션이 일부를 설명할 수 있다고 제안했습니다(2024년 4월 10일 시작).
중복 제거가 없애는 것과 없애지 못하는 것
중복 제거는 하나의 실제 이벤트의 사본을 없앱니다. 서버 사본이 없는 가짜 브라우저 이벤트에는 아무 작용도 하지 않습니다. Meta는 이벤트를 “ID와 이름을 기준으로” 매칭하며, 즉 event_id와 이벤트 이름이 같아야 하고, 그 ID의 첫 이벤트를 “48시간 이내에 받은 경우”에만 중복 제거합니다(픽셀 및 서버 이벤트 중복 제거, Meta for Developers).
한계가 더 중요합니다. Meta는 “브라우저 전용 또는 서버 전용처럼 이벤트 소스를 하나만 사용할 때는 이벤트를 중복 제거하지 않으며”, 같은 정보를 가진 연속된 두 브라우저 이벤트도 둘 다 유지된다고 밝힙니다. 또 fbp나 external_id 방식은 “일반적으로” “먼저 브라우저에서, 그다음 서버를 통해 보낸” 이벤트에서만 작동한다고 설명합니다(같은 페이지). 따라서 브라우저에서 Purchase를 발생시키는 스크립트는 매번 집계됩니다. 이벤트 ID 설정 방법은 중복 제거와 부정 클릭 필터링 전환 설정을 참고하세요.
의심스러운 Purchase 하나를 추적하는 방법
주문과 일치시킬 수 없는 Purchase 하나를 골라 페이지, 규칙, 스크립트까지 따라가세요. 아래 예시는 설명용이며 실제 계정이 아닙니다.
- ‘Overview’에서 차이를 찾으세요. 날짜 범위를 차이가 난 날로 설정하고 Purchase의 ‘Connection Method’를 읽으세요.
- 금액과 통화를 수집하세요. 서버 이벤트의 금액과 통화는 전환 API 로그에 있습니다. 어떤 상품과도 맞지 않는 금액의 브라우저 전용 Purchase가 단서입니다.
- 타임스탬프를 주문과 대조하세요. 몇 분 안에 결제된 주문이 없다면 그 이벤트 뒤에는 고객이 없는 것입니다.
- 브라우저 개발자 도구의 네트워크 패널을 열고 상품 페이지를 새로고침하세요. 어떤 픽셀 요청이 어떤 매개변수로 실행되는지 보세요.
- ‘Meta Ads Data Advisor’로 확인하세요. Meta는 이전에 Meta Pixel Helper였던 이 확장 프로그램이 “현재 웹페이지에서 실행된 픽셀 이벤트의 수”와 그 매개변수를 보여 준다고 설명합니다(Meta for Developers).
- ‘Test Events’에서 재현하세요. 테스트 데이터 세트를 사용하고, test_event_code를 운영 페이로드에 절대 남기지 마세요. Meta는 이 코드와 함께 보낸 이벤트가 “삭제되지 않으며” “이벤트 관리자로 흘러 들어가 타겟팅과 광고 측정에 사용된다”고 경고합니다(전환 API 사용하기).
- 이벤트를 보내는 도메인을 확인하세요. 픽셀의 트래픽 권한에서 확인합니다. 이 설정에 대한 Meta 도움말 페이지는 2026년 11월 12일에 저희 쪽에서 열리지 않았습니다.
페이지를 새로고침할 때 발생하는 Purchase는 모든 방문자에게 발생합니다. 규칙, 테마 코드, 연동 중 하나가 설명해 준다면 버그이고, 아무것도 설명해 주지 않는다면 삽입된 스크립트를 찾아보세요. 재현되지 않고 일치하는 주문도 없다면 도메인과 연결 방법을 확인하세요. 직접 호출했거나 다른 도메인의 스크립트가 보낸 호출은 자신의 네트워크 패널에 나타나지 않습니다.
Meta에서 가짜 이벤트를 막는 방법
가짜 Meta 픽셀 이벤트를 막으려면 이벤트를 보내는 도메인을 제한하고, 중복 제거 키를 고치고, test_event_code를 제거한 다음, 결제된 주문 데이터로 서버에서 Purchase를 보내세요.
- 트래픽 권한을 검토하세요. 미리보기와 테스트 세션을 먼저 배제한 뒤, 현재 화면에서 가능하다면 본인 도메인만 허용하세요. 허용 목록은 본인 소유 도메인에서 실행되는 스크립트를 막지 못합니다.
- 중복 제거 키를 고치세요. 실제 이벤트마다 브라우저와 서버에서 같은 이벤트 ID와 이벤트 이름을 전달하세요.
- 공유된 이벤트 ID로 서버에서 전환 이벤트를 보내세요. 서버는 어떤 주문이 결제되었는지 압니다. 이렇게 해도 가짜 브라우저 이벤트가 사라지지는 않으며 그대로 집계되지만, 비교할 수 있는 서버 확인 Purchase 수가 생깁니다.
- test_event_code를 제거하세요. 배포 전마다 서버 페이로드에서 검색하세요.
- 매주 대조하세요. Purchase와 Lead 이벤트를 결제된 주문, 그리고 기준 기록인 CRM과 비교하세요.
11월 27일이 블랙프라이데이이므로, 세일 당일의 급증을 기준선과 비교해 판단할 수 있도록 지금부터 연결 방법별 일일 Purchase, Lead, AddToCart 수를 내보내 두세요. Google Ads와 Meta를 위한 연말 점검표에서도 같은 방법을 안내합니다.
의도가 없지만 실제 사람인 리드가 궁금하다면 의도가 낮은 리드와 봇을 구별하는 방법을 보세요. 차이가 더 앞, 즉 클릭 단계에서 시작된다면 링크 클릭과 랜딩 페이지 조회를 읽어 보세요.
ClickFortify가 하는 일과 막지 못하는 것
ClickFortify는 Meta 광고 클릭 이후의 의심스러운 전환을 표시하고 CAPI 프록시를 통해 보낸 서버 이벤트를 걸러낼 수 있습니다. 브라우저에서 Meta 픽셀이 발생시키는 이벤트는 제거하지 않습니다.
ClickFortify는 fbclid로 Meta 광고 클릭을 인식하고, 랜딩 페이지 경로에서 각 방문을 100개 이상의 기기, 네트워크, 행동 데이터 포인트로 점수화합니다. 클릭 기록에서 의심스러운 전환 패턴 세 가지를 표시합니다. 클릭 후 2초 이내의 전환, 이미 봇으로 분류된 방문자의 전환, 전환이 3건 이상인 기기입니다. CAPI 프록시를 켜면 ClickFortify를 통해 보낸 전환이 방문자의 사기 점수와 대조되고, 표시된 이벤트는 Meta가 받기 전에 폐기되거나 태그됩니다. 이 필터는 프록시를 통해 보낸 서버 이벤트에만 적용됩니다. 브라우저에서 Meta 픽셀이 발생시키는 이벤트는 여전히 Meta에 도달하며, ClickFortify는 픽셀을 직접 호출하는 스크립트나 봇을 막을 수 없습니다.
ClickFortify는 리드의 이메일 주소나 전화번호를 확인하지 않으므로 CRM 점검과 함께 사용하세요. 인스턴트 양식 리드는 픽셀 이벤트가 아니어서 ClickFortify가 볼 수 없습니다. 그 경우는 Facebook 리드 광고 가짜 리드 가이드를 참고하세요. Meta에서는 IP 주소를 차단하지 않고 타겟 제외도 만들지 않습니다. 설정 방법은 Meta 광고용 ClickFortify에서 확인하세요.
Google Ads도 운영하시나요? 전환 액션 쪽은 Google Ads 가짜 전환 가이드에서 다룹니다.
저희의 결론은 이렇습니다. 먼저 이벤트를 주문과 대조하고 버그를 고치세요. 확인 비용이 가장 적은 원인이기 때문입니다. 차이가 유료 클릭 뒤에 이어지고 정리 후에도 남는다면 그때 전환 점검을 더하세요. 나머지 클러스터는 Meta 광고 부정 클릭 가이드 전체에서 둘러보세요.
