Best practice for tracking UI state?

  • 9 June 2020
  • 1 reply

We have a small web app consisting of only a couple screens, with different panels and view states (you can collapse some panels, enlarge others, etc.). When we track an event like “Report Download”, as a designer I’m also interested in:

  1. what the screen looked like when that event fired—what panels did they have open, etc., and
  2. more generally, what are common sequences of UI changes that users make (e.g., if a user opens and closes a panel a lot without doing anything, we might want to look at the title and content of that panel).

What is the best way to track these kinds of UI changes that might only affect a portion of the screen, and can be combined to create many possible states? Should they be individual events (“List Panel Open”, “Detail Panel Expand”), or maybe one “View Change” event with boolean (super?) properties for the state of each part of the UI?

I think we’ll learn more about what we want after trying something and seeing if we’re able to segment in useful ways, but I was hoping to find some guidance on this kind of thing in the docs (I haven’t found anything yet). Any tips would be great. Thank you!

1 reply

Similarly, I’m interested in knowing how best to track where the user is in our hierarchical data structure.

For example, the user may select “Area 3,” and then within that, “Grouping A,” and then do a lot of stuff related to Grouping A. It could be useful to see which specific groupings are seeing the most traffic, or the most errors, etc.

I was thinking of tracking things like “Grouping” as super properties, but we’d have to be careful to unset each level whenever the user backs up the hierarchy chain (so we don’t end up falsely attributing general event traffic to a grouping).

Would it be better to just use regular event properties and try to attach a bunch of properties about the context to every tracking call?