GA4 이벤트 계층 구조의 정석: 자동 수집 이벤트, 향상된 측정 이벤트, 추천 이벤트, 맞춤 이벤트의 명확한 분류 규칙

GA4 태그(gtag.js 또는 GTM)를 설치하는 순간부터 별도 코드 없이 바로 기록되는 이벤트가 있습니다. first_visit(신규 사용자 최초 방문), session_start(세션 시작), user_engagement(참여도 계산 기초)가 대표적이고, page_view(페이지 조회)도 여기 포함됩니다. 이 이벤트들은 계정 설정만으로 이미 쌓이고 있으므로, 새로 만들 필요 없이 "지금 이미 있는 데이터"로 취급하고 넘어가면 됩니다.

문제는 실무에서 이 이벤트들을 다시 만들려고 시도하는 경우입니다. GTM에서 session_start 같은 이름으로 커스텀 태그를 새로 만들면 GA4 내부적으로 이미 존재하는 이벤트와 이름이 충돌하거나, 의도와 다른 중복 데이터가 쌓일 수 있습니다. 설계를 시작하기 전에 GA4 실시간 보고서에서 어떤 이벤트가 이미 들어오고 있는지부터 확인하는 습관이 필요합니다.

향상된 측정(Enhanced Measurement)은 페이지 조회, 스크롤, 외부 링크 클릭, 사이트 검색, 동영상 참여, 파일 다운로드, 양식 시작, 양식 제출 총 8가지를 지원합니다. 웹 데이터 스트림 설정 화면에서 토글 하나로 켜고 끌 수 있고, 코드를 건드릴 필요가 없습니다. 다만 page_view는 사용 해제가 불가능한 필수 항목이고, 나머지 7개는 선택적으로 켤 수 있습니다.

향상된 측정을 켠 직후에는 데이터가 바로 보이지 않을 수 있습니다. 설정 반영에 최대 24시간이 걸릴 수 있으므로, 켠 당일 실시간 보고서에 안 보인다고 바로 재설정하지 말고 하루 정도 지켜보는 편이 안전합니다.

추천 이벤트(Recommended Events)는 구글이 미리 정의한 이름과 매개변수 구조를 그대로 따르는 이벤트입니다. purchase, add_to_cart, sign_up처럼 표준 이름을 정확히 맞춰 전송하면 GA4 내장 보고서(전자상거래 보고서 등)에 자동으로 매핑됩니다. 반면 맞춤 이벤트(Custom Events)는 이름과 매개변수를 사용자가 임의로 정의하는 이벤트로, 표준 보고서에 자동 반영되지 않고 별도로 탐색 분석이나 커스텀 보고서를 만들어야 값을 확인할 수 있습니다.

이 차이 때문에 실무에서는 "표준 행동을 다루는 이벤트인가"를 먼저 따져보는 게 순서입니다. 구매, 가입, 검색처럼 이미 구글이 이름을 정해둔 행동이라면 추천 이벤트 규격을 그대로 쓰는 편이 리소스를 아낍니다. 추천 이벤트를 올바르게 구현하면 커스텀 차원(custom dimension) 슬롯을 소비하지 않지만, 맞춤 이벤트는 매개변수마다 커스텀 차원이나 측정기준을 별도로 등록해야 하기 때문입니다.

이벤트 설계를 매개변수 이름부터 정하기 시작하면 나중에 구조를 다시 뜯어고쳐야 하는 경우가 많습니다. 4단 분류는 구현 방식(코드 수정 필요 여부)과 보고서 지원 여부라는 두 기준으로 나뉘어 있어서, 이 순서를 지키면 "이미 자동으로 잡히는 걸 다시 만드는" 낭비와 "표준 규격이 있는데 맞춤으로 새로 짜는" 낭비를 둘 다 피할 수 있습니다.

특히 여러 사람이 GTM 컨테이너를 함께 관리하는 팀이라면, 이 분류 기준을 팀 내에 문서로 공유해두는 것이 중요합니다. 신규 담당자가 합류할 때마다 "이 이벤트는 자동인가 맞춤인가"를 매번 새로 확인하는 것보다, 처음부터 4단 표를 만들어 두면 설계 회의 시간이 크게 줄어듭니다.

가장 흔한 혼동은 향상된 측정과 추천 이벤트를 같은 범주로 착각하는 경우입니다. 향상된 측정은 "인터페이스 토글로 켜는 것", 추천 이벤트는 "코드로 표준 규격에 맞춰 보내는 것"이라 구현 방식 자체가 다릅니다. 예를 들어 파일 다운로드는 향상된 측정에서 토글만 켜면 잡히지만, 구매(purchase)는 향상된 측정 항목이 아니라 개발팀이 데이터 레이어를 통해 직접 전송해야 하는 추천 이벤트입니다.

또 하나는 맞춤 이벤트를 만들면서 이미 추천 이벤트로 존재하는 이름을 그대로 재사용하는 경우입니다. 이름은 같아도 매개변수 구조가 구글 표준과 다르면 보고서 매핑이 깨지므로, 맞춤 이벤트를 만들 때는 추천 이벤트 목록에 같은 이름이 있는지 먼저 확인해야 합니다.

새 이벤트를 만들기 전에는 항상 다음 순서로 확인하는 편이 재작업을 줄입니다. 첫째, 실시간 보고서에서 이미 잡히고 있는 자동 수집·향상된 측정 이벤트인지 확인합니다. 둘째, 구글이 정의한 추천 이벤트 목록에 같은 행동을 다루는 표준 이름이 있는지 찾아봅니다. 셋째, 위 두 가지에 해당하지 않을 때만 맞춤 이벤트로 새로 설계하고, 이름·매개변수를 문서로 남겨 팀과 공유합니다.

이 순서를 건너뛰고 맞춤 이벤트부터 만들면, 나중에 같은 행동을 두 가지 이벤트로 중복 집계하거나 표준 보고서와 숫자가 어긋나는 문제를 뒤늦게 발견하게 됩니다.