이벤트
Firebase Analytics 이벤트 설계 오류 찾기
업데이트 2026-09-143 분 분량
짧은 답
이벤트 설계 오류는 대부분 흔적을 남깁니다. 사용자당 이벤트가 너무 많으면 중복, 하나의 행동에 이벤트가 두 개면 이름 문제, 보고서에 매개변수가 없거나 "(not set)"이면 미등록·누락, 값 대부분이 "(other)"로 묶이면 고유값이 너무 많은 매개변수, 아예 나타나지 않는 이벤트는 예약어나 한도 문제입니다. 흔적에서 출발해 DebugView로 확인하고, 보고서가 아니라 코드를 고치세요.
스프레드시트 속 이벤트 계획은 깔끔해 보입니다. 오류는 몇 달 뒤에 조금 높은 숫자, 둘로 쪼개진 보고서, 늘 비어 있는 매개변수로 나타납니다. 그때쯤이면 비교하고 싶은 모든 기간에 오류가 들어가 있습니다. 그래서 각 오류가 남기는 흔적을 알아보는 것이 중요합니다.
증상과 흔한 원인
| 보이는 현상 | 흔한 원인 | 확인 방법 |
|---|---|---|
| 행동에 비해 사용자당 이벤트가 너무 많음 | 렌더링·화면 표시·재개될 때마다 기록되거나, 리스너가 두 번 등록됨 | DebugView에서 행동을 한 번 하고 도착한 이벤트 세기 |
| 하나의 행동에 이벤트가 둘 (예: sign_up과 signUp) | 릴리스나 플랫폼 사이에 이름이 바뀜 — 이벤트 이름은 대소문자를 구분함 | 이벤트를 앱 버전·플랫폼별로 나눠 보기 |
| 모든 screen_view가 두 배 | 자동 화면 보고를 켠 채로 앱에서도 screen_view를 직접 기록함 | DebugView에서 화면 하나 열어 보기 |
| 화면 이름이 호스팅 컨트롤러나 MainActivity 같은 클래스 이름 | 여러 화면을 컨트롤러·액티비티 하나로 처리하는 앱에서 자동 화면 보고를 사용함 | DebugView에서 firebase_screen_class 확인하기 |
| 보고서에 매개변수가 없음 | 맞춤 측정기준으로 등록하지 않음 | 관리 → 맞춤 정의 |
| 등록한 매개변수가 "(not set)" | 일부 코드 경로나 구버전이 매개변수 없이 이벤트를 기록함 | 값을 앱 버전별로 나눠 보기 |
| 값 대부분이 "(other)"로 묶임 | ID, 타임스탬프, 자유 입력 텍스트 같은 고유값을 측정기준으로 사용함 | 매개변수의 고유값 개수 세어 보기 |
| 이벤트가 아예 나타나지 않음 | 예약된 접두사(firebase_, google_, ga_), 잘못된 이름, 40자를 넘는 이름 | 이벤트를 보낼 때 SDK 디버그 로그 확인하기 |
알아둘 만한 한도
| 앱 데이터 한도 | 값 |
|---|---|
| 고유 이벤트 이름 | 앱 사용자당 500개 |
| 이벤트 이름 길이 | 40자 |
| 이벤트당 매개변수 | 25개 |
| 매개변수 이름 길이 | 40자 |
| 매개변수 값 길이 | 100자 |
| 사용자 속성 | 속성당 25개 |
| 사용자 속성 이름 / 값 길이 | 24자 / 36자 |
주의: 맞춤 측정기준, 주요 이벤트, 데이터 필터는 만든 시점부터 적용됩니다. 오늘 등록한 매개변수는 지난달 보고서를 채워주지 않으므로, 중요한 데이터가 들어오기 전에 정해 두세요.
반나절이면 끝나는 점검
이벤트를 횟수·사용자 수와 함께 뽑기
최근 28일의 이벤트 이름, 이벤트 수, 전체 사용자 수를 내보내세요. 사용자당 이벤트 수로 정렬하고 위쪽부터 읽습니다.
비슷한 이름 찾기
이름을 알파벳순으로 정렬하세요. 대소문자, 밑줄, 시제만 다른 share, shared, Share 같은 변형은 대개 하나의 행동이 둘로 쪼개진 것입니다.
주요 이벤트를 원본 기록과 대조하기
구매는 스토어 거래와, 가입은 실제 생성된 계정 수와 비교하세요. 원본 기록과 가장 동떨어진 주요 이벤트부터 고치세요.
주요 이벤트를 버전·플랫폼별로 나눠 보기
이벤트가 사라지거나 두 배가 된 버전이 그 변화를 만든 릴리스를 알려줍니다.
DebugView에서 핵심 흐름 따라가기
기기 하나로 한 번 쭉 진행하면서 모든 이벤트를 세고 모든 매개변수를 읽어 보세요.
우회해서 해결하면 생기는 문제
- 부풀려진 이벤트끼리 나누면 그럴듯하지만 틀린 비율이 나옵니다
- 쪼개진 이름을 매달 스프레드시트에서 합치면 차트는 고쳐지지만 다른 도구가 읽는 데이터는 그대로입니다
- 정리한다고 이벤트 이름을 바꾸면 세 번째 버전이 생기고, 변경 전후의 모든 비교가 깨집니다
- 이벤트를 구분하려고 사용자 ID나 이메일을 매개변수에 넣으면 고유값이 폭증합니다. 게다가 이메일 같은 개인정보는 Google Analytics로 보내면 안 됩니다
대부분의 오류를 막는 규칙
- 소문자와 밑줄로 된 명명 규칙 하나를 문서로 정하고 모든 플랫폼에서 똑같이 쓰세요
- 화면이 나타나는 곳이 아니라 행동이 확정되는 곳에서 기록하세요
- 매개변수 값은 식별자가 아니라 범주처럼 종류가 적게 유지하세요
- 새 이벤트는 릴리스 전에 반드시 DebugView로 확인하세요
- 이벤트의 의미를 바꿀 때는 기존 이벤트를 재정의하지 말고 새 이벤트를 추가하세요
Appnaly에서는 어떻게 보이나요
Appnaly는 앱별로 가장 많이 발생한 이벤트와 화면을 GA4가 보고하는 그대로, 이름을 바꾸거나 합치지 않고 보여줍니다. 그래서 쪼개진 이름을 빨리 찾기 좋습니다. 오타가 난 변형은 대개 올바른 이름 바로 옆에 보이고, 릴리스와 함께 양이 튄 이벤트도 눈에 띕니다. Appnaly는 비슷한 두 이름이 같은 행동이라고 추측하지 않습니다. 잘못된 추측은 오류를 드러내는 대신 숨기기 때문입니다.