데이터 레이어(Data Layer) 설계와 GTM 변수 연동: 개발자가 밀어준 실시간 매출 데이터를 GTM 맞춤 변수로 파싱하는 법

데이터레이어는 key/value 쌍으로 구성된 임시 저장소이며, dataLayer = [{ }] 형태의 배열에 데이터를 담습니다. 개발자는 사용자의 특정 행동(구매 완료, 상품 조회 등)이 발생하는 시점에 dataLayer.push({...}) 명령어로 필요한 데이터를 이 배열에 삽입합니다. GTM은 dataLayer에 새로운 객체가 추가되는 순간 이를 감지하고, 설정된 트리거 조건에 맞으면 연결된 태그를 실행합니다. 이 흐름이 바로 개발자와 마케터가 서로 코드를 직접 건드리지 않고도 협업할 수 있게 해주는 핵심 구조입니다.

데이터레이어에 값이 정상적으로 들어오고 있어도, GTM 안에서 이 값을 자동으로 인식하지는 않습니다. '변수' 메뉴에서 새 사용자 정의 변수를 만들고 유형을 '데이터 영역 변수(Data Layer Variable)'로 지정한 뒤, dataLayer 안의 정확한 키 이름을 입력해야 그 값을 읽어올 수 있는 변수가 만들어집니다. 예를 들어 dataLayer에 revenue라는 키로 매출 값이 들어온다면, 데이터 영역 변수 이름 필드에 정확히 "revenue"를 입력해야 합니다.

실무에서는 dataLayer 안의 값이 단순한 키/값이 아니라 { ecommerce: { purchase: { value: 50000 } } }처럼 여러 단계로 중첩된 객체 구조인 경우가 많습니다. 이런 경우 데이터 영역 변수 이름 필드에 "ecommerce.purchase.value"처럼 점(.) 표기법으로 전체 경로를 입력해야 정확한 값을 읽어올 수 있습니다. 경로 중간의 단계 하나라도 오탈자가 있으면 변수 값이 비어 있는 상태(undefined)로 처리되므로, 개발자가 제공한 실제 데이터 구조 문서를 보고 정확한 경로를 확인하는 것이 중요합니다.

구매 완료 페이지에서 서버가 실제 결제 금액을 계산해 페이지에 렌더링하면, 개발자는 이 금액을 dataLayer에 push하는 스크립트를 페이지 로드 시점에 실행합니다. GTM은 이 push를 감지해 데이터 영역 변수로 값을 읽어오고, 이 변수를 GA4 purchase 이벤트 태그의 value 매개변수에 매핑해 전송합니다. 이 전체 흐름 중 어느 한 단계(서버 계산, 데이터레이어 push, GTM 변수 매핑, 태그 전송)라도 어긋나면 최종적으로 GA4에 찍히는 매출 값이 실제와 달라집니다.

변수 값이 비어 있는 문제가 생기면, 가장 먼저 GTM 미리보기 모드의 데이터 영역 탭을 열어 실제로 dataLayer에 어떤 키·값이 들어오고 있는지부터 확인해야 합니다. 여기서 값이 정상적으로 보인다면 GTM 변수 설정의 키 이름 경로가 잘못됐을 가능성이 크고, 여기서도 값이 안 보인다면 개발자 쪽의 데이터레이어 push 자체가 안 되고 있거나 push 시점이 태그 실행보다 늦다는 뜻입니다. 이렇게 문제를 단계별로 나눠서 확인하면 원인을 빠르게 좁힐 수 있습니다.

데이터레이어 키 이름과 GTM 변수 이름이 서로 다른 규칙(카멜케이스, 스네이크케이스 등)으로 뒤섞여 있으면, 새로운 태그를 만들 때마다 정확한 키 이름을 다시 찾아봐야 하는 비효율이 생깁니다. 개발팀과 함께 데이터레이어 키 이름 규칙을 문서로 정리해두고, GTM 변수 이름도 이 문서의 이름을 그대로 따르도록 통일하면 이후 태그 설계 속도가 눈에 띄게 빨라집니다.

구매 이벤트처럼 여러 상품이 배열로 담기는 데이터(items 배열)는 단일 값과 다른 접근이 필요합니다. 배열 전체를 하나의 변수로 가져와 맞춤 자바스크립트 변수나 GTM의 내장 이커머스 변수 기능을 활용해 items 배열 구조 그대로 태그에 전달하는 방식이 일반적입니다. 배열 안의 개별 상품 값을 하나하나 별도 변수로 쪼개려 하면 상품 수가 가변적인 실제 장바구니 상황에 대응하기 어려우므로, 배열은 배열 형태 그대로 다루는 것이 원칙입니다.

정상 결제 흐름뿐 아니라 할인 쿠폰이 적용된 경우, 여러 개 상품을 한 번에 구매한 경우, 배송비가 별도로 붙는 경우처럼 예외적인 결제 시나리오에서도 데이터레이어 값이 정확히 채워지는지 QA 단계에서 확인해야 합니다. 정상 케이스만 테스트하고 배포하면, 할인이 적용된 주문의 매출 값만 유독 실제보다 크게 잡히는 것 같은 문제를 나중에야 발견하게 되고, 이미 발행된 캠페인 보고서까지 수정해야 하는 후속 작업이 뒤따를 수 있습니다.