Boost Your App's Success with Essential GA4 Insights Simplified

 Smartphones have become an integral part of our everyday lives. Many companies offer their users access to content and services via apps. F...

 Smartphones have become an integral part of our everyday lives. Many companies offer their users access to content and services via apps. Firebase allows you to track users on Android and iOS phones and analyze their data in Google Analytics 4 (GA4).

In many areas, smartphones are the most common platform on which companies reach their customers. Whether for games, shopping, or banking many products and services are primarily used and configured via cell phones.

Boost Your App's Success with Essential GA4 Insights Simplified

The first way users can reach an offering with a smartphone is via a website. Usually, whether users access an offering with a smartphone or a desktop computer makes no difference. The display adapts to the user’s screen dimensions, but the content and action options are usually identical. Programming is also identical for mobile devices and is based on HTML, CSS, and JavaScript.

The second way a user might reach your offer is via an app: a custom application on a user’s smartphone that they’ve installed from one of the app stores. Such an app is programmed for the corresponding operating system of the smartphone and offers several advantages over a mobile website, such as the following:

1. Design and user experience: Apps offer more flexibility and design options. In general, apps allow for more freedom in the design of the user interface and its operating elements.
2. Use of device functions: Apps can access functions such as the camera, microphone, or GPS.
3. Personalization: Apps are always installed on a user’s personal device, which makes it easier to offer individual settings for the user interface, for example.
4. Monetization: Apps offer new ways to monetize activities, such as through in-app purchases.
5. Visibility: Apps have their own icon in the menu or (even better) on the home screen of the smartphone.
6. Simple sending of notifications: Apps can send push notifications and in-app notifications that appear on the user’s device.
7. Offline functionality: Apps can also run on a limited internet connection or without a connection at all. Thus, larger amounts of data can be stored on an end device so that less data needs to be transferred “live.”
8. Faster performance: Apps are usually faster than mobile websites if they have been created natively for a device.

An app is not always automatically a better offer for users than a mobile website because many factors play an important role.

The decisive factor for this post that you can track apps with Google Analytics just like tracking your web 3. GA4 provides additional reports to view your users and even allows you to merge data from apps and from websites.

A joint evaluation of web offerings and apps requires communication with the developers, joint exchange and documentation, and conscientious testing prior to a release.

Collecting User Data in Apps

If apps are an important part of your digital offering, you should also track the user activity there using GA4. Think about the differences between an app and a website: Releases and versions as well as different platforms must be considered.

Types of Apps

Not all apps are the same: The various different types differ mainly in terms of their technical basis, as shown below. You can track all types of apps with GA4, but the ways in which you access their data are different.

In general, you can distinguish between the following variants of mobile content:

(Mobile) website

The content of a website, created using HTML and CSS, is called in a smartphone browser. In most cases, the website is identical to the one you would visit with a desktop browser. Therefore, you may already be recording views with the tags from Google Analytics. Thus, the already familiar GA4 tracking capabilities work the same: Pages, events, sources, and more are recorded using the codes we described in previous posts and then displayed in through reports.

Native app

This app runs as a standalone program on a smartphone. This kind of app can retrieve content from the web or store it locally as well as provide other functions, such as games. Native apps are usually installed from an app store and then appear as a standalone app on your smartphone.

Hybrid app

This type of app is installed as a separate program on a smartphone but sometimes serves as a shell that loads and displays websites within its own browser. Sometimes called a “personalized browser,” functions that are executed on the cell phone are programmed natively. Hybrid apps are also installed via an app store.

Progressive web app (PWA)

A PWA is written entirely in web technologies (e.g., HTML, CSS, JavaScript) and functions more like an offline copy of a website. Special software modules allow the smartphone app to provide certain functions offline. PWAs are not installed via an app store but downloaded from a website.

Different Types of Apps

For mobile websites and web apps, you can use the “normal” tracking codes or use Google Tag Manager. The web content reloaded in hybrid apps is also tracked using JavaScript tracking codes. Native apps and the native parts of hybrid apps, however, require special code calls to send data to Google Analytics.

These calls are provided by the Google development package Firebase. For this reason, you need to know how your app is designed and programmed to decide which tracking technology you must use.

Tracking for Various App Variants

What Is Firebase?

Firebase is a development platform for app and web projects from Google. Providing developers with a software development kit (SDK), you can use Firebase to add commands for programming, as well as create an infrastructure for handling various tasks in the cloud. Tasks include data storage, authentication, error reporting, and message sending.

Firebase - The Basis for Analyzing Apps

Tracking is already an integral part of the Firebase package. If the SDK is integrated into your app, key figures, such as the app being opened or views of certain content, are automatically tracked. If you use Firebase in your app (regardless of which of the functions it contains), you’re most likely already collecting user data.

GA4 is the analysis module for Firebase. The structure from your Google Analytics reports also applies to app user data: Events are measured that may contain other parameters. Google Analytics provides predefined dimensions and metrics. You’ll analyze the data in the same user interface as the data from your websites.

To analyze user data in Firebase, a GA4 property is created and used for this purpose. However, you can also include the app data into an existing property.

Tracking for Different Platforms

For the tracking code on websites, usually which browser a user uses to visit the page is irrelevant. The code used always remains the same; you do not install different codes for Chrome and Safari.

Firebase as a Central Component for App Tracking

But that’s exactly what you must do in apps, as shown in above figure: Apple products run on the iOS system; Samsung and most other brands use Google’s Android. Both operating systems differ in terms of programming and therefore require different app programming. You must therefore choose between these two systems when setting up. In Firebase, each platform has its own app within a project, as shown below. In the end, however, GA4 merges the data so that you can access a standardized report across all platforms.

Various Apps Within a Firebase Project

However, apps are often created by different developers for each platform. In this case, you’re therefore required to mandate the uniform usage of names and values.

You can set up Firebase as an independent service at https://firebase.google.com. Behind the scenes, you’re creating a Google Cloud project. Firebase is actually a single Google Cloud service for establishing a connection between the various services in the cloud.

Flexible Integration

The integration of tracking calls in apps differs from their integration in websites in a number of ways. For websites, you must insert a gtag code either directly or via Google Tag Manager. As soon as this version is “live” (i.e., running on a web server), it is equally valid for all users. Thus, all users receive the same tracking code with the same extensions and adjustments and are therefore counted in a comparable way. Updates are possible with Google Tag Manager almost in real time and independently of website version updates.

Unfortunately, apps are not as flexible as websites. Adjustments must always be made in the app’s code, and their development are usually tied to sprints and release cycles. An update must then be sent to the app or the app stores. The new version is usually checked by the store before allowed to go live. This process is also time consuming, which means that you should plan tracking concepts in apps with more lead time and test them prior to going live. Adjusting codes “on the fly” is much more difficult or even impossible.

Tracking Apps with Google Tag Manager?

The necessary program commands for Firebase are built directly into the app. No version of Google Tag Manager allows you to make adjustments independently of versions, as is the case for websites. Planning, documentation, and, above all, testing before a release are therefore even more important for apps than for websites.

The Android and iOS versions of an app are often created by different developers. Even if they work according to a common programming schedule, differences may arise in these releases due to the different testing procedures required by each app store. For example, an Android app may already have new tracking codes that are still missing from iOS and so you have calls in GA4 from one version that cannot be generated in the other version.

Analyzing Content and Actions in Apps

The structure of measurements and reports for apps does not differ from their web counterparts. Events and parameters are also recorded, which are then combined in various dimensions and metrics.

Viewing Only Users from App Data Streams

If you have created both web and app data streams in a property, data for both the app and the web is shown in the reports. To limit the data shown to apps, you must add a comparison to your view by clicking the Add comparison button above any report.

In the window that opens, click the Create new model button at the top. In the condition, select Stream name as the dimension and then select the app streams if an exact match is available, as shown below. Save the comparison and use it for explicit app considerations. When applied to a report, it shows users who were measured via these streams as a separate data group.

Alternatively, you can also filter individual reports by stream name.

Events

The actions in an app can be measured using events. For this task, a corresponding Firebase command must be installed at every point to be recorded. You can track clicks on buttons, the submission of forms, or the selection of commands in the menu, as shown below. If you use the events recommended for these activities, the transferred parameters run directly into the corresponding dimensions.

Measuring App Events

The Events report works for calls from apps as well as for websites. If you use the same name for certain events in the app and on the website, they will be added together. Then, you’ll receive a total number for all data streams in your property.

Different categories of events exist for apps, such as the following:

• Automatic: These events are recorded as soon as the Firebase analytics module is active (e.g., first_open).
• Recommended: If you use these event names and parameters, the data runs directly into GA4 dimensions and reports. This procedure applies, for example, to screen views or e-commerce.
• Custom: These freely definable event names and parameters describe specific actions in your app.

Automatic Events for Apps

With the installation of the Firebase SDK, some events are fired automatically whenever the app is used. The only step is to load the base code, which we’ll describe later. The first_open event is fired the first time an app is opened after installation. This event is therefore the first event a new user triggers when using the app. Its website counterpart is first_visit.

Each time an app is started, the session_start event is triggered. This event has the same meaning as for websites: A user starts a new session.

You’re also familiar with the user_engagement event from website reports. In the app, this event is fired if the user uses the app in the foreground for a certain period of time.

Analytics automatically tracks changes between screens if the app uses separate UIViewControllers, views, or activities. In this case, the screen_view event is fired, together with the screen class, as described below.

Events Sent Automatically by Firebase

In addition, a number of events capture a user’s interactions with advertising and actions in the app store that are tracked by Firebase. Unlike for websites, no optimized analyses exists for further tracking of user actions in the app. A detailed list of events is available in the documentation at https://support.google.com/analytics/answer/9234069.

Recommended Event Names and Parameters

Google suggests event names for actions from certain subject areas. These suggestions relate primarily to the following areas:

• E-commerce: Purchases, item views, and more 
• Account actions: Registration, login, etc.
• Lead generation: Generation, qualification, and conversion of leads
• Gaming: Level started or completed, score reached, achievement accomplished, and more

The names and parameters for these events are identical for app and web views. A complete list is available at https://support.google.com/analytics/answer/9267735.

Evaluating Gaming Events

Gaming events populate some designated dimensions, as shown, that you can include in data analytics and reports.

Dimensions for Gaming Events

Although a dedicated collection for games exists in the library, it does not contain any explicit gaming reports. The Games reporting collection contains only those known from the other collections like Acquisition, Retention, etc. If you want to evaluate the gaming dimensions, you must either use exploratory data analyses or create custom reports.

Measuring Events in Apps via logEvent

To add tracking to your app, you must insert program code to fire GA4 events. This insertion can be performed using the logEvent function, which can transfer an event name and parameters. The function is always the same, regardless of whether you’re firing a recommended event or a custom event.

[Analytics.logEvent("select_item", parameters: [

  "item_name": name as NSObject,

  "content_type": content as NSObject,

])]

Sample logEvent for iOS/Swift

In the sample view shown above, the select_item event is fired, and the ID and name of the item as well as the content type are transferred as parameters. As is the case with events for websites, predefined and recommended event names sometimes understand their own parameters. GA4 only distinguishes between event names and parameter names.

For example, if you use add_to_basket as an event, this action will be included in the event report as well as in the corresponding e-commerce dimensions and metrics.

As a result, a whole series of event names and parameters are predefined for GA4. You should avoid using these terms for your own custom dimensions or metrics.

These predefined events and parameters are stored as constants in the Firebase library, which allows you to use these constants instead of a free string for logEvent calls. Let’s look at the example shown below. Both the SELECT_ITEM event and its parameters are predefined in GA4.

[firebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_ITEM) {

    param(FirebaseAnalytics.Param.ITEM_ID, id)

    param(FirebaseAnalytics.Param.ITEM_NAME, name)

    param(FirebaseAnalytics.Param.CONTENT_TYPE, "image")

}]  

Sample logEvent for Android/Kotlin

These constants do not exist for events you have defined yourself. You must therefore use a free input  or define your own constants.

If you use the same names for events in the app and on the website, GA4 will add up the views and output the same number of views and users. Incoming calls from the app data stream are saved in GA4 in the same dimensions, and measured values, as calls from a web data stream.

Creating a Naming System for Events

If an app is supposed to run on both Android and iOS, sometimes completely different developers are involved for each version. For events with recommended names and parameters, such as purchase, there is a clear default that applies to all platforms. If, however, actions must be counted via custom events, one implementing developer might end up defining names and transferred values without an explicit specification.

This inconsistency creates the risk that the event names differ between the various platforms. Parameter names and values can also be different no higher-level specification is followed.

Uniform Specification Through a Framework

If a framework such as Unity is used, which can generate apps for both platforms from one code, you won’t have this problem initially. In this case, the events and parameters are only defined once and then rolled out for the various systems.

For this reason, you should define events and parameters in a naming system before starting the Firebase integration. You can use a simple table like the one shown below, which can easily be expanded to include descriptions.

Sample Definitions of Events in App Tracking

Especially when several developers are working on apps for different platforms, centralized documentation and regular exchanges of ideas are vital.

If you intend to merge app data with web data, you’re once again faced with the problem of ensuring uniform names for events and parameters. Measured events will never be 100% identical between the app and the web because different events are measured automatically, for example. But for important actions that can be performed by users, you should set a common default for all platforms.

Screens

A user can perform a specific action on a screen, that is, a home page, a search form, a catalog, a shopping cart, and so on. For each screen view, a name and class are passed as parameters, some of which are automatically collected by Firebase; others you can define yourself in the app’s program code.

GA4 treats the screens like pages that have been viewed: The same measured values are shown (i.e., views, users, and interactions). Key events and Total revenue are also calculated for each screen that has been viewed, as shown below.

In contrast to the page path, no hierarchy exists for screens, for example, through directories. Every screen is treated independently.

Screens for Evaluating the Content of Apps

In cross-platform setups, such as the setup shown below, data about screens and about the pages viewed are blended. The report shows data from both an app data stream 1 and a web data stream 2.

App and Website Data in the Same Report

This combination is particularly advantageous for hybrid apps, which receive calls from Firebase codes but data from a Google tag (gtag) or Google Tag Manager.

The screen_view event is (in simple terms) automatically fired when a new screen is displayed or when a user switches from one screen to the next. However, you can also fire the event manually, for example, to define the value for a screen class or if the automatic function in your app is not working optimally. In this case, as shown in Listing 6.3, you’ll pass the screen name and the class as parameters during the call.

[Analytics.logEvent("screen_view", parameters: [

  AnalyticsParameterScreenName: "product_detail_view",

  AnalyticsParameterScreenClass: "shop_product",

])]  

To count the screens of your app completely yourself, you can disable the automatic recording of screen changes. This approach affords you even more control over where and when a screen view is logged and which parameters are used.

On Android, you must add the following line to the AndroidManifest.xml file for your app, specifically in the <application> tag:

[<meta-data android:name="google_analytics_automatic_screen_reporting_enabled" android:value="false" />]  

On iOS, you must set the value for FirebaseAutomaticScreenReportingEnabled to No in the Info.plist file.

Custom Dimensions and Metrics

You can also use custom dimensions with different scopes for apps. These custom dimensions must be defined in the admin section.

If you’ve defined your own dimension at the event level, you must fill it with an additional parameter when calling Firebase, as shown below.

[Analytics.logEvent("my_firebase_event", parameters: [

  "my_dimension": "my own value"

])]  

Transferring a Dimension with an Event Scope

For custom metrics, you must also transfer the value as a separate parameter with the corresponding name.

To enter a custom dimension at the user level in an app, use the setUserProperty command. The name of the dimension and the value you want to save in GA4 can be passed as parameters. For analysis, you must have previously created the dimension in the GA4 property.

In the example shown below, the value funghi is set for user dimension pizza. Once transferred to GA4, the user property will apply to all further views by this user until it is overwritten with another value.

[firebaseAnalytics.setUserProperty("pizza", "funghi")] 

Setting a Custom Dimension in Android/Kotlin (Java)

[Analytics.setUserProperty("funghi", forName: "pizza")]

Setting a Custom Dimension in iOS/Swift

In the GA4 reports, no distinction is made between custom dimensions for web data streams versus for app data streams. You can use these dimensions in reports or exploratory data analyses.

Key Events for Apps

As we’ve seen with website data streams, you can define, for each event, whether that event is a key event.

Preset Key Events for App Streams

When you create an app data stream in your GA4 property, some additional default key events are defined, as shown above. For web data streams, only purchase is a predefined entry.

Default Key Events in a GA4 Property with an App Data Stream

These key events are available to you in most reports as independent metrics. You can also export them to Google Ads and use them there to evaluate your campaigns.

E-Commerce in Apps

We covered events and reports related to e-commerce in details earlier. The same events and parameters can be used in apps to send data to GA4. All reports that are provided for web views are also available for data from apps.

In the e-commerce views for Firebase, you can pass certain values as direct parameters. The selected items are sent as an array, as shown below.

[firebaseAnalytics.logEvent(FirebaseAnalytics.Event.PURCHASE) {

    param(FirebaseAnalytics.Param.TRANSACTION_ID, "T12345")

    param(FirebaseAnalytics.Param.CURRENCY, "EUR")

    param(FirebaseAnalytics.Param.VALUE, 116.89)

    param(FirebaseAnalytics.Param.TAX, 22.21)

    param(FirebaseAnalytics.Param.SHIPPING, 6.90)

    param(FirebaseAnalytics.Param.ITEMS, arrayOf(itemOneCart, itemTwoCart))

}]  

Sending a Transaction with Parameters

The ITEMS list consists of multiple elements that you build up individually, as shown below. First, an array with the item information is created (itemOne). This array is then extended to the shopping cart (itemOneCart) with a quantity specification (QUANTITY). Both shopping carts are sent as an ITEMS list in the PURCHASE command.

[val itemOne = Bundle().apply {

    putString(FirebaseAnalytics.Param.ITEM_ID, "SKU_3263827")

    putString(FirebaseAnalytics.Param.ITEM_NAME, "Lightsabre")

    putDouble(FirebaseAnalytics.Param.PRICE, 66.99)

}

val itemOneCart = Bundle(itemShirts).apply {

    putLong(FirebaseAnalytics.Param.QUANTITY, 1)

}

val itemTwo = Bundle().apply {

    putString(FirebaseAnalytics.Param.ITEM_ID, "SKU_2475031")

    putString(FirebaseAnalytics.Param.ITEM_NAME, "Blaster")

    putDouble(FirebaseAnalytics.Param.PRICE, 24.95)

}

val itemTwoCart = Bundle(itemTwo).apply {

    putLong(FirebaseAnalytics.Param.QUANTITY, 2)

}]  

Structure of the ITEMS Array for a Transaction

Remember that you must calculate the total amount of the transaction yourself!

Audiences for Apps

Using the data you collect via Firebase in apps, you can create audiences. These audiences can be applied to all reports with filters or comparisons and exported to other tools such as Google Ads.

Data on App Usage

As soon as you create one or more app data streams in your GA4 property, the navigation is expanded. In the menu, you’ll find a new App Developer item with the Firebase subitem, as shown in Figure 6.11. If the menu item is not visible, you must activate the App Developer collection in the library.

App Data Stream with a New Navigation Item

The Firebase overview summarizes data about your apps and the users of your apps. You’re already familiar with some tiles from reports on websites, some of which only appear when you use app data streams.

Users in the Firebase Overview: Not Just Firebase Users

Note that, if you’ve also created a web data stream in the property, web users are also displayed in the Firebase overview! If you only want to see app users, a best practice is to filter the corresponding data streams.

You may be familiar with the User activity over time section from the report snapshot, where the tile is already displayed. These graphs show you, for each day, how many users used the apps on the preceding day, in the last 7 days, and in the last 30 days. Only users for whom a user_engagement has been tracked are considered. For apps, therefore, these users must have the app running in the foreground.

This display allows you to track the short-, medium-, and long-term development of your user base. In the overview shown below, the 1-day line (the lowest of the three) stays pretty straight the whole time. There was a constant number of users in the app every single day. But you cannot tell from this view whether the users are different or always the same.

Firebase Overview in the App Developer Menu

The center line for the 7-day trend provides a better picture: In the last few days, the number of users has risen slightly, so there were more users in total. Finally, the 30 days trend line on top shows the long-term development, which is rising. During this 30 day period, different users visited the app, meaning that the user base in total has grown.

On the second tile in the overview, you can see how many users have used the app in the last 30 minutes, broken down by country. This information can be interesting after sending a push notification or an update to quickly see whether everything is still working.

Versions and Releases

Apps are programs that are installed on smartphones. The latest version is always downloaded from the Apple App Store and the Google Play store. A version is a firmly defined package that has been compiled and published by the developers (released).

Before such a version goes online in the store, the app is checked and approved by the store operator—whenever a new version gets released, the check starts all over again. Once the new version is online in the store, smartphone users still must install it (which can be automated, but not all users do this).

Due to these circumstances, usually, several versions of an app are in circulation at any one time: Not all users always update directly to the latest version. In addition, the versions of an app for iOS and Android can be at different stages, as development rarely runs completely in parallel.

The tile for the App version displays the versions are currently in use. In this diagram, you can view the history of users and revenue by app version for the last 30 days. The View app versions link takes you to the detailed report in the Technology menu area. Now, you’ll find a list of metrics such as Sessions, Engagements, Conversions, and Revenue per version.

Different Versions Used in Parallel

These reports provide an overview of which versions are still in use. You can use the GA4 segmentations to analyze further which devices and in which regions an app has not yet been updated. If you compare the key events and engagement values of the different versions, you can see whether newly introduced features in a version are positively received by users and are reflected in more engagement or higher revenue.

Metrics by App Version in the Technology Details

“(not set)” App Versions

If the (not set) entry appears in your app version report, you’ve probably set up a web data stream in the same property. No app version is transferred for views via the Google tag, so this parameter remains empty, or (not set).

The events described below are automatically tracked by Firebase in connection with updates and serve as the basis for the version report.

Tracking Crashes

The latest versions of your apps are shown on the Latest app release overview tile. The additional Status column provides information on the reliability of each version, as shown below. If crashes occur frequently, the tile recommends a check.

App Releases Tile Indicating Frequent Crashes

Clicking a version takes you to a detailed view of its data, as shown below. In the report, you can see when the last version releases took place and how long it took your users to adopt them.

Each version entry shows a status that indicates the version’s stability and acceptance, according to the following rubric:

• Successful release: At least 10% of users use this version, and less than 1% of sessions register a crash.
• Needs investigation (yellow): Crashes occurred in 1% of the sessions yesterday and today.
• Needs investigation (red): 10% of sessions crash.

Detailed View of a Specific App Release

The more crashes are registered, the more urgently you should check the corresponding version for errors. The events described in below provide the basis for this report.

Events Tracked by Firebase for This Report

Sources and Campaigns for Apps

For apps, GA4 provides the same familiar reports on sources and campaigns. You know some of these sources from the website reports. Searches, ads, and newsletters are also available for apps..

Source_Medium of an App

The Google Play store is shown as a separate source. If a search there leads to the installation of the app, this action is visible as google-play / organic. For links to the Play Store, you can also use the familiar UTM parameters described in detail earlier.

Depending on the programming, direct access to an app is possible on smartphones, for example, via a link in an advertisement or email. For this capability, you must activate deep links in your app. You can use the familiar UTM parameters in this context. For more information about deep links, refer to https://developer.android.com/training/app-links/deep-linking.

Tracking Deep Links

Another option for tracking links is Firebase Dynamic Links. These special redirecting systems evaluate devices and check for existing software.

If users click on a dynamic link and have already installed your app, the linked content is opened within the app. If the user is on a desktop computer or the app is missing, the user is taken to the corresponding content on your website in the browser. The special feature is the constant link: Since the device and software are analyzed live on click, you can use the same link without having to pay attention to the user’s equipment.

Firebase Dynamic Links to Be Discontinued

Google plans to discontinue the dynamic links function in Firebase on August 25, 2025. After this deadline, existing links will also cease to function. If you want to use the Firebase links or are already using them, you’ll have to switch to an alternative. Google provides an overview and FAQs on migrating to other services at https://firebase.google.com/support/dynamic-links-faq.

Setting Up App Data Streams

User data from apps is collected as separate data streams in GA4. If the property is not yet linked to a Firebase project, a Firebase project is created in the background with the first app data stream. If you already have a Firebase project that does not yet contain analytics data, you can link it to an existing property or a new property as a data stream.

Interaction of Firebase and GA4

You need Firebase to collect data from app users, then the data is collected and analyzed in GA4. You therefore need a Firebase project for user analysis in GA4. You have two options for accessing this project:

• You can create a new project at firebase.google.com and link it to a new or existing GA4 property.
• You set up an app data stream in GA4.

The question as to which path is right for your app depends on which projects and properties already exist and where data should end up.

When creating a Firebase project, you’ll be asked whether you want to create a GA4 property at the same time.

Activating GA4 When Setting Up a Firebase Project

If you deactivate this function, no data on app usage will be collected. However, you can select or create a Google Analytics account for data collection at any time.

Next, click Analytics and then the Enable Google Analytics button. Choose whether you want to create a new property or link the Firebase project to an existing GA4 property.

GA4 can also simplify this work for you: When you create an app data stream, a new Firebase project is automatically set up in the background and linked to the property.

As a result, what your current setup looks like, with its apps, websites, and GA4, can be of any combination. Below table provides some insights on how to proceed in each case.

Combinations of App and Website Data in GA4

You can see whether your GA4 property is already linked to a Firebase project in the admin section: The Firebase links menu item should appear. You can see the Firebase project ID under which the app can be found in the Firebase console.

Each GA4 property can be linked to exactly one Firebase project, and vice versa.

Within a Firebase project, you can create apps for multiple systems (e.g., for iOS, Android, and more).

Data on the Linked Firebase Project in GA4

Creating an App Stream in GA4

Go to the Data streams item in the GA4 administration. Now, you can add a new stream and select whether it is an Android or an iOS app. GA4 then guides you through at least four steps:

1. Registering the app
2. Downloading the configuration file
3. Adding the Firebase SDK
4. Checking the installation

Android

First, you must register the app by entering the package name, as shown in Figure 6.21. Usually, the package name corresponds to the applicationId in the build.gradle file. Then, assign an app name. The app will be managed under this alias in the settings and reports. You should assign a unique name in your account, preferably containing the app platform, such as My App Android or My App iOS. This name is the only identification within GA4 and cannot be changed later! If you later want to filter out certain data streams in a filter or segment and two streams are called My App, your work will be unnecessarily complicated.

If you have not yet linked a Firebase/Google Cloud project with GA4, Google Analytics will create one and make some basic configurations. If a Firebase project is already linked in the property, this step is not necessary.

Creating a New Android App in GA4

Google Cloud Project Created

In the next step, you must download the configuration files required to integrate and initialize Firebase in your Android project. GA4 explains where you must add the google-services.json file in the source code of your app in Android Studio.

Adding Firebase to Your Android App

Instructions then follow on how to add the latest Firebase SDK to your app. Include the following commands in the build files:

[buildscript {

  repositories {

    // Check that you have the following line (if not, add it):

    google()  // Google's Maven repository

}

  dependencies {

    ...

    // Add this line 

    classpath 'com.google.gms:google-services:4.3.3'

    ...

  }

}

allprojects {

  ...

  repositories {

    // Check that you have the following line (if not, add it):

    google()  // Google's Maven repository

  }

}]

The build.gradle File at the Project Level

[apply plugin: 'com.android.application'content_copy

// Add this line

apply plugin: 'com.google.gms.google-services'content_copy

dependencies {

  // add the Firebase SDK for Google Analytics

  implementation 'com.google.firebase:firebase-analytics:17.4.1'content_copy

 

  // add SDKs for any other desired Firebase products

  // https://firebase.google.com/docs/android/setup#available-libraries

}]  

The build.gradle File at the App Level

In the last step, Firebase offers to check the implementation of the services in your app, as shown in below. For this step, you must start the app, which will connect to Google servers. If this connection is successful, Google displays a corresponding message. However, you can also skip this step at this stage, for example, to pass on integration instructions to developers.

Firebase Checking Whether the SDK Is Loaded Correctly

iOS

The process is similar for iOS apps but with a few additions. You can optionally enter the App Store ID when registering the app. The configuration file you download is stored in the project folder of the app.

Adding Firebase to Your iOS App

The Firebase SDK uses CocoaPods to install additional services, as shown in above. In the project directory of your app, you must initialize a pod file (if you do not already have one) with the following command:

[$ pod init]

In the newly created Podfile file, add the following line:

[pod 'Firebase/Analytics']

Alternatively, if you do not wish to receive Google Ads ID support, use the following line:

[pod 'Firebase/AnalyticsWithoutAdIdSupport']

After saving the file, you can install everything using the following command:

[$ pod install]

Installing the Firebase SDK for iOS

For initialization within the code, you must add the statement shown in Listing 6.11 in apps that are programmed in Swift. For apps written with Objective-C, you can initialize Firebase using the commands described.

[import UIKit

import Firebase

 

@UIApplicationMain

class AppDelegate: UIResponder, UIApplicationDelegate {

  var window: UIWindow?

  func application(_ application: UIApplication,

    didFinishLaunchingWithOptions launchOptions:

    [UIApplicationLaunchOptionsKey: Any]?)

    -> Bool { 

    FirebaseApp.configure()

    return true

  }

}]

Firebase Initialization in Swift

[@import UIKit;

@import Firebase;

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application

    didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 

    [FIRApp configure];

    return YES;

}]

Firebase Initialization in Objective-C

You can skip the optional app check. Once you have completed these steps, you’ll be taken to the details page of the data stream. You can also access the configuration files and statements.

Detail View for the Stream to the iOS App

The details page for the app stream differs only slightly between the Android and iOS versions. Compared to the web stream, however, you have fewer options: You can create or change events and configure the application programming interface (API) interface for calls via the Measurement Protocol. No other settings for the behavior of the measurement or optimized analyses are available as you would find them on websites.

Frameworks for App Programming

Firebase also supports various frameworks that you can use to develop your apps. For example, many game apps are programmed in Unity, which allows for platform-independent development. Firebase provides direct integration via its SDK for this purpose. For more information on this topic, refer to https://firebase.google.com/docs/unity/setup.

Flutter, a user interface development kit from Google, is also platform independent in development. For the steps required to set Flutter up, refer to https://flutter.dev.

Blending App and Web Data

You can use a GA4 property to blend data from apps and websites. This approach can be useful if you offer a service as a web version and as an app, such as an online store plus shopping app, or if customer service is available both on the web and as a separate app. The features of both offerings are often the same or at least similar, and users can use both variants without any difference so they are either on the web or in the app.

However, in some cases, the transition is more seamless. With hybrid apps, users can use both a native program section and a website.

• Viewing the data together in a joint report has a number of advantages, such as the following:
• You have one number for key events across all platforms.
• Actions can be evaluated with identically named events across all platforms.
• E-commerce data is available in one report for all platforms. You do not have to merge values for sales, shopping carts, and revenue from multiple sources.
• If the website and the app offer one login for users, you can track the user sessions across all platforms.

Several levels of integration for app and web data are available, which we’ll look at in detail next.

Joint Counting of App and Web Data

If you have created data streams for app and web data in a property, this incoming data is mixed in the various reports. In the Pages and screens report, you can see the URLs accessed and views displayed in the app in a common table.

In the other reports on events, channels, key events, and more, the data is also blended but can be differentiated by filtering by the various data streams.

The calls and sessions are collected individually for each platform; there is no connecting element. Users and sessions are therefore counted once for the web and once for apps. The shared property saves you from having to add up individual metrics from different channels.

If your app leads users to your website via links or clicks, you should mark these behaviors accordingly. For this task, you can use the UTM parameter. The labeling allows you to determine how many users jump between the two platforms. You can also record clicks on an outgoing link in the app as an event. You should also use these two methods if the data from the website and app is collected in two separate properties.

Combining User Sessions

When the data is blended as described earlier, the platforms remain separated into individual silos. Jumps between these silos are recognizable but also drive up the values for sessions and users due to double counting.

With the help of a uniform user ID for app and web data streams, GA4 can merge users across stream boundaries.

User IDs

Using the user ID feature, you can enable GA4 to track users across different platforms. If you enter a user ID when calling analytics tags or tracking code, GA4 uses this ID as a unique identifier for the user instead of Google signals or a cookie and device ID. When using user IDs, you’re responsible for the data privacy-compliant collection and use of login data.

User IDs for Tracking IDs Across Device Boundaries

The user ID must be a unique text string for each user. This string can be a customer number, a login name, or an email address. In any case, you should hash the value. In other words, the original value is converted into a character string that is unique for this value, but from which the original value can no longer be created.

This unique value for a user (user ID) must be transferred in the tracking code in the following ways:

For Android (Kotlin)

mFirebaseAnalytics.setUserId("<<user ID>>");  

For iOS (Swift)

Analytics.setUserID("<<user ID>>")  

You can transfer the user ID in the website code using the gtag or via an additional field in Tag Manager:

gtag('config', '<<your MEASUREMENT ID>>', {

'user_id': '<<user ID>>'

});  

As soon as GA4 receives data for Google signals or user IDs, it will automatically use them to generate reports.

Data Privacy during App Tracking

The data privacy requirements for tracking also apply to apps: You may only track the activities of your users with their explicit consent. You alone are responsible for obtaining consent and considering user selections.

Querying Consent in Apps

Instead of a self-programmed solution for the consent query, you can alternatively use a consent manager such as Usercentrics.

This tool provides functions for displaying a consent query and further processing of the results via the SDK for apps. For more information about the use of Usercentrics, refer to https://docs.usercentrics.com/cmp_in_app_sdk/latest/index.html.

Regardless of how you request the user’s consent, you must prevent data collection until you receive the user’s response!

Controlling Initial Tracking

First, you should disable data collection in the basic settings because, otherwise, the Firebase module tracks user actions as soon as the page is loaded.

In an iOS project, you must set the value for FIREBASE_ANALYTICS_COLLECTION_ENABLED to NO in the app’s Info.plist file. In the XML file, things look as follows:

<key>FIREBASE_ANALYTICS_COLLECTION_ENABLED</key>

<false/>  

Once you have received the user’s consent, you can reactivate tracking using the following statement:

For Swift

Analytics.setAnalyticsCollectionEnabled(true)  

For Objective-C

[FIRAnalytics setAnalyticsCollectionEnabled:YES];  

For Android projects, you must configure the initial data collection in the AndroidManifest.xml in the following way:

<meta-data android:name="firebase_analytics_collection_enabled" android:value="false" />  

You can reactivate tracking after you have received user consent by using the following statement:

setAnalyticsCollectionEnabled(true);  

Consent Mode and Personalized Advertising

If you link your GA4 property with Google Ads, you can use data collected in apps to display personalized advertising to users. Thus, you can create audiences for remarketing based on events or other data. As on the web, you must explicitly inform Google of the user’s consent via the consent mode to be allowed to use the data in Google Ads campaigns.

You can see whether consent has been transmitted in the respective app data stream in the GA4 administration section. If GA4 or Firebase does not recognize any consent signals, a corresponding message appears. No signals for measurement or personalized ads were detected in this data stream. You’ll see a simple message during the measurement, but the measurement will still be performed. You can only use data for personalized ads if you have received the appropriate consent. For this reason, an additional Action required button appears.

Action Required for Personalized Ads

You can define the default value of the consent within the configuration file of an app.

For iOS, you must set the values in the info.plist file to disable the consent mode in the default setting.

[<key> GOOGLE_ANALYTICS_DEFAULT_ALLOW_ANALYTICS_STORAGE</key> <false/>

<key>GOOGLE_ANALYTICS_DEFAULT_ALLOW_AD_STORAGE</key> <false/>

<key>GOOGLE_ANALYTICS_DEFAULT_ALLOW_AD_USER_DATA</key> <false/>

<key>GOOGLE_ANALYTICS_DEFAULT_ALLOW_AD_PERSONALIZATION_SIGNALS</key> <false/>]

Default Consent Mode Setting in iOS

For Android, the commands belong in the AndroidManifest.xml file.

[<meta-data android:name="google_analytics_default_allow_analytics_storage" android:value="true"/>

<meta-data android:name="google_analytics_default_allow_ad_storage" android:value="true" />

<meta-data android:name="google_analytics_default_allow_ad_user_data" android:value="true" />

<meta-data android:name="google_analytics_default_allow_ad_personalization_signals" android:value="true" />]

Default Consent Mode Setting in Android

If you then ask for consent within the app and the user agrees, you update the consent mode status for iOS with the code.

[Analytics.setConsent([

.analyticsStorage: .granted,

.adStorage: .granted,

.adUserData: .granted,

.adPersonalization: .granted,

])] 

Updating the Consent Mode for iOS in Swift

For Android, you must use the commands.

[Firebase.analytics.setConsent {

  analyticsStorage(ConsentStatus.GRANTED)

  adStorage(ConsentStatus.GRANTED)

  adUserData(ConsentStatus.GRANTED)

  adPersonalization(ConsentStatus.GRANTED)

}]  

Updating the Consent Mode for Android in Kotlin

If the consent signals are received correctly, the data stream will report this success in GA4, as shown in Figure 6.32.

Confirming Consent Signals Are Transmitted Correctly

Default Setting for the Consent to Data Collection

If making adjustments to the code is difficult, you can use the Default settings for consent option in the administration of the data stream, as shown in Figure 6.33. You can find the link in the consent settings under the respective status.

Automatically Marking Data as “Consented”

By default, incoming data is processed as “not consented.” If you change this setting, all data will be regarded as “consented” and processed further.

You should only consider this option if you want to ensure consent in the app but cannot update the necessary new statements in the code.

You can find more information on the required settings and code statements in the Firebase documentation at https://firebase.google.com/docs/analytics/configure-data-collection.

Checking and Debugging the Integration

You should check your app before each release and whenever problems occur to ensure that the built-in tracking calls work as intended. Unfortunately, this check is a little more complicated with apps than with websites because looking “under the hood” is not so easy. No plugin simplifies debugging, and you cannot look into the network log. For apps, you only have two options:

• Finding your own session in the Realtime report
• Checking an app live in the DebugView

Finding Your Own Session in the Realtime Report

If you want to test an app from the various app stores, the first place to go is the Realtime report in your GA4 account. On this report, you can see what data is currently being received from users. If you call the app on your cell phone, access from this device will also appear in the report. Of course, you must allow data collection so that you can see the calls in your GA4 account.

Real Time Isn’t Always Real Time!

Depending on your internet connection and the data collected, tracking calls in Firebase are first collected in the app and then transmitted in one go (in a batch). Therefore, a few minutes may lapse before your calls appear in the Realtime report. For a real-time test, the best approach is to use a Wi-Fi connection for the end device so that Firebase can redirect the data as quickly as possible.

In the example shown below, we have 129 users in the property in the Realtime report. In other words, in the last 30 minutes, 129 different users have accessed the site. How do you find the calls from your device specifically?

First, open the app so that a new session is created in GA4. In which data stream should your calls arrive: Android or iOS? Use Add comparison (directly under the Realtime overview heading) to create a filter for the Stream name dimension. This filter should reduce the number of users, as shown below. At this point, that you have included the platform when naming the data streams has paid off.

You can now discover “your own” calls using the map. Hover your cursor over the dots and see how many users from this location are displayed. As shown in Figure 6.35, only a few users reside in “your” location in this example, Albuquerque.

Realtime Overview Data on App and Web Usage

Only Viewing Visitors from an App Stream

Clicking on this data point takes you to an individual list of user groups: On the left, you’ll see all users who match the filter you have set (the stream name), while the selected users from the region are listed on the right. If you then click further in the app on your end device, further calls will appear, and you’ll see whether the events are coming in. The View user snapshot link allows you to jump to a detailed view of individual users, where each individual event is displayed including parameters. However, a random user is selected again in this overview, which means that your search for “your” session starts all over again.

Checking an App Live in DebugView

The best approach for individual testing is to use the DebugView option in GA4. This option displays specific sessions, with each individual call and all incoming parameter values.

Live Data of the Test Device in DebugView

However, this view is intended for developers and requires access to the program code or access to the development mode for your device. You’ll also need to think about the two operating systems again.

Android

To activate debugging in an Android app, you must have access to the Android Debug Bridge (adb). With access via adb, you can send the following command to the device:

adb shell setprop debug.firebase.analytics.app <<PACKAGE_NAME_OF_THE_APP>>  

This command activates Firebase debugging for the app. With the following command, you can disable Firebase debugging again:

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

How to Access adb

The Android Debug Bridge is an interface through which you can communicate directly with an Android system. Developers have access to adb within the Android environment.

A simple method of gaining access to an Android device with adb is to use a debugging service. With a service like https://lambdatest.com, you can emulate a mobile device in the browser and run apps. The adb shell is provided as a menu item for virtual devices.

Using a normal terminal device, you can activate adb via the USB debugging option in the system settings of the cell phone.

If you have no experience with technical documentation and command line setup yourself, you should reach out to your developer to establish a permanent testing solution.

iOS

On Apple devices, you can enable the debug mode using the following command line argument in Xcode:

-FIRDebugEnabled

After a successful test, you can disable the mode via with this argument:

-FIRDebugDisabled

Then go to the DebugView in GA4 under Configure. At the top of the menu, select the device that’s now intended for debugging.

Selecting the Test Device

The data stream shows the events from this end device per minute in total (left) and broken down individually (center), as shown below. For each measured event, you can display all parameters, user properties, and, in the case of e-commerce calls, the elements contained.

This feature allows you to perform any action in your app and see what kind of data arrives in GA4. Although you can also scroll back to earlier events in the timeline, this method soon becomes confusing if there is a high number of views. If you notice certain events or values that need to be adjusted, we recommend taking a screenshot of the values shown to make it easier for a developer to understand what has happened and to start troubleshooting.

By the way, calls that appear in the DebugView are automatically excluded from your normal report figures!

Timeline with Incoming Events from the Test Device

Sending Messages via Firebase

Using Firebase, you can send users messages to their cell phones to alert them to news or offers and encourage them to open the app.

Cloud Messaging

Firebase Cloud Messaging (FCM) is a platform-independent service that allows you to send free messages to the smartphones on which your app is installed. These messages are displayed as notifications on both Android and iOS devices, either directly on the screen or in the status bar for later access, depending on the settings. You can include text, an image, or a URL in the message, as shown below.

You can limit the delivery of the message to specific user groups using the properties Firebase collects automatically, such as specific app versions, languages, or regions. You can also send a message after a certain amount of time has passed since the app was first or last opened.

Sending Messages to Smartphones via Firebase

As a special feature, you can send the message to users of a specific audience that you have defined in GA4, as shown in Figure 6.40. When defining the audience, you can use all events and properties that have been collected in your GA4 property.

Sending a Message to Selected Users

Optionally, you can define a specific GA4 event as a conversion for the message. This event is only used for internal Firebase reporting and has no connection with the key events defined in GA4.

Firebase collects data on the sending and use of each message, as shown below. You can view this data in the Messaging section of the Firebase Console.

Send Statistics for a Message

If you have specified a conversion for the message, these achieved events are also shown. Under Reports, you can view detailed analyses, either for individual messages, or for all notifications sent in total.

Sends Statistics for a Single Message in Firebase

Limited Data Basis

One limitation is noticeable when the diagrams are filtered by platform: The data on received and viewed messages (Impressions) is only available for Android devices. For iOS, only the messages sent are counted and how often the app is opened as a result. As a result, the overall figures are also distorted accordingly, and the totals are not always complete for both platforms.

Firebase and GA4 are closely interlinked, as you can see from the eligible audiences and events. This connection works in both directions, as you’ll find events for the FCM messages in GA4. The events are automatically created in GA4 after the messages have been sent. Below describes the events.

Automatic Events in GA4 for Sending Messages

A whole series of parameters are specified for each event, such as ID, name, and send time, as well as the optional parameters topic and label, which you can specify when creating a message.

In-App Messaging

Firebase provides another option for sending messages to your users: in-app messages. You can show these messages to users while they have the app open and active. Compared to FCM messages, you have significantly more design freedom with this type of message, as shown below.

Firebase for Sending In-App Messages

The messages can take different forms (up to full screen size) and contain control elements such as buttons or links. In this context, too, you can restrict the targeting to specific users or audiences of your app.

In GA4, Firebase executes its own events for these messages so that you can differentiate between FCM and in-app messages, as shown below.

Automatic Events for In-App Messages in GA4

The in-app messages are somewhat more economical when it comes to parameters: Only the ID, the name, and the time of the action are transferred. To evaluate the message_name parameter, as below, you must create it as a custom dimension, as described previously.

Events for In-App Messages in the Header

Evaluating Messages in GA4

In GA4, no separate report for messages exists, but under Explorations, you can create your own report for analysis. However, you’ll encounter a problem: You won’t see entries for message names, message IDs, or other parameters in the selection list of dimensions for reports. These messages have been received, and Firebase tracks everything necessary for its own reports, but GA4 cannot display the messaging data by default.

To make these message parameters available for reports in GA4, you must create the parameters in the Configure area. Set up a new dimension for the "message_name" under New custom dimension, as shown below. Now, GA4 saves the value of message_name in this dimension for future incoming events.

Defining the Name of a Message for Analysis in GA4

The new dimension appears in the dimension selection of the data analyses in the Custom group. You can now use it to create custom reports for the messages in GA4.

Note

If you want to save additional parameters for evaluations, you must set up corresponding dimensions for message_id, message_time, message_device_time, topic, label, message_channel, and/or message_type.

The combination of message and events creates a funnel, similar to the one in Firebase. In contrast to the overview in Firebase, in GA4, you can see how many users have closed a notification (notification_dismiss). However, you won’t see the number of messages sent.

User Engagements with a Message in GA4

Unfortunately, only Android users are included in this analysis. GA4 does not receive events from iOS devices before a user starts the app. In addition, GA4 only receives these events if a user has consented to tracking. In Firebase, however, you can see the number of all messages sent. You must always bear this limitation in mind when evaluating and comparing the figures.

Sample GA4 Account with App Data

Google provides a demo account with data from an app. You can register to view the data free of charge. The property will then appear in your GA4 menu as Demo Account and GA4 - Flood-It! property. The links for activation can be found at https://support.google.com/analytics/answer/6367342. Alternatively, search for “ga4 demo account” in Google. If you’ve already activated the demo account with e-commerce data, you should already have access to it.

This sample data comes from the Flood-It! app, a simple strategy game for Android and iOS from the developer Lab Pixies. More information about the app is available at https://flood-it.app. (However, the Android app in Google Play store is now outdated and can no longer be installed on newer devices.)

Flood-It! App with a GA4 Demo Property

In the demo property, as shown in Figure 6.48, you’ll find general usage data, such as the screens and events in the game, as well as channels and sources. Special Firebase reports on app releases and crashes are available. If you go further back in time (12 months), you’ll find in-app purchases.

GA4 Property for Flood-It!

Key events are also defined, and various custom dimensions are created that you can use in analyses.

Your access is limited to reports and data analysis. In other words, you can perform the following tasks:

• Create exploratory data analyses with all dimensions and metrics
• Set filters on various reports
• Create and apply comparative models

You cannot change the settings in administration and the library; that is, you cannot create channel groups or key events.

The demo account is ideal for getting to know the reports and trying out various filters and data analyses.

In this post, you learned how to use GA4 to measure user activity in apps. Events are also used in apps to record data for Android and iOS. You’re already familiar with the reports for screens, users, and campaigns from websites. Information on versions, releases, and push messages can also be evaluated in GA4.

To gain an initial insight into app reports, you can access the property with sample data provided by Google and apply what is illustrated in this post in practice.

In the next post, you’ll learn how to customize the GA4 user interface and run detailed analyses with custom reports.