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

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)

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.

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

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

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

2. Get the Premium pop-up shown

   -> `get_premium_popup_opened`

3. User taps Yes

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

4. User buys subscription

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

Example 2: direct app usage, no deep link

1. Popup shown

   -> `get_premium_popup_opened`

2. 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`