구매 이벤트가 두 배로 찍혀요, 부풀린 전환을 진단하는 순서

어느 날 갑자기 광고 관리자 ROAS가 평소보다 두 배 가까이 좋아졌다면, 좋아하기 전에 한 번 의심해보셔야 해요. 실제로 상품이 갑자기 두 배로 팔린 게 아니라면, 구매 이벤트가 중복으로 찍히고 있을 가능성이 커요. 저도 한 번은 별다른 프로모션도 없었는데 하루아침에 전환수가 확 뛰어서 신났다가, 실제 주문관리 시스템을 확인하고는 허탈했던 적이 있어요. 주문 건수는 그대로인데 광고 관리자에만 두 배로 찍히고 있었던 거예요. 이 글에서는 구매 이벤트가 왜 중복으로 찍히는지, 그리고 원인을 어떤 순서로 좁혀가야 빠르게 찾을 수 있는지 정리해드릴게요.

구매 이벤트 중복이 왜 위험한가

구매 이벤트가 중복으로 찍히면 가장 먼저 광고 성과 판단이 완전히 왜곡돼요. 실제로는 ROAS 2인 캠페인이 4로 보이니까, 손해를 보고 있는 캠페인에 예산을 더 밀어주는 결정을 하게 돼요. 두 번째로 광고 플랫폼의 머신러닝 학습도 왜곡돼요. 가짜로 부풀려진 전환 데이터를 학습한 시스템은 실제로는 전환이 잘 안 나오는 타겟에게 계속 광고를 뿌리게 되고, 결국 진짜 효율은 떨어지는데 리포트만 좋아 보이는 상황이 이어져요.

세 번째 문제는 발견이 늦어질수록 피해가 누적된다는 점이에요. 중복 집계는 한 번 발생하면 며칠, 몇 주씩 계속 같은 방식으로 반복되는 경우가 많아요. 매일 조금씩 왜곡된 데이터를 근거로 광고비를 늘려가다 보면, 나중에 문제를 발견했을 때는 이미 상당한 예산이 잘못된 판단으로 쓰인 뒤예요. 그래서 평소와 다른 이상 신호가 보이면 축하하기 전에 먼저 의심하고 확인하는 습관이 필요해요. 네 번째로 이 왜곡된 숫자를 근거로 대행사 성과를 평가하거나 인센티브를 지급하는 구조라면, 잘못된 판단이 돈으로 직결되는 문제까지 생길 수 있어요. 그래서 중요한 의사결정 앞에서는 항상 실제 주문관리 데이터를 한 번 더 대조해보는 습관을 들이시는 게 안전해요.

원인 후보 1, 새로고침과 뒤로가기

가장 흔한 원인은 결제 완료 페이지에서 고객이 새로고침을 누르거나 뒤로가기 후 다시 앞으로가기를 하는 경우예요. 결제 완료 페이지에 구매 이벤트 코드가 심어져 있으면, 페이지가 다시 로드될 때마다 그 이벤트가 다시 발화돼요. 결제 확인차 페이지를 새로고침하는 고객이 생각보다 많고, 특히 모바일에서 뒤로가기와 앞으로가기를 반복하는 습관을 가진 고객도 적지 않아요. 배송 조회 링크를 결제완료 페이지에 그대로 노출해둔 경우도 은근히 많은데, 고객이 이 링크를 눌렀다가 다시 뒤로가기로 돌아오는 동작만으로도 이벤트가 재발화되는 사례를 종종 봐요.

이 문제는 이벤트가 오직 첫 로드 시에만 한 번 발화하도록 구현되어 있는지 확인하면 금방 찾을 수 있어요. 주문번호를 기준으로 이미 전송된 이벤트인지 체크하는 로직이 없다면, 새로고침 한 번에 이벤트가 다시 쏘아지는 구조일 가능성이 커요. 특히 결제 완료 페이지를 이메일이나 문자로 다시 열어보는 고객이 있다면 그때마다 또 발화되는 경우도 있어서, 생각보다 원인 중 이 케이스의 비중이 꽤 커요.

• 결제 완료 페이지 새로고침만으로 구매 이벤트가 재발화될 수 있어요.
• 모바일 뒤로가기, 앞으로가기 반복도 같은 문제를 만들어요.
• 주문번호 기준 중복 방지 로직이 없으면 이 문제가 계속 반복돼요.
• 결제 완료 링크를 나중에 다시 열어봐도 재발화되는 경우가 있어요.

원인 후보 2, 픽셀과 서버 이벤트 이중 발화

브라우저 픽셀과 서버 전송(CAPI)을 동시에 쓰는 경우, 둘을 같은 이벤트로 묶어주는 이벤트ID가 다르게 들어가면 완전히 별개의 두 이벤트로 잡혀요. 이건 CAPI를 새로 연동한 직후에 특히 자주 생기는 문제예요. 개발팀이 서버 쪽 이벤트ID 생성 로직과 프론트엔드 픽셀 쪽 이벤트ID 생성 로직을 따로 짜다 보면, 겉보기엔 둘 다 잘 작동하는데 실제로는 짝이 안 맞아서 메타가 중복 제거를 못 하는 상황이 생겨요.

이 원인은 메타 이벤트 관리자의 이벤트 세부정보에서 확인할 수 있어요. 같은 주문인데 브라우저 소스와 서버 소스가 각각 다른 이벤트ID로 찍혀 있다면 바로 이 문제예요. 특히 CAPI를 새로 연동한 날짜와 ROAS가 이상하게 좋아진 날짜가 겹친다면, 십중팔구 이게 원인일 가능성이 커요. 연동 작업을 한 개발자나 대행사에 이벤트ID 생성 방식을 양쪽에서 통일했는지 바로 확인해보셔야 해요. 특히 여러 명이 나눠서 개발한 경우, 프론트엔드 담당자와 백엔드 담당자가 각자 편한 방식으로 이벤트ID를 만들어버리면 겉으로는 둘 다 정상 작동하는 것처럼 보여서 문제를 눈치채기가 더 어려워요.

원인 후보 3, 태그 중복 설치

구글 태그매니저를 쓰시는 경우, 같은 구매 이벤트 태그가 실수로 두 번 등록되어 있거나, 이전에 쓰던 태그를 지우지 않고 새 태그를 추가한 경우에도 중복이 생겨요. 특히 쇼핑몰 플랫폼을 이전하거나, 대행사를 교체하거나, 새로운 마케터가 합류해서 태그를 새로 세팅한 직후에 이 문제가 자주 나타나요. 예전 대행사가 심어둔 태그가 그대로 남아있는 상태에서 새 대행사가 또 태그를 심으면, 결제 완료 페이지 하나에 같은 목적의 태그가 두 개씩 발화되는 상황이 생겨요.

이 문제는 구글 태그매니저의 미리보기 모드로 결제 완료 페이지를 직접 열어보면 바로 확인할 수 있어요. 같은 구매 이벤트 태그가 두 번 발화되는 게 보이면 원인이 확정된 거예요. 코드를 직접 볼 줄 모르셔도, 미리보기 모드에서 발화된 태그 목록에 같은 이름의 태그가 몇 번 나오는지 세어보는 정도는 어렵지 않게 확인하실 수 있어요. 태그매니저 관리자 화면에서 작업공간의 버전 히스토리를 열어보시는 것도 도움이 돼요. 언제 어떤 태그가 추가되고 삭제됐는지 이력이 남아있어서, 최근에 누가 어떤 태그를 새로 심었는지 역추적하는 데 유용해요. 특히 여러 명이 같은 태그매니저 계정을 공유해서 쓰고 있다면, 이 버전 히스토리를 정기적으로 확인하는 습관이 중복 문제를 예방하는 데 큰 도움이 돼요.

단계별 진단 순서

원인이 여러 개일 수 있으니 순서대로 하나씩 확인하시는 게 가장 빠른 길이에요. 먼저 태그매니저 미리보기 모드로 결제 완료 페이지를 열어서 같은 이벤트 태그가 중복 발화되는지부터 확인하세요. 여기서 문제가 없다면, 메타 이벤트 관리자에서 같은 주문번호가 브라우저와 서버 양쪽에서 서로 다른 이벤트ID로 찍히고 있는지 확인하는 순서로 넘어가세요. 두 곳 다 문제가 없는데도 여전히 중복이 의심된다면, 결제 완료 페이지 코드 자체에 새로고침 방지 로직이 있는지 개발자에게 확인을 요청하시면 됩니다.

이 순서를 따르면 대부분의 경우 하루 이틀 안에 원인을 좁힐 수 있어요. 중요한 건 세 가지 원인을 동시에 다 뒤지려고 하지 마시고, 확률이 높은 순서대로 하나씩 소거해가시는 거예요. 저는 처음엔 세 가지를 동시에 확인하려다 오히려 뭐가 문제인지 더 헷갈렸는데, 순서를 정해두고 하나씩 확인하니까 훨씬 빠르게 원인을 찾을 수 있었어요.

재발 방지를 위한 운영 습관

원인을 한 번 찾아서 고쳤다고 안심하고 끝내면 같은 문제가 몇 달 뒤 다시 생기는 경우가 흔해요. 특히 대행사를 교체하거나, 쇼핑몰 플랫폼을 이전하거나, 새로운 마케터가 태그 작업을 하는 시점마다 중복 위험이 다시 높아져요. 그래서 이런 변화가 있을 때마다 태그매니저 미리보기로 결제완료 페이지를 다시 점검하는 걸 표준 절차로 만들어두시는 게 좋아요. 담당자가 바뀌어도 이 절차만 지켜지면 중복 문제를 훨씬 빨리 발견할 수 있어요.

또 하나 권해드리고 싶은 건 실제 주문건수와 광고 전환수를 비교하는 걸 월말에 한 번 몰아서 하지 마시고, 매주 짧게라도 확인하는 루틴으로 만드시는 거예요. 문제가 생긴 지 한 달이 지나서야 발견하면 그 사이 잘못된 판단으로 쓰인 광고비를 되돌릴 수 없지만, 매주 확인하면 늦어도 일주일 안에는 이상 신호를 잡아낼 수 있어요. 이 작은 습관 하나가 나중에 훨씬 큰 손실을 막아주는 역할을 해요.

• 대행사 교체, 플랫폼 이전, 담당자 변경 시점마다 태그를 다시 점검하는 걸 표준 절차로 만드세요.
• 월말 몰아보기 대신 매주 짧게 실제 주문과 광고 전환수를 비교하는 루틴을 만드세요.
• 중복을 고친 뒤에도 최소 일주일은 추이를 지켜보며 재발 여부를 확인하세요.
• 이 점검 절차를 문서로 정리해서 팀원이나 대행사와 함께 공유해두세요.