At the beginning of 2012, I was asked to come up with a way for the product management team to be able to understand how areas of the product are being used.

We’ve already had the usual marketing, sales and conversion data, and some statistics about retention, but the idea was to stop guessing why a specific feature produced a specific result, and actually know why.

Together with our platform developers, we’ve started a “usage stats” project which basically meant writing logs about everything the users do(using our system of course…), and producing reports on them. “Everything” means what screens they browse, which forms they start filling, how much time they spend doing what they do and what messages do they react to.

The potential of doing that is amazing. You can find out if writing “Join Now” on a button does better than “Tell Me More” and what shade of green should be used for a pixel at the top right corner of the screen, and much, much more of course.

It’s not a simple thing to do. You need to decide what to log, and then map the different flows and funnels, and write code that analyzes these logs and comes up with bottom lines.There are vendors that can help with some of it, but none of them can take away the pain in having to map all user flows and the “what just happened” coding.

It took time, but it was clearly worth it. When the first usage stats report was ready, we could clearly see what triggers users to buy a product, make changes and check again. It was a nice success and from that point onwards, we tried to make usage stats part of any new feature. When a feature is released, the next day we all want to know how well did it do, without having to speculate.

A feature to be measured can be a new product, a change in wording somewhere, a new email template, simply anything that a user can interact with. Good logs and good analysis of them is a key in doing that.

I’m sure none of it is new and it’s common sense that having more data can drive better, informed decisions. What is also common, unfortunately, is how often this isn’t done.

I’ve done a project or two(but probably twenty) since then, but not every organization realizes the importance and the potential of measuring more than the basics. Even companies who do, often opt to rush to release a feature without having proper logging in place, and “we’ll figure it out afterwards”.

“Afterwards” tends to be allot more expensive, so I definitely recommend looking at logging and analysis as part of the building blocks of every project, just like servers and security and UI/UX, etc. I cannot stress the importance enough, so I’ll just end this “call to log” with a funny note.

Of all places, I’ve seen the cashier at a coffee shop inside an indoor playground I go to with my kids, keep a log of all orders in a notebook. They don’t have a fancy ordering system or even a computer, but they know the importance of counting how many brownies are being ordered on a Saturday between 10:00 and 12:00. How else will they know how many they should bake?

Have a good week !