I am currently implementing a "User action log", that will keep interesting actions of users within our system.

Any advice on what to log? Of course, the answer is "everything you feasibly can", but I want to focus on the important actions, that will help us gain true insights.

Log every button click? Every hover on a button? Same for hrefs? What else?


  1. The goal is better UX - we want to study our users, understand how they behave, and build a better system for them.
  2. I'm aware of some 3rd party solutions that track everything users do, starting from Google Analytics, through apps like Clicktale. I'm not saying we won't use those - but still, a custom log with some select actions might provide extra value over these "log everything" type of systems.
  3. The focus is websites, built for consumption over standard computers (mobile/tablet clients are less relevant for us a.t.m).
  • 2
    Can you describe what your system does? "Interesting" depends on what your (and your users) objectives for the site are.
    – Peter
    Feb 8, 2012 at 8:29
  • 1
    @Peter - I can't at this point ... we're in stealth mode. I have to keep this at a general level.
    – ripper234
    Feb 8, 2012 at 8:39
  • @ripper234 when you do go live, you could provide a public issue tracker, letting users vote on issues. You could also provide a feedback form within the app (which should be as simple as possible.) Feb 8, 2012 at 16:43
  • 2
    @jberger - yeah, but that's orthogonal to this question.
    – ripper234
    Feb 8, 2012 at 17:11
  • i was thinking you were doing it to try to provide a better UX. (direct feedback would seem better than concluding UX through logging). in any event this Q has notable answers. Feb 8, 2012 at 17:48

3 Answers 3


No no no! The answer is not "Everything you feasibly can"!

You really need to turn the situation around. There is no need to log user actions just to be sure. You need to know what you want to know more about. What is the purpose of this data collection?

  1. Start out by defining some goals. What do you want to know?

  2. Then you need to figure out what to look for to answer those questions.

  3. Finally you need to pick some key indicators you can log to feed your metrics/measures.

    (Take a look at the GQM method. This is a very handy method when you need to figure out what to measure/log.)

BTW, the log information does not (necessarily) provide you with valuable information alone. I don't know how many times I've accidentally hit the F1 button when I really aimed for the ESC button. What does these data tell you. Say you have 95% of the users hitting the help-button once or twice during a session. Did they intend to get help? Did they accidentally hit the help-button? Is the help button helpful to these users or is the form/page itself confusing?

What you need to do is to observe users in action. This is the best way to improve the UX of your product.

  • 3
    Observe users in action: Absolutely yes - you should definitely not consider 'logging' as the only tool in the box. Feb 8, 2012 at 10:30
  • 2
    I'll second the 'observe users' - and also talk to them. You need to understand what users are trying to do - as well as what they actually do.
    – PhillipW
    Feb 8, 2012 at 10:45
  • 1
    I went this route, and in the test run I did ... I really like the result. Going top-down really provides very clean insights.
    – ripper234
    Feb 8, 2012 at 17:12

If you're asking yourself this question, then to be honest, I'd suggest not making this kind of decision up front at all, but instead incorporating an adaptive logging solution which you can control from the server side what is logged (and when).

Since you don't know what it is you want to log, then you need to log everything so that you can find out what it is that you want to carry on logging and more importantly find out what it is that you don't want to carry on logging.

Otherwise you run the risk of not logging something that you didn't realise might be of interest. It's all very easy to have an idea of what might be of interest and log that, but really that's just going to tell you something you kind of thought you knew already, where as the point is that you don't know what you don't know!

I don't mean to be awkward, but if you can't answer the question given your own domain knowledge, it strikes me that you certainly can't expect someone who knows nothing about your system to answer it for you.

Having said that, it's also worth saying that in the same way that whitespace is an important part of content and gaps are an important part of speech, you may consider it useful to get an idea of periods of inactivity between actions. Obviously you can't assign a single user's inactivity to a particular problem - I'm talking about when you have significant enough data that you can form a trend or pattern.

  • I really disagree with the "log it all" attitude. One of the biggest problems is that you have to much garbage information that you don't know how to handle - or even worse, you handle it the wrong way. It is pretty essential to have some thoughts on "why are we doing this" and "what are we really trying to figure out, here". A massive logging can be useful, but you need to have a clear opinion on what the different metrics are telling you. Feb 8, 2012 at 10:12
  • 1
    I do agree that you can miss the signal for the noise - but until you can hear the noise, do you know what band to filter out? The point would be to filter the noise asap, so the goal is not to log everything - it's just part of the route. Totally agree on the need for understanding 'why are we doing this' and the need to have a well formed reaction plan. Feb 8, 2012 at 10:18
  • I guess that both statements can be defended. I have been in situations where I was thinking "Why didn't I log that?! It really would have helped me know." But usually - no matter how many just-to-be-sure metrics I've added - there is always some missing pieces to get a proper answer to new question I have. Feb 8, 2012 at 10:33
  • The point is that it's never to late to add more logging to expand your knowledge. Say that you go by the "rocket surgery" [S.Krug] method: Once a month you meet up to evaluate your product and plan the improvements you want to implement during the next month. If some issue/question arises during these monthly events/meetings - a question that can be answered trough logging, then you'll simply implement these as soon as you can, and during the next few weeks you will get the information you are looking for and a proper answer to a real question. An a proper basis for assessment. Feb 8, 2012 at 10:36
  • 1
    So, perhaps coming back to my first paragraph - make sure that you incorporate an adaptive (flexible) logging solution - one that neither restricts nor enforces what you do. One that is centralized, but that you can easily tweak over time as your questions and doubts arise. The logging solution should not be chosen based on the false belief that you know all that you ever need to log. Feb 8, 2012 at 10:44

Start by deciding on what you want to measure and what you can do with these metrics. What sort of improvements and design decisions can be made with this info? E.g. Are you trying to find out how frequently users access the "Help" link

Think about the additional data around clicks that will provide context e.g. sequence, frequency, interval...

Before collecting data, I find it helpful to think about how I would report the findings and the purpose and audience for this report.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.