이 글의 요점
1. 브라우저 이벤트와 서버 이벤트는 확인 방법이 다르며, 테스트 코드는 서버 이벤트에만 씁니다.
2. 같은 구매가 두 번 잡히지 않는지는 event_name·event_id 일치와 fbp·fbc 같은 보조 값으로 봅니다.
3. 이벤트 수는 주문 수와 같은 기준으로 대조하고, 차이가 나는 이유를 설명할 수 있으면 합격입니다.

이 글이 필요한 사람과 점검 순서

메타 픽셀과 전환 API를 처음 붙인 1인 사업자, 그리고 설치 결과를 검수해야 하는 대행사 신입 AE를 위한 글입니다. 순서는 네 단계입니다.

1. 설치 방식 구분
2. 테스트 이벤트 확인
3. 개요·진단에서 중복과 품질 확인
4. 도메인 인증·토큰 등 계정 설정 확인

1단계. 설치 방식부터 구분합니다

어디를 확인할지는 설치 방식에 따라 달라집니다. 메뉴 이름은 솔루션마다 다르므로 아래 표에서는 확인할 대상만 적었습니다.

2단계. 테스트 이벤트 탭에서 브라우저와 서버를 나눠 봅니다

경로는 이벤트 관리자 → 데이터 소스 → 대상 픽셀(데이터 세트) 선택 → 테스트 이벤트입니다.

1. 브라우저 이벤트: 탭에서 사이트 URL을 입력하고 열리는 새 창에서 상품 보기, 장바구니, 결제 시작, 구매를 차례로 실행합니다. 행동마다 이벤트가 한 건씩 뜨고, 구매 이벤트에 value와 currency(KRW)가 채워져 있으면 합격입니다.
2. 서버 이벤트: 같은 탭에 표시되는 테스트 코드를 전환 API 요청의 test_event_code에 넣어 전송합니다. 테스트 코드는 서버 이벤트용이며 브라우저 이벤트에는 쓰지 않습니다. 확인을 마치면 이 값을 코드나 태그에서 제거합니다. 남겨 두면 운영 이벤트로 처리되지 않을 수 있습니다.
3. 브라우저와 서버로 같은 행동을 모두 보냈다면 중복 제거로 처리됐는지 이벤트 표시를 확인합니다. 표기는 화면 기준입니다.

시험 주문 처리: 메타 쪽에서 시험 이벤트를 따로 분리하는 방법은 없습니다. 쇼핑몰 쪽에서 표시해 두는 방식이 현실적입니다.

• 주문 메모에 'TEST'를 적습니다.
• 테스트 전용 쿠폰이나 상품을 씁니다.
• 시험 주문의 번호와 시각을 기록합니다.

나중에 주문 수와 대조할 때는 그 건수를 차감하고 비교합니다.

3단계. 개요·진단에서 중복과 품질을 판단합니다

이벤트 관리자 → 데이터 소스 → 개요·진단에서 아래 항목을 봅니다.

중복 제거에서 볼 것

• 브라우저 이벤트와 서버 이벤트의 이름과 event_id가 같아야 같은 이벤트로 묶입니다.
• 브라우저와 서버 이벤트가 도착하는 시간 간격에는 허용 범위가 있습니다. 서버 이벤트를 나중에 모아서 보내는 방식은 중복 제거가 안 될 수 있으니, 결제 시점에 실시간으로 보내는 구성을 기본으로 합니다. 정확한 허용 시간은 공식 도움말의 중복 제거 항목에서 확인합니다.
• fbp(_fbp 쿠키), fbc(_fbc 쿠키, 광고 클릭 시 생성), external_id는 서버 이벤트에 함께 보내면 사용자 매칭에 도움이 되는 값입니다. fbp·fbc는 해시하지 않고 그대로 보내며, 이메일·전화번호는 정규화한 뒤 해시해서 보냅니다.

주문 수와 대조하는 법

같은 기간, 같은 기준(결제 완료 기준)으로 구매 이벤트 수와 쇼핑몰 주문 수를 비교합니다. 이벤트 수가 주문 수와 꼭 일치하거나 더 적어야 하는 것은 아닙니다. 아래 사유로 어느 쪽이든 차이가 날 수 있습니다.

• 취소·환불 주문
• 시험 주문
• 광고 차단이나 동의 거부로 인한 브라우저 이벤트 누락
• 결제 완료 페이지 새로고침으로 인한 중복 발화

계산 예시(가정값): 주문이 50건인데 구매 이벤트가 62건이면 차이는 12건입니다. 시험 주문 3건을 빼고 나머지 9건이 새로고침 중복인지, 중복 제거 실패인지 event_id 단위로 나눠 봅니다.

4단계. 계정 설정 세 가지를 확인합니다

1. 도메인 인증: 비즈니스 설정의 브랜드 안전 → 도메인에서 쇼핑몰 도메인이 인증 상태인지 봅니다. 미인증이면 이벤트 설정이 제한될 수 있습니다.
2. 집계 이벤트 측정(AEM): 이벤트 관리자 설정에서 웹 이벤트 설정 항목이 보이는지, 구매 이벤트가 우선순위에 들어 있는지 확인합니다. 화면 구성과 필요 여부는 바뀔 수 있어 공식 도움말과 대조합니다.
3. 액세스 토큰: 전환 API 설정에서 토큰을 발급한 계정에 해당 데이터 세트 권한이 있는지 봅니다. 토큰은 코드 저장소나 메신저에 남기지 않고 만료·교체 일정을 관리합니다. 토큰 오류가 나면 서버 이벤트만 끊기므로 진단 탭의 오류 메시지부터 봅니다.

바로 쓰는 체크리스트

• 설치 방식(내장 연동, GTM, 직접 개발)을 기록했습니다.
• 테스트 이벤트 탭에서 브라우저 이벤트 5종을 URL 방식으로 확인했습니다.
• 서버 이벤트는 test_event_code로 확인했고, 확인 후 코드를 제거했습니다.
• 구매 이벤트에 value, currency, content_ids가 들어 있습니다.
• 브라우저와 서버의 event_name·event_id가 같고, 구매가 이중 집계되지 않습니다.
• fbp·fbc·external_id 전달 여부와 이벤트 일치 품질 점수를 확인했습니다.
• 시험 주문을 쇼핑몰에서 표시하고 건수를 기록했습니다.
• 구매 이벤트 수와 주문 수 차이의 원인을 설명할 수 있습니다.
• 도메인 인증, AEM, 토큰 권한을 확인했습니다.

자주 하는 실수

• 브라우저 이벤트에 테스트 코드를 넣으려 합니다. 테스트 코드는 서버 이벤트용이므로, 브라우저는 테스트 이벤트 탭에서 사이트 URL로 확인합니다.
• event_id를 서버에서 따로 새로 만듭니다. 브라우저에서 만든 값을 서버로 넘기거나, 주문번호 기반의 같은 규칙으로 양쪽에서 생성합니다.
• 시험 주문이 메타에서 빠질 것으로 생각합니다. 빠지지 않으므로 쇼핑몰 쪽에 표시하고 대조할 때 차감합니다.
• test_event_code를 운영 코드에 남깁니다. 검수가 끝나면 제거하고 개요에서 서버 이벤트가 들어오는지 다시 봅니다.
• 일치 품질 점수만 올리려 합니다. 점수보다 먼저 중복 제거와 구매 값 정확도를 확인합니다. 고객 정보는 동의 범위와 개인정보 처리방침 고지 내용 안에서 보냅니다.
• 설치 직후 한 번 보고 끝냅니다. 쇼핑몰 스킨 변경이나 결제 모듈 교체 뒤에는 같은 순서로 다시 확인합니다.

메뉴 이름과 정책은 바뀔 수 있으니 공식 도움말에서 최신 내용을 확인하세요. Meta 비즈니스 고객센터(https://www.facebook.com/business/help)에서 '이벤트 관리자', '전환 API', '중복 제거'를 검색하면 됩니다. 개발 관련 항목은 https://developers.facebook.com/docs/marketing-api/conversions-api에서 볼 수 있습니다.

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