Screen View na análise móvel — o que é, métricas principais e como rastrear

O que é Screen View?

Screen View é um evento de análise que é enviado quando uma tela de aplicativo móvel é aberta. O evento contém o nome da tela (screen_name), a classe (screen_class) e um carimbo de data/hora. Ao contrário da análise web, onde page_view está vinculado a um URL, em aplicativos móveis as telas são identificadas pelo nome da Activity, Fragment, ViewController ou Custom View.

Estrutura do evento Screen View

O parâmetro previous_screen é especialmente importante: ele permite restaurar a sequência de transições e construir um Screen Flow — um mapa dos caminhos do usuário pelo aplicativo.

Screen View vs Page View: diferenças principais

Screen View e Page View resolvem a mesma tarefa — registar uma visualização — mas em ambientes diferentes. Na web, um URL identifica exclusivamente uma página, e o Page View está vinculado ao carregamento do documento. Em aplicativos móveis, uma tela é um estado da IU que não corresponde necessariamente a um endereço separado.

• Page View está vinculado a uma solicitação HTTP e a um URL — Screen View está vinculado a um evento do ciclo de vida da Activity/ViewController
• Page View não é duplicado ao voltar atrás (usa-se cache) — Screen View é enviado novamente cada vez que a tela é aberta
• Page View é geralmente mais curto — os usuários visualizam uma página web mais rápido do que uma tela móvel com elementos interativos

Outra diferença é a profundidade do contexto. Screen View em um aplicativo móvel inclui parâmetros de estado: se o usuário está autenticado, quais dados estão carregados, se a tela está aberta em modo de edição. Page View na web raramente carrega esse contexto — ele apenas regista o facto do carregamento do URL. Isso torna o Screen View mais informativo para a análise de produto, já que cada evento pode ser segmentado por estado.

Erros típicos ao trabalhar com Screen View

O primeiro erro é enviar screen_view em cada mudança de estado dentro de uma tela (alternância de abas, abertura de popup). Screen View deve registrar apenas uma transição completa para uma nova tela, não microinterações.

O segundo erro é usar o nome técnico da classe em vez de um nome legível. “ProductDetailActivityKt” é inútil para um analista — use “Product Details” no screen_name.

O terceiro erro é enviar screen_view sem os campos correspondentes. Um screen_name vazio cria um conjunto de registos de lixo que não podem ser agrupados. Sempre passe pelo menos screen_name e screen_class, mesmo em telas de teste.

Como rastrear Screen View?

A implementação do rastreamento de Screen View depende da arquitetura de navegação. Vamos analisar as abordagens automática e manual usando Jetpack Compose e SwiftUI como exemplo.

Android: rastreamento automático no Jetpack Compose

Use LifecycleEventObserver ao nível do NavigationComponent. Cada vez que um usuário navega para uma nova rota, o evento screen_view é acionado.

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()
            )
        }
    }
}

// Conexão no NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Esta abordagem garante que o screen_view seja enviado sempre que a tela retorna ao primeiro plano, incluindo o retorno do segundo plano. Lifecycle.Event.ON_RESUME é o momento certo para o rastreamento, não ON_START ou ON_CREATE.

iOS: rastreamento automático no SwiftUI

No SwiftUI, usa-se o modificador onAppear, incorporado em cada View. Para automação, é criado um 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))
    }
}

// Uso:
ProductDetailView()
    .trackScreen("Product Details")

O modificador trackScreen é adicionado a qualquer View com uma única linha. É uma solução limpa e escalável para projetos SwiftUI.

Screen View em projetos multimódulo

Em projetos com arquitetura modular, cada módulo pode usar sua própria nomenclatura de telas, o que leva à duplicação de screen_name. Um enum ScreenName centralizado resolve o problema — todas as telas são nomeadas de acordo com um padrão único em um só lugar. Adicionar uma nova tela requer apenas uma nova constante no enum, em vez de procurar em todo o código.

Use uma sealed class para descrever screen_name com agrupamento por funcionalidade: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Isso simplifica a filtragem nos relatórios de análise.

Screen Flow: análise de transições entre telas

Screen Flow (ou Path Analysis) é uma visualização da sequência de telas que um usuário percorre. É a ferramenta principal para identificar gargalos na navegação.

Construção de um Screen Flow

Cada Screen View com o parâmetro previous_screen fornece uma aresta do grafo: CatalogScreen → ProductDetails → CartScreen. Agregando todas as transições, um mapa de caminhos é construído. Um funil de três etapas baseado no Screen Flow mostra onde os usuários desistem.

• Etapa 1: HomeScreen → CatalogScreen (95% continuam)
• Etapa 2: CatalogScreen → ProductDetails (65% continuam — 35% saem)
• Etapa 3: ProductDetails → AddToCart (30% continuam — perdemos mais 35%)

De acordo com a Mixpanel (2024), a análise de Screen Flow revela até 40% dos problemas de UX que não são visíveis ao analisar eventos individuais. Por exemplo, uma transição frequente ProductDetails → HomeScreen sem compra indica um problema com o preço ou a descrição do produto.

Análise de abandono (Drop-off)

Drop-off é um ponto onde o usuário abandona um cenário. Se 60% dos usuários saem após a tela de carregamento, o problema está na velocidade de carregamento ou na animação. Se for após um Paywall — no custo ou valor da assinatura.

Screen Flow no Firebase e BigQuery

Firebase não fornece um relatório Screen Flow pronto, mas os dados de screen_view estão disponíveis no BigQuery. Crie uma consulta que agrupe as transições por par (previous_screen, screen_name) e conte a frequência. O resultado é uma matriz de transições que pode ser visualizada no Looker Studio como um diagrama de Sankey.

Complemente o Screen Flow com segmentação: separadamente para novos usuários (primeiros 7 dias) e usuários que retornam. Novos usuários frequentemente ficam presos nas telas de onboarding, enquanto usuários experientes chegam mais rápido às ações-alvo. Comparar os dois fluxos revela gargalos de adaptação.

Ferramentas para análise de Screen View

A escolha da ferramenta para análise de Screen View depende do orçamento, da stack e do nível de detalhe necessário. Vamos analisar três soluções populares.

Firebase Analytics (gratuito)

Firebase rastreia automaticamente as telas através do parâmetro screen_view em cada evento. Não requer código adicional após a integração do SDK. Limitação: o screen_name é gerado a partir da Activity/ViewController, o que nem sempre produz nomes legíveis.

Amplitude (profissional)

Amplitude oferece um Pathfinder integrado — um construtor visual de Screen Flow. Suporta propriedades de usuário e segmentação por coortes. Permite renomear telas no lado do servidor sem alterações no código do aplicativo.

Mixpanel (segmento médio)

Mixpanel fornece um relatório Flows em tempo real. Pode mostrar não apenas transições lineares, mas também ramificações — quais telas são visitadas após uma específica. Integra-se com SDKs iOS, Android, Flutter e React Native.

Impacto do Screen View no desempenho

Cada evento screen_view é um envio de dados pela rede. Se um aplicativo envia screen_view em cada alternância de aba (20+ por minuto), cria uma carga desnecessária. Otimização: armazene em buffer os screen_view e envie em lote a cada 5 segundos. O Firebase agrega eventos automaticamente, mas SDKs personalizados podem enviar cada chamada imediatamente.

Meça a sobrecarga do rastreamento: adicione um carimbo de data/hora a cada screen_view e calcule o atraso desde onResume até o envio. Se o atraso exceder 100 ms, o rastreamento afeta a UX. Use uma thread em segundo plano para o envio para não bloquear a thread da IU. Em dispositivos de baixo custo, a diferença é notável.