Thanks @toupper ! Overal looks good to me, but I'd propose a few changes with the main goal to keep it simplier

Implement_WooPosOrdersAnalyticsTracker_for_enhanced_order_analytics_tracking.patch

Proposed Changes: Extract Tracking Logic from WooPosOrdersViewModel

1. Add tracking fields to OrderItemViewState, to avoid separate "caching"

  // WooPosOrdersState.kt
  data class OrderItemViewState(
      ...
      val statusSlug: String,
      val createdAtMillis: Long
  )

2. Create WooPosOrdersAnalyticsTracker class

New file with all tracking methods as suspend functions:

• trackOrdersListFetched(elapsedMs)
• trackOrdersListRowTapped(orderId, orderStatus, listPosition, createdAtMillis)
• trackOrderDetailsLoaded(orderId, orderStatus, createdAtMillis)
• etc.

3. Remove from ViewModel:

• OrderTrackingMeta data class
• trackingMeta mutable map
• cacheOrderTrackingMeta() method
• retrieveOrderTrackingData() helper
• trackOrderDetailsShown() and trackOrdersListRowTapped() private methods
• 9 analytics event imports + MILLIS_PER_DAY

4. Update ViewModel:

• Inject WooPosOrdersAnalyticsTracker instead of WooPosAnalyticsTracker
• Replace all direct analyticsTracker.track() calls with ordersAnalyticsTracker.track*() in viewModelScope.launch
• Track OrderDetailsLoaded directly in onOrderSelected() (no separate UI callback needed)

Why This Is Better:

• Separation of concerns: Tracking logic separated from state management
• No mutable cache: Tracking data lives naturally in the view state
• Cleaner: Removes ~60 lines from ViewModel
• Testable: Analytics logic can be tested in isolation
• Maintainable: Changes to tracking don't touch ViewModel and don't make it even bigger

Wdyt?

@toupper

In this case, memory usage would be the same since we store it in another structure, but keeping it out of the state avoids unnecessary recompositions and keeps the state cleaner and more focused on UI data. What do you think — do we have a convention for handling this kind of case?

That's all correct, except in this case you do the changes only when the state that changes the UI changes as well, so no extra recompositions unless I am missing something. All this should be handled by having all the orders we show in cache, and then we would take the order data lazily, when it's needed to be tracked, from the cache. I hope we'll implement this in I2 of this project alongside the replacement of the refetching of the order after email sent and/or refund made.

If we couple the OrderDetailsLoaded event to onOrderSelected, we’ll miss the initial auto-selected case (first item on load/refresh), and we’re not matching the event’s intent. Selection is an intention; loading details is an outcome. A bug could select an order without actually rendering/loading its details. I know that second case shouldn’t happen with our current flow, but it’s still a leaky proxy. What do you think?

Yep, you are right. My intention was to simplify it by not passing it via the UI layer, but indeed it's not ideal. The workaround, which I don't like but avoids having this round trip, is here. So apparently no ideal solution here - up to you
Track_order_details_loading_in_WooPosOrdersViewModel.patch

Also, I noticed that we now track pos_orders_list_fetched and pos_orders_list_search_results_fetched on success, but as peer description it's about request completion - check the patch out

Track_elapsed_time_for_orders_list_search_and_fetch_operations.patch

Other than that, LGTM!