마케팅

메타 픽셀·전환 API 이벤트 중복 점검 가이드

메타 픽셀·전환 API 이벤트 중복 점검 가이드

메타 픽셀·전환 API 이벤트 중복 점검 가이드

메타 픽셀과 전환 API(CAPI)를 함께 연동했는데 전환수가 실제보다 부풀려져 보인다면?

메타 픽셀과 전환 API(CAPI)를 함께 연동했는데 전환수가 실제보다 부풀려져 보인다면?

위그로스 아카데미

메타 픽셀과 전환 API(CAPI)를 함께 연동하면 같은 구매나 리드가 두 경로로 각각 전송되어 광고 관리자에 이중으로 집계될 수 있습니다. 메타는 이벤트 이름과 event_id가 동일하고 첫 이벤트 수신 후 48시간 이내에 도착한 이벤트만 하나로 합쳐 처리합니다. event_id를 픽셀과 서버 양쪽에 동일하게 전달하지 않으면 이 조건이 성립하지 않아 중복 집계가 그대로 남습니다.

증상: 전환수가 주문 건수보다 많게 나온다면

광고 관리자 결과 탭에서 구매 전환수를 확인했는데 실제 쇼핑몰 관리자의 당일 주문 건수보다 많게 나오는 경우가 있습니다. 전환 값 합계가 같은 기간 매출액보다 크게 잡히거나, 캠페인 두 개 이상에서 같은 주문이 각각 잡혀 총합이 부풀어 보이는 경우도 있습니다. 픽셀만 쓰다가 전환 API를 새로 연동한 시점부터 이런 차이가 시작됐다면 두 신호가 겹쳐 잡혔을 가능성이 있습니다.

이런 상황에서 많은 담당자가 먼저 픽셀 코드를 지우고 재설치하거나, 전환 API 연동 자체를 끄고 픽셀 하나만 남기는 방식으로 대응합니다. 두 신호 중 하나를 없애면 전환수는 줄어들지만, 픽셀만 남기면 iOS 브라우저 차단이나 광고 차단 프로그램으로 놓치는 전환이 다시 늘어납니다. 문제는 픽셀과 전환 API를 같이 쓰는 것 자체가 아니라, 메타가 두 신호를 하나의 행동으로 합칠 조건이 충족되지 않은 것이므로 신호를 지우기 전에 이 조건부터 점검하는 순서가 필요합니다.

이번 글에서는 픽셀과 전환 API 이벤트가 중복 집계되는 판정 기준과, 계정에서 이 조건이 충족되고 있는지 확인하는 방법을 살펴보겠습니다.

출처: Convert Your Tracking with the Facebook Conversions API

1. 픽셀과 전환 API, 이벤트 중복이란

메타 픽셀은 웹사이트에 설치되어 브라우저에서 발생한 이벤트를 메타 서버로 전송하는 코드입니다. 전환 API(Conversions API)는 광고주의 서버에서 이벤트 데이터를 메타 서버로 직접 전송하는 방식입니다. 이벤트 중복은 동일한 실제 행동(같은 구매, 같은 리드 제출)이 픽셀과 전환 API 양쪽에서 각각 별도 이벤트로 집계되는 상태를 말합니다.

표1. 전송 방식별 특성 비교

전송 방식

데이터 발생 위치

브라우저 차단 영향

단독 사용 시 중복 위험

픽셀 단독

방문자 브라우저

광고 차단 프로그램, ITP 등에 영향받음

없음

전환 API 단독

광고주 서버

영향받지 않음

없음

픽셀 + 전환 API 병행

브라우저와 서버 동시

서버 이벤트로 손실분 보완

event_id 미설정 시 발생

2. event_id가 왜 필요한가

출처: Top 5 Meta Pixel Mistakes (and How to Fix Them)

픽셀과 전환 API를 함께 쓰면 같은 구매가 브라우저 신호와 서버 신호로 동시에 도착합니다. 메타 입장에서는 두 신호가 같은 행동을 가리키는지 스스로 판단할 방법이 없으므로, 광고주가 지정한 식별자로 두 이벤트를 하나로 합칠지 판정하는 절차가 필요합니다. Meta 픽셀과 전환 API 중복 제거 안내 – Meta for Developers에 따르면 이 판정은 두 조건이 모두 충족될 때만 성립합니다.

첫째, 픽셀의 eventID 파라미터와 서버 이벤트의 event_id 필드 값이 문자열 그대로 일치해야 합니다. 둘째, 픽셀의 event 이름과 서버의 event_name이 일치해야 합니다. 여기에 시간 조건도 함께 적용되어, 두 이벤트는 첫 이벤트가 수신된 시점으로부터 48시간 이내에 도착한 경우에만 하나로 합쳐지며 이 시간을 넘기면 별도 이벤트로 각각 집계됩니다.

표2. event_id 값에 따른 처리 결과 예시

아래 값은 이해를 돕기 위해 임의로 구성한 예시입니다. 실제 계정의 값과는 다를 수 있습니다.

픽셀 event_id

서버 event_id

event_name 일치 여부

수신 시간차

처리 결과

evt_1001

evt_1001

일치(Purchase)

3초

1건으로 병합

evt_1002

(미전달)

일치(Purchase)

5초

2건으로 각각 집계

evt_1003

evt_1099

일치(Purchase)

2초

2건으로 각각 집계(ID 불일치)

evt_1004

evt_1004

일치(Purchase)

50시간

2건으로 각각 집계(48시간 초과)

표2에서 보듯 event_id가 같은 값으로 전달되었더라도 48시간이라는 시간 조건을 넘기면 병합되지 않습니다. 반대로 event_id가 같고 이름도 같더라도 서버 쪽 event_id 필드 자체가 비어 있다면 애초에 비교할 값이 없어 병합 조건이 성립하지 않습니다.

3. 계정에서 확인할 점검 항목

픽셀 코드 점검: 구매·리드 등 주요 이벤트 트리거 코드에 eventID 파라미터가 포함되어 있는지 확인합니다. eventID가 지정되어 있다면 서버 쪽 값과 비교할 수 있는 상태이고, 지정되어 있지 않다면 픽셀 이벤트는 항상 별도로 집계되는 상태입니다.

서버(전환 API) 이벤트 점검: 서버에서 보내는 이벤트 페이로드에 event_id, event_name, event_time, action_source 필드가 모두 채워져 있는지 확인합니다. event_id 필드가 비어 있거나 이벤트마다 새로 생성되는 임의 값이라면 픽셀 쪽 값과 절대 일치할 수 없습니다.

동일 행동에 대한 event_id 값 비교: 같은 주문 한 건에 대해 픽셀과 서버가 실제로 같은 event_id 문자열을 쓰는지 개발 환경에서 직접 대조합니다. 주문 번호나 트랜잭션 ID처럼 프론트엔드와 백엔드가 동시에 접근 가능한 값을 event_id로 쓰고 있다면 일치 가능성이 높고, 프론트엔드에서만 생성되는 임시 값을 쓰고 있다면 서버로 전달되지 않아 불일치할 가능성이 높습니다.

데이터 소스(픽셀 ID) 점검: 픽셀 이벤트와 서버 이벤트가 동일한 픽셀 ID를 대상으로 전송되고 있는지 확인합니다. 서버 이벤트가 다른 픽셀 ID로 전송되고 있다면 event_id가 정확히 일치해도 애초에 같은 데이터 소스로 집계되지 않습니다.

표3. 중복 집계 점검 프로세스

단계

수행 활동

목적

1단계

광고 관리자 결과와 주문 시스템 건수 대조

중복 집계 발생 여부 1차 확인

2단계

픽셀·서버 코드에서 event_id 전달 여부 확인

병합 조건 중 ID 존재 여부 점검

3단계

동일 주문 기준 event_id·event_name 값 대조

두 신호가 같은 값을 쓰는지 점검

4단계

수정 후 일정 기간 결과 대비 주문 건수 재비교

병합 조건 적용 여부 확인

[위그로스 실무 사례 삽입 지점 — 병행 연동 전후 전환수와 실제 주문 건수 대비표, 수정 적용 시점, 개선폭 데이터 필요]

4. 자가 진단 체크리스트

다음 항목을 순서대로 확인합니다.

  1. 픽셀과 전환 API를 동시에 연동하고 있다.

  2. 최근 결과(전환수)가 주문 시스템 건수보다 많게 나온 적이 있다.

  3. 픽셀 이벤트 코드에 eventID 파라미터가 없다.

  4. 서버 이벤트 페이로드에 event_id 필드가 비어 있거나 매번 새로 생성된다.

  5. 픽셀과 서버가 서로 다른 값 체계(예: 세션 ID vs 주문번호)로 event_id를 만들고 있다.

  6. 서버 이벤트 전송이 첫 픽셀 이벤트 수신 후 48시간을 넘겨 지연되는 경우가 있다.

  7. 픽셀과 서버 이벤트가 서로 다른 픽셀 ID로 전송되고 있다.

  8. 최근 픽셀 코드나 전환 API 연동을 변경한 적이 있다.

즉시 조치 구간(5개 이상 해당): event_id를 주문번호나 트랜잭션 ID 등 프론트·백엔드가 동시에 참조 가능한 값으로 통일하고, 픽셀과 서버 코드 양쪽에 동일하게 전달되도록 수정합니다. 수정을 반영한 이벤트가 쌓이기 시작하면 3~4일 뒤 결과와 주문 건수를 다시 대조합니다.

관찰 구간(2~4개 해당): event_id는 전달되고 있으나 값 체계가 일부 이벤트에서만 어긋나는 경우이므로, 이벤트 종류별로 event_id 생성 로직을 점검합니다. 2~3주 뒤 이벤트 종류별 결과와 주문 건수를 다시 비교합니다.

정상 구간(1개 이하 해당): event_id·event_name이 양쪽에서 일치하고 결과와 주문 건수 차이도 크지 않은 상태이므로, 별도 조치 없이 다음 분기 정기 점검 때 재확인합니다.

5. FAQ

Q1. event_id를 아예 안 쓰면 어떻게 되나요?

event_id 없이 픽셀과 전환 API를 함께 쓰면 event_name만으로는 병합 조건이 성립하지 않아 같은 행동이 두 건으로 각각 집계됩니다.

Q2. 서버 이벤트만 남기고 픽셀을 꺼도 되나요?

가능하지만 방문자 행동 데이터 일부를 서버에서 재현하지 못하는 이벤트(스크롤, 페이지뷰 등)는 픽셀에서만 수집되는 경우가 있어 함께 검토해야 합니다.

Q3. event_id는 매번 새로 만들어도 되나요?

동일한 실제 행동에 대해서는 픽셀과 서버가 같은 event_id 값을 써야 병합되므로, 행동마다 고유하되 두 경로에서 재현 가능한 값(주문번호 등)을 써야 합니다.

Q4. 48시간이 지나면 중복 집계된 값은 되돌릴 수 없나요?

이미 별도로 집계된 과거 이벤트는 소급 병합되지 않으므로, 앞으로 발생하는 이벤트부터 event_id 조건을 맞추는 방식으로 접근해야 합니다.

6. 핵심 요약

출처: Conversions API vs Meta Pixel: What Is the Difference and Which Should You Use?

  • 메타는 event_id 일치, event_name 일치, 48시간 이내 수신이라는 세 조건이 모두 충족될 때만 픽셀과 전환 API 이벤트를 하나로 합칩니다.

  • event_id가 비어 있거나 두 경로에서 서로 다른 값을 쓰면 같은 행동이 두 건으로 각각 집계됩니다.

  • 픽셀 코드와 서버 페이로드 양쪽의 event_id·event_name 필드를 실제 값 단위로 대조하는 것이 1차 점검입니다.

  • 수정 반영 후에는 즉시 조치 구간은 며칠, 관찰 구간은 몇 주 단위로 결과와 주문 건수를 재비교합니다.

  • 신호를 끄기 전에 병합 조건 충족 여부부터 확인하는 순서가 필요합니다.

신호를 늘리기 전에 그 신호들이 하나로 합쳐질 조건부터 맞추는 순서가 필요합니다.

지금 계정의 결과 탭 전환수와 주문 시스템 건수를 나란히 놓고 비교해 보신 적이 있으신가요?

위그로스는 퍼포먼스 계정 진단을 통해 픽셀·전환 API 연동 상태와 이벤트 매칭 조건을 함께 점검하고, 실제 주문 데이터와 광고 관리자 수치의 차이를 항목별로 확인해 드립니다. 전환 집계 구조 자체를 처음부터 다시 설계해야 하는 계정도 있고, event_id 필드 하나만 수정하면 되는 계정도 있어 진단을 통한 정확한 원인 확인이 필요합니다.


📢 더 많은 마케팅 실무 팁과 트렌드가 궁금하다면?

실무에서 바로 활용 가능한 데이터 분석 노하우부터 마케팅 실무자들과의 실시간 네트워킹, 유용한 학습 자료까지 아낌없이 나누어 드립니다. 혼자 고민하지 말고 함께 공부하며 빠르게 성장해 봐요!

위그로스아카데미 디스코드 커뮤니티 참여하기

위그로스아카데미 교육 문의하기



메타 픽셀과 전환 API(CAPI)를 함께 연동하면 같은 구매나 리드가 두 경로로 각각 전송되어 광고 관리자에 이중으로 집계될 수 있습니다. 메타는 이벤트 이름과 event_id가 동일하고 첫 이벤트 수신 후 48시간 이내에 도착한 이벤트만 하나로 합쳐 처리합니다. event_id를 픽셀과 서버 양쪽에 동일하게 전달하지 않으면 이 조건이 성립하지 않아 중복 집계가 그대로 남습니다.

증상: 전환수가 주문 건수보다 많게 나온다면

광고 관리자 결과 탭에서 구매 전환수를 확인했는데 실제 쇼핑몰 관리자의 당일 주문 건수보다 많게 나오는 경우가 있습니다. 전환 값 합계가 같은 기간 매출액보다 크게 잡히거나, 캠페인 두 개 이상에서 같은 주문이 각각 잡혀 총합이 부풀어 보이는 경우도 있습니다. 픽셀만 쓰다가 전환 API를 새로 연동한 시점부터 이런 차이가 시작됐다면 두 신호가 겹쳐 잡혔을 가능성이 있습니다.

이런 상황에서 많은 담당자가 먼저 픽셀 코드를 지우고 재설치하거나, 전환 API 연동 자체를 끄고 픽셀 하나만 남기는 방식으로 대응합니다. 두 신호 중 하나를 없애면 전환수는 줄어들지만, 픽셀만 남기면 iOS 브라우저 차단이나 광고 차단 프로그램으로 놓치는 전환이 다시 늘어납니다. 문제는 픽셀과 전환 API를 같이 쓰는 것 자체가 아니라, 메타가 두 신호를 하나의 행동으로 합칠 조건이 충족되지 않은 것이므로 신호를 지우기 전에 이 조건부터 점검하는 순서가 필요합니다.

이번 글에서는 픽셀과 전환 API 이벤트가 중복 집계되는 판정 기준과, 계정에서 이 조건이 충족되고 있는지 확인하는 방법을 살펴보겠습니다.

출처: Convert Your Tracking with the Facebook Conversions API

1. 픽셀과 전환 API, 이벤트 중복이란

메타 픽셀은 웹사이트에 설치되어 브라우저에서 발생한 이벤트를 메타 서버로 전송하는 코드입니다. 전환 API(Conversions API)는 광고주의 서버에서 이벤트 데이터를 메타 서버로 직접 전송하는 방식입니다. 이벤트 중복은 동일한 실제 행동(같은 구매, 같은 리드 제출)이 픽셀과 전환 API 양쪽에서 각각 별도 이벤트로 집계되는 상태를 말합니다.

표1. 전송 방식별 특성 비교

전송 방식

데이터 발생 위치

브라우저 차단 영향

단독 사용 시 중복 위험

픽셀 단독

방문자 브라우저

광고 차단 프로그램, ITP 등에 영향받음

없음

전환 API 단독

광고주 서버

영향받지 않음

없음

픽셀 + 전환 API 병행

브라우저와 서버 동시

서버 이벤트로 손실분 보완

event_id 미설정 시 발생

2. event_id가 왜 필요한가

출처: Top 5 Meta Pixel Mistakes (and How to Fix Them)

픽셀과 전환 API를 함께 쓰면 같은 구매가 브라우저 신호와 서버 신호로 동시에 도착합니다. 메타 입장에서는 두 신호가 같은 행동을 가리키는지 스스로 판단할 방법이 없으므로, 광고주가 지정한 식별자로 두 이벤트를 하나로 합칠지 판정하는 절차가 필요합니다. Meta 픽셀과 전환 API 중복 제거 안내 – Meta for Developers에 따르면 이 판정은 두 조건이 모두 충족될 때만 성립합니다.

첫째, 픽셀의 eventID 파라미터와 서버 이벤트의 event_id 필드 값이 문자열 그대로 일치해야 합니다. 둘째, 픽셀의 event 이름과 서버의 event_name이 일치해야 합니다. 여기에 시간 조건도 함께 적용되어, 두 이벤트는 첫 이벤트가 수신된 시점으로부터 48시간 이내에 도착한 경우에만 하나로 합쳐지며 이 시간을 넘기면 별도 이벤트로 각각 집계됩니다.

표2. event_id 값에 따른 처리 결과 예시

아래 값은 이해를 돕기 위해 임의로 구성한 예시입니다. 실제 계정의 값과는 다를 수 있습니다.

픽셀 event_id

서버 event_id

event_name 일치 여부

수신 시간차

처리 결과

evt_1001

evt_1001

일치(Purchase)

3초

1건으로 병합

evt_1002

(미전달)

일치(Purchase)

5초

2건으로 각각 집계

evt_1003

evt_1099

일치(Purchase)

2초

2건으로 각각 집계(ID 불일치)

evt_1004

evt_1004

일치(Purchase)

50시간

2건으로 각각 집계(48시간 초과)

표2에서 보듯 event_id가 같은 값으로 전달되었더라도 48시간이라는 시간 조건을 넘기면 병합되지 않습니다. 반대로 event_id가 같고 이름도 같더라도 서버 쪽 event_id 필드 자체가 비어 있다면 애초에 비교할 값이 없어 병합 조건이 성립하지 않습니다.

3. 계정에서 확인할 점검 항목

픽셀 코드 점검: 구매·리드 등 주요 이벤트 트리거 코드에 eventID 파라미터가 포함되어 있는지 확인합니다. eventID가 지정되어 있다면 서버 쪽 값과 비교할 수 있는 상태이고, 지정되어 있지 않다면 픽셀 이벤트는 항상 별도로 집계되는 상태입니다.

서버(전환 API) 이벤트 점검: 서버에서 보내는 이벤트 페이로드에 event_id, event_name, event_time, action_source 필드가 모두 채워져 있는지 확인합니다. event_id 필드가 비어 있거나 이벤트마다 새로 생성되는 임의 값이라면 픽셀 쪽 값과 절대 일치할 수 없습니다.

동일 행동에 대한 event_id 값 비교: 같은 주문 한 건에 대해 픽셀과 서버가 실제로 같은 event_id 문자열을 쓰는지 개발 환경에서 직접 대조합니다. 주문 번호나 트랜잭션 ID처럼 프론트엔드와 백엔드가 동시에 접근 가능한 값을 event_id로 쓰고 있다면 일치 가능성이 높고, 프론트엔드에서만 생성되는 임시 값을 쓰고 있다면 서버로 전달되지 않아 불일치할 가능성이 높습니다.

데이터 소스(픽셀 ID) 점검: 픽셀 이벤트와 서버 이벤트가 동일한 픽셀 ID를 대상으로 전송되고 있는지 확인합니다. 서버 이벤트가 다른 픽셀 ID로 전송되고 있다면 event_id가 정확히 일치해도 애초에 같은 데이터 소스로 집계되지 않습니다.

표3. 중복 집계 점검 프로세스

단계

수행 활동

목적

1단계

광고 관리자 결과와 주문 시스템 건수 대조

중복 집계 발생 여부 1차 확인

2단계

픽셀·서버 코드에서 event_id 전달 여부 확인

병합 조건 중 ID 존재 여부 점검

3단계

동일 주문 기준 event_id·event_name 값 대조

두 신호가 같은 값을 쓰는지 점검

4단계

수정 후 일정 기간 결과 대비 주문 건수 재비교

병합 조건 적용 여부 확인

[위그로스 실무 사례 삽입 지점 — 병행 연동 전후 전환수와 실제 주문 건수 대비표, 수정 적용 시점, 개선폭 데이터 필요]

4. 자가 진단 체크리스트

다음 항목을 순서대로 확인합니다.

  1. 픽셀과 전환 API를 동시에 연동하고 있다.

  2. 최근 결과(전환수)가 주문 시스템 건수보다 많게 나온 적이 있다.

  3. 픽셀 이벤트 코드에 eventID 파라미터가 없다.

  4. 서버 이벤트 페이로드에 event_id 필드가 비어 있거나 매번 새로 생성된다.

  5. 픽셀과 서버가 서로 다른 값 체계(예: 세션 ID vs 주문번호)로 event_id를 만들고 있다.

  6. 서버 이벤트 전송이 첫 픽셀 이벤트 수신 후 48시간을 넘겨 지연되는 경우가 있다.

  7. 픽셀과 서버 이벤트가 서로 다른 픽셀 ID로 전송되고 있다.

  8. 최근 픽셀 코드나 전환 API 연동을 변경한 적이 있다.

즉시 조치 구간(5개 이상 해당): event_id를 주문번호나 트랜잭션 ID 등 프론트·백엔드가 동시에 참조 가능한 값으로 통일하고, 픽셀과 서버 코드 양쪽에 동일하게 전달되도록 수정합니다. 수정을 반영한 이벤트가 쌓이기 시작하면 3~4일 뒤 결과와 주문 건수를 다시 대조합니다.

관찰 구간(2~4개 해당): event_id는 전달되고 있으나 값 체계가 일부 이벤트에서만 어긋나는 경우이므로, 이벤트 종류별로 event_id 생성 로직을 점검합니다. 2~3주 뒤 이벤트 종류별 결과와 주문 건수를 다시 비교합니다.

정상 구간(1개 이하 해당): event_id·event_name이 양쪽에서 일치하고 결과와 주문 건수 차이도 크지 않은 상태이므로, 별도 조치 없이 다음 분기 정기 점검 때 재확인합니다.

5. FAQ

Q1. event_id를 아예 안 쓰면 어떻게 되나요?

event_id 없이 픽셀과 전환 API를 함께 쓰면 event_name만으로는 병합 조건이 성립하지 않아 같은 행동이 두 건으로 각각 집계됩니다.

Q2. 서버 이벤트만 남기고 픽셀을 꺼도 되나요?

가능하지만 방문자 행동 데이터 일부를 서버에서 재현하지 못하는 이벤트(스크롤, 페이지뷰 등)는 픽셀에서만 수집되는 경우가 있어 함께 검토해야 합니다.

Q3. event_id는 매번 새로 만들어도 되나요?

동일한 실제 행동에 대해서는 픽셀과 서버가 같은 event_id 값을 써야 병합되므로, 행동마다 고유하되 두 경로에서 재현 가능한 값(주문번호 등)을 써야 합니다.

Q4. 48시간이 지나면 중복 집계된 값은 되돌릴 수 없나요?

이미 별도로 집계된 과거 이벤트는 소급 병합되지 않으므로, 앞으로 발생하는 이벤트부터 event_id 조건을 맞추는 방식으로 접근해야 합니다.

6. 핵심 요약

출처: Conversions API vs Meta Pixel: What Is the Difference and Which Should You Use?

  • 메타는 event_id 일치, event_name 일치, 48시간 이내 수신이라는 세 조건이 모두 충족될 때만 픽셀과 전환 API 이벤트를 하나로 합칩니다.

  • event_id가 비어 있거나 두 경로에서 서로 다른 값을 쓰면 같은 행동이 두 건으로 각각 집계됩니다.

  • 픽셀 코드와 서버 페이로드 양쪽의 event_id·event_name 필드를 실제 값 단위로 대조하는 것이 1차 점검입니다.

  • 수정 반영 후에는 즉시 조치 구간은 며칠, 관찰 구간은 몇 주 단위로 결과와 주문 건수를 재비교합니다.

  • 신호를 끄기 전에 병합 조건 충족 여부부터 확인하는 순서가 필요합니다.

신호를 늘리기 전에 그 신호들이 하나로 합쳐질 조건부터 맞추는 순서가 필요합니다.

지금 계정의 결과 탭 전환수와 주문 시스템 건수를 나란히 놓고 비교해 보신 적이 있으신가요?

위그로스는 퍼포먼스 계정 진단을 통해 픽셀·전환 API 연동 상태와 이벤트 매칭 조건을 함께 점검하고, 실제 주문 데이터와 광고 관리자 수치의 차이를 항목별로 확인해 드립니다. 전환 집계 구조 자체를 처음부터 다시 설계해야 하는 계정도 있고, event_id 필드 하나만 수정하면 되는 계정도 있어 진단을 통한 정확한 원인 확인이 필요합니다.


📢 더 많은 마케팅 실무 팁과 트렌드가 궁금하다면?

실무에서 바로 활용 가능한 데이터 분석 노하우부터 마케팅 실무자들과의 실시간 네트워킹, 유용한 학습 자료까지 아낌없이 나누어 드립니다. 혼자 고민하지 말고 함께 공부하며 빠르게 성장해 봐요!

위그로스아카데미 디스코드 커뮤니티 참여하기

위그로스아카데미 교육 문의하기



메타 픽셀과 전환 API(CAPI)를 함께 연동하면 같은 구매나 리드가 두 경로로 각각 전송되어 광고 관리자에 이중으로 집계될 수 있습니다. 메타는 이벤트 이름과 event_id가 동일하고 첫 이벤트 수신 후 48시간 이내에 도착한 이벤트만 하나로 합쳐 처리합니다. event_id를 픽셀과 서버 양쪽에 동일하게 전달하지 않으면 이 조건이 성립하지 않아 중복 집계가 그대로 남습니다.

증상: 전환수가 주문 건수보다 많게 나온다면

광고 관리자 결과 탭에서 구매 전환수를 확인했는데 실제 쇼핑몰 관리자의 당일 주문 건수보다 많게 나오는 경우가 있습니다. 전환 값 합계가 같은 기간 매출액보다 크게 잡히거나, 캠페인 두 개 이상에서 같은 주문이 각각 잡혀 총합이 부풀어 보이는 경우도 있습니다. 픽셀만 쓰다가 전환 API를 새로 연동한 시점부터 이런 차이가 시작됐다면 두 신호가 겹쳐 잡혔을 가능성이 있습니다.

이런 상황에서 많은 담당자가 먼저 픽셀 코드를 지우고 재설치하거나, 전환 API 연동 자체를 끄고 픽셀 하나만 남기는 방식으로 대응합니다. 두 신호 중 하나를 없애면 전환수는 줄어들지만, 픽셀만 남기면 iOS 브라우저 차단이나 광고 차단 프로그램으로 놓치는 전환이 다시 늘어납니다. 문제는 픽셀과 전환 API를 같이 쓰는 것 자체가 아니라, 메타가 두 신호를 하나의 행동으로 합칠 조건이 충족되지 않은 것이므로 신호를 지우기 전에 이 조건부터 점검하는 순서가 필요합니다.

이번 글에서는 픽셀과 전환 API 이벤트가 중복 집계되는 판정 기준과, 계정에서 이 조건이 충족되고 있는지 확인하는 방법을 살펴보겠습니다.

출처: Convert Your Tracking with the Facebook Conversions API

1. 픽셀과 전환 API, 이벤트 중복이란

메타 픽셀은 웹사이트에 설치되어 브라우저에서 발생한 이벤트를 메타 서버로 전송하는 코드입니다. 전환 API(Conversions API)는 광고주의 서버에서 이벤트 데이터를 메타 서버로 직접 전송하는 방식입니다. 이벤트 중복은 동일한 실제 행동(같은 구매, 같은 리드 제출)이 픽셀과 전환 API 양쪽에서 각각 별도 이벤트로 집계되는 상태를 말합니다.

표1. 전송 방식별 특성 비교

전송 방식

데이터 발생 위치

브라우저 차단 영향

단독 사용 시 중복 위험

픽셀 단독

방문자 브라우저

광고 차단 프로그램, ITP 등에 영향받음

없음

전환 API 단독

광고주 서버

영향받지 않음

없음

픽셀 + 전환 API 병행

브라우저와 서버 동시

서버 이벤트로 손실분 보완

event_id 미설정 시 발생

2. event_id가 왜 필요한가

출처: Top 5 Meta Pixel Mistakes (and How to Fix Them)

픽셀과 전환 API를 함께 쓰면 같은 구매가 브라우저 신호와 서버 신호로 동시에 도착합니다. 메타 입장에서는 두 신호가 같은 행동을 가리키는지 스스로 판단할 방법이 없으므로, 광고주가 지정한 식별자로 두 이벤트를 하나로 합칠지 판정하는 절차가 필요합니다. Meta 픽셀과 전환 API 중복 제거 안내 – Meta for Developers에 따르면 이 판정은 두 조건이 모두 충족될 때만 성립합니다.

첫째, 픽셀의 eventID 파라미터와 서버 이벤트의 event_id 필드 값이 문자열 그대로 일치해야 합니다. 둘째, 픽셀의 event 이름과 서버의 event_name이 일치해야 합니다. 여기에 시간 조건도 함께 적용되어, 두 이벤트는 첫 이벤트가 수신된 시점으로부터 48시간 이내에 도착한 경우에만 하나로 합쳐지며 이 시간을 넘기면 별도 이벤트로 각각 집계됩니다.

표2. event_id 값에 따른 처리 결과 예시

아래 값은 이해를 돕기 위해 임의로 구성한 예시입니다. 실제 계정의 값과는 다를 수 있습니다.

픽셀 event_id

서버 event_id

event_name 일치 여부

수신 시간차

처리 결과

evt_1001

evt_1001

일치(Purchase)

3초

1건으로 병합

evt_1002

(미전달)

일치(Purchase)

5초

2건으로 각각 집계

evt_1003

evt_1099

일치(Purchase)

2초

2건으로 각각 집계(ID 불일치)

evt_1004

evt_1004

일치(Purchase)

50시간

2건으로 각각 집계(48시간 초과)

표2에서 보듯 event_id가 같은 값으로 전달되었더라도 48시간이라는 시간 조건을 넘기면 병합되지 않습니다. 반대로 event_id가 같고 이름도 같더라도 서버 쪽 event_id 필드 자체가 비어 있다면 애초에 비교할 값이 없어 병합 조건이 성립하지 않습니다.

3. 계정에서 확인할 점검 항목

픽셀 코드 점검: 구매·리드 등 주요 이벤트 트리거 코드에 eventID 파라미터가 포함되어 있는지 확인합니다. eventID가 지정되어 있다면 서버 쪽 값과 비교할 수 있는 상태이고, 지정되어 있지 않다면 픽셀 이벤트는 항상 별도로 집계되는 상태입니다.

서버(전환 API) 이벤트 점검: 서버에서 보내는 이벤트 페이로드에 event_id, event_name, event_time, action_source 필드가 모두 채워져 있는지 확인합니다. event_id 필드가 비어 있거나 이벤트마다 새로 생성되는 임의 값이라면 픽셀 쪽 값과 절대 일치할 수 없습니다.

동일 행동에 대한 event_id 값 비교: 같은 주문 한 건에 대해 픽셀과 서버가 실제로 같은 event_id 문자열을 쓰는지 개발 환경에서 직접 대조합니다. 주문 번호나 트랜잭션 ID처럼 프론트엔드와 백엔드가 동시에 접근 가능한 값을 event_id로 쓰고 있다면 일치 가능성이 높고, 프론트엔드에서만 생성되는 임시 값을 쓰고 있다면 서버로 전달되지 않아 불일치할 가능성이 높습니다.

데이터 소스(픽셀 ID) 점검: 픽셀 이벤트와 서버 이벤트가 동일한 픽셀 ID를 대상으로 전송되고 있는지 확인합니다. 서버 이벤트가 다른 픽셀 ID로 전송되고 있다면 event_id가 정확히 일치해도 애초에 같은 데이터 소스로 집계되지 않습니다.

표3. 중복 집계 점검 프로세스

단계

수행 활동

목적

1단계

광고 관리자 결과와 주문 시스템 건수 대조

중복 집계 발생 여부 1차 확인

2단계

픽셀·서버 코드에서 event_id 전달 여부 확인

병합 조건 중 ID 존재 여부 점검

3단계

동일 주문 기준 event_id·event_name 값 대조

두 신호가 같은 값을 쓰는지 점검

4단계

수정 후 일정 기간 결과 대비 주문 건수 재비교

병합 조건 적용 여부 확인

[위그로스 실무 사례 삽입 지점 — 병행 연동 전후 전환수와 실제 주문 건수 대비표, 수정 적용 시점, 개선폭 데이터 필요]

4. 자가 진단 체크리스트

다음 항목을 순서대로 확인합니다.

  1. 픽셀과 전환 API를 동시에 연동하고 있다.

  2. 최근 결과(전환수)가 주문 시스템 건수보다 많게 나온 적이 있다.

  3. 픽셀 이벤트 코드에 eventID 파라미터가 없다.

  4. 서버 이벤트 페이로드에 event_id 필드가 비어 있거나 매번 새로 생성된다.

  5. 픽셀과 서버가 서로 다른 값 체계(예: 세션 ID vs 주문번호)로 event_id를 만들고 있다.

  6. 서버 이벤트 전송이 첫 픽셀 이벤트 수신 후 48시간을 넘겨 지연되는 경우가 있다.

  7. 픽셀과 서버 이벤트가 서로 다른 픽셀 ID로 전송되고 있다.

  8. 최근 픽셀 코드나 전환 API 연동을 변경한 적이 있다.

즉시 조치 구간(5개 이상 해당): event_id를 주문번호나 트랜잭션 ID 등 프론트·백엔드가 동시에 참조 가능한 값으로 통일하고, 픽셀과 서버 코드 양쪽에 동일하게 전달되도록 수정합니다. 수정을 반영한 이벤트가 쌓이기 시작하면 3~4일 뒤 결과와 주문 건수를 다시 대조합니다.

관찰 구간(2~4개 해당): event_id는 전달되고 있으나 값 체계가 일부 이벤트에서만 어긋나는 경우이므로, 이벤트 종류별로 event_id 생성 로직을 점검합니다. 2~3주 뒤 이벤트 종류별 결과와 주문 건수를 다시 비교합니다.

정상 구간(1개 이하 해당): event_id·event_name이 양쪽에서 일치하고 결과와 주문 건수 차이도 크지 않은 상태이므로, 별도 조치 없이 다음 분기 정기 점검 때 재확인합니다.

5. FAQ

Q1. event_id를 아예 안 쓰면 어떻게 되나요?

event_id 없이 픽셀과 전환 API를 함께 쓰면 event_name만으로는 병합 조건이 성립하지 않아 같은 행동이 두 건으로 각각 집계됩니다.

Q2. 서버 이벤트만 남기고 픽셀을 꺼도 되나요?

가능하지만 방문자 행동 데이터 일부를 서버에서 재현하지 못하는 이벤트(스크롤, 페이지뷰 등)는 픽셀에서만 수집되는 경우가 있어 함께 검토해야 합니다.

Q3. event_id는 매번 새로 만들어도 되나요?

동일한 실제 행동에 대해서는 픽셀과 서버가 같은 event_id 값을 써야 병합되므로, 행동마다 고유하되 두 경로에서 재현 가능한 값(주문번호 등)을 써야 합니다.

Q4. 48시간이 지나면 중복 집계된 값은 되돌릴 수 없나요?

이미 별도로 집계된 과거 이벤트는 소급 병합되지 않으므로, 앞으로 발생하는 이벤트부터 event_id 조건을 맞추는 방식으로 접근해야 합니다.

6. 핵심 요약

출처: Conversions API vs Meta Pixel: What Is the Difference and Which Should You Use?

  • 메타는 event_id 일치, event_name 일치, 48시간 이내 수신이라는 세 조건이 모두 충족될 때만 픽셀과 전환 API 이벤트를 하나로 합칩니다.

  • event_id가 비어 있거나 두 경로에서 서로 다른 값을 쓰면 같은 행동이 두 건으로 각각 집계됩니다.

  • 픽셀 코드와 서버 페이로드 양쪽의 event_id·event_name 필드를 실제 값 단위로 대조하는 것이 1차 점검입니다.

  • 수정 반영 후에는 즉시 조치 구간은 며칠, 관찰 구간은 몇 주 단위로 결과와 주문 건수를 재비교합니다.

  • 신호를 끄기 전에 병합 조건 충족 여부부터 확인하는 순서가 필요합니다.

신호를 늘리기 전에 그 신호들이 하나로 합쳐질 조건부터 맞추는 순서가 필요합니다.

지금 계정의 결과 탭 전환수와 주문 시스템 건수를 나란히 놓고 비교해 보신 적이 있으신가요?

위그로스는 퍼포먼스 계정 진단을 통해 픽셀·전환 API 연동 상태와 이벤트 매칭 조건을 함께 점검하고, 실제 주문 데이터와 광고 관리자 수치의 차이를 항목별로 확인해 드립니다. 전환 집계 구조 자체를 처음부터 다시 설계해야 하는 계정도 있고, event_id 필드 하나만 수정하면 되는 계정도 있어 진단을 통한 정확한 원인 확인이 필요합니다.


📢 더 많은 마케팅 실무 팁과 트렌드가 궁금하다면?

실무에서 바로 활용 가능한 데이터 분석 노하우부터 마케팅 실무자들과의 실시간 네트워킹, 유용한 학습 자료까지 아낌없이 나누어 드립니다. 혼자 고민하지 말고 함께 공부하며 빠르게 성장해 봐요!

위그로스아카데미 디스코드 커뮤니티 참여하기

위그로스아카데미 교육 문의하기



Read More

Read More

위그로스 Wegrowth®

대표: 이성봉 l 사업자등록번호: 518-71-00476 l  주소: 서울시 강남구 테헤란로128, 2층

이메일: contact@wegrowth.kr   l   통신판매업신고: 2023-서울강남-04765

Copyright ©2026 WEGROWTH® All rights reserved.

위그로스 Wegrowth®

대표: 이성봉 l 사업자등록번호: 518-71-00476

주소: 서울시 강남구 테헤란로128, 2층 222호

이메일: contact@wegrowth.kr

통신판매업신고: 2023-서울강남-04765

Copyright ©2026 WEGROWTH® All rights reserved.

위그로스 Wegrowth®

대표: 이성봉 l 사업자등록번호: 518-71-00476 l  주소: 서울시 강남구 테헤란로128, 2층

이메일: contact@wegrowth.kr   l   통신판매업신고: 2023-서울강남-04765

Copyright ©2026 WEGROWTH® All rights reserved.