Description

Adds Home Viewed Segment event tracking for the hub page discovery tabs UI. Fires interaction_type: tab_viewed on initial mount (Portfolio) and on every subsequent tab switch, using a stable ref-based callback so analytics reads are never stale without causing extra re-renders.

• New useTabViewedEvent hook encapsulates the event builder, guards against visitId === 0 (session not yet initialized), and exposes a stable trackTabViewed(name) callback.
• active_ab_tests for HOME_VIEWED is injected automatically by the existing analytics registry HUB_PAGE_DISCOVERY_TABS_AB_TEST_ANALYTICS_MAPPING, no extra wiring needed here.
• Full unit test coverage for both the hook and the tab switching behavior in HomepageDiscoveryTabs.

Changelog

CHANGELOG entry:null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-592

Manual testing steps

Feature: Hub page discovery tab analytics

  Scenario: user views the Portfolio tab on app open
    Given the hub page discovery tabs UI is enabled
    When the homepage mounts
    Then a Home Viewed event fires with name: portfolio and interaction_type: tab_viewed

  Scenario: user switches between tabs
    Given the homepage is open on the Portfolio tab
    When user taps the Perpetuals tab
    Then a Home Viewed event fires with name: perpetuals
    When user taps the Predictions tab
    Then a Home Viewed event fires with name: predictions
    When user taps the Portfolio tab
    Then a Home Viewed event fires with name: portfolio

  Scenario: user taps the already-active tab
    Given the homepage is open on any tab
    When user taps the same tab again
    Then no additional Home Viewed event fires

Screenshots/Recordings

Before

~

After

~

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.