Dwell time on UI elements | Community
Skip to main content
H
Hith
New Participant
June 29, 2022
Solved

Dwell time on UI elements

  • June 29, 2022
  • 2 replies
  • 1249 views

Hi All,

 

Does Adobe Analytics help track the user dwell time around buttons/links/navigation bars which helps to determine rage actions?

 

Thanks!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jennifer_Dungan

Technically you could probably create custom code to do this.. but the feasibility of such a thing may not make the most sense....

 

There's a lot of considerations:

  • Are you going to track each hover as a separate item (on then off - 1 call, on and off again - 2nd call, etc)
  • Are you going to track the total dwell time per page view (on / off, on / off again, on / off a third time... total time collected... )
  • Are you planning on sending a call for each dwell - meaning a lot of extra server calls (be aware this could cause you to exceed your server calls in your contract)
  • Are you planning on sending the "totals" for each element on the next page view (similar to how Activity Map works) - this will require custom code to store ALL the interactions, maintain them to the next page, include them in the tracking (with a reference to the previous page) and then clearing them so that you can start with fresh data on the new page
  • How are you going to record all this data and for how many elements? Trying to get this data into reasonable representations if you are sending all at once, and ensuring that you can parse and understand the data in the end will be challenging
  • Are you going to build in compensation for quick roll-overs? Like if a user rolled over 5 elements to get to a 6th element.. they weren't dwelling on those elements - they were just in the path to get to another element
  • On the opposite to the above, are you going to build in compensation for a user's mouse just stopping above an element while they are reading content... they aren't actually paying attention to where their mouse is... that's just where they stopped....

 

This is just a sample of the considerations that come to mind... there are more that I haven't even touched on.... To be honest, if someone came to me with such a request, I would politely explain why such tracking wouldn't be a good idea to try and achieve... there are too many variables to get anything really worthwhile, and the potential to incur massive overage charges (depending on the implementation) is reason enough to reconsider....

 

 

So with a lot of custom coding, and a lot of planning to come up with a clearly defined method to understand what is being tracked.. of course it's possible... but being possible doesn't necessarily mean that it should be done.... I think you really need to understand the use case of such a request, and how they plan on consuming the data... 

2 replies

Alexis_Cazes_
Alexis_Cazes_
New Participant
July 1, 2022

In terms of code it would be quite heavy. I would advise you to explore other product that use heat map functionality. 

 

I believe some products already do that out of the box lke ContentSquare: https://contentsquare.com/platform/zone-based-heatmaps/

 

 

Jennifer_Dungan
Jennifer_DunganAccepted solution
New Participant
June 29, 2022

Technically you could probably create custom code to do this.. but the feasibility of such a thing may not make the most sense....

 

There's a lot of considerations:

  • Are you going to track each hover as a separate item (on then off - 1 call, on and off again - 2nd call, etc)
  • Are you going to track the total dwell time per page view (on / off, on / off again, on / off a third time... total time collected... )
  • Are you planning on sending a call for each dwell - meaning a lot of extra server calls (be aware this could cause you to exceed your server calls in your contract)
  • Are you planning on sending the "totals" for each element on the next page view (similar to how Activity Map works) - this will require custom code to store ALL the interactions, maintain them to the next page, include them in the tracking (with a reference to the previous page) and then clearing them so that you can start with fresh data on the new page
  • How are you going to record all this data and for how many elements? Trying to get this data into reasonable representations if you are sending all at once, and ensuring that you can parse and understand the data in the end will be challenging
  • Are you going to build in compensation for quick roll-overs? Like if a user rolled over 5 elements to get to a 6th element.. they weren't dwelling on those elements - they were just in the path to get to another element
  • On the opposite to the above, are you going to build in compensation for a user's mouse just stopping above an element while they are reading content... they aren't actually paying attention to where their mouse is... that's just where they stopped....

 

This is just a sample of the considerations that come to mind... there are more that I haven't even touched on.... To be honest, if someone came to me with such a request, I would politely explain why such tracking wouldn't be a good idea to try and achieve... there are too many variables to get anything really worthwhile, and the potential to incur massive overage charges (depending on the implementation) is reason enough to reconsider....

 

 

So with a lot of custom coding, and a lot of planning to come up with a clearly defined method to understand what is being tracked.. of course it's possible... but being possible doesn't necessarily mean that it should be done.... I think you really need to understand the use case of such a request, and how they plan on consuming the data... 

Terms & ConditionsAccessibility statement

Loading footer...