Analytics refactor (extension): cross-platform schema alignment

[piyalbasu]

Context

Tracking issue for the extension side of the cross-platform Amplitude analytics refactor proposed in stellar/wallet-eng-monorepo#10. See the RFC for full event-mapping tables, property-bucketing rationale, and the shared schema catalog.

Goal: align the extension's Amplitude events with freighter-mobile on a shared domain.action_past schema, clean up the property model, and retire redundant events.

Dependency: This work is designed to land after the unified user ID project ships (sets Amplitude user_id to a stable cross-platform identifier). Do not start the migration before that lands.

Each checkbox below is a small, independently shippable task.

Amplitude taxonomy cleanup — account property limit ⚠️ (do now, NOT blocked by the unified user ID dependency)

The shared dev-sdf/freighter Amplitude project has hit its maximum number of event properties (dashboard warning), so we can't add new properties until we free some up. This is account-level taxonomy hygiene — it does not require new app code and is not gated on the unified user ID project. Prioritize it ahead of the schema migration so the refactor has property headroom to land into.

• Audit the event-property taxonomy and identify unused / invalid / orphaned properties (no recent volume, no dashboard/cohort/funnel references)
• Confirm with dashboard/cohort/funnel owners before removing any property still referenced
• Delete or block the confirmed-unused properties in Amplitude to get back under the account limit
• Verify the "max properties" warning clears and we have headroom for the new shared-schema properties
• Fold the resulting do-not-recreate list into the schema migration so retired properties aren't reintroduced

Schema migration

• Collapse all loaded screen: … events into a single canonical screen.viewed event with screen_name, flow, step, surface properties
• Rename domain action events to the shared domain.action_past catalog (payment.completed, signing.transaction_approved, etc.) per RFC Part 3
• Consolidate blockaid: scanned domain/transaction/asset → blockaid.scan_completed + scan_target + result
• Consolidate trustline removal error: * → trustline_remove.failed + reason_code (has_balance, buying_liabilities, low_reserve)
• Consolidate send payment: selected type payment / … path payment → payment.type_selected + payment_type
• Consolidate add token: confirmed / rejected → asset_add.responded + decision
• Add schema_version to every new-schema event (dual-write period); enables old-vs-new parity validation

Property-model cleanup (RFC Part 2a)

• Stop manually duplicating SDK-auto-captured fields (platform, platformVersion→os_version, appVersion→app_version) on every event
• Move durable traits to Identify user properties (wallet_count, has_hardware_wallet, has_imported_account, bundle_id)
• Keep volatile/active-account context event-level (network, account_type, account_funded, is_hardware_account, account_id_hash)
• Reclassify hw_connected (currently a per-event property) → has_hardware_wallet user prop or explicit connection event
• Never store raw public keys; use account_id_hash for account-level analysis

Make swap a first-class domain (RFC Part 1.3)

• Emit swap.completed / swap.failed directly; stop inferring swap success from send/path-payment events

Missing events to add (RFC Part 2c)

• app.opened (with one-time snapshot: surface, network, connection_type, effective_type, schema_version)
• transaction.submitted (distinct funnel step from approval, for sign-and-submit)
• collectible_send.completed / collectible_send.failed
• asset_remove.responded
• screen.viewed parity for transaction-details screens

Remove / reclassify redundant events (RFC Part 2b)

• Delete after parity validation: user signed transaction, recover account finished: closed recover account flow, loaded screen: trustline error
• Delete from prod analytics: loaded screen: debug, loaded screen: integration test; move loaded screen: loading to observability if kept
• Replace vague umbrella events with canonical product events: user cancelled signing flow, reviewed authorization entry, backup phrase: success
• Normalize loaded screen: confirm sidebar request → screen.viewed + surface=sidebar
• Validate live volume of loaded screen: account migration* (5 events) — the Security-screen entry point is currently commented out, so they may emit ~zero; retire or keep based on event counts
• Review manage asset: add token — keep only if funnel owners need an initiation step

Shared product/analytics decisions (cross-platform spike)

These need a product/analytics decision before implementation; resolve once and apply to both platforms:

• Is path payment analytically a payment.* or always swap.*?
• Should user rejection and runtime failure always be separate results? (RFC recommends yes)
• Do success/completion screens deserve dedicated semantics, or collapse into screen.viewed + action outcomes?
• Model popup/sidebar/fullpage as a surface property vs separate screen names? (RFC recommends surface)

Companion mobile tracking issue: see freighter-mobile.

[piyalbasu]

Companion mobile tracking issue: stellar/freighter-mobile#918