Skip to content

Analytics Examples

This section demonstrates practical examples of using Firebase Analytics in real Unreal Engine projects. The examples below focus on common gameplay and monetization scenarios and show how analytics events, parameters, and user properties are typically logged during normal game flow.

All examples are shown using Blueprint nodes, as this is the most common workflow for gameplay-related analytics. The same logic applies to C++ usage, using the corresponding C++ API.

These examples are intentionally scenario-driven rather than API-driven. They do not list every available function, but instead demonstrate recommended patterns and best practices for collecting meaningful analytics data from your game.

Naming Rules and Important Constraints

Before using any Analytics logging functions, keep the following Firebase requirements in mind:

  • Event names, parameter names, and user property names must follow Firebase naming rules: only lowercase letters, numbers, and underscores are allowed
  • Event and parameter names should be concise and meaningful, as they are used directly in the Firebase Console
  • User Properties are limited to 25 per project and should represent stable attributes rather than frequently changing values

Failing to follow these rules may result in events or properties being ignored by Firebase without visible errors.

All examples below assume that Firebase has already been successfully initialized.

Logging a Simple Event

The most basic use of Firebase Analytics is logging a simple event without any parameters. This is typically used to track high-level actions such as application start, entering the main menu, or opening a specific screen.

In this example, a game_started event is logged when the game begins. This event can be used to measure total launches, active sessions, or as a starting point for more advanced funnels.

This type of event does not include any additional data and is useful for confirming that analytics is working correctly and that events are reaching Firebase.

Logging an Event with a Single Parameter

For simple analytics events where only one parameter is required, you can use the dedicated parameter logging nodes. These nodes allow you to attach a single value to an event without additional configuration.

This approach is suitable when an event only needs one piece of contextual information, such as a counter, a state flag, or a simple numeric value.

Logging an Integer Parameter

In this example, an integer parameter is logged to track the attempt number when a level starts.

  • Event Name: level_started
  • Parameter Name: attempt
  • Parameter Value: 1

This can be implemented using the Analytics Log Event Parameter Int node.

The same pattern applies to other parameter types:

  • String - Analytics Log Event Parameter String
  • Float - Analytics Log Event Parameter Float
  • Bool - Analytics Log Event Parameter Bool

If an event requires multiple parameters or different parameter types, the map-based event logging node should be used instead.

Logging an Event with Parameters

In many cases, a single event needs to carry additional contextual information. Firebase Analytics supports this through event parameters, which allow you to attach structured data to an event.

In this example, a level_started event is logged with multiple parameters describing the current gameplay context, such as level name, difficulty, and attempt number. This approach is preferred over creating separate events for each variation, as it keeps analytics data clean and easier to analyze.

The event is logged using the generic Log Event With Parameters node, which supports string, integer, float, and boolean parameters.

This node requires all parameter maps to be provided. If a parameter type is not used, an empty Map must be passed.

This is a Blueprint signature requirement. Firebase Analytics itself does not require all parameter types, but the node expects all maps to be present to compile correctly.

Predefined Events

Firebase Analytics provides a set of predefined events that are recognized and processed specially by Firebase. These events follow official naming conventions and are automatically grouped, visualized, and interpreted inside the Firebase Console.

The plugin exposes these predefined events as dedicated Blueprint nodes, allowing you to log common gameplay and user lifecycle actions without manually defining event names or parameters.

Available predefined events include:

  • Login and sign-up events
  • Level start, completion, and failure
  • Tutorial begin and completion
  • Purchase events

Using predefined events is recommended whenever your use case matches one of them, as Firebase applies additional internal processing and reporting logic to these events.

Purchase Event (Special Case)

Among all predefined events, Log Purchase has a special role. This event is part of Firebase’s commerce analytics pipeline and is treated differently from regular custom events.

When a purchase event is logged:

  • Firebase automatically recognizes it as a monetization event
  • Revenue data is aggregated and displayed in monetization dashboards
  • Purchase metrics become available in Analytics, Retention, and Revenue reports

Because of this, Log Purchase should always be used for real-money transactions, rather than a custom analytics event.

Tracking an In-App Purchase

In this example, a purchase is initiated using the billing system provided by the PloxTools: Google Play Billing plugin, and the analytics event is logged only after the purchase is successfully completed.

  • The purchase flow is handled by the billing plugin
  • The analytics event is logged only after a confirmed successful purchase
  • Currency, value, and item ID are passed exactly as required by Firebase

This ensures that the transaction is correctly recorded as revenue inside the Firebase Console and contributes to monetization statistics.

Using this pattern guarantees that analytics data remains accurate, consistent, and compatible with Firebase’s built-in revenue reporting.

The Currency parameter must be provided as a valid ISO 4217 currency code in uppercase (for example USD, EUR, GBP). This is a requirement of Firebase Analytics and is necessary for correct revenue tracking and monetization reports.

Using User Properties

User Properties allow you to attach persistent attributes to a user profile. These values are stored by Firebase Analytics and automatically included with all subsequent events, making them useful for segmentation, filtering, and audience creation in the Firebase Console.

User Properties are not event-specific. Once set, they remain active until explicitly changed or reset.

Setting Player Attributes

In this example, user properties are set after the player profile is initialized. This could happen after login, account creation, or when player progression data becomes available.

  • player_type is used to distinguish between free and premium users
  • difficulty reflects the selected game difficulty
  • region can be used for geographic segmentation

Once set, these properties will be visible in the Firebase Analytics dashboard and can be used to:

  • Filter events by user characteristics
  • Build custom audiences
  • Analyze behavior differences between player groups

User Properties are especially effective when combined with event logging, allowing you to analyze who performed an action, not just what happened.

Using Default Event Parameters

Default Event Parameters allow you to attach a set of parameters that will be automatically included with every Analytics event logged afterwards. This is useful for shared context such as app version, build type, platform, or game mode, without manually passing the same data to each event.

Once set, these parameters apply globally until they are cleared or overridden.

Typical use cases include:

  • application version
  • build type (debug, release)
  • platform or distribution channel
  • game mode or environment flags

Setting Default Event Parameters

You can call Set Default Event Parameters during initialization, for example in Game Instance Init or right after Firebase initialization.

  • String parameters might include values like app_version or build_type
  • Integer or boolean parameters can describe feature flags or configuration states

After this node is executed, you can log events normally using any Analytics logging function, and the default parameters will be attached automatically.

Clearing Default Parameters

If you no longer want default parameters to be applied, call Clear Default Event Parameters.
This removes all previously set default values and returns Analytics behavior to normal.

Important Notes

  • Default parameters are merged with per-event parameters
  • If an event explicitly sets a parameter with the same key, the event-level value overrides the default
  • Use default parameters only for stable, global context, not for dynamic or frequently changing data

This approach helps keep event logging clean, consistent, and easier to maintain in large projects.

Summary

Firebase Analytics provides a flexible and lightweight way to track player behavior, progression, and monetization events without adding complexity to your game logic.

Using a combination of simple events, parameterized events, predefined events, user properties, and default event parameters, you can build a clear and consistent analytics layer that scales from early prototypes to live production projects.

The examples above demonstrate the most common and recommended usage patterns. Additional analytics events can be added incrementally as your project grows, without requiring changes to existing tracking logic.