Keywords

1 Introduction

When people enter in a retail environment, their decision about whether to buy and what to buy is influenced by several factors. Their needs and the appeal of the products on sale are the most important factors. Nevertheless, the environment can play a key role as well. For instance, it is possible to manipulate factors such as music, colour, fragrance, what is displayed on monitors, the advertisements, and so on; we call them comfort aspects.

We remark that the above-mentioned aspects can be configured for providing comfort in order to encourage customers to buy products or services in the environment. More importantly, the appropriate configuration of those aspects can provide customers with a good impression of the environment. The latter has several advantages:

  • the customers feel satisfied of the time used for the visit;

  • satisfied customers are likely to visit again;

  • satisfied customers are the best advertisement to other potential customers;

  • the overall reputation of the environment improves.

In this paper we propose an approach for the automatic configurations of comfort aspects in retail environments. The contribution of this paper is twofold. On the one hand, we propose a model of user context based on external, statistical and personal information, which will be exploited by the decision system to set the comfort aspects. On the other hand, we propose a microservice architecture boosting modularity and flexibility, useful to adapt our approach to different scenarios. It is worth noting that we will not address neither psychological aspects, such as which music is the most appropriate in a given situation, nor decision algorithms, which can be chosen among those available in literature.

The rest of the paper is organised as follows. First, in Sect. 2 we describe related work in the field. Then, in Sect. 3 we show how we model the context of customers, i.e. how we organize the information that can be exploited to take decisions about comfort aspects. In Sect. 4 we describe the proposed architecture and provide a general description of the microservices used. In Sect. 5 we detail three case studies for showing real-world applications of the approach. Finally, Sect. 6 concludes the paper and draws final remarks.

2 Related Work

The issue of increasing the comfort level inside retail stores by means of digital technologies can be considered as an aspect of the digitalisation of our urban environments. Zambonelli et al. discussed this process in several works arguing the relevance of systems capable of taking both reactive and goal-oriented actions based on the user experience [5, 14].

Betzing et al. [2] recently argued that customer experience theory insufficiently accounts for the transformative power of mobile technologies enabling digital and contextual services. Thus, they propose eight propositions to frame enriched customer experience enabled by mobile technologies. In line with these propositions, they also propose several design principles for shaping digital customer experience.

Meyer et al. [11] examine if there is a possibility to digitalise the retailers’ advantage of personal advice, supported by contextual data, to achieve a closer and more personal digital relationship. Specifically, they explore the impact of various combinations of technology-enabled advanced services in customer-retail-relationships. Authors compare and evaluate a combination of both context-aware and emotional approaches/services discussing both online and offline advantages.

Bauer et al. [1] recently argued that the presence of digital signage showing emotional content creates favourable shopping experiences and positively influences consumer behaviour. Authors review recent findings related to digital signage in retailing and conclude that, leaving aside technical skills, knowledge from a number of fields (e.g., psychology, design) is needed for effectively deploy customer-ready systems.

Lamche et al. [10] investigated the customers’ experience and context in e-commerce, in light of providing suggestions about what to buy. Authors enhanced a baseline recommender system by the integration of context conditions like weather, time, temperature and the user’s company. These context conditions are embedded into the recommendation algorithm via pre- and post-filtering. However, the “comfort” issues are limited to the case of online or mobile shopping while our work is more focused on physical environments.

Finally, an important aspect to be considered for extracting and using customer data is privacy. We do not address privacy issues in this paper because we focus on the architectural aspects. Nevertheless, set aside further investigations, Schaub, Könings and Weber [12] have tackled the issue in the broader field of ubiquitous computing and their results can be applied to the specific case of retail environments as well.

3 Context Model

Taking decisions about which configuration of the comfort aspects could be more enjoyable for a specific set of costumers requires the modelling and understanding of costumers’ preferences. Since there might be more than one customer inside the environment, with possibly different preferences, the decision system must also weight individual preferences to find optimal solutions.

We build the user context from different sources of information from which we derive three contexts: External context, Statistical context, and Personal context, as depicted in Fig. 1. Furthermore, Table 1 summarises the different kinds of contexts and reports their key features.

Fig. 1.
figure 1

Different kinds of contexts of customers.

Full size image
Table 1. Summary of the features of the three different context types: external, statistical, and personal.
Full size table

The external context accounts for information unrelated with the customers such as weather, time of day, day of the week, temperature, location, and type of store. Of course, additional information can be taken into consideration.

These pieces of information can be useful to frame the general situation; for instance, in a spring day lights with warm colours inside the environment are suggested instead of cold colours; as other examples, a hard-rock music hardly convinces people to buy sweets and biscuits, as well as a classical music is likely to not provide comfort in a weapon store. This context is easy to gather, it could be retrieved even without the use of specific services. On the other hand, this context is the least informative one, since it does not concern the preferences of individual customers.

The statistical context concerns the distribution of the preferences in time (i.e., which situations are more comfortable in a given hour or in a given day), in space (i.e., which situations are more comfortable in a given place), and depending on other parameters (e.g., statistical distribution of age, gender, presence of families). For instance, people are likely to prefer lively music in the morning and calm music in the evening. In this case, the gathered information is weakly dependent on the people in the environment: the statistical approach tells us that customers are likely to have some preferences, but nothing grants they actually have them. This context is easy to gather, but requires specific services. Given it reports statistical preferences, it is somehow influencing the customers in the environment.

The personal context models information about specific customers such as age, gender, personal interests, habits, shopping history. Also in this case additional information can be considered depending on the store. This is the most dependent on the customers actually present in the environment, thus it can be very influencing on their own behaviour. On the other hand, it is the most complex to gather. The easiest way is to rely on a smartphone app, which can gather customer’s preferences and information and can notify the environment about the customer’s presence. Otherwise, a generic identification can be carried out by cameras or other devices, trying to estimate the age, the gender, the sentiment and other information about the customers in the environment. Needless to say, this kind of context might lead to significant privacy concerns.

Summarising, the proposed system is conceived to gather information and take decisions about the configuration of the environment accordingly. The information used is of different kinds (e.g., registry information, external information, contingent information) and is gathered from different sources (e.g., from services, from smartphone apps, statistical). The targets of the decision can also be different comfort aspects (e.g., music, colour, fragrance, advertisements).

As already mentioned, we do not adopt any specific decision algorithm because we focus on the general architecture. Thus, any decision algorithm can be actually implemented within the proposed system.

4 Architecture

The architecture of the proposed decision system is based on microservicesFootnote 1. Newman defines microservices as “small, autonomous service that work together” [12]. The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack. More specifically:

  • it enables a focused development, since each developer is devoted to one (autonomous) component;

  • it allows for heterogeneous technologies to be adopted;

  • it simplifies testing in the small;

  • it simplifies the deployment, removal and maintenance of services.

Of course, they also have drawbacks, which must be carefully considered before and during development:

  • the development of the whole system could be more complex, since they present the typical issues of distributed systems and there is no specific IDE available;

  • a good and stable agreement about interfaces is needed;

  • the testing in the large is more difficult;

  • more resources needed, in particular, memory.

One of the main issues in adopting microservices is the definition of which services must be available and with which granularity. In our case, the microservices are divided into the following families, depending on their use:

  • decision services, the core of the architecture, mainly the Decision service;

  • general purpose services, which provide basic information, such as Time service, which provides the time of the day, Location service, which provides the location of the environment, and so on;

  • context services, which provide information about the context of the customer and can be in turn divided into:

    • external services, such as Weather service, which provides information about the current weather given the location of the environment;

    • statistical services, such as Demographic service, which provides statistical information about customers’ age, gender, origin, ...;

    • personal services, which provide personal information about a user, identified in some way;

  • elaboration services, which can elaborate the provided information, for instance to calculate averages;

  • decision support services, which provide information useful to take decision, such as the Weight service that provides a table of weights;

  • actuator services, which enact the decision, such as the Music service, the Color service, and so on.

All the available services can be orchestrated and coordinated to take decision about the comfort aspects. In the next section we will show some examples of microservice composition.

5 Case Study

In this section we present a case study to provide examples of the proposed approach. We consider a retail store in which a music is played in background; for simplicity’s sake, we focus on music only, but the examples can be easily extended to other comfort aspects and their combinations. The aim of this case study is not about the kind of music to choose in a specific store, but to enable the choice of a given music depending on the context.

5.1 The Decision System

For concreteness’s sake, we propose a decision approach taken from a previous work [6] relying on the following three features:

  • classification of customers

  • definition of weights

  • definition of a composition graph

The idea is that, after the profile of the customers in the retail environment has been identified, a weight-based map is used for selecting the most appropriate value of the comfort aspect. If more than one comfort aspect have to be decided, a composition graph can be exploited to take a single decision considering not only the suitability of the single aspects, but also the suitability of couples of them (for instance, if a given music is suitable with a given fragrance).

We now consider the use case of a decision system used for configuring the music and the fragrance in a retail store.

The classification of customers can be made in different ways. For instance, customers can be classified based on their age, on their gender, on their social status, on their degree of loyalty to a brand, and so on. The system relies on a predefined classification of the customers to classify the actual customers in the environment in a given moment. How to recognise the customers in a store is discussed in Sect. 5.2.

Table 2. Example of coefficients for the different kinds of music on the base of customers’ age.
Full size table

The definition of weights allows to create connections between classes of customers and values of the comfort aspects. For instance, Table 2 reports an example of weights between customers classified by their age and group (family) and kinds of music. Similar tables can be defined for the other customers’ classes and values of comfort aspects.

Fig. 2.
figure 2

Decision graph for music and fragrance.

Full size image

Finally, a composition graph enables to define different compositions of comfort aspects. Figure 2 shows a decision graph regarding the use case summarised in Table 2. Let us suppose that the system identifies that the most of the customer are young, so the weights in the second raw of Table 2 is considered; the corresponding weights are reported in the nodes \(M_1\), \(M_2\) and \(M_3\). The weight of the fragrances (nodes \(F_1\) and \(F_2\)) can be retrieved in a similar way. Then, we define the weights of the edges, which represent the suitability for couples of nodes. For instance, the upper edges represent the suitability of a given music to the environment, while the middle edges represent the suitability of a music to a fragrance. Note that not all combination could be possible (for instance, there is no edge between the node \(M_1\) and the node \(F_2\)). Once we have normalised all weights to the range [0,1], the weight of each path from the environment E to the decision D can be computed as the product of the node and edge weights of the path. The path with the highest weight product represents the best combination of music and fragrance for the environment E when the most of the customers are young.

Interested readers can find more details about the decision graph in [6].

Service Composition Based on Statistical Information

The first example concerns the decision about what music to play in a retail store to provide comfort to the customers. Of course, the “best” music depends on the tastes of the persons present in the store. As a first approach, we can exploit statistical information to know information about potential people in the store, such as age, gender, and other. If the music preferences are not a piece of the statistical information, the system can rely on a specific service that provides the weight to give to the pieces of information. The decision service can put all information together and decide the music to play.

Fig. 3.
figure 3

Example of service composition to decide the most appropriate music, using statistical information.

Full size image

5.2 Examples of Service Composition

Figure 3 reports a simple example in which the age of the potential customers is exploited to decide the music to play. Following the microservice architecture, in this example we exploit a service to get the hour of the day (Time service) which gives the input to a service (Demographic service) that provides statistical information about the mean ages of the customers in that hour to another service that ranges the ages (Age range service). The Decision service takes the range of ages as input along with the weights to be considered for each age range from the Weight service and decide which music to play. The decided music is passed to the Music service that finally play the music in the store.

Service Composition Based on Identification Information

In connection with the first example, we can think at a more refined approach that identifies the customer inside the retail store. For example, by providing customers with an app on their smartphones capable of communicating their presence in the store.

More sophisticated approaches can be enacted as well, in particular biometric recognition [9] or face recognition [7] or context-aware edge computing [8]. These approaches imply privacy issues, because people are identified and tracked possibly without explicit consent. If the identification is carried out by an app, we can assume that the customer has agreed in being sensed inside a store; nevertheless, in this way less people can be identified (only those with the store app and only those who granted the permission to the app to access the position). Otherwise, recognising people by means of face or biometric recognition, allows the identification of more people, but is more complex to be deployed and it might be forbidden by national laws.

Fig. 4.
figure 4

Example of service composition to decide the most appropriate music using identification of customers in the store.

Full size image

Independently of implementation details, microservices can be composed as depicted in Fig. 4. Some services have been reused from the previous case; this is one benefit of exploiting microservices. Furthermore, we introduced a statistical service (Demographic service in Fig. 3) for identifying customers (Identification service) coupled with a service that calculate the average age distribution of the customers in the store (Average service).

Service Composition with Different Sources

As mentioned above, the decision system can rely on different and heterogeneous information sources [13]. For instance, the decision system can get information from both a statistical and an identification services (see Fig. 5). Having more sources can improve the precision of the context, but it is also more difficult to manage.

Fig. 5.
figure 5

Example of decision system for music, weighting different sources.

Full size image

The clouds represent the fact that the information is likely to be provided by a set of coordinated services. In this case, the Decision service must apply weights to the different pieces of information in order to take a decision.

Service Composition for Colours

To assess the modularity of the proposed architecture, we also consider the case in which the system can control the lights inside a store.

As depicted in Fig. 6, using the microservice based architecture we can compose the set of needed services by reusing the statistical and the identification clouds of service, and exploiting the Weight service for the colours and the Color service to enact the decision. The modularity of the microservices enables us to adapt the architecture to other decisions, with only small changes. The differences with the previous case are highlighted by red circles in Fig. 6.

Fig. 6.
figure 6

Example of decision system for colours, weighting different sources; the differences between Fig. 5 are highlighted. (Color figure online)

Full size image

6 Conclusion and Future Work

In this paper we have presented a user-aware architecture to enhance comfort in retail environments. The comfort is achieved by choosing the most appropriate comfort aspects (e.g., music, colours, fragrance, ...) inside the retail store.

We have proposed a model of user context relying on external, statistical and personal information. This context is then used for taking decisions to maximise the comfort level of the customers inside the store.

We have chosen to use an architecture based on microservices, granting modularity, flexibility and ease of deployment if real-world cases. Three case studies show concrete applications of the architecture.

Regarding future work, we sketch some main directions. First, privacy issues should be taken into account, in particular when people inside the store are identified and tracked. Second, we will evaluate interoperability issues possibly related to service discovery and composition [3, 4]. Third, it would be interesting to explore how the change of the environment (e.g., a change in the store colours) can affect the customers’ context, triggering a sort of “loop”. Last, we are developing a prototype of the architecture that will be tested in actual environments.