왜 같은 전환이 두 번 잡히는가

픽셀과 CAPI를 함께 운영하는 것은 표준 구성이지만, 여기에는 구조적 함정이 있습니다. 사용자가 구매를 완료하는 순간, 브라우저에서는 결제완료 페이지에 심어둔 픽셀 코드가 fbq('track', 'Purchase') 이벤트를 메타로 보내고, 동시에 서버에서는 결제 완료 웹훅을 받은 CAPI 로직이 똑같은 Purchase 이벤트를 별도로 메타로 보냅니다. 메타 입장에서는 이 두 요청을 구분할 방법이 없으면 서로 다른 두 건의 구매로 인식해버립니다.

이 문제를 방치하면 전환수가 실제의 거의 두 배로 부풀려지고, 메타의 머신러닝은 이 부풀려진 신호를 그대로 학습해 예산 배분과 타겟팅 최적화 방향을 왜곡시킵니다. 겉으로는 성과가 좋아 보이는 착시가 생기지만 실제 CPA·ROAS는 그 절반 수준이라는 뜻이므로, 이 착시를 기반으로 예산을 늘리면 실질 손해로 이어집니다.

event_id가 하는 일

이 문제를 막는 장치가 event_id입니다. event_id는 메타가 픽셀(클라이언트)과 CAPI(서버)에서 들어온 같은 사용자 행동을 하나로 인식하도록 만드는 공유 식별자입니다. 같은 event_name과 같은 event_id를 짧은 시간 내에 두 경로에서 받으면, 메타는 이를 하나의 이벤트로 판단해 딱 한 번만 집계합니다. 즉 event_id는 "이 두 요청은 사실 같은 사건을 두 번 보고한 것"이라고 메타에게 알려주는 역할을 합니다.

이 값을 만들 때 핵심 규칙은 두 가지입니다. 첫째, event_id는 각 전환마다 고유한 문자열이어야 합니다. 주문번호처럼 시스템 전체에서 유일하고 재사용되지 않는 값을 쓰는 것이 원칙입니다. 둘째, 이 값을 픽셀의 fbq() 호출과 CAPI 페이로드 양쪽에 동일하게 실어야 합니다. 프론트엔드가 생성한 값을 백엔드가 그대로 재사용하거나, 백엔드가 생성한 값을 프론트엔드로 넘겨 픽셀 호출에 실어야 하는데, 이 값이 두 경로에서 서로 다르게 만들어지면 중복제거는 작동하지 않습니다.

실무에서 event_id를 설계하는 방법

가장 안전한 방식은 주문 완료 시 백엔드가 생성하는 주문번호를 event_id로 그대로 씁니다. 결제완료 페이지가 렌더링될 때 서버가 이 주문번호를 페이지 데이터에 함께 내려주고, 프론트엔드의 픽셀 코드는 이 값을 그대로 fbq() 호출의 eventID 파라미터에 넣습니다. 백엔드의 CAPI 로직도 같은 주문번호를 event_id로 실어 보내면, 두 요청이 서로 다른 시점(브라우저는 즉시, 서버는 결제 승인 웹훅 수신 시점)에 도착하더라도 메타가 같은 사건으로 인식합니다.

주의할 점은 배치 요청(batch requests)을 쓰는 경우에도 이 규칙이 그대로 적용된다는 것입니다. 대량의 이벤트를 한 번에 전송하더라도 배치 안의 각 이벤트는 여전히 고유한 event_id를 가져야 합니다. 이 설정이 정상 작동하면 브라우저 경로만으로는 손실됐던 전환 데이터의 20~30%를 복구하면서도 중복 계산 없이 정확한 전환수를 유지할 수 있습니다.

중복제거가 실패했을 때 나타나는 신호

event_id 설계가 잘못되면 몇 가지 징후로 미리 알아챌 수 있습니다. 이벤트 관리자의 진단(Diagnostics) 탭에서 같은 이벤트가 "Browser"와 "Server" 양쪽 소스로 각각 별도 집계되고 중복제거 표시가 뜨지 않는다면, event_id가 두 경로에서 다르게 생성되고 있다는 뜻입니다. 흔한 원인은 프론트엔드가 주문번호 확정 전에 임시 세션 ID로 event_id를 먼저 만들어버리거나, 백엔드가 결제 승인 웹훅을 여러 번 받아 매번 새 event_id를 생성하는 경우입니다. 후자는 결제대행사(PG사) 웹훅이 네트워크 재시도로 같은 결제 건을 중복 발송할 때 특히 자주 발생하므로, 웹훅 수신 로직 자체에 "이미 처리한 주문번호인지" 확인하는 멱등성(idempotency) 체크를 별도로 두는 것이 안전합니다.