Graphed LogoGraphed
Graphed LogoGraphed
How It WorksAgentsIntegrationsPricing

What is Screen Class in Google Analytics?

Cody Schneider••8 min read

If you're digging into your app's performance in Google Analytics 4, you've likely come across two similar-sounding dimensions: 'Screen name' and 'Screen class.' While they might seem interchangeable, they serve distinct purposes and offer different insights into user behavior. This article will break down exactly what 'Screen class' is, how it differs from 'Screen name,' and how you can use both to get a more complete understanding of your app's user experience.

GraphedGraphed

Your AI Data Analyst to Create Live Dashboards

Connect your data sources and let AI build beautiful, real-time dashboards for you in seconds.

Watch Graphed demo video

What is 'Screen Class' in Google Analytics 4?

At its core, the Screen class is an automated dimension that Google Analytics captures directly from your app’s code. It represents the technical name of the screen template or a component that is currently in focus on a user's device. For app developers, this corresponds to the class name of the UIViewController on iOS or the Activity on Android.

Think of it as the blueprint's name for a particular screen. For example, if you have a product details page in your e-commerce app, its screen class might be something like ProductDetailViewController. Every single product page uses this same "blueprint," so they will all share the same screen class, regardless of whether the user is looking at a pair of shoes or a hat.

Because it's pulled directly from the app's codebase, the Screen class is:

  • Automatic: You don’t need to do any extra configuration to start collecting this data. The Google Analytics (Firebase) SDK handles it for you.
  • Technical: The names are literal class names from the code, meaning they are developer-centric and not always intuitive for marketers or business analysts.
  • Consistent: Since it’s programmatic, it’s not prone to typos or inconsistent naming conventions that can sometimes happen with manual tagging.

Free PDF Guide

AI for Data Analysis Crash Course

Learn how to get AI to do data analysis for you — the best tools, prompts, and workflows to go from raw data to insights without writing a single line of code.

Screen Class vs. Screen Name: What's the Real Difference?

This is where most of the confusion arises. If 'Screen class' tells you what template is being used, what is 'Screen name' for? A Screen name is a custom, human-readable label that you or your developers manually assign to a screen. It's meant to provide clear, friendly context that anyone on the team can understand.

Let’s go back to our e-commerce app analogy. The screen class for all product pages is ProductDetailViewController. This is great for developer debugging, but it doesn't help a marketer figure out which products are most popular. This is where 'Screen name' shines.

A developer can manually set the screen name to be "Product Page - Running Shoes" when a user views that specific item, and "Product Page - Baseball Cap" for another. They both share the same ProductDetailViewController screen class, but their screen names provide crucial, specific context.

An Easy Way to Think About It

Imagine your house. The 'Screen class' is the type of room: "Kitchen," "Bedroom," or "Living Room." It’s the formal blueprint name. The 'Screen name' is what you actually call it to provide more detail: "Master Bedroom," "Guest Bedroom," or "Kid's Playroom." You need both to get the full picture.

Here’s a simple table to highlight the key differences:

GraphedGraphed

Your AI Data Analyst to Create Live Dashboards

Connect your data sources and let AI build beautiful, real-time dashboards for you in seconds.

Watch Graphed demo video

Why and When You Should Use 'Screen Class'

While marketers will spend most of their time looking at 'Screen name,' the 'Screen class' dimension is incredibly valuable for specific scenarios, especially when collaborating across technical and non-technical teams.

For Developers and Technical Teams

  • Debugging Crashes and Bugs: If your crash reporting tool shows an issue happening on a specific screen, you can use the screen class in GA4 to analyze user flows leading up to that point. It provides an unambiguous reference to the exact component in the code that's causing trouble.
  • Auditing Automated Events: Since screen views are recorded automatically, analyzing data by 'Screen class' can help you verify that your tracking is implemented correctly across the app without worrying about inconsistencies in manual screen naming. Are you seeing unusual events tied to SettingsViewController? Something might be misconfigured.
  • Ensuring Engineering Consistency: The screen class is a source of truth for technical teams. It helps ensure that screens built by different developers over time maintain a consistent underlying structure, as identified by the SDK.

For Analysts and Product Managers

  • Sanity Checking Your Data: Use 'Screen class' as a secondary dimension to verify your 'Screen name' data. For instance, if you filter for the LoginViewController class, you should only see screen names like "Login Screen" or "Forgot Password." If you find a screen name like "Checkout Page," you’ve likely found a tracking error.
  • Understanding App Architecture: Looking at a report based on 'Screen class' gives you an instant, high-level overview of your app’s technical structure. This is helpful when planning redesigns or new feature integrations, as it shows you which screen templates are used most frequently.
  • Analyzing Screen Template Performance: Are users on screens with the PopupModalViewController class a major source of drop-offs? This insight goes beyond the content of a specific popup (which you’d get from 'Screen name') and can point to a fundamental usability issue with that type of overlay across your entire app.

How to Find 'Screen Class' in Your GA4 Reports

You can find both screen dimensions in the standard reports and build much more powerful comparisons in the 'Explore' section.

In Standard Reports

  1. From the left-hand menu, navigate to Reports > Engagement > Pages and screens.
  2. By default, this report shows the primary dimension 'Page path and screen class.' The table will automatically display the screen class data for your app traffic.
  3. To switch to 'Screen name,' simply click the dropdown arrow next to the 'Page path and screen class' dimension title at the top of the table and select Screen name. You can switch back and forth to compare.

Building a Custom Report in 'Explore'

To view both dimensions side-by-side, the 'Explore' section is your best friend. This allows for deeper analysis.

  1. Go to the Explore tab in the left navigation panel and start a new Free form exploration.
  2. In the 'Variables' column on the left, click the '+' icon next to Dimensions. Search for and import both 'Screen class' and 'Screen name.'
  3. Next, click the '+' icon next to Metrics. Import the metrics you want to analyze, such as 'Views,' 'Users,' and 'Engaged sessions.'
  4. Drag Screen class from the 'Variables' panel into the Rows configuration in the 'Tab Settings' panel.
  5. Then, drag Screen name right below 'Screen class' in the Rows configuration. This will create a nested view.
  6. Finally, drag your chosen metrics (like 'Views') into the Values configuration.

You will now see a report that shows each 'Screen class' and, nested underneath it, all the specific 'Screen names' that were triggered within that class. This is a powerful way to audit tracking and understand how your general screen templates are used to display specific content.

How to Fix Common Issues with Screen Tracking

Even with automatic tracking, you might run into bumps. Here are some common problems and how to solve them.

Problem: My report is full of '(not set)' values.

This is a frequent issue, especially for 'Screen name.'

  • For 'Screen name': A '(not set)' value means the GA4 SDK automatically tracked a screen view, but your developer hasn't manually assigned a custom screen name to that particular screen. The fix is to work with your development team to ensure every user-facing screen has a designated screen name set in the code.
  • For 'Screen class': This is less common, but can occur if your app uses non-standard components or web views that the SDK cannot automatically identify as a standard screen. A technical review by developers is needed to identify and properly tag these views.

Free PDF Guide

AI for Data Analysis Crash Course

Learn how to get AI to do data analysis for you — the best tools, prompts, and workflows to go from raw data to insights without writing a single line of code.

Problem: Our Screen Names are a Mess!

Your report shows "product_details," "ProductPage," and "Prod. Details Screen" for what should be the same thing. This is a classic manual tagging problem.

  • The Cause: No single naming convention was decided on, so different developers or teams named things differently over time.
  • The Solution: Create a short, simple tracking document that defines your naming convention. A good practice is a Object - Action format, like Product - View, Checkout - Shipping Details, or Article - Read. Share this with your whole team and enforce it for all new development.

Problem: One Screen Class Contains Thousands of Different Screen Names.

You're seeing the ProductViewController screen class with what seems like an endless list of unique screen names beneath it.

  • Is it a problem? No, this is actually analytics working as designed! This is exactly the purpose of having both dimensions. The single 'Screen class' tells you that your generic product template is working correctly. The many different 'Screen names' are giving you the valuable, granular data about which specific products users are viewing. This isn't something to fix, it's something to leverage for analysis.

Final Thoughts

In short, 'Screen class' is the automated, technical blueprint of a screen, while 'Screen name' is the custom, descriptive label you give it. You need both for robust app analysis: one provides a stable, technical foundation for debugging and high-level structure, and the other offers the granular context needed for marketing and business insights.

Of course, digging through GA4, customizing Explore reports, and getting all your settings right still takes time. We built Graphed to cut through this manual work. Once your GA4 account is connected, you can simply ask questions in plain English, like "Show me my top 10 screens by user views last month" or "Compare engagement on iOS vs Android," and get live, interactive dashboards built for you in seconds. It allows your entire team to explore your data and get answers without needing to become GA4 experts.

Related Articles