System Component Latencies

In addition to the latencies resulting from detecting proximate BLE beacons, we further investigated system-related latencies that may occur when proximity sightings and content requests are passed through the Tacita system components. As shown in Figure6.5, such system- and network-related latencies are particularly crucial to ensuring that personalised content is delivered fast enough to an individual passing by a display. The assignment of a random globally unique identifier to each request issued by the viewer’s mobile device (i.e. at the point at which a proximate BLE beacon was detected), we are able to trace and time each request throughout the chain of APIs and system components.

An overview and aggregation of the request timings captured through our in-the-wild study are shown in Table6.4and Figure6.7. In particular, we consider the following latencies:

Mobile Client to Trusted Content Provider describes the latency from the point at which the mobile phone detects a proximate BLE beacon to the point at which the request has arrived at the Trusted Content Provider. The Tacita Mobile Client transmits a timestamp of the time at which the beacon was detected, allowing us to capture potential latencies that include transmission delays relating to the mobile network.

6.3 Tacita: Client-based Tracking 142

Trusted Content Provider to Display Gateway describes the latency from the point at which the Trusted Content Provider issues content requests that arrive at the Display Gateway.

Display Gateway to Content Shown describes the latency from the point at which the Display Gateway issues a request to the display node, and the display node shows the content on the display (captured through logs on the Trusted Content Provider). In particular, this latency includes potential processing and display scheduling latencies that may occur on the display itself. If a display has not shown the requested content, we consider this as afailed requestin the subsequent analysis.

Overall Latency – Mobile Client to Content Shown describes the overall latency from the point at which the Tacita Mobile Client detects a proximate beacon and requests the content to be shown to the time at which the display shows the requested content. Considering the overall latency, we were able to capture a median of 1.66 and mean of 4.8 seconds (SD: 11.75). These measures highlight that just considering system and networking performance, Tacita is fast enough to respond to content scheduling requests and support walk-by personalisation. In addition to the network performance, the previously discussed latencies for detecting beacons on the mobile device need to be further considered with regards to configuring the beacon range accordingly.

Considering the latencies between individual system components, we firstly observe a median latency of 0.09 seconds (mean: 2.15, SD: 16.52) between detecting a proximate BLE beacon and the request arriving at the Trusted Content Provider. Whilst for the majority of cases this latency is low, the high variance suggests the potential impact of poor mobile data connectivity and network connection. In particular, such issues may arise when viewers transition between in- and outdoor locations or the mobile device switches from a cellular data connection to Wi-Fi. We measured the delays between Trusted Content Providers and Display Gateways at a median of 0.02 seconds (mean: 0.19, SD: 5.82) as the lowest latencies in the chain of system components. This is likely due to the negligible network latency (both systems were located on the same virtual network) and short processing and parsing times. The second highest latency was identified between the Display Gateway sending the request to a display node and the display node showing the requested content (median: 1.33, mean: 3.16, SD: 7.19 seconds). Despite the Display Gateway keeping an open communication channel with each display node, the high latency is a result of completing the scheduling process on the display node itself. In particular, for each incoming personalisation requests, display nodes have to issue a new lottery scheduling request to enable a dynamic change of content creating a noticeable processing overhead. We note that there is a potential to improve this latency by simplifying the scheduling process on the display node and, for example, always prioritising personalisation requests.

In order to measure the reliability of the overall Tacita system, we consider the total number of daily content requests and those requests that have been issued by a Tacita Mobile

6.3 Tacita: Client-based Tracking 143

Figure 6.8:The total number of daily requests issued to Trusted Content Providers across all client applications (top left); originating from the iOS-based Tacita Mobile Client (top right); originating from iLancaster (bottom left); and the number of daily failed requests (bottom right) (initially published in [Mik+18d]).

Client but have not yielded the personalised content to be shown on nearby display nodes. Figure6.8provides an overview of the total number of request counts, requests issued by the individual mobile client applications (iLancaser and the Tacita Mobile Client), and the number of failed requests (i.e. requested content has not appeared on the display). We observed that Tacita was able to handle large amounts of daily requests (peaked at over 750 on certain days) of which the majority originated from the Tacita. The number of failed requests over the entire study was measured at approximately 20% of the entire amount of issued requests. However, we note that requests can fail for various reasons. For example, if a viewer has requested multiple Trusted Content Providers to show on a proximate display, at most only one of these will be scheduled to be shown on the display – leaving the remainder of requests to fail. Additionally, proximate display nodes may consider different scheduling requirements and contextual events that overrule the incoming personalisation request from the Display Gateway.

6.3.3.1 Accuracy for Analytics Data Capture

Based on the statistics reported previously, we gained a high level of insights into the perfor- mance and accuracy of using viewer-based tracking technology in the form of BLE beacons to detect viewers in the proximity of displays and measure their dwell times. In particular, we observed that viewers are detected entering the viewable area of displays with only a small delay (using monitoring as a technique between−1.23-5.10 seconds; Table6.3). Whilst this is often fast enough to support walk-by personalisation, it also provides an accurate measure for display analytics purposes to, for example, capture the content that viewers may have seen when walking by displays, or to simply count the number of (unique) viewers across a network of displays.

6.3 Tacita: Client-based Tracking 144

Table 6.5:Details of application adoption showing the percentage of total users who issued at least one content request to the Trusted Content Provider and the availability of the Trusted Content Provider during the study period (initially published in [Mik+18d]).

Category Trusted Content Provider Availability (%) Users (%)

Transport and Navigation Bus Departures 100 65

News and Information Weather 100 40

News and Information World Clock 100 34

News and Information News 100 23

Entertainment Live TV 100 21

Social Networks Twitter News Feed 100 8

Entertainment Pictures 86 7

In contrast, using viewer-based tracking via BLE beacons to compute dwell times, i.e. a metric that is highly reliant on an accurate detection of viewers leaving the viewable area of a display, has proven to be challenging. Using monitoring as a technique (representing the current state-of-the-art for tracking viewers whilst their phone is in standby mode), the captured delays in our controlled experiment ranged from 26.32-33.14 seconds (Table6.3) depending on the route. In particular, the standard deviations measured ranging across 10.68- 39.38 seconds (Table6.3) show the high variability in the results making it almost impossible to provide an accurate measure.