테스트 이벤트 탭에서 브라우저·서버 수신을 먼저 확인하고, event_name·event_id 일치 여부로 중복 제거를 점검합니다.
개요·진단 탭의 경고와 주문 수 차이는 기간·시간대·기여 설정·중복 순서로 좁혀 갑니다.
테스트 코드는 확인 후 운영 요청에서 빼고, 외부 결제 복귀 누락과 가상계좌 같은 사이트 고유 조건은 따로 점검합니다.

누구에게 필요하고, 어떤 순서로 보는가

픽셀이나 전환 API(Conversions API)를 막 설치한 1인 사업자와 대행사 신입 AE를 위한 글입니다. 설치 완료 화면이 떴다는 것과 최적화에 쓸 만한 이벤트가 들어온다는 것은 다른 문제입니다.

순서는 ① 테스트 이벤트 수신 ② 중복 제거 조건 ③ 개요·진단 탭 ④ 실제 주문 수 대조입니다. 아래 메뉴명은 모두 현재 기준 이벤트 관리자(데이터 소스 > 해당 픽셀 선택) 화면입니다.

1단계. 테스트 이벤트 탭에서 수신 확인

무엇을 볼지는 브라우저 이벤트와 서버 이벤트가 각각 도착하는지입니다. 위치는 데이터 소스 > 픽셀 > 테스트 이벤트 탭(현재 기준)입니다.

1. 브라우저: 사이트 주소를 입력해 새 창을 열고 상품 조회, 장바구니, 결제 시작, 구매 순으로 직접 진행합니다. 합격 기준은 단계별 이벤트가 모두 표시되고, 구매 이벤트에 value(금액)와 currency(KRW)가 들어오는 것입니다.
2. 서버: 같은 탭에 표시되는 테스트 코드를 전환 API 요청 본문 최상위의 test_event_code 필드(data 배열과 같은 층위)에 넣어 보냅니다. 합격 기준은 서버 이벤트가 같은 이벤트명으로 표시되고, 요청에 action_source(website), event_source_url, client_user_agent가 포함되는 것입니다.
3. 정리: 확인이 끝나면 test_event_code를 운영 요청에서 제거합니다.

test_event_code는 테스트 이벤트 탭에서 해당 요청을 골라 보여 주는 식별용 값입니다. 탭에 보인다는 것은 요청이 도착했고 형식이 맞다는 뜻이지 운영 데이터로 집계된다는 뜻이 아니며, 공식 문서도 운영 요청에서는 이 필드를 빼도록 안내합니다. 제거한 뒤에는 개요 탭에서 코드 없는 이벤트가 들어오는지 다시 확인합니다.

플랫폼마다 서버 이벤트 전송 방식이 다릅니다. 쇼피파이는 Facebook & Instagram 앱의 데이터 공유 수준 설정에 따라 전송 범위가 달라지는 것으로 알려져 있으니, 각 플랫폼 도움말에서 확인하세요.

2단계. 중복 제거 조건 확인

무엇을 볼지는 한 주문이 브라우저와 서버에서 두 번 들어왔을 때 한 건으로 합쳐지는지입니다. 위치는 개요 탭의 이벤트별 수신 경로와 진단 탭입니다(현재 기준). 공식 문서에 나온 조건은 아래와 같습니다.

• event_name 일치: 철자와 대소문자까지 같아야 합니다.
• event_id 일치: 픽셀 호출의 eventID와 서버 요청의 event_id에 같은 값을 넣습니다. 구매는 주문번호처럼 주문마다 고유한 값을 두 곳에서 똑같이 씁니다. 접속마다 새로 만드는 난수를 각각 쓰면 일치하지 않습니다.
• 수신 시간: 같은 이벤트명·ID의 이벤트가 48시간 이내에 들어와야 중복 제거 대상입니다.
• 순서: 브라우저 이벤트가 먼저, 서버 이벤트가 뒤에 도착하는 흐름이 기본으로 설명됩니다. 서버를 먼저 보내는 구조라면 중복 제거 문서의 순서 항목을 확인하세요.

event_id를 쓸 수 없는 환경에서는 fbp·external_id로 중복 제거하는 방법도 있지만, 적용 조건이 더 까다로워 event_id가 우선입니다.

3~4단계. 개요·진단 탭 확인과 주문 수 대조

3단계는 개요 탭에서 이벤트별 수신 경로(브라우저·서버)와 이벤트 매칭 품질을 보고, 진단 탭에서 경고를 읽는 것입니다. 경고는 구매의 value·currency 누락, event_id 누락에 따른 중복 제거 경고, 고객 정보 매개변수 부족 같은 유형으로 나옵니다. 문구는 시점에 따라 달라질 수 있으니 의미 기준으로 읽으세요. 합격 기준은 오류가 없고, 남은 경고마다 원인이 기록되어 있는 것입니다.

4단계는 이벤트 수와 쇼핑몰 주문 수를 아래 순서로 대조하는 것입니다.

1. 같은 기간·같은 시간대로 맞춥니다. 광고 계정 시간대와 쇼핑몰 관리자 시간대를 확인합니다.
2. 쇼핑몰 주문 수는 결제 완료 기준으로 세고 취소·미입금 주문을 따로 뺍니다.
3. 개요 탭의 구매 건수를 봅니다. 광고 귀속과 무관하게 수신된 건수입니다.
4. 광고 관리자 결과는 열 설정의 기여 설정(예: 7일 클릭)에 따라 광고에 귀속된 건수만 보여 줍니다. 이벤트 관리자보다 적게 나오는 것이 자연스럽습니다.
5. 캠페인 필터와 삭제된 항목 포함 여부를 확인합니다.
6. 그래도 차이가 크면 2단계의 중복 제거를 다시 봅니다.

계산 예시(가정값): 쇼핑몰 40건, 개요 탭 52건이면 (52-40)÷40=30% 초과이므로 중복 발화를 의심합니다. 개요 탭이 36건이면 -10%이고, 광고 차단기 등에 의한 누락 범위인지 봅니다. 허용 오차를 ±10%로 두는 것은 팀 내부 기준 예시이며 공식 기준이 아닙니다.

점검 기준표와 체크리스트

• 테스트 이벤트 탭에서 브라우저 구매 이벤트를 확인했다.
• 서버 요청에 test_event_code를 넣어 수신을 확인한 뒤 코드를 제거했다.
• 구매 이벤트에 value·currency가 들어간다.
• 브라우저와 서버의 event_name·event_id가 같다.
• 개요 탭에서 서버 수신 경로가 보인다.
• 진단 탭의 경고 사유를 기록했다.
• 주문 수 대조 기준(기간, 시간대, 기여 설정, 허용 오차)을 문서로 남겼다.

자주 하는 실수

• 외부 PG 결제 후 완료 페이지로 돌아오지 않음: 간편결제·앱카드 이동 중 이탈하면 브라우저 구매 이벤트가 빠집니다. 결제 승인 확인 시점에 서버에서 구매 이벤트를 보내고, event_id를 주문번호로 맞춥니다.
• 가상계좌 입금 대기 주문이 구매로 집계됨: 주문 완료 페이지에서 구매를 발화하면 입금 전 주문도 잡힙니다. 입금 확인 시점에 서버로 보낼지, 주문 접수를 별도 이벤트로 나눌지 정합니다. 서버 이벤트의 event_time은 오래된 과거 값이면 거부될 수 있으니 허용 범위를 문서에서 확인합니다.
• 광고 차단기·iOS 환경의 브라우저 이벤트 누락: 브라우저만으로는 일부가 빠질 수 있고, 전환 API는 이를 보완하는 용도입니다. 개요 탭에서 브라우저와 서버 수신 비중을 비교합니다.
• 새로고침 중복 발화: 완료 페이지를 다시 열 때마다 구매가 잡힙니다. 주문번호 기준으로 한 번만 발화하게 막습니다.
• 이중 설치: 쇼핑몰 기본 연동과 직접 삽입 코드가 함께 있으면 같은 이벤트가 두 번 들어옵니다. Meta Pixel Helper 같은 확장 도구로 호출 횟수를 보고 하나로 정리합니다.
• 테스트 코드 방치: 운영 요청에 test_event_code가 남으면 테스트용 요청과 운영 요청을 구분하기 어렵습니다. 배포 전 검색으로 제거 여부를 확인합니다.
• 업데이트 후 끊김: 테마 교체나 앱 업데이트 뒤 개요 탭의 마지막 수신 시간을 확인합니다.

메뉴 이름과 정책은 바뀔 수 있으니 공식 도움말에서 최종 확인하세요. 경로는 Meta 비즈니스 고객센터 > 픽셀·전환 API > 이벤트 중복 제거, 그리고 Conversions API 개발자 문서의 중복 제거·테스트 이벤트 항목입니다.

마케팅랩 에디터가 정리한 글입니다. 플랫폼 정책과 메뉴는 바뀔 수 있으니 실행 전 공식 도움말을 한 번 더 확인해 주세요. 틀린 내용이나 더 좋은 방법이 있으면 댓글로 알려 주세요.