맞춤 이벤트(Custom Event) 설계: 일반 구매 외에 "체류 시간 3분 이상", "상세페이지 스크롤 80% 달성" 데이터를 포스트백으로 광고 서버에 넘기기

3강에서 다룬 PageView, ViewContent, AddToCart 같은 표준 이벤트는 사용자가 실제로 취한 명확한 행동만 포착합니다. 하지만 상세 페이지에 3분 이상 머물렀다거나 페이지를 80% 이상 스크롤했다는 신호는 구매로 이어지지 않아도 관심도가 높다는 유용한 정보이며, 표준 이벤트 체계에는 이런 세부 행동을 위한 항목이 따로 없습니다. 이런 신호를 별도의 맞춤 이벤트로 설계해두면, 실제 구매자보다 훨씬 넓은 고관여 잠재고객군을 리마케팅·유사타겟팅의 기반 데이터로 쓸 수 있습니다.

1강에서 강조했듯 표준 이벤트 이름은 매체의 자동 최적화 로직이 전제로 삼는 값입니다. 체류시간 신호를 ViewContent 같은 표준 이벤트 이름으로 억지로 끼워 넣으면, 매체가 이를 실제 상품 조회로 오인해 최적화 알고리즘이 왜곡됩니다. 맞춤 이벤트는 반드시 표준 이벤트와 구분되는 별도 이름(예: HighEngagement, ScrollDepth80)으로 정의해야 두 데이터가 서로 섞이지 않습니다.

구글 태그매니저(GTM)는 window.dataLayer라는 전역 자바스크립트 배열로 이벤트·변수를 수신·처리합니다. 체류시간 3분 트리거는 페이지 진입 후 타이머를 시작해 180초가 지나도 사용자가 페이지에 남아 있으면 발화하도록, 스크롤 80% 트리거는 페이지 전체 높이 대비 스크롤 위치가 80%를 넘는 순간 발화하도록 GTM의 타이머 트리거·스크롤 깊이 트리거 기능으로 구성할 수 있습니다. 이렇게 정의한 조건이 만족되면 데이터 레이어에 이벤트를 푸시하고, 이를 픽셀 태그가 받아 매체로 전송하는 흐름입니다.

맞춤 이벤트도 2강에서 다룬 포스트백 파라미터 구조를 그대로 활용해 서버사이드로 전달할 수 있습니다. 다만 체류시간·스크롤 같은 신호는 서버가 직접 알 수 없는 클라이언트 행동이므로, 프론트엔드에서 조건이 충족된 순간 자사 서버로 먼저 알리고, 서버가 이를 다시 포스트백 형태로 매체에 전달하는 중계 구조가 필요합니다. 이 중계 단계를 생략하고 프론트엔드에서 매체로 직접 픽셀만 쏘면, 7강에서 다룬 프라이버시 강화 환경에서는 이 맞춤 신호 역시 픽셀과 똑같이 손실될 수 있습니다.

맞춤 이벤트라고 해서 발화 시점이나 중복 방지 원칙이 느슨해지는 것은 아닙니다. 같은 세션에서 스크롤 80% 조건을 여러 번 충족할 수 있는 페이지 구조라면(예: 무한 스크롤), 세션당 한 번만 발화하도록 제한하는 로직이 필요하며, 4강에서 다룬 event_id 기반 중복제거 원칙도 맞춤 이벤트에 동일하게 적용해야 합니다. 이를 지키지 않으면 소수의 사용자가 반복 발화시킨 이벤트가 전체 신호를 왜곡하게 됩니다.

체류시간·스크롤 깊이 같은 고관여 신호는 구매 전환 대비 발생량이 훨씬 많아, 이를 기반으로 만든 유사타겟팅 오디언스는 모수가 넓으면서도 관심도가 검증된 집단이 됩니다. 다만 이 신호만으로 입찰 최적화를 맡기면 실제 구매와 무관한 사용자까지 폭넓게 잡을 위험이 있으므로, 맞춤 이벤트는 어디까지나 리마케팅 오디언스 확장용 보조 신호로 쓰고 입찰 최적화 기준은 여전히 표준 전환 이벤트에 맡기는 것이 안전한 운영 방식입니다.

맞춤 이벤트는 표준 이벤트와 달리 매체 공식 문서에 정의돼 있지 않으므로, 개발팀에 구현을 요청할 때는 트리거 조건(예: 180초 이상 체류, 스크롤 80% 도달)과 발화 시 전달할 파라미터, 그리고 세션당 발화 횟수 제한 여부까지 구체적으로 명시한 문서를 함께 전달해야 합니다. "체류시간이 길면 이벤트를 보내주세요" 같은 모호한 요청은 개발자마다 다르게 해석할 여지가 커서, 10강에서 다루는 데이터 레이어 스펙 문서 작성 원칙을 맞춤 이벤트에도 동일하게 적용해야 합니다.

맞춤 이벤트를 붙인 뒤에는 6강에서 다룬 픽셀 헬퍼로 실제 조건이 충족됐을 때 이벤트가 정확히 한 번만 발화하는지 먼저 확인하고, 이 신호를 기반으로 만든 오디언스가 실제로 표준 전환 이벤트 대비 유의미하게 높은 전환율을 보이는지 일정 기간 관찰해야 합니다. 신호를 만들어놓고도 검증 없이 방치하면, 실제로는 관심도와 무관한 잡음 신호를 광고 최적화에 계속 흘려보내는 상태가 될 수 있습니다.

맞춤 이벤트를 하나둘 추가하다 보면 어느 순간 표준 이벤트보다 종류가 많아져, 어떤 이벤트가 아직 쓰이고 있고 어떤 이벤트가 이미 목적을 다했는지 파악하기 어려워질 수 있습니다. 새 맞춤 이벤트를 추가할 때마다 목적·소유 담당자·폐기 기준을 함께 기록해두면, 11강에서 다룰 정기 점검 시 더 이상 쓸모없는 이벤트를 정리하는 판단이 훨씬 쉬워집니다.