크리테오 전용 추적 원태그(OneTag) 엔지니어링: 홈, 카테고리, 상품, 장바구니, 구매 완료 페이지에 원태그 에러 없이 삽입하고 데이터 레이어 맞추기

여기서 다루는 페이지별 이벤트 구분과 파라미터 정확성 원칙은 크리테오 원태그에만 국한되지 않고, 65강에서 다룬 다른 매체 픽셀 구현에도 동일하게 적용되는 일반 원칙입니다. 이 관점으로 접근하면 새로운 매체 태그를 붙일 때마다 처음부터 다시 배우지 않아도 됩니다.

65강에서 다룬 메타·구글 픽셀이 각 매체별로 별도의 표준 이벤트 체계를 갖는 것처럼, 크리테오도 자체 태그인 원태그를 통해 유저 행동을 수집합니다. 원태그는 단일 자바스크립트 스니펫으로, 이 스니펫을 사이트 전체 페이지에 심어두면 페이지 유형에 따라 서로 다른 이벤트를 자동으로 발화하도록 설계돼 있습니다. 즉 여러 개의 서로 다른 태그를 페이지마다 따로 삽입하는 것이 아니라, 하나의 로더 스크립트와 페이지별 파라미터 설정으로 구성됩니다.

크리테오 원태그는 단일 자바스크립트 스니펫으로, 홈페이지 조회(viewHome), 상품 조회(View Item), 카테고리·검색 목록 조회(View List), 장바구니 조회(viewBasket, 상품ID·가격·수량 포함), 구매 완료(Track Transaction, 결제 완료 후 '감사합니다' 페이지에서 발화) 다섯 가지 핵심 이벤트를 페이지 유형별로 감지해 크리테오 서버에 전송합니다. 이 다섯 이벤트가 유저의 쇼핑 여정 전체를 단계별로 포착해, 1강에서 다룬 리타겟팅 엔진이 각 유저의 관심 단계를 파악하는 근거가 됩니다.

홈페이지에는 viewHome 이벤트만 발화하면 되므로 비교적 구현이 단순하지만, 카테고리·검색 목록 페이지(View List)는 해당 목록에 노출된 여러 상품의 ID를 배열 형태로 함께 전달해야 합니다. 이 상품 ID 목록이 빠지면 크리테오는 유저가 어떤 카테고리를 조회했는지는 알아도 구체적으로 어떤 상품들을 봤는지는 알 수 없어, 이후 리타겟팅 정밀도가 떨어집니다.

viewBasket 이벤트는 장바구니에 담긴 상품ID·가격·수량 정보를 함께 전달합니다. 장바구니는 구매 직전 단계로 전환 가능성이 가장 높은 신호이기 때문에, 이 데이터가 정확하지 않으면(예: 수량이 실제와 다르거나 이미 삭제한 상품이 남아있는 경우) DCO가 부정확한 장바구니 리마인드 배너를 만들게 됩니다.

구매 완료(Track Transaction) 이벤트는 결제 완료 후 '감사합니다' 페이지에서 발화해야 합니다. 이는 65강에서 다룬 Purchase 표준 이벤트와 동일한 원칙으로, 결제 진행 중 페이지나 결제 수단 선택 화면에서 미리 발화시키면 실제로는 결제가 실패한 주문까지 전환으로 잡히는 오류가 생깁니다. 감사 페이지가 새로고침되거나 뒤로가기로 재진입될 때 중복 발화하지 않도록 주문번호 기준 중복 방지 로직도 함께 고려해야 합니다.

크리테오는 자체 디버깅 도구를 제공해 각 페이지에서 원태그가 정상적으로 발화하는지, 파라미터가 올바르게 채워지는지 확인할 수 있게 합니다. 65강 6강에서 다룬 픽셀 헬퍼와 마찬가지로, 실제 쇼핑 여정(홈 → 카테고리 → 상품 → 장바구니 → 구매)을 직접 재현하며 각 단계에서 원태그가 정확히 발화하는지 검증하는 절차를 신규 사이트 개편 때마다 반복해야 합니다.

65강에서 다룬 데이터 레이어(GTM dataLayer) 구조를 이미 갖추고 있다면, 원태그의 각 이벤트 파라미터를 데이터 레이어의 기존 변수와 매핑해 재사용할 수 있습니다. 이렇게 하면 크리테오를 위해 별도의 파라미터 수집 로직을 처음부터 새로 만들 필요 없이, 기존 데이터 레이어 인프라를 확장하는 형태로 원태그를 구현할 수 있어 개발 리소스를 절약할 수 있습니다.

View Item 이벤트에 담기는 상품ID는 3강에서 다룬 상품 피드의 id 필드와 정확히 일치해야 합니다. 원태그가 전달하는 상품ID와 피드의 상품ID 체계가 다르면(예: 원태그는 내부 SKU, 피드는 다른 코드 체계), 크리테오는 유저가 조회한 상품과 피드에 등록된 상품을 서로 연결하지 못해 리타겟팅 자체가 작동하지 않습니다. 이 불일치는 시스템이 별다른 오류 메시지 없이 조용히 실패하는 경우가 많아 발견이 늦어지기 쉽습니다.

프론트엔드 프레임워크를 교체하거나 페이지 구조를 리뉴얼할 때, 원태그 스니펫이 새 코드베이스에 누락되거나 파라미터를 채우던 로직이 삭제되는 사고가 흔히 발생합니다. 65강에서 강조한 배포 직후 검증 원칙을 크리테오 원태그에도 동일하게 적용해, 사이트 개편 직후에는 반드시 다섯 페이지 전체를 재검증해야 합니다.