주문 확인 화면을 한 번만 열었는데 Meta에 서버 구매 이벤트가 두 번 들어왔다면, 테스트 주문번호 하나로 최초 전송과 재시도 기록을 찾아보세요. 같은 구매를 다시 보내는 동안 이벤트 ID가 바뀌었는지, 두 연동이 같은 주문을 각각 보냈는지 확인하면 수정할 범위를 좁힐 수 있습니다.
주문번호 하나로 전송 경로를 따라가세요
먼저 쇼핑몰 관리자에서 주문과 결제가 한 건인지 확인합니다. 그 주문에 해당하는 서버 전송 기록에서 발생 시각, 전송한 연동, 이벤트 이름, 이벤트 ID, 응답이나 오류를 찾아보세요. 쇼핑몰 앱이 전송을 담당한다면 그 앱에서 확인할 수 있는 진단 화면이나 지원 기록을 사용하세요. 로그를 공유할 때는 고객 정보와 인증 키를 가려 주세요.
Meta 픽셀과 전환 API를 함께 쓰는 경우에는 같은 데이터 세트에 보낸 이벤트 이름과 ID를 맞춰 보세요. 픽셀 쪽의 eventID와 서버 쪽의 event_id가 동일한 구매를 가리켜야 이름과 ID를 기준으로 두 신호를 짝지을 수 있습니다. 서버 기록은 각 시도가 발생한 이유까지 확인하는 데 쓰세요. Meta 픽셀·전환 API 중복 제거 안내
응답이 끊긴 테스트 주문을 예로 들어볼까요?
가상의 주문 TEST-071에서 첫 서버 요청의 응답을 받지 못했다고 가정해 보겠습니다.
표를 좌우로 스크롤해 읽어 보세요.
| 시각 | 전송 경로 | 이름과 ID | 확인할 점 |
|---|---|---|---|
| 10:02:11 | 브라우저 픽셀 | Purchase / purchase-071 | 같은 구매를 서버에서도 보내는지 확인합니다. |
| 10:02:12 | 서버 최초 전송 | Purchase / purchase-071 | 전송 프로그램에서 응답을 받지 못했습니다. 상대가 요청을 받았는지는 이 기록만으로 알 수 없습니다. |
| 10:02:42 | 서버 재시도 | Purchase / purchase-071-retry | 같은 구매에 새 ID를 붙인 코드나 연동 설정을 확인합니다. |
이 예에서는 재시도 때 ID를 새로 만드는 경로부터 확인하세요. 최초 전송에 사용한 ID를 주문의 해당 구매 이벤트와 함께 보관하고, 재시도에도 그 값을 사용하도록 수정할 수 있습니다. 서버 앱과 별도 연동이 각각 전송한 경우라면 어느 경로가 구매 전송을 맡을지 정하고 두 경로의 설정을 검토하세요.
수정 뒤에는 최초 주문과 새 주문을 각각 확인하세요
- 테스트 환경에서 새 주문을 넣으세요. 최초 전송 기록과 이벤트 관리자의 수신 기록에서 주문과 이벤트 이름·ID를 대조합니다.
- 같은 구매의 재시도 경로를 확인하세요. 연동이 제공하는 테스트 기능이나 테스트 환경의 로그로 원래 ID가 유지되는지 봅니다. 다른 구매를 위한 ID가 재사용되지 않는지도 확인하세요.
- 별도 주문을 한 건 더 넣으세요. 새 구매에 새 ID가 붙는지 확인합니다. 실제 수집 결과를 검토할 때는 이벤트 수신 기록과 처리된 집계 수치를 함께 확인하세요.
브라우저와 GA4까지 확인해야 한다면 Meta와 GA4 테스트 주문 체크리스트를 따라가 보세요.
구매 이벤트 추적 점검을 요청하세요
스토어 주소, 전환 API를 보내는 앱이나 서버 연동, 중복이 보인 시점을 알려주세요. 고객 정보와 인증 키를 가린 테스트 기록을 함께 보내주시면, 클랩스가 최초 전송과 재시도 중 어디부터 확인할지, 수정 후 어떤 증거로 검수할지 함께 정리합니다.