6.3.1.1 Integration in the Context of e-Campus
In order to allow us to conduct a long-term and in-the-wild trial of Tacita, we integrated the system into the e-Campus display test-bed and deployed it as a service to students, staff and visitors across the University campus. In order to fully support Tacita, substantial additions were required to the previously introduced systems and components including the Lottery Scheduler, particularly regarding the interactions of displays with the Display Gateway and associated interfaces (Figure6.2, highlighted in blue). Figure6.3provides an overview of the communication and data flow between the Display Gateway and subsequent components within the Lottery Scheduler.
In the subsequent section, we provide a brief overview of the additions and implementa- tions of individual system components.
Display Gateway Interfaces
The Display Gateway was initially introduced in Section3.4.1.1and serves as the application programming interface for third-party applications requesting screen time, e.g. based on viewer presence at a particular location in the vicinity of the display. The Display Gateway communicates with individual display nodes through a two-way communication channel enabling displays to receive and process content scheduling requests in real time. We modelled the interface for communicating with the Display Gateway as a virtual sensor within Yarely’s Sensor Management component (Figure5.4). Similar to other components in Yarely, the sensor has access to the internal communication channels and the Context Store of the Lottery Scheduler (Figure6.3). The Display Gateway includes the description of the request time
6.3 Tacita: Client-based Tracking 131 Tacita Mobile Application Map Provider Trusted Content Provider Display Gateway Displays Status Response Content Request Receives Map Updates Subscribes to Map Updates Content Request Status Response Sche- dule Requests 3 1 2 7 6 5 4 Tacita Mobile Application Map Provider Trusted Content Provider Display Gateway Displays Status Response Content Request Receives Map Updates Subscribes to Map Updates Content Request Status Response Sche- dule Requests 3 1 2 7 6 5 4
Figure 6.2:Tacita system architecture focussing on the Display Gateway and interfaces on the display node.
6.3 Tacita: Client-based Tracking 132
and the Content Descriptor Set of the requesting third-party application in the payload of the request. The sensor validates incoming messages (e.g. ensuring the trusted source and expected format) and forwards the request, similar to subscription updates, to the Context and Constraints Parser for further processing using the internal eventing system of Yarely. The Context and Constraints Parser processes the CDS by parsing and transforming it into an internal object-based format and stores it within the Context Store for further consideration. Due to the use of the CDS format, we support the full stack of features as part of the CDS such as nested content items (i.e. content that is composed of multiple items), content scheduling requirements and constraints (e.g. content date and time availabilities).
Filtering and Ticket Allocation
After parsing and storing requests in the Context Store, the Context and Constraints Parser module initiates a new Lottery Scheduling process to allow the filtering and lottery allocation components to immediately consider and react to changes in the context of the display. The lottery scheduler has the opportunity to re-evaluate the previous content decision and determine whether the currently shown item is still appropriate. In order to support Tacita, we have considered the following two approaches (Figure6.3): supporting Tacita via (a) theTacita
Ticket Allocator, and (b) theTacita Filter Module. In the case of approach (a), the probability
for the requested item is dependent on the number of lottery tickets that have been made available for the Tacita Ticket Allocator in relation to other potential ticket allocators, and the number of tickets the ticket allocator has associated with the requested content item. In the case of approach (b), the Tacita Filter has already removed any content that has not been requested by a client – leaving the remaining set of eligible content items with requested content only. Therefore, the lottery process will yield the requested content item in any case (e.g. if multiple content items have been requested, one content will be determined at random). This approach is particularly useful to support walk-by personalisation in which case we ensure that passers-by willalways see the requested content under the assumption that a content scheduling request has been successfully issued. To maximise the user experience and ensure that personalised content is provided to the user as often as possible, we have chosen to implement approach (b) for the entire duration of the trial.
6.3.1.2 Trial Context and Collected Datasets
To support the evaluation of Tacita including all components, we collected a large set of quantitative measures as part of an in-the-wild study at Lancaster University. The study duration consisted of 206 consecutive days (from May 2017) and 44 displays equipped with BLE beacon sensors. During the study, a total of 226,620 events were captured including 24,565 content personalisation requests from a cohort of 147 users. We only consider users who installed Tacita on their mobile device and issued at least one content personalisation request within the study, enabling us to remove users without any intentions of using the
6.3 Tacita: Client-based Tracking 133
Figure 6.4: Tacita users at Lancaster University over the study period (initially published in [Mik+18d]).
system. Figure6.4provides an overview of the growth of the user base during the study period including fast growths during periods of active recruitment.
To enable accurate and comprehensive data collection for the subsequent analysis of Tacita, we instrumented all components of the Tacita ecosystem (i.e. Trusted Content Providers, the Display Gateways and the Tacita Mobile Client applications) to capture system and user interaction events and the following timestamps:
1. BLE beacon sightings (i.e. display proximity) on the mobile phone,
2. requests received from the Tacita Mobile Clients to Trusted Content Providers, 3. requests received from Trusted Content Providers to Display Gateways,
4. display opening and showing the content from the requested Trusted Content Provider, and
5. viewers accessing the configuration page of Trusted Content Providers through the Tacita Mobile Client.
The above mentioned timestamps have been captured as follows. Event (1) has been logged on the user’s device with a timestamp at the point at which the iOS background process detected the beacon in proximity to the user’s device and called the location tracking method of the Tacita Mobile Client application. In addition to the timestamps, the Tacita Mobile Client creates a unique request identifier (UUID version 4) to each beacon sighting, enabling us to trace and capture the latencies of the request through the chain of subsequent API requests throughout the Tacita ecosystem from the Trusted Content Provider to the Display Gateway and display nodes. Events (2), (3) and (4) were logged on our backend systems with the associated timestamp, and server clocks have been synchronised for those events that were executed on separate servers. We compute the latencies between system components by matching associated requests using the unique request identifier. The mapping of beacon
6.3 Tacita: Client-based Tracking 134 Entering viewable area Beacon entry detection delta System Latency time System Latency Display and System Viewer Content visible on display Beacon exit
detection delta viewable areaLeaving 1
2 3
2
Figure 6.5:Overview of the content delivery process in pervasive display systems together with critical events affecting the proximity detection performance. Beacon entry (1) and exit detection deltas (3) depend on the underlying proximity detection technology, whereas system latency (2) depends on network and system performance (initially published in [Mik+18d]).
sighting to each display, and the subsequent analysis of beacon sightings and associated content requests have been conducted on server-side based on the requests that have been recorded on Trusted Content Providers.
In addition to system logs and timestamps, we captured user interactions with Trusted Content Providers through the Tacita Mobile Client by logging access to the configuration pages on our backend. In particular, this included capturing occurrences of users accessing the configuration page of a Trusted Content Provider and changing their preferences – including the configuration values, timestamps and anonymous user identifiers.