문제가 드러나는 전형적인 패턴

CAPI와 픽셀을 동시에 켠 계정에서 중복제거가 깨지면, 처음에는 오히려 좋은 신호처럼 보입니다. 전환수가 갑자기 늘고 CPA가 낮아진 것처럼 리포트에 찍히기 때문입니다. 문제는 이 착시가 실제 매출·주문 데이터와 비교하지 않으면 한동안 발견되지 않는다는 점입니다. 실무에서 흔히 나타나는 흐름은 이렇습니다 — 광고 리포트상 구매전환수는 늘었는데 실제 매출(자사 주문 시스템 기준)은 그대로이고, 광고 관리자가 CPA 개선을 이유로 예산을 늘렸는데도 실질 매출은 따라오지 않는 상황입니다. 이 시점에 이벤트 관리자의 이벤트 진단(Diagnostics) 탭을 열어보면, 동일 이벤트가 Browser·Server 두 소스로 각각 집계되고 중복제거 표시가 없는 것이 확인됩니다.

원인은 대개 event_id 생성 로직에 있다

가장 흔한 원인 세 가지는 4강에서 다룬 내용과 그대로 이어집니다. 첫째는 결제대행사(PG사) 웹훅이 네트워크 재시도로 같은 결제 건을 두 번 보내고, 서버가 이를 별도 이벤트로 처리해 매번 새 event_id를 만드는 경우입니다. 둘째는 프론트엔드가 주문번호 확정 전에 임시 세션 ID로 event_id를 먼저 생성해버려, 백엔드가 나중에 만드는 실제 event_id와 값이 어긋나는 경우입니다. 셋째는 단일 페이지 애플리케이션(SPA) 구조에서 결제완료 화면이 리로드 없이 렌더링될 때 픽셀 이벤트 자체가 여러 번 발동해, 같은 event_id를 쓰더라도 애초에 여러 건의 픽셀 이벤트가 발생하는 경우입니다.

이 세 경우 모두 겉보기 증상은 비슷하지만(전환수 2배 근접) 수정 지점은 다릅니다. 첫 번째는 웹훅 수신 로직에 멱등성 체크를 추가해야 하고, 두 번째는 event_id 생성 책임을 프론트엔드와 백엔드 중 한쪽으로 통일해야 하며, 세 번째는 픽셀 이벤트 발동 조건을 URL 변경이 아니라 결제완료 API 응답 시점 단 한 번으로 재설계해야 합니다.

부풀려진 전환이 머신러닝에 미치는 피해

메타의 광고 최적화 알고리즘은 전환 이벤트를 학습 신호로 삼아 어떤 사용자에게, 어떤 입찰가로, 어떤 소재를 보여줄지 결정합니다. 실제로는 100건인 구매가 200건으로 잡히면, 알고리즘은 실제보다 훨씬 낮은 CPA로 전환이 발생하고 있다고 오판하고 그 패턴에 맞춰 타겟팅과 입찰을 재조정합니다. 이 왜곡된 학습 데이터가 누적되면 실제로는 전환 가능성이 낮은 사용자군에 예산이 쏠리고, 학습 데이터를 다시 신뢰할 수 있는 수준으로 되돌리기까지 상당한 시간이 걸립니다.

복구 절차: 진단 → 수정 → 재학습 관리

복구는 세 단계로 진행합니다. 먼저 이벤트 진단 탭과 서버 로그를 대조해 어느 경로에서 event_id가 어긋나는지 정확히 특정합니다. 다음으로 위에서 정리한 세 가지 원인 중 해당하는 지점의 코드를 수정하고, 테스트 이벤트 도구(6강 참조)로 수정 후 event_id가 두 경로에서 동일하게 생성되는지 반드시 재확인합니다. 마지막으로, 부풀려진 학습 데이터로 인해 광고 세트가 비정상적인 학습 상태에 있었다면 수정 직후 일정 기간은 예산·타겟팅을 크게 건드리지 않고 안정화 기간을 두는 것이 필요합니다. 급하게 예산을 되돌리거나 소재를 대거 교체하면 학습 단계가 다시 리셋되어 회복이 더 늦어집니다.

재발 방지: 사고 후 무엇을 루틴으로 남겨야 하나

한 번 이런 사고를 겪은 팀은 사후 대응만 하고 끝내지 말고, 재발을 막는 점검 루틴을 남겨야 합니다. 가장 효과적인 방법은 이벤트 관리자의 진단 탭에서 중복제거율을 주간 단위로 확인하는 항목을 광고 운영 체크리스트에 정식으로 포함시키는 것입니다. 또한 PG사·쇼핑몰 솔루션·프론트엔드 배포 등 결제 흐름과 관련된 시스템이 바뀔 때마다 event_id 생성 로직에 영향이 없는지 확인하는 절차를 배포 체크리스트에 명시해두면, 이번 사례처럼 조용히 몇 주간 데이터가 오염되는 상황을 초기에 잡아낼 수 있습니다. 광고 성과 지표(CPA, ROAS)만 보는 것이 아니라 광고 리포트 전환수와 자사 주문 시스템의 실제 매출을 정기적으로 대조하는 습관도 이런 사고를 가장 빨리 발견하는 방법 중 하나입니다.