Customer-Facing Analytics Event Guide for Firebase

This article explains:

Which custom analytics events are logged
When each event is logged (user behavior trigger)
Which parameters may be sent with each event

This article explains only custom parameters.

The Firebase SDK automatically logs certain events to Analytics, which can be viewed here: https://support.google.com/analytics/answer/9234069?hl=en

Parameter dictionary (what each field means)

Events can include one or more of these parameters:

`screen_name`: logical app screen where the action happened
`team_parent_id`, `team_parent_name`: home club identifier/name
`team_id`, `team_name`: home team identifier/name
`away_team_parent_id`, `away_team_parent_name`: away club identifier/name
`away_team_id`, `away_team_name`: away team identifier/name
`competition_id`, `competition_name`: competition identifier/name
`competition_parent_id`, `competition_parent_name`: parent competition identifiers
`competition_round`: competition round label
`match_date`: match date value
`match_id`: match identifier
`person_id`, `person_name`, `person_role`: person/player/staff context
`person2_id`, `person2_name`: secondary person context (e.g., assists/substitutions)
`content_type`: object/content category (match, club, person, ad format, etc.)
`content_id`: object/content identifier
`search_term`: text user searched for
`method`: interaction method metadata (where applicable)
`source`: attribution source (used primarily for subscription deep-link attribution)

Important:

Parameters are sent only when relevant to that event context.
Not every event carries all parameters.

Event catalog - what is logged and when

Screen and content interaction

`screen_view`

Logged when a tracked screen is shown (matches, match details tabs, news, etc.).

`screen_view` parameter variations by screen/context

Because parameters are optional, the `screen_view` payload changes by context.

Below are the practical patterns customers should expect in reports.

1) Basic app/settings/auth screens

Typical screens:

`settings`
`settings_notifications`
`settings_news`
`login`
`sign_up`
`complete_profile`
`edit_profile`
favorites tabs (`favorites_*`)

Typical parameters:

Always: `screen_name`
Sometimes: `content_type`, `content_id`

Use this as a lightweight “screen reached” signal.

2) Matches list/calendar screens

Typical screens:

`matches_list`
`matches_live`
`matches_page`

Typical parameters:

`screen_name`
Often `match_date`
Depending on context/filter: `competition_id`, `competition_name`, `content_type`
Usually, no person fields

Use for calendar/list engagement and date-based traffic analysis.

3) Match detail family screens

Typical screens:

`match`
`match_timeline`
`match_lineups`
`match_info`
`match_event`
`match_table`
`match_h2h`

Typical parameters (core):

`screen_name`
`match_id`, `match_date`
`competition_id`, `competition_name`
`competition_parent_id`, `competition_parent_name`
Home side: `team_parent_id`, `team_parent_name`, `team_id`, `team_name`
Away side: `away_team_parent_id`, `away_team_parent_name`, `away_team_id`, `away_team_name`
Optional event context: `content_type`, `content_id`

Timeline/event-specific variation:

May also include `person_id`, `person_name`, `person_role`
May include secondary participant: `person2_id`, `person2_name`

Use for full match journey + in-match interaction context.

4) Competition screens

Typical screens:

`competition`
`competition_results`
`competition_elements`
`competition_schedule`
`competition_table`
`competition_stats`
`competition_stats_extend`

Typical parameters:

`screen_name`
Always/mostly: `competition_id`, `competition_name`
Often: `competition_parent_id`, `competition_parent_name`
In team-filtered or row-open contexts: `team_id`, `team_name`, and parent team fields
In player/stat contexts: `person_id`, `person_name`
Optional: `content_type`, `content_id`

Use for competition funnel and drill-down analysis.

5) Club screens

Typical screens:

`club`
`club_results`
`club_schedule`
`club_contacts`
`club_teams`

Typical parameters:

`screen_name`
`team_id`, `team_name`
`team_parent_id`, `team_parent_name` (club parent hierarchy where available)
Optional: `content_type`, `content_id`
Usually, no away-team fields unless entering from the match context

Use for club profile and sub-tab engagement.

6) Person/player screens

Typical screens:

`person`
`person_matches`
`person_stats`

Typical parameters:

`screen_name`
`person_id`, `person_name`
Usually also `team_id`, `team_name` (club context of person)
Optional: `person_role` (if available), `content_type`, `content_id`

Use for player/profile content engagement.

7) News screens

Typical screens:

`news`

Typical parameters:

`screen_name`
Usually: `content_type`, `content_id`
Other sports entities usually absent

Use for editorial/news consumption tracking.

When a field is blank/missing in Firebase, it usually means it is not relevant to that screen’s context. It is not necessarily that data collection failed.

For dashboarding, prefer:

`screen_name` as the primary dimension, then split by available context fields (`competition_id`, `match_id`, `person_id`, etc.) only where they are expected.
`select_content` --> Logged when user selects/clicks a content item (for example opening a specific content target).
`open` --> Logged when a tracked entity is opened (typically item open action).
`share` --> Logged when user triggers a share action from supported screens.
`search` --> Logged when user initiates search flow.
`search_action` --> Logged when the user executes a concrete search action/update.

Favorites, notifications, sounds, and settings actions

`add_favorite` --> Logged when user adds an item to favorites.
`remove_favorite` --> Logged when user removes an item from favorites.
`add_notifications` --> Logged when user enables a notification-type preference/subscription.
`remove_notifications` --> Logged when user disables a notification-type preference/subscription.
`add_sounds` --> Logged when football sounds are enabled.
`remove_sounds` --> Logged when football sounds are disabled.
`map_style` --> Logged when user changes map style.

Authentication and profile lifecycle

`login` --> Logged on successfully.
`logout` --> Logged on logout.
`sign_up` --> Logged on to a successful sign-up event.
`complete_profile` --> Logged when the profile completion flow is completed.
`update_profile` --> Logged when the user profile update is saved.
`forgot_password` --> Logged when the forgot-password flow is triggered.
`reset_password` --> Logged when the password reset is completed.

Ads and rating

`ad_open` --> Logged when an ad click/open action occurs.
`ad_close` --> Logged when ad is closed/dismissed.
`rating_like` --> Logged when the user provides positive rating feedback.
`rating_dislike` --> Logged when the user provides negative rating feedback.
`rating_dismiss` --> Logged when the rating prompt is dismissed without a rating.
`replay_onboarding` --> Logged when onboarding is replayed.

Subscription and premium conversion funnel

These events are especially important for attribution and conversion analysis.

`subscription_deeplink_opened` --> Logged when the app is opened via subscription deep link.
- Parameter focus: `source` (from deep-link query param, e.g., campaign source)
`get_premium_popup_opened` --> Logged when the Get Premium popup is shown to the user.
`get_premium_popup_yes` --> Logged when user clicks Yes in Get Premium popup.
- Parameter focus: `source` (if same session originated from subscription deep link)
`get_premium_popup_no` --> Logged when user clicks No / dismisses Get Premium popup.
- Parameter focus: `source` (if same session originated from subscription deep link)
`subscription_bought` --> Logged after a successful subscription purchase.
- Parameter focus: `source`
- Attribution rule: if a purchase occurs in the same app session after a subscription deep-link open, `source` is preserved; otherwise, `source` is empty.

Subscription attribution

If the user comes from a subscription deep link that includes:

`...&source=<value>`

then:

that `source` is saved for the current app session,
and reused on premium conversion events in that same session:
`get_premium_popup_yes`
`get_premium_popup_no`
`subscription_bought`

If there was no subscription deep link in the same session, `source` is blank.

Practical examples

Example 1: campaign deep-link -> purchase

User opens app from deep link with `source=announcementents.`

-> `subscription_deeplink_opened` (`source=announcementents`)

Get the Premium pop-up shown

-> `get_premium_popup_opened`

User taps Yes

-> `get_premium_popup_yes` (`source=announcementents`)

User buys subscription

-> `subscription_bought` (`source=announcementents`)

Example 2: direct app usage, no deep link

Popup shown

-> `get_premium_popup_opened`

User buys subscription later

-> `subscription_bought` (`source=""`)

User properties (separate from events)

Firebase user properties maintained by the app:

`person_age`
`person_gender`
`person_id`
`person_zip`

These are set/reset based on authentication/profile state.

Reporting recommendations

Suggested dashboards:

Premium Funnel
`get_premium_popup_opened` -> `get_premium_popup_yes` -> `subscription_bought`
Premium Attribution by Source
Group `subscription_bought` by `source`
Engagement
`screen_view`, `select_content`, `open`, `share`
Retention behavior
`add_favorite`, `add_notifications`, `add_sounds`

Event list summary (quick reference)

`screen_view`
`select_content`
`add_notifications`
`remove_notifications`
`share`
`add_favorite`
`remove_favorite`
`open`
`add_sounds`
`remove_sounds`
`search`
`search_action`
`login`
`logout`
`sign_up`
`complete_profile`
`update_profile`
`forgot_password`
`reset_password`
`ad_open`
`ad_close`
`rating_like`
`rating_dislike`
`rating_dismiss`
`replay_onboarding`
`map_style`
`subscription_deeplink_opened`
`subscription_bought`
`get_premium_popup_opened`
`get_premium_popup_yes`
`get_premium_popup_no`