Client-side Data Collection

In order support the capture of display-oriented analytics data, we defined a data model and developed a set of client-libraries that provide the ability to describe and collect a standard set of traditional signage analytics metrics.

3.3.2.1 Data Modelling

To model signage analytics data, we draw on our literature survey (Section2.3.1(Systems) and existing analytics engines from the Web, utilising the Universal Measurement Protocol (UMP) – initially developed by Google for Web and mobile phone related analytics [Goo18h]. UMP defines attributes for a typical set of analytics events such as page views, e-Commerce related activities and the more general ‘events’ type that can be used to describe in-page or in-app viewer behaviour. In the context of digital signs, we describe the content shown on displays as aPage Viewhit type described as part of UMP, similar to a user opening a Web site on their browser. Typical attributes of the page view hit type include the description of the content shown, referrer attributes and details about the user agent (in this case, about the display that showed the content). To capture the physical state of the display, we utilise the customEventstype that provides a certain level of flexibility in describing analytics events using the fully customisable category, attribute, label and value fields. The physical power state of the display is categorised asdisplay_power_statewith the actual power states stored in the attribute field (e.g. ‘on’, ‘off’ or ‘unknown’). A more detailed mapping from signage-related analytics data to Web analytics is described in Chapter4(Reporting).

3.3 Capturing Traditional Signage Analytics Data 61

To illustrate the extensibility of UMP and to allow us to capture additional user-related interaction activities such as explicit interactions (e.g. through direct touch), and implicit interaction through display personalisation systems such as Tacita [Dav+12], we extended UMP with additional data attributes. Table3.2shows the set of attributes that are supported by Pheme to collectproximityandinteractionrelated analytics events.

3.3.2.2 Display Client Libraries

We developed a set of front-end libraries that provide support for the integration of Pheme into existing systems and deployments. These libraries follow a similar principle that can be found in Web analytics systems which typically feature a set of simple libraries and code snippets for administrators to integrate on their Web pages to immediately enable basic analytics tracking [Goo18e]. These code snippets are automatically loaded as part of the interactive JavaScript code executed on the visitor’s browser and report the visitor’s activity automatically back to the analytics system. In digital signage, however, analytics need to be captured within the digital signage players—typically developed in proprietary software in the form of heavy clients. Due to the lack of standards and heterogeneous implementations, an automated or dynamic integration of an analytics client library to provide an analytics tracking automatised to the same extend as in the Web, we developed separate client libraries that provide developers with a way to easily integrate and enable analytics tracking within their infrastructure.

The Pheme client libraries are available as a set of Python-based modules (both for Python 2.7 and 3). Providing support for front-end systems and enabling the capture of user interactions, we also provide libraries for PHP and JavaScript (e.g. for dynamic, Web-based display content). The libraries provide methods that can be reused by developers and content creators to associate user interactions with appropriate UMP attributes. For example, direct user interactions (e.g. touch displays) can be captured through the integration of Pheme within a Web-based content item, while personalisation requests and contextual information can be captured and reported on the back-end.

An example code snippet for the integration of Pheme analytics tracking into a Python code base can be found in Listing1. Developers are simply required to initialisePhemeAnalytics

with their associated TID and can use the Pheme analytics instance to report events. Providing a unique user identifier through the.set_client_uuid method can be used to associate an event to a specific user, whilst reusing the same user identifier enables the tracking of users across across multiple instances and devices. Pheme libraries for Python 2.7, PHP and JavaScript provide an identical set of functionalities and tracking methods for developers.

If events are collected using Pheme’s analytics libraries, each event is automatically associated with a timestamp at the point at which the event was reported, and with a timestamp at the point at which the event reached the Pheme back-end—in line with the industry standard of other analytics libraries [Goo18c]. In addition, display identifiers and TIDs are used to accurately determine the source of the event and enable us to filter out potential false reports.

3.3 Capturing Traditional Signage Analytics Data 62

1 from phemelibrary import PhemeAnalytics 2

3 # Set up the tracking ID to be attached to all reports.

4 pheme = PhemeAnalytics("example_tracking_id") 5

6 # Set a client identifier for the display or user interacting.

7 pheme.set_client_uuid("client_uuid") 8

9 # Report a custom event asynchronously

10 pheme.track_event_async("category", "action", "value") 11

12 # Report a proximity event asynchronously.

13 pheme.track_d_proximity_async(

14 distance='1.2m', person_uuid='xyz', time_spent='17s' 15 )

Listing 1:Pheme library example code snippet to enable analytics tracking for Python-based applica- tions..

API / Impor

t

Pheme: Analytics Support System

Visualisation Reporting Injection and Export Individual Reports Displays Sales Visitor Tracking Sensors Google Analytics Privacy

Mediator Storage Module

Synthesis

Module MediatorPrivacy Secure Data Store

Access and Synthesis Rules User and Application Interface Pre-Processing and Data Integration

Figure 3.5:Pheme high level architecture and data flow diagram. Components highlighted in green have been fully implemented whilst components highlighted in yellow have not been implemented.