모바일 분석에서 Screen View — 정의, 주요 지표 및 추적 방법

Screen View란?

Screen View는 모바일 애플리케이션 화면이 열릴 때 전송되는 분석 이벤트입니다. 이벤트에는 화면 이름(screen_name), 클래스(screen_class) 및 타임스탬프가 포함됩니다. page_view가 URL에 연결되는 웹 분석과 달리, 모바일 애플리케이션에서는 화면이 Activity, Fragment, ViewController 또는 Custom View의 이름으로 식별됩니다.

Screen View 이벤트 구조

previous_screen 매개변수는 특히 중요합니다. 전환 순서를 복원하고 Screen Flow(애플리케이션을 통한 사용자 경로 맵)를 구축할 수 있습니다.

Screen View vs Page View: 주요 차이점

Screen View와 Page View는 동일한 작업(조회 기록)을 해결하지만 다른 환경에서 작동합니다. 웹에서는 URL이 페이지를 고유하게 식별하고 Page View는 문서 로딩에 연결됩니다. 모바일 애플리케이션에서 화면은 UI 상태이며 반드시 별도의 주소에 해당하지는 않습니다.

• Page View는 HTTP 요청 및 URL에 연결됨 — Screen View는 Activity/ViewController의 수명 주기 이벤트에 연결됨
• Page View는 뒤로 가기 시 중복되지 않음(캐시 사용) — Screen View는 화면이 열릴 때마다 다시 전송됨
• Page View는 일반적으로 더 짧음 — 사용자는 대화형 요소가 있는 모바일 화면보다 웹 페이지를 더 빠르게 봄

또 다른 차이점은 컨텍스트 깊이입니다. 모바일 애플리케이션의 Screen View에는 사용자 인증 여부, 로드된 데이터, 편집 모드에서 화면이 열렸는지 여부 등의 상태 매개변수가 포함됩니다. 웹의 Page View는 이러한 컨텍스트를 거의 전달하지 않으며 URL 로딩 사실만 기록합니다. 이로 인해 Screen View는 제품 분석에서 더 유용하며 각 이벤트를 상태별로 세분화할 수 있습니다.

Screen View 작업 시 일반적인 실수

첫 번째 실수는 화면 내의 모든 상태 변경(탭 전환, 팝업 열기)에서 screen_view를 전송하는 것입니다. Screen View는 미세 상호작용이 아닌 새 화면으로의 전체 전환만 기록해야 합니다.

두 번째 실수는 읽을 수 있는 이름 대신 기술적 클래스 이름을 사용하는 것입니다. “ProductDetailActivityKt”는 분석가에게 쓸모없습니다. screen_name에 “Product Details”를 사용하세요.

세 번째 실수는 해당 필드 없이 screen_view를 전송하는 것입니다. 빈 screen_name은 그룹화할 수 없는 쓰레기 레코드 집합을 만듭니다. 테스트 화면에서도 최소한 screen_name과 screen_class를 항상 전달하세요.

Screen View 추적 방법

Screen View 추적 구현은 탐색 아키텍처에 따라 다릅니다. Jetpack Compose와 SwiftUI를 예로 들어 자동 및 수동 접근 방식을 살펴보겠습니다.

Android: Jetpack Compose에서 자동 추적

NavigationComponent 수준에서 LifecycleEventObserver를 사용합니다. 사용자가 새 라우트로 이동할 때마다 screen_view 이벤트가 트리거됩니다.

class ScreenTrackingObserver(
    private val analytics: AnalyticsProvider
) : LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        if (event == Lifecycle.Event.ON_RESUME) {
            val route = source.getRouteFromLifecycleOwner()
            analytics.logScreenView(
                screenName = route.screenName,
                screenClass = source.getLocalClassName()
            )
        }
    }
}

// NavHost 연결
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

이 접근 방식은 백그라운드에서 돌아오는 경우를 포함하여 화면이 포그라운드로 돌아올 때마다 screen_view가 전송되도록 보장합니다. Lifecycle.Event.ON_RESUME이 추적에 적합한 시점이며 ON_START나 ON_CREATE가 아닙니다.

iOS: SwiftUI에서 자동 추적

SwiftUI에서는 각 View에 내장된 onAppear 수정자를 사용합니다. 자동화를 위해 ViewModifier가 생성됩니다.

struct ScreenTrackingModifier: ViewModifier {

    let screenName: String

    func body(content: Content) -> some View {
        content.onAppear {
            Analytics.shared().logScreenView(
                name: screenName,
                className: "\(Self.self)"
            )
        }
    }
}

extension View {
    func trackScreen(_ name: String) -> some View {
        modifier(ScreenTrackingModifier(screenName: name))
    }
}

// 사용법:
ProductDetailView()
    .trackScreen("Product Details")

trackScreen 수정자는 한 줄로 모든 View에 추가됩니다. 이는 SwiftUI 프로젝트를 위한 깔끔하고 확장 가능한 솔루션입니다.

멀티 모듈 프로젝트에서 Screen View

모듈식 아키텍처를 사용하는 프로젝트에서 각 모듈은 자체 화면 명명 규칙을 사용할 수 있어 screen_name이 중복될 수 있습니다. 중앙 집중식 ScreenName 열거형이 문제를 해결합니다. 모든 화면이 한 곳에서 단일 표준에 따라 명명됩니다. 새 화면을 추가하려면 열거형에 새 상수만 추가하면 되고 전체 코드를 검색할 필요가 없습니다.

기능별로 그룹화된 screen_name을 설명하기 위해 sealed class를 사용하세요: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. 이렇게 하면 분석 보고서에서 필터링이 간소화됩니다.

Screen Flow: 화면 간 전환 분석

Screen Flow(또는 경로 분석)는 사용자가 통과하는 화면 시퀀스를 시각화한 것입니다. 탐색에서 병목 현상을 식별하는 주요 도구입니다.

Screen Flow 구축

previous_screen 매개변수가 있는 각 Screen View는 그래프 가장자리를 제공합니다: CatalogScreen → ProductDetails → CartScreen. 모든 전환을 집계하여 경로 맵을 구축합니다. Screen Flow 기반의 3단계 퍼널은 사용자가 어디에서 이탈하는지 보여줍니다.

• 단계 1: HomeScreen → CatalogScreen (95% 진행)
• 단계 2: CatalogScreen → ProductDetails (65% 진행 — 35% 이탈)
• 단계 3: ProductDetails → AddToCart (30% 진행 — 추가 35% 손실)

Mixpanel(2024)에 따르면, Screen Flow 분석은 개별 이벤트 분석에서 보이지 않는 UX 문제의 최대 40%를 드러냅니다. 예를 들어, 구매 없이 빈번한 ProductDetails → HomeScreen 전환은 가격 또는 제품 설명에 문제가 있음을 나타냅니다.

이탈 분석(Drop-off)

Drop-off는 사용자가 시나리오를 떠나는 지점입니다. 로딩 화면 후 60%의 사용자가 떠나면 로딩 속도 또는 애니메이션에 문제가 있는 것입니다. Paywall 이후라면 — 구독 비용 또는 가치에 문제가 있습니다.

Firebase 및 BigQuery에서 Screen Flow

Firebase는 기성 Screen Flow 보고서를 제공하지 않지만 screen_view 데이터는 BigQuery에서 사용할 수 있습니다. 전환을 쌍(previous_screen, screen_name)으로 그룹화하고 빈도를 계산하는 쿼리를 만듭니다. 결과는 Looker Studio에서 Sankey 다이어그램으로 시각화할 수 있는 전환 매트릭스입니다.

Screen Flow를 세분화로 보완하십시오: 신규 사용자(처음 7일)와 재방문 사용자를 분리하여 분석합니다. 신규 사용자는 온보딩 화면에서 더 자주 막히는 반면, 숙련된 사용자는 목표 작업에 더 빨리 도달합니다. 두 흐름을 비교하면 적응 병목 현상이 드러납니다.

Screen View 분석 도구

Screen View 분석 도구 선택은 예산, 스택 및 필요한 세부 수준에 따라 다릅니다. 세 가지 인기 솔루션을 살펴보겠습니다.

Firebase Analytics (무료)

Firebase는 각 이벤트의 screen_view 매개변수를 통해 자동으로 화면을 추적합니다. SDK 통합 후 추가 코드가 필요하지 않습니다. 제한 사항: screen_name이 Activity/ViewController에서 생성되어 항상 읽을 수 있는 이름이 제공되지는 않습니다.

Amplitude (전문가용)

Amplitude는 내장 Pathfinder(시각적 Screen Flow 빌더)를 제공합니다. 사용자 속성 및 코호트 세분화를 지원합니다. 애플리케이션 코드 변경 없이 서버 측에서 화면 이름을 변경할 수 있습니다.

Mixpanel (중간 시장)

Mixpanel은 실시간 Flows 보고서를 제공합니다. 선형 전환뿐만 아니라 분기(특정 화면 이후에 어떤 화면이 방문되는지)도 표시할 수 있습니다. iOS, Android, Flutter 및 React Native SDK와 통합됩니다.

Screen View가 성능에 미치는 영향

각 screen_view 이벤트는 네트워크 데이터 전송입니다. 앱이 탭을 전환할 때마다(분당 20회 이상) screen_view를 전송하면 불필요한 부하가 발생합니다. 최적화: screen_view를 버퍼링하고 5초마다 배치로 전송합니다. Firebase는 자동으로 이벤트를 집계하지만 사용자 정의 SDK는 각 호출을 즉시 전송할 수 있습니다.

추적의 오버헤드를 측정합니다: 각 screen_view에 타임스탬프를 추가하고 onResume에서 전송까지의 지연을 계산합니다. 지연이 100ms를 초과하면 추적이 UX에 영향을 미칩니다. UI 스레드를 차단하지 않도록 백그라운드 스레드를 사용하여 전송합니다. 저가형 기기에서는 차이가 두드러집니다.