Android 앱 사용자 분석 완벽 가이드 — Firebase Analytics, BigQuery, 사용자 유지율과 코호트 분석

Android 앱을 개발해 Google Play에 출시하면 가장 먼저 확인하게 되는 숫자가 다운로드 수입니다.

앱을 설치한 사용자가 100명에서 1,000명으로 늘어나면 성과가 나타나고 있다고 느낄 수 있습니다.

하지만 다운로드 수만으로 앱이 성공적으로 운영되고 있는지 판단하기는 어렵습니다.

실제로 중요한 것은 사용자가 앱을 설치한 이후의 행동입니다.

사용자가 앱을 설치한 뒤 다시 실행하는가?
어떤 화면을 가장 많이 이용하는가?
검색 기능을 사용한 뒤 실제 결과를 확인하는가?
특정 화면에서 사용자가 이탈하는가?
좋아요나 즐겨찾기 기능을 사용하는가?
신규 사용자가 일주일 뒤에도 앱을 사용하는가?
광고 제거 상품을 구매하는 사용자는 어떤 행동을 보이는가?

이러한 질문에 답하려면 사용자 행동 데이터를 체계적으로 수집하고 분석해야 합니다.

이번 글에서는 Firebase Analytics를 이용해 Android 앱의 사용자 행동을 분석하고, BigQuery로 데이터를 확장 분석하는 방법을 살펴보겠습니다.

특히 조류 도감이나 버스 정보 앱처럼 검색과 정보 조회가 중심인 앱을 예제로 설명합니다.

개발 환경: Kotlin, XML ViewBinding, MVVM, Firebase Analytics, Firebase Crashlytics, BigQuery, Google Play Console. 아래 수치와 분석 결과는 설명을 위한 가상 예시이며 실제 앱에서 측정한 결과가 아닙니다.

1. 앱 사용자 분석이 필요한 이유

앱을 운영하면서 다운로드 수와 광고 수익만 확인하면 다음과 같은 문제를 발견하기 어렵습니다.

예를 들어 조류 도감 앱의 사용자가 많아졌다고 가정하겠습니다.

하지만 실제 이용 패턴을 확인해 보니 다음과 같을 수 있습니다.

앱 설치
   ↓
첫 실행
   ↓
조류 검색
   ↓
검색 결과 없음
   ↓
앱 종료

이 경우 광고를 추가하거나 새로운 기능을 개발하는 것보다 검색 기능을 개선하는 것이 먼저일 수 있습니다.

반대로 다음과 같은 사용자가 많다면 다른 전략을 고려할 수 있습니다.

앱 설치
   ↓
조류 검색
   ↓
상세 정보 확인
   ↓
좋아요 등록
   ↓
다음 날 재방문

좋아요나 관찰 기록 기능이 재방문과 관련되어 있는지 분석해 볼 수 있습니다.

다만 특정 기능을 사용하는 사용자의 유지율이 높다고 해서 해당 기능이 유지율을 높인 원인이라고 단정할 수는 없습니다.

사용자 분석에서는 상관관계와 인과관계를 구분하는 것도 중요합니다.

Firebase Analytics 이해하기

2. Firebase Analytics란?

Firebase Analytics는 앱과 웹사이트에서 발생하는 사용자 행동을 분석할 수 있는 서비스입니다.

Android 앱에서는 Firebase SDK를 이용해 이벤트를 기록할 수 있습니다.

대표적인 분석 항목은 다음과 같습니다.

항목	설명
활성 사용자	일정 기간 앱을 이용한 사용자
이벤트 수	특정 행동이 발생한 횟수
화면 조회	화면이 표시된 횟수
사용자 유지율	일정 기간 이후 재방문한 사용자 비율
사용자 속성	분석에 사용할 사용자 분류 정보
전환 이벤트	중요한 사용자 행동
사용자 획득	앱 유입 경로

Firebase Analytics는 Google Analytics 4의 이벤트 기반 데이터 모델을 사용합니다.

따라서 앱에서 어떤 이벤트를 수집할지 미리 설계하는 것이 중요합니다.

3. Firebase 프로젝트 연결

Firebase Console에서 프로젝트를 생성한 뒤 Android 앱을 등록합니다.

일반적인 설정 순서는 다음과 같습니다.

Firebase 프로젝트 생성
Android 앱 등록
앱 패키지명 입력
google-services.json 다운로드
앱 모듈에 설정 파일 추가
Google Services Gradle 플러그인 적용
Firebase Analytics SDK 추가

기존에 Firebase Crashlytics를 사용하고 있다면 동일한 Firebase 프로젝트에 Analytics를 연결할 수 있습니다.

단, 앱 패키지명과 빌드 변형 설정이 일치하는지 확인해야 합니다.

Firebase Analytics 설치

4. Gradle 설정

프로젝트의 플러그인 관리 방식에 맞춰 Google Services 플러그인을 추가합니다.

예를 들어 Version Catalog를 사용하지 않는 프로젝트라면 다음과 같은 구성을 사용할 수 있습니다.

// 프로젝트 build.gradle.kts

plugins {
    id("com.google.gms.google-services") version "<version>" apply false
}

앱 모듈에서는 플러그인을 적용합니다.

// app/build.gradle.kts

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
    id("com.google.gms.google-services")
}

Firebase BoM과 Analytics SDK를 추가합니다.

dependencies {

    implementation(
        platform(
            "com.google.firebase:firebase-bom:<version>"
        )
    )

    implementation(
        "com.google.firebase:firebase-analytics"
    )
}

<version>은 Firebase 공식 문서에서 확인한 버전으로 교체해야 합니다.

최신 Firebase BoM에서는 별도의 Firebase KTX 모듈이 더 이상 BoM에 포함되지 않으므로 기존 firebase-analytics-ktx 예제를 그대로 사용하지 않는 것이 좋습니다.

이벤트 기반 분석

5. 이벤트란?

이벤트는 앱에서 발생하는 특정 행동을 의미합니다.

예를 들어 다음과 같습니다.

앱 실행
검색 실행
검색 결과 표시
상세 화면 진입
좋아요 등록
메모 저장
광고 제거 화면 진입
구매 버튼 클릭

이러한 행동을 이벤트로 기록하면 사용자가 앱을 어떻게 이용하는지 확인할 수 있습니다.

다만 모든 버튼 클릭을 기록할 필요는 없습니다.

분석 목적이 없는 이벤트를 지나치게 많이 수집하면 데이터 관리가 어려워집니다.

6. 이벤트 이름 설계

조류 도감 앱을 기준으로 다음과 같이 이벤트를 설계할 수 있습니다.

이벤트 이름	의미
`bird_search`	조류 검색 실행
`bird_search_result`	검색 결과 표시
`bird_detail_view`	상세 정보 확인
`bird_favorite_add`	좋아요 등록
`bird_favorite_remove`	좋아요 해제
`bird_memo_save`	메모 저장
`bird_filter_use`	분류 필터 사용
`premium_screen_view`	프리미엄 화면 진입

이벤트 이름은 프로젝트에서 일관된 규칙을 사용하는 것이 좋습니다.

Firebase에는 예약된 이벤트 이름과 매개변수 이름, 길이 및 개수 제한이 있으므로 공식 문서를 확인해야 합니다.

Analytics 공통 클래스

7. AnalyticsLogger 인터페이스

MVVM 구조에서는 Activity나 Fragment에서 Firebase SDK를 직접 호출하는 대신 공통 인터페이스를 사용할 수 있습니다.

interface AnalyticsLogger {

    fun logEvent(
        name: String,
        params: Bundle? = null
    )
}

이렇게 하면 Analytics 구현을 교체하거나 테스트하기 쉬워집니다.

8. FirebaseAnalyticsLogger 구현

class FirebaseAnalyticsLogger(
    context: Context
) : AnalyticsLogger {

    private val analytics =
        FirebaseAnalytics.getInstance(context)

    override fun logEvent(
        name: String,
        params: Bundle?
    ) {
        analytics.logEvent(
            name,
            params
        )
    }
}

실제 프로젝트에서는 Hilt 같은 의존성 주입 도구를 이용해 Repository나 ViewModel에 전달할 수 있습니다.

다만 Analytics 이벤트를 모든 Repository에서 무분별하게 호출하면 추적 흐름이 복잡해질 수 있습니다.

이벤트의 소유 계층을 명확하게 정하는 것이 좋습니다.

검색 기능 분석

9. 검색 이벤트 기록

조류 검색 기능에서 사용자가 검색을 실행했을 때 이벤트를 기록할 수 있습니다.

fun logBirdSearch(
    keyword: String
) {

    val params = Bundle().apply {

        putLong(
            "keyword_length",
            keyword.length.toLong()
        )
    }

    analytics.logEvent(
        "bird_search",
        params
    )
}

여기서는 검색어 자체를 기록하지 않고 검색어 길이만 기록합니다.

검색어에는 사람 이름, 위치, 개인적인 내용 등이 포함될 수 있기 때문입니다.

특히 Analytics 서비스에는 개인식별정보를 전송하지 않도록 주의해야 합니다.

10. 검색 결과 이벤트

검색 결과 개수를 기록하면 검색 기능의 품질을 분석하는 데 도움이 됩니다.

fun logSearchResult(
    resultCount: Int
) {

    val params = Bundle().apply {

        putLong(
            "result_count",
            resultCount.toLong()
        )
    }

    analytics.logEvent(
        "bird_search_result",
        params
    )
}

이 데이터를 이용하면 검색 결과가 없는 경우가 얼마나 자주 발생하는지 확인할 수 있습니다.

예를 들어 검색 결과가 0건인 이벤트 비율이 높다면 다음 사항을 검토할 수 있습니다.

검색어 오타 처리
한글 초성 검색
부분 검색
동의어 검색
학명 검색
검색 결과 안내 UI

화면 조회 분석

11. 화면 추적이 필요한 이유

앱에 여러 화면이 있다면 사용자가 어떤 화면을 가장 많이 이용하는지 확인할 수 있어야 합니다.

예를 들어 다음과 같은 화면이 있다고 가정하겠습니다.

MainActivity
 ├── HomeFragment
 ├── SearchFragment
 ├── FavoriteFragment
 └── SettingsFragment

하나의 Activity 안에서 Fragment가 전환되는 구조에서는 자동 화면 추적만으로 원하는 화면 단위의 데이터를 충분히 얻지 못할 수 있습니다.

따라서 중요한 Fragment는 수동으로 화면 조회 이벤트를 기록하는 방법을 고려할 수 있습니다.

12. screen_view 이벤트

Firebase Analytics에서는 화면 조회를 위한 권장 이벤트를 제공합니다.

val params = Bundle().apply {

    putString(
        FirebaseAnalytics.Param.SCREEN_NAME,
        "bird_search"
    )

    putString(
        FirebaseAnalytics.Param.SCREEN_CLASS,
        "SearchFragment"
    )
}

analytics.logEvent(
    FirebaseAnalytics.Event.SCREEN_VIEW,
    params
)

이 예제는 검색 화면이 표시되었음을 기록합니다.

단, 자동 화면 추적과 수동 화면 추적을 함께 사용하는 경우 중복 기록 여부를 확인해야 합니다.

13. Fragment 생명주기와 이벤트

화면 조회 이벤트를 단순히 onCreate()에서 기록하면 실제 화면 표시 횟수와 차이가 발생할 수 있습니다.

Fragment가 생성되었지만 사용자에게 표시되지 않을 수도 있기 때문입니다.

따라서 Navigation Component의 목적지 변경이나 실제 화면 가시성을 기준으로 이벤트를 기록하는 방법을 검토할 수 있습니다.

예를 들어 다음과 같습니다.

navController.addOnDestinationChangedListener {
        _, destination, _ ->

    val screenName =
        destination.label?.toString()
            ?: destination.id.toString()

    logScreenView(screenName)
}

실제 프로젝트에서는 목적지 ID와 분석용 화면 이름을 명시적으로 매핑하는 것이 좋습니다.

화면 제목이 다국어로 변경되면 동일한 화면이 서로 다른 이름으로 집계될 수 있기 때문입니다.

사용자 속성

14. User Property란?

사용자 속성은 사용자를 일정한 기준으로 분류할 때 사용하는 값입니다.

예를 들어 다음과 같은 속성을 생각할 수 있습니다.

앱 테마 설정
무료 사용자 여부
프리미엄 사용자 여부
주요 기능 사용 유형

단, 사용자 속성은 개인정보를 저장하는 용도로 사용해서는 안 됩니다.

또한 사용자 속성의 개수와 값 길이에는 제한이 있습니다.

15. 프리미엄 사용자 구분

analytics.setUserProperty(
    "account_tier",
    "premium"
)

무료 사용자라면 다음과 같이 기록할 수 있습니다.

analytics.setUserProperty(
    "account_tier",
    "free"
)

이 데이터를 이용하면 무료 사용자와 프리미엄 사용자의 행동 차이를 분석할 수 있습니다.

다만 사용자 속성은 설정 시점 이후의 데이터에 영향을 주므로 과거 이벤트까지 자동으로 재분류된다고 가정해서는 안 됩니다.

사용자 유지율

16. Retention이란?

Retention은 일정 기간 이후 사용자가 다시 앱을 이용하는 비율을 의미합니다.

대표적으로 다음과 같은 지표가 있습니다.

지표	의미
D1 Retention	첫 사용 다음 날 재방문
D7 Retention	첫 사용 7일 후 재방문
D30 Retention	첫 사용 30일 후 재방문

예를 들어 10월 1일에 앱을 처음 사용한 사람이 100명이라고 가정하겠습니다.

이 중 10월 8일에 다시 앱을 사용한 사람이 20명이라면 D7 Retention은 20%입니다.

[
D7\ Retention = \frac{20}{100} \times 100 = 20%
]

단, 분석 도구마다 일 단위 계산과 사용자 코호트 기준이 다를 수 있습니다.

따라서 서로 다른 분석 도구의 Retention 수치를 비교할 때는 정의를 먼저 확인해야 합니다.

17. Retention이 중요한 이유

신규 사용자가 계속 증가하더라도 기존 사용자가 빠르게 이탈한다면 앱의 장기적인 성장은 어려울 수 있습니다.

예를 들어 다음 두 앱을 비교해 보겠습니다.

항목	앱 A	앱 B
신규 사용자	1,000명	1,000명
D7 Retention	10%	30%
7일 후 재방문 사용자	100명	300명

위 수치는 설명을 위한 가상 예시입니다.

앱 B는 동일한 신규 사용자 수에서도 더 많은 사용자가 일주일 뒤 다시 방문합니다.

이는 광고 수익이나 프리미엄 기능 이용 기회에도 영향을 줄 수 있습니다.

코호트 분석

18. 코호트란?

코호트(Cohort)는 특정한 공통 특성을 가진 사용자 집단을 의미합니다.

앱 분석에서는 주로 같은 날짜에 앱을 처음 사용한 사용자를 하나의 코호트로 묶습니다.

예를 들어 다음과 같습니다.

10월 1일 신규 사용자
10월 2일 신규 사용자
10월 3일 신규 사용자

각 집단의 재방문 비율을 비교하면 앱 업데이트나 기능 변경이 사용자 유지율에 어떤 영향을 주었는지 탐색할 수 있습니다.

19. 코호트 분석 예제

다음은 가상의 데이터입니다.

신규 사용자 날짜	D1	D7	D30
10월 1일	42%	24%	12%
10월 8일	45%	28%	15%
10월 15일	51%	33%	—
10월 22일	49%	—	—

아직 관찰 기간이 지나지 않은 값은 계산할 수 없습니다.

예를 들어 10월 22일에 유입된 사용자의 D30 Retention은 10월 말에는 알 수 없습니다.

이러한 미완성 코호트를 낮은 유지율로 잘못 해석하지 않도록 주의해야 합니다.

BigQuery 연동

20. BigQuery란?

BigQuery는 Google Cloud의 데이터 분석 서비스입니다.

Firebase Analytics에서 수집한 이벤트 데이터를 BigQuery로 내보내면 SQL을 이용해 상세 분석을 수행할 수 있습니다.

예를 들어 다음과 같은 질문에 답할 수 있습니다.

검색 기능을 사용한 사용자의 재방문율은?
좋아요 기능을 사용한 사용자는 얼마나 자주 앱을 실행하는가?
프리미엄 화면을 본 사용자는 몇 명인가?
앱 버전별 검색 결과 0건 비율은?
특정 기능을 사용한 사용자 그룹의 유지율은?

Firebase Console의 기본 보고서로 확인하기 어려운 분석을 SQL로 직접 수행할 수 있다는 장점이 있습니다.

21. Firebase와 BigQuery 연결

Firebase Console에서 프로젝트 설정의 통합 메뉴를 통해 BigQuery 연결을 구성할 수 있습니다.

일반적인 흐름은 다음과 같습니다.

Android 앱
    ↓
Firebase Analytics
    ↓
BigQuery Export
    ↓
BigQuery Dataset
    ↓
SQL 분석
    ↓
보고서 또는 대시보드

BigQuery는 사용량에 따라 비용이 발생할 수 있습니다.

특히 이벤트 데이터가 많거나 큰 테이블을 반복적으로 조회하면 쿼리 비용이 증가할 수 있습니다.

개인 개발자는 필요한 데이터만 조회하고 비용 알림을 설정하는 것이 좋습니다.

BigQuery 데이터 구조

22. Firebase 이벤트 테이블

Firebase Analytics를 BigQuery로 내보내면 일반적으로 날짜별 이벤트 테이블이 생성됩니다.

예를 들어 다음과 같은 구조입니다.

analytics_123456789
 ├── events_20261001
 ├── events_20261002
 ├── events_20261003
 └── ...

실제 Dataset 이름과 테이블 구성은 프로젝트 설정에 따라 달라집니다.

일부 내보내기 구성에서는 일중 테이블이 생성될 수도 있습니다.

23. 주요 이벤트 필드

Firebase Analytics의 BigQuery Export에서는 다음과 같은 필드를 활용할 수 있습니다.

필드	설명
`event_name`	이벤트 이름
`event_date`	이벤트 날짜
`event_timestamp`	이벤트 발생 시각
`user_pseudo_id`	가명 사용자 식별자
`event_params`	이벤트 매개변수
`user_properties`	사용자 속성
`app_info`	앱 관련 정보
`device`	기기 관련 정보

user_pseudo_id는 실제 사용자 계정 ID와 동일한 개념이 아닙니다.

또한 분석 식별자는 재설정되거나 수집 동의 상태에 따라 달라질 수 있습니다.

BigQuery SQL 분석

24. 이벤트별 발생 횟수

다음 SQL은 이벤트별 발생 횟수를 집계합니다.

SELECT
    event_name,
    COUNT(*) AS event_count
FROM
    `project_id.analytics_123456789.events_*`
WHERE
    _TABLE_SUFFIX BETWEEN '20261001' AND '20261031'
GROUP BY
    event_name
ORDER BY
    event_count DESC;

project_id와 Dataset 이름은 실제 프로젝트에 맞게 변경해야 합니다.

이 쿼리는 2026년 10월 한 달 동안 어떤 이벤트가 많이 발생했는지 확인하는 예제입니다.

25. 검색 결과가 없는 비율 분석

앞에서 bird_search_result 이벤트에 result_count 매개변수를 기록했습니다.

이를 이용해 검색 결과가 없는 비율을 계산할 수 있습니다.

WITH search_results AS (

    SELECT
        (
            SELECT
                value.int_value
            FROM
                UNNEST(event_params)
            WHERE
                key = 'result_count'
        ) AS result_count

    FROM
        `project_id.analytics_123456789.events_*`

    WHERE
        event_name = 'bird_search_result'
        AND _TABLE_SUFFIX
            BETWEEN '20261001' AND '20261031'
)

SELECT
    COUNT(*) AS total_searches,

    COUNTIF(
        result_count = 0
    ) AS empty_searches,

    SAFE_DIVIDE(
        COUNTIF(result_count = 0),
        COUNTIF(result_count IS NOT NULL)
    ) * 100 AS empty_rate_percent

FROM
    search_results;

이 쿼리는 결과 개수가 정상적으로 기록된 이벤트를 기준으로 0건 비율을 계산합니다.

매개변수가 누락된 이벤트는 분모에서 제외되므로, 전체 검색 이벤트 수와 분석 대상 이벤트 수가 다를 수 있습니다.

DAU 분석

26. 일간 활성 사용자 계산

BigQuery에서는 이벤트 데이터를 이용해 일별 사용자 수를 계산할 수 있습니다.

SELECT
    event_date,

    COUNT(
        DISTINCT user_pseudo_id
    ) AS users

FROM
    `project_id.analytics_123456789.events_*`

WHERE
    _TABLE_SUFFIX
        BETWEEN '20261001' AND '20261031'

GROUP BY
    event_date

ORDER BY
    event_date;

이 쿼리는 해당 날짜에 이벤트가 기록된 고유 가명 식별자 수를 계산합니다.

주의할 점은 이것이 Firebase Analytics 화면에 표시되는 공식 DAU 지표와 완전히 일치하지 않을 수 있다는 것입니다.

Firebase의 활성 사용자 정의, 데이터 수집 조건, 식별자 처리 방식 등이 다를 수 있기 때문입니다.

따라서 위 결과는 이벤트 기반 일별 고유 사용자 수로 해석하는 것이 정확합니다.

코호트 SQL

27. 신규 사용자 코호트 만들기

Firebase Analytics의 first_open 이벤트를 이용하면 신규 사용자 코호트를 구성할 수 있습니다.

다음은 신규 사용자 날짜별 D1 재방문 비율을 계산하는 단순 예제입니다.

WITH first_open_users AS (

    SELECT
        user_pseudo_id,
        MIN(
            PARSE_DATE('%Y%m%d', event_date)
        ) AS first_date

    FROM
        `project_id.analytics_123456789.events_*`

    WHERE
        event_name = 'first_open'
        AND _TABLE_SUFFIX
            BETWEEN '20261001' AND '20261031'
        AND user_pseudo_id IS NOT NULL

    GROUP BY
        user_pseudo_id
),

daily_activity AS (

    SELECT DISTINCT
        user_pseudo_id,
        PARSE_DATE(
            '%Y%m%d',
            event_date
        ) AS activity_date

    FROM
        `project_id.analytics_123456789.events_*`

    WHERE
        _TABLE_SUFFIX
            BETWEEN '20261001' AND '20261101'
        AND user_pseudo_id IS NOT NULL
)

SELECT
    f.first_date,

    COUNT(
        DISTINCT f.user_pseudo_id
    ) AS new_users,

    COUNT(
        DISTINCT IF(
            a.activity_date =
                DATE_ADD(
                    f.first_date,
                    INTERVAL 1 DAY
                ),
            f.user_pseudo_id,
            NULL
        )
    ) AS retained_d1_users,

    SAFE_DIVIDE(

        COUNT(
            DISTINCT IF(
                a.activity_date =
                    DATE_ADD(
                        f.first_date,
                        INTERVAL 1 DAY
                    ),
                f.user_pseudo_id,
                NULL
            )
        ),

        COUNT(
            DISTINCT f.user_pseudo_id
        )

    ) * 100 AS d1_retention_percent

FROM
    first_open_users f

LEFT JOIN
    daily_activity a

ON
    f.user_pseudo_id = a.user_pseudo_id

WHERE
    f.first_date <= DATE '2026-10-30'

GROUP BY
    f.first_date

ORDER BY
    f.first_date;

이 예제에서는 10월 31일 신규 사용자의 D1 재방문 데이터를 아직 관찰할 수 없으므로 제외했습니다.

또한 이벤트가 기록된 사용자만을 기준으로 계산하므로 Firebase Console의 공식 Retention 지표와 차이가 있을 수 있습니다.

기능 사용과 재방문 관계 분석

28. 좋아요 기능 사용자의 유지율

조류 도감 앱에서 좋아요 기능을 사용한 사용자의 재방문율이 궁금할 수 있습니다.

예를 들어 다음 두 그룹을 비교할 수 있습니다.

그룹 A
좋아요 기능 사용

그룹 B
좋아요 기능 미사용

두 그룹의 D7 Retention을 비교하면 좋아요 기능 사용과 재방문 사이의 관계를 탐색할 수 있습니다.

하지만 이 결과만으로 좋아요 기능이 재방문을 증가시킨다고 단정해서는 안 됩니다.

원래 앱에 관심이 많은 사용자가 좋아요 기능도 더 많이 사용할 수 있기 때문입니다.

인과관계를 확인하려면 무작위 실험 등 별도의 검증이 필요합니다.

앱 버전별 분석

29. 업데이트 효과 확인

새로운 앱 버전을 출시한 뒤 사용자 행동이 어떻게 변했는지 분석할 수 있습니다.

예를 들어 다음과 같은 변경이 있다고 가정하겠습니다.

버전 1.2
일반 LIKE 검색

버전 1.3
한글 초성 검색 추가

업데이트 전후의 검색 결과 0건 비율과 검색 후 상세 화면 진입률을 비교할 수 있습니다.

다만 앱 버전 외에도 사용자 구성, 계절, 마케팅 활동 등이 결과에 영향을 줄 수 있습니다.

따라서 단순 전후 비교만으로 업데이트 효과를 확정하지 않는 것이 좋습니다.

사용자 이탈 분석

30. Funnel 분석

Funnel은 사용자가 특정 목표에 도달하기까지 거치는 단계입니다.

예를 들어 조류 도감 앱에서는 다음과 같이 구성할 수 있습니다.

앱 실행
   ↓
검색 화면 진입
   ↓
검색 실행
   ↓
검색 결과 표시
   ↓
상세 화면 진입
   ↓
좋아요 등록

각 단계에서 다음 단계로 이동한 사용자 비율을 계산할 수 있습니다.

예를 들어 검색을 실행한 사용자 중 상세 화면을 열어본 비율이 낮다면 검색 결과 UI나 데이터 품질을 검토할 수 있습니다.

단, 모든 사용자가 좋아요 등록을 목표로 앱을 이용하는 것은 아닙니다.

따라서 Funnel의 마지막 단계를 무조건 성공으로 정의하는 것은 적절하지 않을 수 있습니다.

개인정보 보호

31. Analytics 데이터 수집 시 주의사항

사용자 분석을 위해 모든 데이터를 수집할 필요는 없습니다.

특히 다음 정보는 Firebase Analytics 이벤트에 직접 기록하지 않는 것이 좋습니다.

이메일 주소
전화번호
실명
상세 주소
비밀번호
인증 토큰
사용자가 작성한 메모 내용
개인을 식별할 수 있는 검색어

또한 정확한 GPS 좌표처럼 개인 위치를 식별할 수 있는 데이터도 Analytics 이벤트로 무분별하게 전송하지 않아야 합니다.

분석 목적에 필요한 최소한의 데이터만 수집하는 것이 중요합니다.

32. Google Play Data Safety

Firebase Analytics를 사용하는 앱은 실제 데이터 수집과 처리 방식에 따라 Google Play Data Safety 신고 내용을 검토해야 합니다.

특히 다음 사항을 확인해야 합니다.

수집하는 데이터 유형
데이터 사용 목적
제3자 SDK의 데이터 처리
데이터 공유 여부
삭제 요청 처리
개인정보처리방침
사용자 동의 및 선택권

Firebase SDK를 사용한다는 이유만으로 모든 앱의 Data Safety 신고 내용이 동일한 것은 아닙니다.

실제 앱 설정과 수집 데이터에 따라 달라질 수 있습니다.

데이터 수집 동의

33. Analytics 수집 제어

앱의 개인정보 정책과 사용자 동의 요구사항에 따라 Analytics 수집을 제어해야 할 수 있습니다.

예를 들어 다음과 같이 설정할 수 있습니다.

FirebaseAnalytics
    .getInstance(context)
    .setAnalyticsCollectionEnabled(false)

사용자가 적절하게 동의한 이후 수집을 활성화할 수 있습니다.

FirebaseAnalytics
    .getInstance(context)
    .setAnalyticsCollectionEnabled(true)

실제 구현에서는 앱 시작 시 수집이 먼저 발생하지 않도록 초기 설정과 SDK 동작을 함께 검토해야 합니다.

동의가 필요한 지역이나 상황에서는 수집 시작 전에 관련 요구사항을 충족해야 합니다.

BigQuery 비용 관리

34. 개인 개발자가 주의할 점

BigQuery는 강력한 분석 도구지만 쿼리 사용량에 따라 비용이 발생할 수 있습니다.

다음과 같은 방법을 고려할 수 있습니다.

필요한 날짜 범위만 조회
필요한 컬럼만 선택
_TABLE_SUFFIX 필터 활용
반복 쿼리 최소화
Google Cloud 예산 알림 설정
데이터 보관 기간 검토
대시보드 새로고침 주기 조절

예를 들어 다음과 같은 쿼리는 모든 날짜의 이벤트 테이블을 조회할 수 있습니다.

SELECT *
FROM
    `project_id.analytics_123456789.events_*`;

대신 필요한 기간과 컬럼을 지정하는 것이 좋습니다.

실제 앱 적용 전략

35. 조류 도감 앱

조류 도감 앱에서는 다음 항목을 우선 분석하는 것이 좋습니다.

분석 항목	목적
검색 실행 횟수	검색 기능 이용 정도
검색 결과 0건 비율	검색 품질 확인
상세 화면 진입률	검색 결과 활용
좋아요 등록률	개인화 기능 활용
메모 저장률	관찰 기록 기능 활용
D7 Retention	재방문 수준
광고 제거 구매율	유료 기능 수요

이 데이터를 통해 새로운 기능을 개발하기 전에 기존 기능의 사용성을 개선할 수 있습니다.

36. 버스 정보 앱

버스 정보 앱에서는 다음 항목을 분석할 수 있습니다.

버스 검색 실행 횟수
검색 결과 표시 성공률
즐겨찾기 등록률
즐겨찾기 화면 재방문
검색 후 상세 화면 진입률
앱 버전별 오류 발생률
D1 및 D7 Retention

버스 정보 앱에서는 사용자가 필요한 정보를 얼마나 빠르게 찾는지가 중요할 수 있습니다.

따라서 화면 조회 수뿐 아니라 검색 성공 여부와 오류 발생률을 함께 분석하는 것이 좋습니다.

37. 음력 달력 앱

음력 달력 앱에서는 다음과 같은 이벤트를 검토할 수 있습니다.

달력 화면 조회
기념일 등록
기념일 수정
D-Day 계산기 사용
만나이 계산기 사용
설정 변경
위젯 사용 관련 이벤트

단, 생일이나 기념일의 실제 날짜와 이름을 Analytics 이벤트에 기록하는 것은 피하는 것이 좋습니다.

사용자가 어떤 기능을 이용했는지만 기록해도 충분한 경우가 많습니다.

실무 적용 순서

38. 처음부터 모든 이벤트를 수집하지 않기

Firebase Analytics를 처음 도입한다면 다음 순서로 적용하는 것이 좋습니다.

1단계: 분석 목적 정의

앱에서 어떤 문제를 해결하고 싶은지 정합니다.

2단계: 핵심 이벤트 선정

검색, 상세 조회, 좋아요, 메모 저장 등 주요 행동을 선택합니다.

3단계: 이벤트 이름 통일

이벤트와 매개변수의 이름을 일관되게 관리합니다.

4단계: 개인정보 검토

불필요한 사용자 데이터를 수집하지 않도록 합니다.

5단계: Firebase DebugView 확인

개발 기기에서 이벤트가 정상적으로 수집되는지 확인합니다.

6단계: 기본 보고서 분석

활성 사용자, 화면 조회, 주요 이벤트를 확인합니다.

7단계: Retention 분석

사용자가 다시 방문하는지 확인합니다.

8단계: BigQuery 연동

기본 보고서로 부족한 분석을 SQL로 수행합니다.

9단계: 개선 가설 수립

분석 결과를 바탕으로 개선할 기능을 선정합니다.

10단계: 개선 결과 검증

업데이트 이후 동일한 지표를 다시 확인합니다.

Firebase DebugView

39. 이벤트가 정상적으로 기록되는지 확인

Firebase Analytics 이벤트는 일반 보고서에 즉시 표시되지 않을 수 있습니다.

개발 중에는 DebugView를 활용해 이벤트 수집 상태를 확인할 수 있습니다.

ADB를 이용해 특정 앱의 Analytics 디버그 모드를 활성화할 수 있습니다.

adb shell setprop debug.firebase.analytics.app com.example.birdapp

앱 패키지명은 실제 Application ID로 변경해야 합니다.

디버그 모드를 해제하려면 다음 명령을 사용할 수 있습니다.

adb shell setprop debug.firebase.analytics.app .none.

이후 Firebase Console의 DebugView에서 이벤트가 정상적으로 수집되는지 확인합니다.

단, DebugView에서 이벤트가 보인다고 해서 모든 일반 보고서에 즉시 동일하게 반영되는 것은 아닙니다.

사용자 분석 체크리스트

40. 출시 및 운영 전 점검

Firebase 프로젝트 연결
Analytics SDK 적용
이벤트 수집 목적 정의
핵심 이벤트 선정
이벤트 이름 규칙 통일
이벤트 매개변수 설계
검색어 원문 수집 여부 검토
사용자 메모 수집 금지
화면 조회 중복 기록 확인
Fragment 화면 추적 검토
DebugView 이벤트 확인
사용자 속성 최소화
DAU 분석
D1 Retention 확인
D7 Retention 확인
D30 Retention 확인
코호트 분석
검색 결과 0건 비율 분석
주요 기능 사용률 확인
BigQuery 연동 필요성 검토
BigQuery 비용 관리
개인정보처리방침 검토
Google Play Data Safety 확인
사용자 동의 요구사항 검토
앱 업데이트 전후 지표 비교
분석 결과 기반 개선 계획 수립

41. 마무리

Android 앱 사용자 분석은 단순히 다운로드 수나 화면 조회 수를 확인하는 작업이 아닙니다.

사용자가 앱을 어떻게 이용하는지 이해하고, 실제로 필요한 기능을 개선하기 위한 과정입니다.

이번 글의 핵심을 정리하면 다음과 같습니다.

다운로드 수보다 실제 사용자 행동이 중요합니다.
Firebase Analytics는 이벤트 기반으로 데이터를 수집합니다.
분석 목적에 맞는 이벤트를 먼저 설계해야 합니다.
Fragment 기반 앱에서는 화면 추적 방식을 검토해야 합니다.
검색 결과 0건 비율은 검색 품질을 평가하는 데 도움이 됩니다.
Retention으로 사용자의 재방문 수준을 확인할 수 있습니다.
코호트 분석으로 신규 사용자 그룹의 행동을 비교할 수 있습니다.
BigQuery를 이용하면 SQL 기반 상세 분석이 가능합니다.
분석 결과의 상관관계를 인과관계로 단정해서는 안 됩니다.
개인정보를 최소한으로 수집하는 것이 중요합니다.

개인 개발자가 운영하는 Android 앱이라면 처음부터 복잡한 분석 시스템을 구축할 필요는 없습니다.

우선 검색, 상세 화면, 좋아요, 메모 저장처럼 핵심 기능의 이벤트를 기록하고, D1·D7 Retention을 확인하는 것부터 시작하면 됩니다.

이후 데이터가 쌓이면 BigQuery를 이용해 사용자 행동을 더 자세히 분석할 수 있습니다.

좋은 사용자 분석은 많은 데이터를 수집하는 것이 아니라, 앱을 개선하는 데 필요한 질문에 답할 수 있는 데이터를 수집하는 것입니다.

참고 자료

Firebase Analytics 시작하기
https://firebase.google.com/docs/analytics/get-started
Firebase Analytics 이벤트 기록
https://firebase.google.com/docs/analytics/events
Firebase Analytics DebugView
https://firebase.google.com/docs/analytics/debugview
Firebase Analytics BigQuery Export
https://firebase.google.com/docs/projects/bigquery-export
Firebase Analytics BigQuery 스키마
https://support.google.com/analytics/answer/7029846
Google BigQuery
https://cloud.google.com/bigquery
Firebase 개인정보 및 보안
https://firebase.google.com/support/privacy
Google Play Data Safety
https://support.google.com/googleplay/android-developer/answer/10787469

태그: Android, Kotlin, Firebase Analytics, Google Analytics 4, BigQuery, 사용자 분석, DAU, Retention, 코호트 분석, Funnel, Firebase DebugView, Android MVVM, 사용자 행동 분석, Google Play, Android 앱 운영

Android

Android 앱 사용자 분석 완벽 가이드 — Firebase Analytics, BigQuery, 사용자 유지율과 코호트 분석

Android 앱 사용자 분석 완벽 가이드 — Firebase Analytics, BigQuery, 사용자 유지율과 코호트 분석

1. 앱 사용자 분석이 필요한 이유

Firebase Analytics 이해하기

2. Firebase Analytics란?

3. Firebase 프로젝트 연결

Firebase Analytics 설치

4. Gradle 설정

이벤트 기반 분석

5. 이벤트란?

6. 이벤트 이름 설계

Analytics 공통 클래스

7. AnalyticsLogger 인터페이스

8. FirebaseAnalyticsLogger 구현

검색 기능 분석

9. 검색 이벤트 기록

10. 검색 결과 이벤트

화면 조회 분석

11. 화면 추적이 필요한 이유

12. screen_view 이벤트

13. Fragment 생명주기와 이벤트

사용자 속성

14. User Property란?

15. 프리미엄 사용자 구분

사용자 유지율

16. Retention이란?

17. Retention이 중요한 이유

코호트 분석

18. 코호트란?

19. 코호트 분석 예제

BigQuery 연동

20. BigQuery란?

21. Firebase와 BigQuery 연결

BigQuery 데이터 구조

22. Firebase 이벤트 테이블

23. 주요 이벤트 필드

BigQuery SQL 분석

24. 이벤트별 발생 횟수

25. 검색 결과가 없는 비율 분석

DAU 분석

26. 일간 활성 사용자 계산

코호트 SQL

27. 신규 사용자 코호트 만들기

기능 사용과 재방문 관계 분석

28. 좋아요 기능 사용자의 유지율

앱 버전별 분석

29. 업데이트 효과 확인

사용자 이탈 분석

30. Funnel 분석

개인정보 보호

31. Analytics 데이터 수집 시 주의사항

32. Google Play Data Safety

데이터 수집 동의

33. Analytics 수집 제어

BigQuery 비용 관리

34. 개인 개발자가 주의할 점

실제 앱 적용 전략

35. 조류 도감 앱

36. 버스 정보 앱

37. 음력 달력 앱

실무 적용 순서

38. 처음부터 모든 이벤트를 수집하지 않기

Firebase DebugView

39. 이벤트가 정상적으로 기록되는지 확인

사용자 분석 체크리스트

40. 출시 및 운영 전 점검

41. 마무리

참고 자료

댓글 0