시작하기

Firebase Analytics에서 테스트 사용자와 실제 사용자 구분하기

업데이트 2026-09-143 분 분량

짧은 답

Firebase는 테스터와 고객을 구분하지 못합니다. 그래서 출시 전에 테스트 트래픽을 어떻게 구분할지 정해야 합니다. 개발 빌드는 별도의 Firebase 앱으로 분리하고, 디버그 빌드에서는 Analytics를 끄고, GA4에는 디버그 모드 기기를 제외하는 개발자 트래픽 필터를 설정하세요. 이미 섞인 데이터는 나중에 필터링할 수 없고, 탐색 분석에서 앱 버전·기기·테스터 사용자 속성으로 제외해서 볼 수만 있습니다.

자기 휴대폰을 사용자로 세고 싶은 사람은 없습니다. 그런데도 그런 일이 생기는 건 Firebase가 누가 테스트 중인지 모르기 때문입니다. 책상 위의 디버그 빌드도, 동료 휴대폰의 TestFlight 빌드도, 결제한 고객도 모두 똑같은 first_open, session_start, screen_view 이벤트를 보냅니다.

데이터에 나타나는 테스트 트래픽의 모습

  • 출시일마다 신규 사용자가 튀었다가 다음 날 원래대로 돌아옵니다
  • 이벤트를 엄청나게 많이 보내는 소수의 사용자가 있습니다
  • 스토어에 한 번도 출시하지 않은 앱 버전에서 활동이 잡힙니다
  • 업무 시간대에 한 도시, 즉 개발팀이 있는 도시에 사용자가 몰려 있습니다
  • 스토어에는 매출이 없는데 직접 만든 구매·구독 이벤트가 잡힙니다 (GA4는 샌드박스 구매를 in_app_purchase에서 제외하지만, 직접 만든 이벤트는 걸러지지 않습니다)
예시: 출시 첫 달의 작은 앱
월간 활성 사용자                        410
1.3.0-beta 사용자 (미출시 버전)          62
사용자당 이벤트, 상위 5명              2,900
사용자당 이벤트, 나머지 전체              38

"사용자"의 최소 15%가 테스트 중이며,
기기 5대가 전체 이벤트의 약 절반을 만듭니다.

테스트 트래픽이 들어오는 경로

출처데이터에 들어오는 이유
Xcode·Android Studio에서 실행한 디버그 빌드별도로 분리하지 않으면 출시 빌드와 같은 Firebase 설정을 사용합니다
TestFlight와 Google Play 테스트 트랙테스터가 설치하는 빌드도 일반 출시 빌드처럼 Analytics를 보냅니다
디버그 모드로 남겨둔 기기디버그 모드는 DebugView에 이벤트를 보여줄 뿐 보고서에서 빼주지 않습니다
자동화 테스트Google Play 출시 전 보고서는 Firebase Test Lab 기기에서 앱을 사람처럼 실행합니다
개발자 본인의 평소 사용데모용으로 쓰는 휴대폰도 Analytics 입장에서는 사용자입니다

앞으로 테스트 트래픽을 막는 방법

  1. 개발 빌드에 별도의 Firebase 앱 주기

    고유한 번들 ID나 애플리케이션 ID를 가진 디버그·스테이징 빌드를 별도의 Firebase 프로젝트에 등록해, 그 이벤트가 운영 속성에 들어가지 않게 합니다.

  2. 디버그 빌드에서 Analytics 끄기

    Firebase 앱을 하나만 쓴다면 디버그 빌드에서 setAnalyticsCollectionEnabled(false)를 호출하거나, Info.plist의 FIREBASE_ANALYTICS_COLLECTION_ENABLED와 AndroidManifest.xml의 firebase_analytics_collection_enabled로 수집을 끄고 출시 빌드에서만 켭니다.

  3. GA4에 개발자 트래픽 필터 추가하기

    관리 → 데이터 수집 및 수정 → 데이터 필터에서 개발자 트래픽 필터를 만들어 디버그 모드 기기의 이벤트를 제외합니다. 처음에는 테스트 상태로 두고 탐색 분석에서 "테스트 데이터 필터 이름" 측정기준을 확인한 뒤 활성화하세요.

  4. Android에서 Firebase Test Lab 감지하기

    Test Lab 기기는 firebase.test.lab이라는 시스템 설정을 "true"로 둡니다. 앱 시작 시 이 값을 확인해 설정되어 있으면 Analytics 수집을 끄세요.

  5. 출시 빌드를 쓰는 내부 테스터 표시하기

    스토어 빌드로 테스트하는 사람에게는 숨겨진 설정 스위치로 tester = true 같은 사용자 속성을 설정하세요. 데이터가 지워지지는 않지만 탐색 분석과 비교에서 제외할 수 있습니다.

주의: 데이터 필터는 영구적이고 소급 적용되지 않습니다. 제외된 이벤트는 처리되지 않아 복구할 수 없고, 필터가 활성화되기 전에 쌓인 데이터는 그대로 남습니다. 의도한 트래픽만 걸리는지 확인할 때까지 새 필터는 테스트 상태로 두세요.

참고: GA4의 내부 트래픽 필터는 IP 주소 기준이라 앱 사용자에게는 적용할 수 없습니다. 앱에서는 빌드 분리와 개발자 트래픽 필터가 실제로 쓸 수 있는 방법입니다.

이미 섞여 버린 데이터 구분하기

과거 데이터는 나중에 필터링할 수 없지만, 걸러서 읽을 수는 있습니다. 탐색 분석에서 다음을 제외하는 세그먼트나 비교를 추가하세요.

  • 스토어에 출시한 적 없는 앱 버전
  • 테스터 사용자 속성 (설정하기 시작한 날부터)
  • 개발팀만 쓰는 기기 모델이나 지역 — 실제 사용자도 해당될 수 있으므로 마지막 수단으로만

공유하는 숫자 옆에는 무엇을 제외했는지 적어 두세요. 분기 중간에 조용히 정의가 바뀐 사용자 수는 테스트가 포함되었다고 밝힌 숫자보다 더 나쁩니다.

섞인 채로 두면 생기는 문제

  • 테스터는 매일 앱을 열기 때문에 초기 리텐션이 실제보다 훨씬 좋아 보입니다
  • 테스터는 확인할 기능으로 곧장 가기 때문에 퍼널 전환율이 말도 안 되게 높게 나옵니다
  • 출시일의 급증이 성공적인 출시로 읽힙니다
  • 몇 대의 테스트 기기가 만든 많은 이벤트가, 실제 고객에게서는 끊긴 이벤트를 가려 버립니다

Appnaly에서는 어떻게 보이나요

Appnaly는 GA4 속성에서 처리된 데이터를 읽기 때문에, GA4에서 활성화한 필터는 그 시점부터 Appnaly에도 반영되고, 거르지 않은 테스트 트래픽은 다른 사용자와 똑같이 집계됩니다. Appnaly의 점검 규칙은 최소 사용자 수가 채워질 때까지 판단을 미루므로 테스트 기기 몇 대만으로 알림이 뜨지는 않습니다. 하지만 테스터와 고객을 구분할 수는 없습니다. 그 구분은 데이터가 만들어지는 곳에서 해야 합니다.

함께 읽을 글