Detailed analysis of user behaviour using touchscreen devices
What, why and how should you use it? How do we connect it to other data, so that we can acquire relevant information that is easy to understand, and in a filtered and user-friendly format? Which method will help you to move forward?
This year I was involved in implementing the Smart Kiosk project for Prague Airport, where you can see the results for yourself by trying out the kiosks. This project offers airport users an interactive approach, through a system of touch screen devices and data taken from the Prague Airport portal. We presented the Smart Kiosk solution at the UX Tuesday conference, and the concept attracted great interest.
After implementing a month-long pilot project, Prague Airport wanted to carry out a detailed analysis of which kiosks are repeatedly visited/used, which aspects of the interactive content are used more than others, and statistics wherever possible.
Kiosk usage – basic measurements
In the original project draft (read about the case study here), visitor numbers – or in this case “visitor kiosk usage” – were taken into account. The content of the prg.aero portal is not accessible to ordinary users, and so we are talking about kiosk usage here, rather than visitor numbers, which from the Google Analytics perspective, are analysed for all kiosks from one IP address.
Picture the situation: inside the airport there are 15 touch screen devices, in all places. In addition, they are located in one of two zones, which are differentiated by the content of the navigational features. Each Smart Kiosk has its own internal number – the means of logging on to the airport network. Kiosk content is generated from a single point, there is an option to split information by zones, and there should be at least one zone. This solution was proposed mainly to ensure that administration of information, which is tied to the zone and not the kiosk itself, runs smoothly. The application is supported by hardware in the Smart Kiosk and reverts to the homepage after a period of inactivity. Users search for information and such a system monitors when they have finished, leaving the information on the screen, and leave the kiosk. Each new user can start off with an interactive system on a basic navigational screen.
We use Google Analytics in our measurements because it is a practical solution to part of the website, i.e. the prg.aero portal sub-project. In the basic measurements the homepage is displayed as the primary status of the “application”, and it tells us how often people have been using the kiosk. By analysing the basic automatic status of the application (using automatically refresh – see the paragraph above), which we do not record in Google Analytics, we can precisely determine the actual number of visits to the kiosk. Filtering out automatic visits is the key to accurately measuring use of a particular kiosk.
Until this point, we only had a basic idea of the actual numbers of users and had a breakdown by language version (Czech, English and Russian). At this stage, no other data could be measured due to the nature of the application and the system infrastructure. However, this stage was designed to be a pilot phase in order to set the security policy of the internal systems and to test the operation.
New requests were made!
Each touch screen displays navigation in 12 items linked to the Prague Airport website. After the pilot project, a logical request was made, which involved measuring the use of individual kiosks and specific content.
If you are asking why, the answer is simple: it is a practical way of checking if the location of some kiosks results in no one using them, or if the kiosk content is balanced, or if there is a predominance of just a few functions, which keep repeating.
This is a complex issue and kiosk positions were chosen with great care, but until they are actually placed, it is always a lottery “in theory”.
How to do it
The first step was to decide how we want to display these measurement units and how and for what purposes the data will be used. We can also ask what is the primary goal of the data? And are other ways of using it and who will work with the data?
Only Google Analytics were used, and then we carried out back-up program adjustments to the application’s internal code. We prepared the latter option as the last resort only because we could lose the enormous flexibility that we now have in setting the new versions, content and data management.
Google Analytics offers two useful tools for measuring specific component parts of data of this nature. One of them is Event tracking and the other is Campaign tracking, and in some cases the Urchin Tracking Module codes. Both need no introduction and are widely used. I have mentioned them in other parts of my blog series (czech only). We considered all the benefits and tended towards UTM codes, which have more detailed statistical information than Event tracking and, above all, are more flexible when setting them in the project and in terms of management. No UTM code management is necessary, and in some cases you simply need to change them in the application itself. In contrast, with Event tracking, you must set them in Google Analytics. In addition, Events tracking measures only hits, whereas in Campaign tracking you can measure activity on the page, exits, transfers, etc., essentially complete statistics.
A decision was reached.
A well-designed application structure serving the content is a prerequisite. In this case, we solved it using our CMS LARS Vivo, which serves as a central mechanism for managing communication channels at Prague Airport.
We had to adjust calls of individual Smart Kiosks so that at the application level we could distinguish which specific Smart Kiosks are requesting content. The first step involved the HW supplier adjusting its internal application in an appropriate way. Each kiosk now calls contents of our application using a unique number that identifies it and which we then further work with. That was everything, and no other SW adjustments were needed, all the others were processed in the application, which is placed in the prg.aero portal. There is therefore no need at all to manually pre-set data values at the Smart Kiosks or change any feature of the hardware.
The application was adjusted so that for every navigational feature, an on-click event was added, which makes contact the relevant UTM form for the appropriate button. Basically, this alters all the links to that they dynamically take information about which kiosk is calling (GA medium), which event is happening (GA source), which zone the kiosk is in (GA campaign) and in which language (GA content).
All this information is displayed in real time and in “live” visitor number statistics, which are divided by the relevant campaigns. In Google Analytics there are two “Kiosks” indicating the individual content of zones, in Campaign tracking. These zones are further divided into the numbers of kiosks (medium), content name/button (source) and language (content).
Then, in Google Analytics, it is enough to select, e.g. Campaign “Zone 2” and filter out 115. I can immediately see how many visits this kiosk received in a specific period, which button was clicked several times and for how long it was used.
Why did I choose this method of division? The reason was clarity. I can easily distinguish the two new campaigns from the others, and in the details of each campaign I can already see the kiosk numbers with a breakdown into specific operating features, which I can put into groups based on other criteria.
This method of statistical detail has been in operation for several weeks and is now generating very interesting numbers, leading to the optimised use of the kiosks, or merely turning them round 90°. At the start, I mentioned that we carefully chose where to place the kiosks, and many people were involved in this decision. The numbers indicate where the team made the right choice and where small changes were needed.
Not only does this valuable information serve for company management reporting purposes, but it has an actual impact on the use and optimisation of the device’s physical location at the airport, as well.
This project was an interesting example of cooperation between the electronic and the real worlds using features that can’t be found on the web.
The real and the electronic world in synergy - as it should be!