GTM 태그 중복 실행: 두 번 잡히는 원인 5가지와 진단 순서
전환 수가 실제 주문보다 눈에 띄게 많다면, 성과가 좋아진 게 아니라 태그가 두 번 실행되고 있을 가능성이 높습니다.
GTM 태그 중복 실행은 대부분 태그 하나의 설정 실수가 아닙니다. 설치 경로, 트리거 조합, 데이터 영역 push 중 한 곳이 겹쳐서 생깁니다.
그래서 먼저 볼 것은 태그 설정 화면이 아닙니다. 실제 값과 비교한 배수가 몇 배인지부터 확인하고, 그 배수로 원인을 좁히는 것이 가장 빠릅니다.
아래에서 중복 여부를 숫자로 확인하는 법, 원인 5가지, 실무 사례, 재발을 막는 설정 기준을 순서대로 설명합니다.
1. GTM 태그 중복 실행, 숫자로 먼저 확인하는 법
중복이 의심될 때 바로 GTM 태그 목록부터 여는 경우가 많습니다.
하지만 태그가 수십 개인 컨테이너에서는 화면만 봐서는 원인을 찾기 어렵습니다.
기준값과 비교한 배수를 먼저 계산하면 원인 후보가 절반 이하로 줄어듭니다.
실제 값과 비교하는 배수 기준
비교 기준이 되는 값은 측정 도구가 아니라 원본 시스템의 숫자여야 합니다.
구매라면 쇼핑몰 관리자의 주문 건수, 리드라면 CRM에 실제로 들어온 신청 건수입니다.
같은 기간, 같은 기준(취소 포함 여부까지)으로 맞춘 뒤 아래 표처럼 읽습니다.
측정값 ÷ 실제값 | 의심되는 원인 | 먼저 볼 곳 |
|---|---|---|
거의 정확히 2.0배 | 설치 경로 이중화 (같은 태그가 두 군데서 실행) | 사이트 소스, 플랫폼 기본 연동 설정 |
3.0배 이상 정수배 | 경로 이중화 + 트리거 겹침 동시 발생 | 설치 경로 → 트리거 순서로 |
1.1~1.9배 | 일부 페이지·일부 상황에서만 중복 | 완료 페이지 새로고침, SPA 페이지 전환, 특정 트리거 |
1.0배 근처인데 매체만 많음 | 태그 중복이 아니라 귀속 방식 차이 | 매체 어트리뷰션 설정 |
여기서 핵심은 정수배인지 아닌지입니다.
모든 전환이 정확히 두 번 잡히면 배수가 2.0에 붙습니다. 이건 사이트 전체에서 같은 태그가 두 번 실행된다는 뜻이라 설치 경로 문제일 확률이 높습니다.
반대로 1.3배, 1.6배처럼 애매하게 나오면 특정 조건에서만 중복이 생기는 겁니다. 이때는 사용자 행동(새로고침, 뒤로 가기)이나 특정 페이지 구조를 의심해야 합니다.
-> 배수가 정수에 가까우면 "어디에 설치됐나", 애매하면 "언제 실행되나"를 먼저 봅니다.
미리보기와 네트워크 탭으로 확정하기
배수로 후보를 좁혔다면 실제로 두 번 실행되는 장면을 확인해야 합니다.
① GTM 미리보기(Tag Assistant)
미리보기를 켜고 의심 페이지에 접속한 뒤, 왼쪽 이벤트 타임라인을 하나씩 눌러봅니다.
같은 태그가 'Container Loaded', 'DOM Ready', 'Window Loaded' 등 여러 이벤트에 걸쳐 'Tags Fired'에 반복으로 보이면 트리거 겹침입니다.
반대로 GTM 미리보기에서는 한 번만 실행되는데 실제 수치가 2배라면, GTM 밖에서 같은 태그가 또 실행되고 있는 겁니다.
② 브라우저 개발자 도구 네트워크 탭
GTM 미리보기는 GTM 안에서 일어난 일만 보여줍니다.
그래서 최종 확정은 네트워크 탭에서 합니다. GA4라면 collect?v=2, 메타 픽셀이라면 facebook.com/tr로 필터를 걸고 요청 수를 셉니다.
구매 완료 페이지 한 번 진입에 purchase 요청이 2개 나가면 중복이 확정입니다.
Tip: 요청의 측정 ID(G-로 시작하는 값)나 픽셀 ID가 서로 다른지도 같이 보세요. ID가 다르면 중복이 아니라 서로 다른 두 속성으로 각각 보내는 것이라 의도된 설정일 수 있습니다.
GTM 미리보기 안됨: 연결 실패부터 태그 미작동까지 진단 순서
2. GTM 태그 중복 실행을 만드는 원인 5가지
실무에서 보는 중복은 거의 아래 5가지 안에 들어갑니다.
배수 진단에서 나온 결과와 맞춰 보면서 해당하는 항목부터 확인하면 됩니다.
① 설치 경로 이중화: 같은 태그가 GTM 안팎에서 동시에 실행
가장 흔하고, 배수가 정확히 2.0으로 나오는 원인입니다.
대표적인 패턴은 다음과 같습니다.
gtag.js 직접 설치 + GTM의 GA4 태그: 예전에 개발자가 심어둔 구글 태그 코드가 남아 있는 상태에서 GTM으로 다시 GA4를 설정한 경우
플랫폼 기본 연동 + GTM 태그: 쇼핑몰 빌더의 관리자 화면에서 GA4 측정 ID나 메타 픽셀 ID를 입력해 두고, GTM에도 같은 태그를 만든 경우
GTM 컨테이너 코드 중복 삽입: 테마 헤더와 플러그인 양쪽에 컨테이너 코드가 들어가 있는 경우
특히 두 번째가 놓치기 쉽습니다.
플랫폼 연동은 소스 코드에 직접 보이지 않는 경우가 많아서, 개발자 도구에서 소스를 검색해도 안 걸리는 일이 생깁니다. 이럴 때는 네트워크 탭의 요청 수가 가장 확실한 증거입니다.
-> 원칙은 하나입니다. 태그 하나에 설치 경로도 하나. GTM으로 관리할 거라면 다른 경로는 모두 끕니다.
② 한 태그에 트리거를 여러 개 연결: 트리거는 OR로 작동
GTM에서 태그 하나에 트리거를 두 개 이상 연결하면, 트리거끼리는 '또는(OR)' 으로 작동합니다.
조건 A와 B를 모두 만족할 때 실행하라는 뜻이 아니라, A가 발생해도 실행하고 B가 발생해도 실행한다는 뜻입니다.
예를 들어 리드 전환 태그에 아래 두 트리거를 같이 걸어두면 어떻게 될까요?
양식 제출 트리거
감사 페이지(/thanks) 페이지뷰 트리거
사용자가 양식을 제출하면 한 번, 감사 페이지로 넘어가면서 또 한 번 실행됩니다.
"둘 중 하나는 잡히겠지"라는 보험 차원의 설정이 그대로 중복 집계가 되는 겁니다. 버튼 클릭 트리거와 링크 클릭 트리거를 같이 거는 경우도 마찬가지입니다.
조건을 '그리고(AND)'로 묶고 싶다면 트리거를 여러 개 연결하는 것이 아니라, 트리거 하나 안에 조건을 여러 줄 추가해야 합니다.
GTM 버튼 클릭 전환 설정: 오집계 막는 트리거 4단계 기준
③ 페이지뷰 계열 트리거 겹침과 SPA 페이지 전환
GTM의 페이지 로드 관련 트리거는 여러 단계로 나뉩니다.
동의 초기화 → 초기화 → 페이지뷰(Container Loaded) → DOM 사용 가능 → 창 로드 순서로 발생하고, 각각이 별개의 이벤트입니다.
그래서 같은 태그에 '모든 페이지(페이지뷰)'와 'DOM 사용 가능' 트리거를 함께 걸면 한 페이지에서 두 번 실행됩니다.
'모든 페이지' 트리거와 '일부 페이지' 트리거를 같이 걸어도, 일부 페이지에 해당하는 곳에서는 두 번 실행됩니다.
SPA(싱글 페이지 애플리케이션) 사이트는 한 단계 더 주의해야 합니다.
GA4 향상된 측정의 '브라우저 기록 이벤트 기반 페이지 변경'이 켜져 있으면, GA4가 이미 페이지 전환마다 page_view를 보냅니다.
여기에 GTM에서 '기록 변경' 트리거로 page_view 이벤트 태그를 하나 더 만들면 페이지 전환마다 2건이 됩니다.
일부 프레임워크는 첫 로드 시점에도 history 상태를 바꾸기 때문에, 첫 진입에서 페이지뷰 트리거와 기록 변경 트리거가 동시에 실행되는 경우가 있습니다.
-> SPA에서는 "GA4 자동 수집"과 "GTM 수동 수집" 중 하나만 남깁니다.
④ 데이터 영역 push 반복: 이벤트 자체가 두 번 발생
GTM 설정이 완벽해도 데이터 영역에 같은 이벤트가 두 번 들어오면 태그도 두 번 실행됩니다.
이건 GTM 문제가 아니라 사이트 쪽 문제라서, GTM만 들여다보면 끝까지 못 찾습니다.
자주 보는 상황은 세 가지입니다.
구매 완료 페이지 새로고침·뒤로 가기: 페이지가 다시 로드될 때마다 purchase push가 다시 실행됩니다.
개발 코드에서 push 중복: 컴포넌트가 두 번 렌더링되면서 같은 이벤트를 두 번 push하는 경우입니다.
결제 대행사 리디렉션 후 재진입: 결제창에서 돌아오는 경로가 두 갈래라서 완료 페이지를 두 번 거치는 경우입니다.
GTM 미리보기 타임라인에 같은 이름의 커스텀 이벤트(예: purchase)가 두 줄 찍혀 있으면 이 유형입니다.
배수가 1.1~1.5배처럼 애매하게 나오는 계정은 대부분 새로고침 유형입니다. 모든 사용자가 새로고침을 하지는 않으니까요.
⑤ 태그 시퀀싱과 실행 옵션 설정
마지막은 비교적 드물지만 찾기 어려운 원인입니다.
태그 시퀀싱에서 A 태그를 B 태그의 '설정 태그(먼저 실행)'로 지정해 두면, B가 실행될 때마다 A도 같이 실행됩니다.
그런데 A 태그에 자체 트리거까지 걸려 있으면, A는 자기 트리거로 한 번, B의 설정 태그로 또 한 번 실행됩니다.
태그 실행 옵션도 확인해야 합니다. 태그의 고급 설정에는 아래 세 가지 옵션이 있습니다.
옵션 | 동작 | 적합한 태그 |
|---|---|---|
이벤트당 한 번 | 트리거 이벤트가 발생할 때마다 1회 (기본값) | 대부분의 이벤트 태그 |
페이지당 한 번 | 한 페이지 로드에서 최대 1회 | 구매·리드 등 페이지당 1회만 의미 있는 전환 |
무제한 | 조건이 맞을 때마다 제한 없이 | 거의 쓰지 않음 |
'무제한'으로 바뀌어 있는 태그는 한 이벤트 안에서도 여러 번 실행될 수 있으니, 설정한 이유가 명확하지 않다면 기본값으로 돌리는 것이 안전합니다.
3. 실무 사례: 구매 전환이 정확히 2배로 잡히던 계정
실제로 자주 마주치는 유형을 하나 정리해 보겠습니다.
자사몰을 쇼핑몰 빌더로 운영하던 한 브랜드의 경우, GA4 구매 수가 관리자 주문 수의 거의 정확히 2배로 잡히고 있었습니다.
광고 매체 쪽 전환도 같이 부풀어 있었기 때문에, 자동 입찰이 실제보다 성과가 좋다고 판단하고 있던 상황이었습니다.
진단 과정은 이렇게 진행됐습니다.
① 배수 확인: 일자별로 나눠 봐도 2.0배 근처에서 거의 흔들리지 않음 → 설치 경로 이중화로 후보를 좁힘
② GTM 미리보기: 구매 완료 페이지에서 GA4 purchase 태그는 한 번만 실행됨 → GTM 내부 문제가 아님
③ 네트워크 탭: collect?v=2 요청 중 purchase가 2개, 측정 ID는 동일 → GTM 밖에서 같은 속성으로 한 번 더 보내고 있음
④ 원인 확인: 쇼핑몰 관리자의 마케팅 연동 메뉴에 같은 GA4 측정 ID가 입력되어 있었음. 이전 담당자가 연동해 둔 것을 모르고 GTM에 다시 구축한 것
해결은 간단했습니다. 플랫폼 연동을 해제하고 GTM 한 곳으로 일원화했습니다.
이 사례에서 더 중요한 건 해결 이후입니다.
중복을 제거하면 전환 수가 하루아침에 절반으로 떨어집니다.
이 숫자를 성과 하락으로 오해해서 예산을 줄이거나 소재를 갈아엎으면 안 됩니다. 실제 성과는 그대로이고, 숫자가 실제에 맞춰진 것뿐입니다.
또 자동 입찰은 그동안 부풀려진 전환 데이터로 학습해 왔기 때문에, 수정 직후 한동안 입찰이 출렁일 수 있습니다.
그래서 수정 전에 아래 세 가지를 같이 정해두는 것이 좋습니다.
수정 날짜를 기록하고 보고서에 주석으로 남기기
수정 전 기간의 전환 수·ROAS는 "중복 포함 수치"로 구분해서 비교하지 않기
목표 CPA·목표 ROAS로 입찰 중이라면, 실제 수치 기준으로 목표값을 다시 계산해서 조정하기
-> 중복 제거는 설정을 고치는 작업이 아니라, 성과 기준선을 다시 세우는 작업입니다.
구글 광고 전환 중복: 전환이 두 번 잡히는 4가지 원인과 정리 순서
4. 중복 실행 막는 설정 기준과 재발 방지 체크
원인을 고쳐도 담당자가 바뀌거나 사이트를 개편하면 같은 문제가 다시 생깁니다.
그래서 처음부터 중복이 생겨도 걸러지는 구조를 만들어 두는 편이 낫습니다.
전환 태그에 거는 3중 안전장치
① 고유 ID 전달
구매 이벤트에는 반드시 주문번호를 transaction_id로 함께 보냅니다.
GA4와 구글 광고는 같은 주문번호가 들어오면 중복으로 처리할 수 있는 근거가 생깁니다. 메타는 픽셀과 전환 API를 함께 쓸 때 event_id를 맞춰야 중복 제거가 됩니다.
ID 없이 보내는 전환은 중복이 생겨도 매체가 구분할 방법이 없습니다.
② 실행 옵션 '페이지당 한 번'
구매·리드 완료처럼 한 페이지에서 한 번만 의미가 있는 전환 태그는 '페이지당 한 번'으로 바꿔 둡니다.
다만 이 옵션은 같은 페이지 안의 중복만 막습니다. 새로고침으로 페이지가 다시 로드되면 다시 실행되니, 새로고침 중복은 ③으로 막아야 합니다.
③ 주문번호 기준 1회 실행 조건
구매 태그가 실행될 때 주문번호를 쿠키나 브라우저 저장소에 기록하고, 같은 주문번호가 이미 기록되어 있으면 태그가 실행되지 않도록 트리거에 예외 조건을 겁니다.
가장 깔끔한 방법은 개발 쪽에서 완료 페이지 재진입 시 purchase push 자체를 하지 않도록 처리하는 것입니다. GTM 쪽 차단은 그게 어려울 때의 보완책입니다.
게시 전 점검 체크리스트
새 태그를 만들거나 사이트를 수정한 뒤에는 게시 전에 아래를 확인합니다.
점검 항목 | 확인 방법 | 통과 기준 |
|---|---|---|
설치 경로 | 플랫폼 연동 메뉴, 소스 검색 | 태그 1개당 경로 1개 |
트리거 개수 | 태그 상세의 트리거 목록 | 전환 태그는 트리거 1개 원칙 |
페이지뷰 계열 겹침 | 미리보기 이벤트 타임라인 | 한 페이지 로드에 1회 실행 |
데이터 영역 이벤트 | 미리보기에서 커스텀 이벤트 개수 | 같은 이름 이벤트 1줄 |
실제 요청 수 | 네트워크 탭 필터 | 완료 1회 = 요청 1건 |
새로고침 테스트 | 완료 페이지에서 새로고침 2회 | 추가 요청 0건 |
마지막 새로고침 테스트는 의외로 많이 빠뜨리는 항목입니다.
테스트 주문을 넣을 때 완료 페이지에서 새로고침을 두 번 해보는 것만으로 ④번 유형의 대부분을 걸러낼 수 있습니다.
컨테이너 운영 규칙
중복은 결국 "누가 어디에 무엇을 심었는지 모르는 상태"에서 생깁니다.
태그 이름에 매체·이벤트·트리거를 넣기 (예: GA4 | purchase | 완료페이지)
게시할 때 버전 이름과 변경 내용을 반드시 기록하기
분기에 한 번은 플랫폼 연동 메뉴와 GTM 태그 목록을 대조하기
메타 픽셀처럼 플랫폼 연동과 GTM 설치가 동시에 가능한 매체는 특히 이 대조 작업이 효과가 큽니다.
GTM 메타 픽셀 설치 기준: 태그·트리거·중복 방지 3단계
자주 묻는 질문
GTM 태그가 두 번 실행되는 이유는?
대부분 세 가지 중 하나입니다. 같은 태그가 GTM과 다른 경로(직접 설치 코드, 플랫폼 연동)에 동시에 있거나, 한 태그에 트리거가 여러 개 연결되어 있거나, 데이터 영역에 같은 이벤트가 두 번 push되는 경우입니다. 실제 값 대비 배수가 정확히 2배라면 설치 경로부터 확인하세요.
GTM 미리보기에서는 한 번인데 GA4에는 두 번 잡히는 이유는?
GTM 미리보기는 GTM 내부에서 실행된 태그만 보여줍니다. GTM 밖에서 직접 설치된 구글 태그나 쇼핑몰 플랫폼의 GA4 연동이 같은 측정 ID로 데이터를 보내고 있을 가능성이 높습니다. 브라우저 네트워크 탭에서 collect?v=2 요청 수를 세면 확인할 수 있습니다.
GTM 태그 실행 옵션 '이벤트당 한 번'과 '페이지당 한 번' 차이는?
'이벤트당 한 번'은 트리거 이벤트가 발생할 때마다 실행되는 기본값이고, '페이지당 한 번'은 한 페이지 로드 안에서 최대 1회만 실행됩니다. 구매·리드 완료 태그에는 '페이지당 한 번'이 안전합니다. 다만 새로고침으로 페이지가 다시 로드되는 경우는 막지 못합니다.
구매 완료 페이지 새로고침 시 전환 중복을 막는 방법은?
가장 확실한 방법은 사이트 쪽에서 완료 페이지 재진입 시 purchase 이벤트를 다시 push하지 않도록 처리하는 것입니다. GTM에서는 주문번호를 쿠키에 기록하고 같은 주문번호면 태그가 실행되지 않도록 트리거 예외를 거는 방식으로 보완할 수 있습니다. 어떤 경우든 transaction_id는 반드시 함께 보내야 합니다.
마무리
GTM 태그 중복 실행은 숫자를 부풀리는 데서 끝나지 않습니다.
부풀려진 전환으로 자동 입찰이 학습하고, 그 숫자를 근거로 예산과 소재를 판단하게 됩니다. 원인 하나가 모든 의사결정을 조금씩 틀어지게 만드는 셈입니다.
정리하면 순서는 이렇습니다.
① 실제 값 대비 배수로 원인 후보를 좁히고
② 미리보기와 네트워크 탭으로 GTM 안팎을 구분해 확정하고
③ 설치 경로 일원화, 트리거 정리, 데이터 영역 점검 순으로 고치고
④ 고유 ID·실행 옵션·새로고침 테스트로 재발을 막습니다.
그리고 수정 직후 전환이 줄어드는 것은 성과 하락이 아니라 기준선이 바로잡히는 과정이라는 점을 꼭 기억해 두세요.
함께 보면 좋은 글:
GTM 미리보기 안됨: 연결 실패부터 태그 미작동까지 진단 순서