Meta CAPI 중복 제거: event_id 생성·전달·검증 체크리스트

Meta Conversions API(CAPI)와 브라우저 픽셀을 병행하면 같은 실제 전환에 대해 두 번 집계되는 것을 방지해야 합니다. 이를 위해 Meta는 동일 이벤트에 대해 일치하는 event_id(또는 eventID)와 event_name을 사용하도록 권고합니다. 본 가이드는 스타트업 대표·마케터·마케팅 엔지니어가 협업해 어떤 ID를 어디서 언제 생성하고, 필수 필드를 어떤 방식으로 전달하며, 실무에서 검증·모니터링할지를 좁고 실행 가능하게 정리합니다. 또한 48시간 창, Event Match Quality(EMQ) 영향, 서버-클라이언트 도착 시간 차이로 발생하는 한계와 대처법을 명확히 제시합니다. 공식 Meta 플레이북(Conversions API Playbook 및 Direct Integration Playbook)의 핵심 권고를 바탕으로 실무 체크리스트와 테스트 절차를 제공합니다.

핵심 원리: event_id와 매칭 규칙

중복 제거의 기본은 같은 실제 전환에 대해 픽셀과 서버 이벤트가 동일한 event_id와 event_name을 갖는 것입니다. Meta 문서에 따르면 event_id(eventID)와 event_name이 일치하면 시스템은 두 이벤트를 하나로 묶어 중복을 제거합니다. 따라서 event_id는 전환 단위를 고유하게 식별할 수 있어야 합니다(예: 주문 ID 또는 UUID).

event_time(Unix 초)도 매칭 로직에 영향을 줍니다. 서버 전송이 클라이언트보다 상당히 늦을 경우, 플랫폼에서 매칭을 실패하거나 최종 집계에서 둘 중 하나만 반영될 수 있습니다. Playbook은 지연을 최소화하고 event_time을 정확히 설정할 것을 권고합니다. 48시간 창은 운영상 고려해야 할 제한 조건으로 인식하세요(아래 검증 섹션 참고).

누가, 언제 event_id를 생성해야 하나

권장 접근은 서버 측에서 event_id를 생성하고 클라이언트에 전달하는 것입니다. 주문 완료나 확인 페이지에서 서버가 UUID 또는 주문번호를 생성해 동일 값을 픽셀과 CAPI에 함께 보내면 중복 제거 정확도가 높아집니다. 서버 생성은 재전송·장애 복구 시 일관성 유지에 유리합니다(Playbook 권고). (예시) 주문 완료 API 응답에 event_id를 포함해 클라이언트가 바로 픽셀에 설정하도록 합니다.

클라이언트에서만 생성하는 경우 동기화 실패 위험이 커집니다. 특히 SPA나 비동기 결제 흐름에서 event_id가 전파되지 않으면 중복 판정이 안 됩니다. 따라서 반드시 서버 로그에 event_id를 저장하고, 실패 시 재전송 로직(서버→Meta 재시도)을 구현해 보존성을 확보하세요. 재시도 시에도 동일 event_id를 사용해야 합니다. (운영 팁) event_id를 DB 트랜잭션과 함께 기록해 장기 감사가 가능하도록 하세요.

필드별 역할과 꼭 포함할 값

중복 제거에 필수인 필드는 event_id(eventID)와 event_name입니다. 이 둘이 정확히 일치해야 해당 두 이벤트가 같은 전환으로 묶입니다. 추가로 user_data(예: 이메일 해시), fbp와 fbc 같은 브라우저 식별자도 함께 전송해야 EMQ 저하를 막고 매칭 성공률을 높입니다. Playbook은 서버 이벤트에 클라이언트 식별자(fbp/fbc)를 포함할 것을 권고합니다.

event_time은 Unix 초 단위로 서버가 생성 시점을 명확히 보내야 합니다. 전송 지연으로 인해 event_time과 수신 시간이 크게 불일치하면 매칭이 실패할 수 있습니다. 48시간 이내 전송을 목표로 하되, 시스템 설계상 더 긴 지연 가능성이 있으면 공식 문서를 확인해 처리 정책을 검토하세요. EMQ는 user_data 품질 저하 시 매칭 성능을 떨어뜨릴 수 있음을 기억하세요.

검증·테스트 절차(실행 순서)

1) 개발 단계에서 서버가 event_id를 생성·저장·응답에 포함하는지 확인합니다. 2) 클라이언트는 응답의 event_id를 픽셀에 set하고 CAPI 서버 호출에 함께 포함합니다. 3) Events Manager의 Test Events 탭으로 픽셀-서버 이벤트의 도착을 실시간으로 확인합니다. 이 순서를 스크립트화해 파이프라인 테스트 케이스로 저장하세요.

검증 체크포인트: a) 픽셀과 서버 이벤트의 event_id와 event_name이 일치하는가? b) event_time이 실제 발생 시점을 반영하는가? c) 서버 이벤트에 fbp/fbc 또는 user_data가 포함되어 EMQ가 급감하지 않는가? d) 서버 지연이 48시간을 넘지 않는가? 각 항목은 자동화된 테스트로 주기 검사하도록 설정하세요(예: CI 테스트, 로그 검사).

모니터링·운영 체크리스트과 실수 방지

운영 체크리스트(항목 예시): event_id 발급 위치(서버) 기록, DB에 event_id 보존, 픽셀/서버 전송에 동일 event_id 포함, user_data·fbp·fbc 동시 전송, event_time 동기화, Events Manager Test Events 점검. 각 항목을 소유자(엔지니어/마케터)와 SLA(예: 48시간 이내 재전송)로 명시하세요.

자주 하는 실수: 1) 클라이언트에서만 event_id를 생성해 서버 이벤트와 불일치, 2) event_time을 현재 시각이 아닌 전송 시각으로 설정해 매칭 실패, 3) fbp/fbc 미포함으로 EMQ 저하, 4) 재시도 시 새로운 event_id를 발급해 중복 제거 실패. 이런 실수는 로그·Test Events 검증으로 빠르게 잡을 수 있습니다. 문제가 불확실하면 Meta 개발자 문서를 다시 확인하세요.

우리 팀의 다음 실행 과제 찾기

현재 유입과 전환 흐름을 점검하고 실행 우선순위를 정하고 싶다면 히치하이커 AI와 상담해 보세요.

참고 자료