이커머스 광고 추적 코드 진단(2026)

이 가이드 사용 방법

이 가이드는 대행사, 플러그인, 앱 또는 내부 구현을 통해 설치된 추적을 감사해야 하는 퍼포먼스 마케터, 전자상거래 운영자, 분석가, 개발자 및 팀을 위해 작성되었습니다. 테스트는 스테이징 환경이나 취소·환불이 가능한 테스트 주문으로 진행하십시오. 실제 고객 주문으로 반복 테스트하지 마십시오.

이 가이드를 완료하면 다음 작업을 수행할 수 있습니다

• 코드 존재, 태그 실행, 요청 전송, 플랫폼 수신, 입찰에 사용할 수 있는 전환을 구분합니다.
• 주문 ID, 매출, 통화, 제품 ID, 이벤트 ID 같은 핵심 필드를 검증합니다.
• 중복 구매, 누락된 구매, 값이 0인 전환, 손실된 교차 도메인 기여 분석 및 동의 구성 문제를 진단합니다.
• Shopify, WordPress, WooCommerce 또는 맞춤형 전자상거래 스택에 적합한 진단 방식을 선택합니다.
• 마케팅, 개발, 분석 또는 경영 팀을 위한 명확한 진단 보고서를 작성합니다.

추적을 설치해도 데이터가 신뢰할 수 없는 이유

독립 전자상거래 스토어가 Google Ads, Meta Ads, Microsoft Ads 또는 TikTok Ads에서 광고를 시작하면 각 플랫폼은 추적 태그나 픽셀 설치를 요구합니다. 페이지 소스에서 해당 코드를 찾았다는 사실만으로 전환 추적이 올바르게 작동한다고 볼 수는 없습니다.

• 광고 플랫폼에서 태그가 확인되지 않음, 비활성 또는 최근 활동 없음으로 표시됩니다.
• GA4에는 주문이 기록되지만 Google Ads에는 전환이 표시되지 않습니다.
• 스토어 백엔드에는 주문이 1건인데 광고 플랫폼에는 구매가 2건 보고됩니다.
• 전환 수는 합리적으로 보이지만 매출, 통화 또는 제품 데이터가 잘못되었습니다.
• 홈페이지에서는 픽셀이 감지되지만 결제 과정이나 주문 확인 페이지에서 사라집니다.
• 브라우저와 서버 이벤트가 모두 전송되지만 올바르게 중복 제거되지 않습니다.
• 광고 추적이 방문자의 동의 선택에 따라 작동하지 않습니다. 마케팅 동의가 denied된 뒤에도 광고 저장소가 읽히거나 기록되고 광고 식별자 또는 사용자 데이터가 계속 전송됩니다. 고급 동의 모드에서는 쿠키 없는 동의 핑이 ad_storage 또는 analytics_storage가 denied된 상태에서도 전송될 수 있습니다. 이 동작만으로 구현 오류라고 판단할 수는 없습니다.
• 방문자가 동의를 허용한 후에도 태그가 다시 실행되지 않습니다.

전체 감사는 “코드가 존재하는가?”라는 질문에서 끝나면 안 됩니다. 실제 비즈니스 행동이 올바른 이벤트 이름, 매개변수, 값, 통화 및 주문 ID와 함께 올바른 플랫폼에 도달하고, 브라우저와 서버 전송이 중복 제거 후 하나의 논리적 전환으로 처리되는지 확인하십시오.

1. 광고 추적 진단에서 실제로 확인하는 항목

광고 추적은 5개 계층으로 평가할 수 있습니다. 5개 계층을 모두 통과해야 데이터를 성과 분석, ROAS 계산 및 자동 입찰에 사용할 수 있습니다.

GTM에 “Tag Fired”가 표시되어도 트리거 조건이 충족되었다는 사실만 확인할 수 있습니다. 전환이 정확하다는 의미는 아닙니다. 데이터 레이어, 네트워크 요청, 플랫폼 테스트 도구 및 해당 백엔드 주문을 계속 확인하십시오.

2. 먼저 전자상거래 이벤트 추적 계획 수립

문제를 해결하기 전에 사이트에서 실제로 측정해야 할 고객 행동을 정의하십시오. 일반적인 전자상거래 구현은 최소한 제품 조회, 장바구니 추가, 결제 시작 및 구매를 포함해야 합니다.

이 가이드의 2026년 8월 버전에서 TikTok은 Purchase를 표준 전자상거래 purchase 이벤트로, Lead를 리드 제출용으로 사용합니다. CompletePayment와 SubmitForm은 Purchase 및 Lead에 매핑되는 호환 레거시 이름입니다. 이전 계획 없이 정상 작동하는 레거시 구현의 이름을 변경하지 마십시오. Contact는 실제 문의 행동에만 사용하십시오. GA4는 purchase를 사용하며 transaction_id, value, currency 및 items 배열과 같은 매개변수를 권장합니다.

purchase 이벤트에 필요한 최소 데이터

3. 진단 테스트 준비

실제 고객 주문을 기본 테스트로 사용하지 마십시오. 취소 또는 환불할 수 있는 테스트 주문을 생성하고 시작하기 전에 아래 정보를 기록하십시오.

기본 구현 테스트에서는 브라우저 광고 차단 확장 프로그램을 비활성화하되 사이트의 동의 배너는 비활성화하지 마십시오. 광고 차단 테스트와 동의 테스트는 별도로 실행해야 합니다. 그렇지 않으면 브라우저 확장 프로그램과 동의 구성 중 무엇이 태그를 차단했는지 구분할 수 없습니다.

최소 3개의 동의 시나리오 테스트

• 아직 쿠키 선택을 하지 않은 신규 방문자.
• 관련 쿠키를 모두 허용한 방문자.
• 마케팅 쿠키를 거부한 방문자.

Google 동의 모드에서는 관련 태그가 실행되기 전에 기본 동의 상태를 설정하고, 방문자가 선택한 뒤 같은 페이지에서 즉시 업데이트합니다. ad_storage, analytics_storage, ad_user_data 및 ad_personalization를 각각 검증하십시오. 고급 동의 모드에서는 저장소가 denied 상태여도 쿠키 없는 핑을 보낼 수 있습니다. 방문자의 선택에 반해 광고 저장소, 광고 식별자 또는 사용자 데이터가 전송되지 않는지 확인하십시오.

진단 도구 모음

1. Google Tag Assistant 및 GTM Preview

Google Tag Manager Preview에는 페이지 이벤트, 실행된 태그, 실행되지 않은 태그, 트리거 조건, 변수 및 동의 상태가 표시됩니다. 이를 통해 “사이트에서 무슨 일이 발생했는가?”와 “GTM가 왜 태그를 실행했거나 실행하지 못했는가?”라는 두 가지 핵심 질문에 답할 수 있습니다.

2. GA4 DebugView

GA4 DebugView는 GA4가 실제로 이벤트를 수신했는지 확인하고 해당 매개변수를 표시합니다. GTM 구현 문제와 전송 또는 GA4 수집 문제를 구분하는 데 도움이 됩니다.

3. Chrome DevTools의 Network 패널

Network 패널에는 브라우저가 실제로 전송한 요청이 표시됩니다. 플랫폼 도메인, 요청 유형, 파일 이름, 태그 ID 또는 측정 ID로 필터링할 수 있습니다. “브라우저가 데이터를 보냈는가?”에 답하는 핵심 도구입니다.

4. 플랫폼별 테스트 도구

Test Events 및 진단는 Meta Events Manager에서 사용합니다. TikTok에는 Pixel Helper, Test Events 및 진단를, UET Tag Helper는 Microsoft Advertising에서, Shopify Pixel Helper는 Shopify 맞춤 픽셀에서 사용합니다.

4. 전체 광고 추적 진단 워크플로

1단계: 모든 추적 구현 목록화

중복 전환은 하나의 태그가 고장 난 경우보다 동일한 플랫폼이 여러 경로로 설치되어 발생하는 경우가 많습니다.

• GTM가 테마에 한 번, 플러그인을 통해 다시 한 번 설치되어 있습니다.
• 공식 Shopify Meta 앱이 픽셀을 설치하고 별도의 맞춤 Meta pixel도 존재합니다.
• WordPress 플러그인이 Purchase를 보내고 GTM도 같은 Purchase를 다시 보냅니다.
• 네이티브 Google Ads 구매 액션과 가져온 GA4 구매 액션이 모두 기본 목표로 설정되어 있습니다.
• Meta Pixel와 Conversions API가 제대로 된 중복 제거 없이 동일한 구매를 전송합니다.
• TikTok 앱, GTM 및 테마 코드가 각각 동일한 픽셀을 설치합니다.

구현 목록을 작성하십시오. 읽기 쉽도록 설치 방법, 기본 태그 위치, 구매 이벤트 소스 및 서버 이벤트 상태를 하나의 구현 메모 필드에 정리합니다.

페이지 소스, GTM 태그 목록, WordPress 플러그인, 테마 맞춤 코드 영역, Shopify Customer Events, Shopify 앱, Cloudflare Zaraz, 서버 측 GTM 및 맞춤 백엔드 통합에서 각 ID를 검색하십시오.

2단계: 기본 태그가 올바르게 로드되는지 확인

GTM에서는 주문 확인 페이지를 직접 여는 것부터 시작하지 마십시오. 홈페이지 또는 광고 랜딩 페이지에서 Preview를 연결한 다음 제품 조회, 장바구니, 결제 및 결제로 이어지는 실제 고객 여정을 따르십시오.

• Preview가 올바른 도메인에 연결되었는지 확인합니다.
• 페이지가 로드될 때 예상한 GTM 컨테이너가 표시되는지 확인합니다.
• 컨테이너 ID가 활성 계정 및 환경과 일치하는지 확인합니다.
• 기본 Google tag가 필요한 모든 페이지에서 로드되는지 확인합니다.
• 결제 완료 페이지가 동일한 디버그 세션에 유지되는지 확인합니다.
• 리디렉션 또는 교차 도메인 전환 후 세션이 끊기는지 확인합니다.
• 태그를 차단하는 Consent Initialization 및 동의 상태를 검토합니다.

동시에 Chrome DevTools를 열고 Network 패널에서 GTM 컨테이너 ID, GA4 측정 ID, Google Ads 전환 ID, Meta pixel ID, TikTok 픽셀 ID 또는 Microsoft UET 태그 ID를 검색합니다. 요청 경로는 변경될 수 있으므로 하나의 고정 엔드포인트에 의존하는 것보다 실제 ID를 검색하는 편이 더 안정적입니다.

요청이 전혀 표시되지 않으면 먼저 다음을 확인하십시오

• 코드가 누락되었거나 구성한 ID가 잘못되었습니다.
• GTM 컨테이너가 게시되지 않았거나 잘못된 환경이 로드되었습니다.
• 동의 설정이 태그 실행을 차단합니다.
• 콘텐츠 보안 정책이 외부 스크립트 또는 엔드포인트를 차단합니다.
• 광고 차단 프로그램 또는 브라우저 개인정보 보호 설정이 요청을 차단합니다.
• 추적 코드가 실행되기 전에 JavaScript 오류가 발생합니다.
• 캐시 또는 CDN이 여전히 이전 버전의 사이트 코드를 제공합니다.

3단계: 데이터 레이어 또는 고객 이벤트 검증

데이터 레이어는 전자상거래 활동과 광고 태그를 연결하는 다리입니다. Google Tag Manager 및 gtag.js는 이 구조화된 계층에서 이벤트와 변수를 읽습니다. 태그가 무관한 페이지 요소에서 값을 추출하게 하지 말고 예측 가능한 구조화 데이터를 사용하십시오.

단순화한 GA4 형식의 purchase 이벤트는 다음과 같습니다.

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-10086",
    value: 129.90,
    currency: "USD",
    tax: 8.20,
    shipping: 0,
    items: [
      {
        item_id: "SKU-001",
        item_name: "Portable Coffee Grinder",
        price: 64.95,
        quantity: 2
      }
    ]
  }
});
</script>

GA4 전자상거래에서 이벤트 수준 value는 일반적으로 items 배열의 price × quantity 합계와 같아야 합니다. 문서화된 보고 정의와 대상 플랫폼이 다른 값을 명시적으로 요구하지 않는 한 배송비나 세금은 포함하지 마십시오.

초기 점검에는 Chrome Console에서 다음 명령을 사용하십시오.

window.dataLayer

purchase 이벤트만 표시하려면 다음을 사용하십시오.

window.dataLayer?.filter(item => item.event === "purchase")

다음 6가지 항목 검증

1. 이벤트 발생 시점이 올바름: 고객이 ‘지금 결제’ 또는 ‘주문 제출’을 클릭한 시점이 아니라 주문이 실제로 성공한 뒤 Purchase가 생성되어야 합니다.
2. 주문 ID가 고유함: 같은 주문은 새로고침 후에도 같은 ID를 유지해야 하며, 서로 다른 주문이 같은 ID를 공유해서는 안 됩니다.
3. 값이 숫자임: “$129.90”, “USD 129.90” 또는 천 단위 구분자가 들어간 문자열이 아니라 129.90을 사용합니다.
4. 통화가 주문과 일치함: 다중 통화 스토어에서는 표시 통화, 결제 통화 및 플랫폼에 전송된 통화를 비교합니다.
5. items 배열이 완전함: 제품 ID, 가격, 수량 및 할인은 백엔드 주문과 일치해야 합니다.
6. 이전 값이 유지되지 않음: 단일 페이지 애플리케이션, 장바구니 드로어 및 AJAX 결제에서는 이전 이벤트의 데이터를 실수로 재사용할 수 있습니다.

4단계: GTM 트리거 및 변수 검사

GTM Preview에서 실제 테스트 여정을 완료하고 purchase 이벤트를 선택한 뒤 Tags Fired, Tags Not Fired, Variables, Data Layer 및 동의를 검사합니다.

트리거 조건이 너무 광범위함

‘Page URL에 thank-you 포함’ 같은 규칙은 방문자가 주문 확인 페이지를 새로고침하거나 북마크에서 열거나 다시 방문할 때마다 재실행될 수 있습니다. 전자상거래 구매는 실제 주문 완료 이벤트와 고유 주문 ID를 사용하는 것이 좋습니다.

트리거 조건이 너무 제한적임

실제 URL이 /en/checkout/success인데 트리거는 /checkout/success만 허용할 수 있습니다. 언어 폴더, 쿼리 문자열 및 대체 결제 경로 때문에 지나치게 엄격한 규칙이 작동하지 않을 수 있습니다.

맞춤 이벤트 이름이 일치하지 않음

데이터 레이어는 event: “checkout_completed”를 보내지만 GTM는 purchase를 수신 대기합니다. 대소문자와 밑줄을 포함해 이벤트 이름이 정확히 일치해야 합니다.

데이터가 도착하기 전에 태그 실행

태그는 페이지 로드 중 실행되지만 value, currency 및 주문 ID는 수백 밀리초 뒤 데이터 레이어에 들어옵니다. 태그가 성공적으로 실행된 것처럼 보이지만 빈 매개변수를 전송합니다.

AJAX 또는 단일 페이지 애플리케이션에서 기존 방식의 페이지 로드가 발생하지 않음

장바구니 드로어, 모달 결제, React 또는 Vue 애플리케이션에서는 일반 페이지 조회가 발생하지 않을 수 있습니다. 페이지 로드나 URL 변경에만 의존하지 말고 비즈니스 이벤트를 기준으로 추적을 실행하십시오.

5단계: Network로 요청 전송 확인

Chrome DevTools -> Network를 열고 Preserve log를 활성화한 뒤 전체 테스트를 반복합니다. 플랫폼 ID 또는 도메인으로 필터링하고 일치하는 요청을 연 다음 Headers 및 Payload를 확인합니다.

• 대상 플랫폼과 태그 또는 픽셀 ID를 확인합니다.
• 이벤트 이름, 값, 통화 및 주문 ID를 확인합니다.
• 제품 ID, 수량 및 items 배열이 있는지 확인합니다.
• 브라우저와 서버 이벤트가 플랫폼별 중복 제거 식별자를 공유하는지 확인합니다. Meta와 TikTok은 일치하는 이벤트 이름 또는 유형과 event_id가 필요하며, GA4 및 Google Ads 구매에는 transaction_id를 사용합니다.
• 요청이 취소되거나 차단되거나 오류를 반환했는지 확인합니다.
• 요청이 페이지 리디렉션 전후 중 언제 발생했는지 확인합니다.

그럴듯한 페이로드가 포함된 요청을 확인했더라도 브라우저가 전송을 시도했거나 엔드포인트가 요청을 수락했다는 사실만 입증됩니다. 플랫폼 처리, 기여 분석, 입찰 자격 또는 비즈니스 데이터 정확성까지 입증하지는 않습니다. 값이 0인 Purchase 요청도 성공적으로 전송될 수 있습니다.

GTM에는 태그가 실행되었다고 표시되지만 Network에는 요청이 없음

• 동의 상태 및 기본 제공 동의 검사.
• 광고 차단 또는 브라우저 개인정보 보호 설정.
• 콘텐츠 보안 정책 제한.
• 손상된 태그 템플릿 또는 JavaScript 런타임 오류.
• 즉시 탐색으로 인해 취소된 요청.
• Shopify Pixel Sandbox 제한.

6단계: 각 광고 플랫폼 내에서 수신 확인

GA4

DebugView를 열고 테스트 기기를 선택한 뒤 이벤트 순서가 합리적인지 확인합니다.

page_view
view_item
add_to_cart
begin_checkout
purchase

purchase를 열고 transaction_id, value, currency 및 items를 확인합니다.

Google Ads

Goals -> Conversions -> Summary를 열고 관련 액션의 추적 상태를 검토합니다. Unverified, Tag inactive 또는 Needs attention인 경우 전환 액션에서 Tag Assistant를 실행하십시오. 수정 후 계정 상태가 갱신되는 데 시간이 걸릴 수 있으므로 Tag Assistant와 실제 요청을 즉각적인 검증 계층으로 사용합니다.

Meta Ads

Events Manager에서 올바른 데이터 소스를 선택하고 Overview, Test Events, 진단, Event Deduplication 및 Event Match Quality를 검토합니다. Test Events에서 브라우저와 서버 전송을 확인하고 진단에서 중복 이벤트, 잘못된 매개변수 또는 데이터 품질 문제를 식별할 수 있습니다.

TikTok Ads

TikTok Pixel Helper로 브라우저 태그, 이벤트 및 매개변수를 검사하고, 실시간 수신은 Events Manager -> Test Events에서, 지속적인 구현 오류는 Events Manager -> 진단에서 확인합니다.

Microsoft Advertising

UET Tag Helper를 사용해 UET 태그 ID, 페이지 로드 이벤트, 맞춤 이벤트, 변동 매출, 통화 및 전환 목표 조건을 검증합니다. UET 상태는 Microsoft Advertising에서 업데이트에 시간이 더 걸릴 수 있습니다. Microsoft Advertising Conversions API도 사용하는 경우 해당 event_id를 검증하고 브라우저와 서버 전송이 중복 보고를 만들지 않는지 확인합니다. 변동 매출에서는 대상 플랫폼이 요구하는 대로 revenue_value와 통화를 정확히 유지하십시오.

5. 중복 Conversions 및 Event Deduplication 진단

중복 구매는 보고된 ROAS를 부풀리고 자동 입찰에 잘못된 신호를 제공합니다. 한 계층만 감사하지 말고 브라우저, 서버, 플러그인, 앱, GTM 및 가져온 목표를 함께 검토하십시오.

Google Ads 중복 제거

Google Ads는 구매할 때마다 고유한 거래 ID를 전송할 것을 권장합니다. 주문 확인 페이지를 새로고침하여 같은 주문이 동일한 전환 액션으로 다시 전송되면 Google Ads는 일치하는 거래 ID로 중복을 식별할 수 있습니다. 거래 ID가 별도의 Purchase 전환 액션까지 자동으로 중복 제거하지는 않습니다.

• 서로 다른 주문이 동일한 거래 ID를 공유해서는 안 됩니다.
• 거래 ID는 비워 두면 안 됩니다.
• 고객 이메일 주소나 전화번호를 주문 ID로 사용하지 마십시오.
• 동일한 거래에는 브라우저 태그와 백엔드 업로드에서 같은 주문 ID를 사용해야 합니다.

Meta Pixel 및 Conversions API 중복 제거

동일한 Purchase를 Meta Pixel 및 Conversions API를 통해 전송할 때 브라우저와 서버 이벤트는 같은 event_name 및 event_id를 공유해야 합니다. 서로 다른 주문에는 서로 다른 event_id 값을 사용해야 합니다. 그렇지 않으면 하나의 주문이 두 개의 이벤트로 집계될 수 있습니다.

• 브라우저와 서버 이벤트가 동일한 event_name를 사용합니까?
• 같은 주문의 두 버전이 동일한 event_id를 사용합니까?
• 서로 다른 주문마다 다른 이벤트 ID를 받습니까?
• 서버 재시도로 새 이벤트 ID가 생성되어 실수로 두 번째 이벤트가 만들어집니까?
• Shopify 앱과 맞춤 CAPI 구현이 모두 동일한 구매를 전송합니까?

TikTok Pixel 및 Events API 중복 제거

TikTok Pixel과 Events API가 동일한 이벤트를 전송할 때 TikTok이 두 이벤트를 한 쌍으로 인식하고 하나의 논리적 이벤트만 유지할 수 있도록 양쪽에서 동일한 이벤트 이름 또는 유형과 동일한 event_id를 사용해야 합니다.

주문 확인 페이지 새로고침

주문 확인 페이지 조회만으로 Purchase를 실행하는 방식은 위험합니다. 새로고침, 북마크 또는 페이지 다시 열기로 이벤트가 다시 실행될 수 있습니다. 고유한 주문 ID를 사용하고 가능하면 일반 페이지 로드가 아니라 실제 주문 완료 이벤트에서 실행하십시오.

6. 전환 Goals, 교차 도메인 결제 및 기여 분석 검토

Primary와 보조 전환 액션 비교

Google Ads에서 기본 전환 액션은 일반적으로 Conversions 열에 표시되며 캠페인이 관련 목표를 사용할 때 입찰에 사용할 수 있습니다. Secondary 액션은 주로 관찰용이며 보통 All conversions에 표시됩니다. 단, 캠페인이 실제로 사용하는 맞춤 목표에 보조 액션이 포함되어 있으면 입찰에 사용할 수 있습니다.

이벤트가 계정에는 표시되지만 캠페인이 해당 이벤트를 기준으로 최적화하지 않는다면 액션이 기본으로 설정되어 있고 캠페인이 해당 목표를 사용하는지 확인합니다.

Every와 One

Purchase 액션은 일반적으로 모든 거래를 집계해야 합니다. Lead 양식은 동일한 광고 클릭에서 반복 제출된 항목이 여러 개의 가치 있는 리드를 의미하지 않을 수 있어 One를 사용하는 경우가 많습니다. 판매에서는 고유한 거래 ID로 중복 주문을 제거하십시오.

중복 기본 구매 목표

계정에는 네이티브 Google Ads Purchase, 가져온 GA4 Purchase 및 Purchase(Shopify 앱에서 생성)가 있을 수 있습니다. 세 가지가 모두 기본이며 캠페인에서 사용되면 Conversions 열에 하나의 주문을 위한 여러 구매 신호가 포함될 수 있습니다.

향상된 Conversions

향상된 Conversions를 활성화한 후 적격한 자사 고객 데이터가 필요한 형식으로 실제 전송되는지 확인하십시오. 기본 Purchase 태그가 작동한다고 해서 향상된 Conversions가 정상이라는 의미는 아닙니다.

교차 도메인 결제 및 결제 리디렉션

일부 스토어는 방문자를 기본 도메인에서 별도 결제 도메인, 타사 결제 서비스 제공업체, 예약 시스템, 양식 서비스, 하위 도메인 또는 지역 사이트로 이동시킵니다. 교차 도메인 구성이 잘못되면 다음 문제가 발생할 수 있습니다.

• 하나의 고객 세션이 여러 세션으로 분리됩니다.
• 원래 광고 유입 소스가 사라집니다.
• 결제 서비스 제공업체가 추천 소스로 보고됩니다.
• 결제 전에 클릭 ID가 손실됩니다.
• 스토어에서는 이벤트가 발생하지만 결제가 완료된 후에는 이벤트가 발생하지 않습니다.

GA4 교차 도메인 측정은 직접 제어하고 동일한 GA4 태그를 배포할 수 있는 도메인 사이에서만 사용하십시오. 해당 태그를 배포할 수 없는 타사 결제 도메인에서는 제공업체가 원래 소스를 덮어쓰지 않도록 List unwanted referrals를 검토하십시오. 이는 교차 도메인 측정을 대체하지 않습니다. 성공 페이지를 직접 열지 말고 랜딩 페이지에서 전체 리디렉션을 테스트하십시오.

7. Shopify 전용 추적 진단

Shopify Customer Events 픽셀은 샌드박스 환경에서 실행됩니다. 앱 픽셀은 Strict sandbox를, 맞춤 픽셀은 Lax sandbox를 사용하므로 기능이 동일하지 않습니다. 두 유형 모두 Shopify Customer Events 및 Web Pixels API를 사용하고 기존 DOM 스크래핑에 의존하지 않아야 합니다.

1. Google Tag Assistant에만 의존하지 않기

Google Tag Assistant는 GTM 맞춤 픽셀(Shopify 내부)과 호환되지 않습니다. Shopify Pixel Helper로 고객 이벤트가 샌드박스에 들어오는지 확인한 뒤 생성된 Network 요청과 대상 플랫폼의 Test Events 또는 진단을 검증하십시오.

Shopify Pixel Helper
-> Custom Pixel dataLayer
-> GTM 태그
-> Network 요청
-> 광고 플랫폼 Test Events

2. 샌드박스 내부에서 DOM 스크래핑 피하기

Shopify Web Pixels는 샌드박스에서 작동합니다. 스토어의 DOM를 읽거나 수정하는 구현은 실패하거나 일관되지 않게 작동할 수 있습니다. CSS 선택자로 제품 가격, 버튼 또는 주문 세부 정보를 스크래핑하지 말고 Shopify Customer Events 및 Web Pixels API가 제공하는 데이터를 우선 사용하십시오.

• 테마 버튼을 직접 감지하는 클릭 트리거.
• 표시된 제품 가격을 스크래핑하는 DOM Element Variable.
• document.querySelector 직접 사용.
• 샌드박스 URL을 스토어 URL처럼 사용.
• GA4 향상된 측정이 샌드박스 내 모든 상호작용을 자동으로 감지할 수 있다고 가정.

3. 픽셀이 동의 대기 상태인지 확인

Shopify Settings -> Customer events -> Custom pixels를 열고 테스트를 시작합니다. Pixel Helper에 ‘Pixel is awaiting 동의’가 표시되면 다음을 검토하십시오.

• 맞춤 픽셀에 할당된 고객 개인정보 보호 권한.
• 활성 시장의 쿠키 배너 구성.
• 방문자가 Analytics 또는 Marketing을 granted하고 동의했는지 여부.
• 동의 관리 플랫폼이 Shopify Customer Privacy API와 통합되는지 여부.

4. checkout_completed 올바르게 사용하기

Shopify checkout_completed는 일반적으로 결제당 한 번 실행되며 Thank You 페이지에서 관찰되는 경우가 많습니다. 구매 후 업셀을 사용하면 Thank You 페이지에서 다시 실행되는 대신 첫 번째 업셀 페이지에서 실행될 수 있습니다. 예상한 페이지가 정상적으로 로드되지 않으면 실행되지 않을 수도 있습니다.

표준 카드 결제, Shop Pay 또는 빠른 결제, 할인 주문, 무료 주문, 구매 후 업셀, 다중 통화 주문 및 Thank You 페이지가 완전히 로드되지 않는 경우를 테스트합니다.

8. WordPress 및 WooCommerce의 일반적인 진단 문제

WordPress에서 가장 흔한 문제는 추적을 설치하지 못하는 것이 아니라 같은 추적을 너무 많은 위치에 설치하는 것입니다. 다음 위치를 순서대로 검토하십시오.

• GTM 설치 플러그인.
• GA4 또는 광고 전환 플러그인.
• Meta, TikTok 또는 Microsoft Advertising용 별도 플러그인.
• 테마 헤더 및 푸터 맞춤 코드 영역.
• 페이지 빌더 맞춤 코드.
• WooCommerce Thank You 페이지 사용자 지정.
• CDN, 캐싱, 스크립트 결합 및 JavaScript 지연 설정.

WooCommerce의 장바구니 추가, 결제 및 결제 흐름은 AJAX 또는 타사 플러그인에 의해 자주 변경됩니다. 표준 버튼 클릭 규칙이나 기본 주문 확인 페이지 규칙이 계속 작동한다고 가정하지 마십시오. 실제 데이터 레이어와 주문 완료 이벤트를 정보의 기준으로 사용하십시오.

성능 및 캐싱 플러그인 추가 확인

• GTM 또는 픽셀 로드를 지연합니까?
• 결합된 스크립트가 실행 순서를 변경합니까?
• 주문 데이터가 포함된 주문 확인 페이지가 캐시됩니까?
• 광고 태그가 이미 실행된 후에 동의 업데이트가 발생합니까?
• 타사 추적 요청이 차단되거나 잘못 프록시됩니까?
• 관리자가 로그아웃한 경우에만 문제가 나타납니까?

9. 문제 해결 매트릭스

10. 신뢰할 수 있는 구현의 승인 기준

성공적인 테스트 구매는 다음 조건을 모두 충족해야 합니다.

• 주문이 실제로 성공한 후에만 Purchase가 실행됩니다.
• One건의 테스트 주문이 중복 제거 후 하나의 논리적 전환으로 처리됩니다.
• 주문 ID가 전자상거래 백엔드와 일치합니다.
• 전환 가치가 합의된 정의를 따르고 통화가 정확합니다.
• 제품 ID, 가격 및 수량이 정확합니다.
• GTM Preview에 전체 이벤트와 값이 채워진 변수가 표시됩니다.
• 해당 요청이 Network에 존재합니다.
• 대상 플랫폼의 테스트 도구가 이벤트를 인식합니다.
• 브라우저와 서버 이벤트가 중복 제거됩니다.
• 허용 및 거부된 동의 상태가 의도한 동작을 생성합니다.
• Google Ads의 Primary, Secondary 및 Count 설정이 정확합니다.
• 교차 도메인 결제가 원래 소스를 유지합니다.
• 주문 확인 페이지를 새로고침해도 별도의 독립 전환이 생성되지 않습니다.

최종 승인 기준
One건의 실제 주문 -> 중복 제거 후 하나의 논리적 광고 전환 -> 정확한 주문 ID, 값, 통화 및 제품 데이터 -> 플랫폼에서 검증 -> 전자상거래 백엔드와 조정 가능

11. 광고 추적 진단 보고서 템플릿

아래 구조를 사용해 감사 내용을 기록하십시오. 테스트 경로, Network 페이로드, 플랫폼 Test Events 및 백엔드 주문의 스크린샷을 증거 첨부 파일로 저장합니다.

1. 웹사이트 및 환경

2. 추적 설치 목록

3. 테스트 주문

4. 진단 결과

5. 문제 및 해결

6. 회귀 테스트

전체 증거 체인

비즈니스 행동
-> Customer Event/Data Layer
-> GTM 트리거
-> 광고 태그
-> Network 요청
-> 플랫폼 테스트 이벤트
-> 전환 목표
-> 백엔드 대조

이 체인의 모든 계층이 정확할 때만 전환 데이터를 캠페인 평가, ROAS 보고 및 자동 입찰에 사용해야 합니다.