screen_class vs screen_name
In GA4 app analytics, a screen_view event carries two related parameters: screen_class and screen_name. screen_class is automatically derived from the UI component class (like the Activity or ViewController name), while screen_name is a label you set to describe the screen meaningfully. Knowing the difference keeps app screen reporting readable instead of full of code-level class names.
What this means
screen_view is the app event marking that a screen was shown. Its screen_class parameter is set automatically by the SDK from the class of the current UI component — the Android Activity or iOS ViewController name. Its screen_name parameter is one you provide to give the screen a human-meaningful label. Both ride on the screen_view event and appear in app engagement reports.
Why set screen_name
If you never set screen_name, reports identify screens by their class names, which are developer-facing and often unhelpful for analysis (multiple distinct screens may even share a class). Setting a clear screen_name — 'Checkout', 'Product detail' — makes engagement and funnel reports readable for everyone. screen_class remains as a technical fallback and disambiguator. Keep the name a description of the screen, never anything that identifies the user on it.
- screen_class: auto-derived UI component class
- screen_name: the readable label you set
- Set screen_name so reports are not full of class names
How it appears in analytics and logs
Screen reports full of class names (ViewController, MainActivity) mean screen_name was not set, so reporting falls back to the auto-derived screen_class.
Diagnostic use case
Make app screen reports readable by setting a clear screen_name, while understanding screen_class is auto-derived from the UI component class.
What WebmasterID can help detect
WebmasterID is web-first where the analogue is the page path/title; the same principle holds — a readable, non-identifying screen or page label.
Common mistakes
- Leaving screen_name unset and reporting on class names.
- Encoding user or account data into screen_name.
- Assuming screen_class always uniquely identifies a screen.
Privacy and accuracy notes
Both parameters describe a screen, not a person. Keep screen_name a generic screen label; never encode user or account data into it. This is educational, not legal advice.
Related pages
- The screen_view event (apps)
screen_view is the GA4 event that records when a screen is displayed in a mobile app, the app analogue of the web's page_view. It carries firebase_screen and firebase_screen_class parameters identifying the screen. It is collected automatically by the Firebase/GA4 SDKs and is the basis for app navigation and screen-engagement analysis.
- Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
- The app_open event
app_open is a GA4 event collected automatically by the Firebase/GA4 SDK when a user opens an app or brings it to the foreground after it was in the background. It marks app launches and returns, underpinning app engagement, retention, and session analysis — but a foreground event is not the same as meaningful use.
- Event Explorer
Inspect screen_view parameters.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.