2026년 10월 29일·3분 읽기
GA4 이벤트 500개 한도? 웹에는 없습니다 — 좀비 이벤트 정리
이벤트 목록이 200줄이 넘고 대부분 28일에 몇 건뿐입니다. 500개 한도는 앱 스트림 이야기라 웹에는 해당되지 않습니다. 그런데도 정리해야 하는 이유와, 지워도 되는 이벤트를 가르는 순서를 정리했습니다.
증상
보고서 > 참여도 > 이벤트를 열면 목록이 끝없이 내려갑니다. 200줄쯤 되고, 위쪽 열 개를 빼면 28일 동안 3건, 1건, 0건입니다. test_event_2, btn_click_old, promo_0428 같은 이름이 보입니다. 누가 왜 만들었는지 아는 사람은 이미 회사에 없습니다.
여기서 대개 이런 말이 나옵니다. "GA4 이벤트 500개 한도에 걸리기 전에 정리해야 하지 않나요?"
먼저, 500개 한도부터 바로잡습니다
웹 데이터 스트림에는 고유 이벤트 이름 개수 제한이 없습니다. Google의 수집 한도 문서는 웹 데이터 스트림의 경우 고유하게 이름이 지정된 이벤트 수에 제한이 없고, 500개는 앱 사용자당 앱 데이터 스트림에 적용되는 한도라고 적고 있습니다. 같은 문서가 자동 수집 이벤트와 향상된 측정 이벤트는 그 한도에 포함되지 않는다고도 밝히고 있습니다.
그러니 웹사이트만 측정하고 있다면, 이벤트가 200개든 400개든 한도 때문에 잘리지는 않습니다. 인터넷에 도는 "GA4 이벤트는 500개까지"라는 문장은 앱 스트림 한도가 웹으로 건너온 것입니다. 앱 스트림을 함께 쓰고 있다면 그때는 실제 한도입니다.
바로잡았으니 진짜 질문으로 갑니다. 한도에 안 걸리는데 왜 정리해야 하나요?
좀비 이벤트가 실제로 비용인 이유
목록이 200줄이라는 사실 자체가 증상입니다.
- 다음 사람이 무엇을 믿어야 할지 모릅니다. 진짜 쓰는 이벤트 12개가 죽은 이름 180개 사이에 섞여 있으면, 새 담당자는 매번 처음부터 조사해야 합니다.
- 고를 때마다 실수가 끼어듭니다. 잠재고객·키 이벤트·탐색에서 이름을 고르는 순간마다
purchase와purchase_old중 하나를 잘못 고를 기회가 생깁니다. - 설계가 없었다는 신호입니다. 이벤트 180개가 쌓이는 동안 아무도 지우지 않았다면, 보통 그 프로퍼티는 이름 규칙도 파라미터 규칙도 없는 상태입니다.
우리 점검(EV-05)의 기준은 이렇습니다. 28일 동안 10건 미만인 이벤트를 좀비 후보로 세고, 그 비율이 전체 이벤트의 20%를 넘으면 감점, 40%를 넘으면 0점입니다. 고유 이벤트 수 자체가 300개를 넘으면 비율과 무관하게 0점으로 봅니다 — GA4의 한도가 아니라, 사람이 관리할 수 있는 선을 우리가 그은 값입니다.
좀비와 '죽은 이벤트'는 다릅니다
둘을 섞으면 엉뚱한 것을 지웁니다.
| 좀비 이벤트 | 죽은 이벤트 | |
|---|---|---|
| 모양 | 처음부터 계속 적음 | 잘 오다가 어느 날 0 |
| 뜻 | 쓰지 않는 이벤트 | 대개 고장 |
| 할 일 | 정리 | 원인 조사 |
두 번째가 훨씬 급합니다. 우리 EV-04는 최근 7일 연속 0건이면서 그 앞 기간에는 충분히 쌓였던 이벤트를 '멈춘 이벤트'로 보고 감점합니다(주 단위로 ±60% 이상 흔들리는 이벤트는 주의로 봅니다). 목록 정리를 하다가 이런 이벤트를 발견하면, 지울 게 아니라 그날 무엇이 배포됐는지부터 찾아야 합니다.
정리하는 순서
1) 기간을 28일로 놓고 이벤트 수로 정렬합니다. 보고서 > 참여도 > 이벤트에서 이벤트 수가 적은 순으로 보면 후보가 아래쪽에 모입니다.
2) 지우면 안 되는 것을 먼저 뺍니다. 건수가 적은 것과 안 쓰는 것은 다릅니다. 환불, B2B 문의, 고액 상품 구매, 계약 해지처럼 원래 드물지만 가장 중요한 이벤트가 목록 바닥에 있습니다. 이런 이벤트는 건수가 0에 가까울수록 오히려 주시해야 합니다.
3) 남은 후보를 세 갈래로 나눕니다.
- 오타·시험용 (
purchse,test_event_2) — 바로 정리 대상입니다. - 끝난 캠페인 (
promo_0428) — 정리 대상이되, 그 기간 리포트를 다시 볼 일이 있는지만 확인합니다. - 같은 행동의 옛 이름 (
addToCart) — 정리하되, 이름 규칙부터 정해야 또 생기지 않습니다.
4) 보내는 쪽에서 멈춥니다. 이벤트는 GA4 화면에서 지우는 것이 아니라 보내지 않으면 사라집니다. GTM이라면 해당 태그·트리거를 제거하고, 사이트 코드에 직접 박혀 있으면 코드에서 뺍니다. 보고서는 선택한 기간에 수집된 이벤트를 보여주므로, 멈춘 뒤 기간이 지나가면 목록에서 자연히 빠집니다.
5) 지우기 전에 목록을 남깁니다. 이벤트 이름과 마지막 건수, 그리고 "왜 지웠는지"를 한 줄씩 적어 두세요. 반년 뒤 "예전에 이런 거 안 봤나요?"라는 질문에 답할 수 있는 유일한 기록입니다.
한 줄 요약
웹에는 500개 한도가 없습니다. 그래도 정리하는 이유는 한도가 아니라 사람입니다. 28일에 10건도 안 되는 이름이 전체의 5분의 1을 넘으면 그 목록은 이미 지도를 잃은 상태입니다. 단, 드물어서 소중한 이벤트와 어제부터 멈춘 이벤트는 정리 대상이 아니라 각각 보호 대상과 조사 대상입니다.
다음 글을 메일로 받아보세요
실제 진단에서 나온 GA4 문제와 고치는 순서를 월 1~2회 보냅니다. 한 번의 클릭으로 언제든 그만 받을 수 있습니다.
수집 항목·목적·보유 기간은 개인정보처리방침에 적어 두었습니다 — 개인정보처리방침