The proposed framework consists of four core components, as illustrated in Figure 1. First, nudges and attached conditions are stored in a nudging repository. Second, a data hub manages the required data, which are necessary for defining situations. Data are either stored in a central database or are referenced in the data hub (distributed data storage). Third, ontologies link the data hub with the nudging repository, considering clients’ situations. Fourth, an interface connects clients with the central data hub and controls for the temporal aspects of situation-aware nudges. 

The nudging repository contains all available nudges, each with text and nudging conditions. The nudging text is the information conveyed to receivers of the nudges. Depending on the nudging design, these texts range from simple information to concrete calls for action. The texts are either fixed or contain flexible elements that can be updated depending on conditions (time stamp, location, environmental variables) or user-specific characteristics (mode preferences, age, gender, etc.). The nudge conditions refer to situations in which the nudge is available and to predefined exclusion criteria based on user-specific characteristics. Table 1 presents examples of the different types of nudge texts and conditions. The different types of texts and conditions can be combined as needed.

Situation awareness is attributed in two different ways to nudges. First, nudge texts contain semantic information that describes a situation; for instance, “Most roads are congested and weather will be dry the entire day. Why not take the bike to work?” In this example, the text refers to traffic and weather conditions, which directly describe the current situation. Second, if nudge texts do not contain specific information on the situation, situation awareness can still be introduced by conditions, such as, “Why not take the bike today?” with the conditions: location = home, and bikeability around the current location = high.

Technically, the nudging repository is a flat database table with columns containing a unique ID, the nudge text, thresholds for conditions, and applicability criteria. The nudges from the repository are linked to the data hub through ontologies. 

The data hub connects situation awareness, described by various input data layers, with the nudges, which are then delivered to the client. Input data layers are managed in a data repository, where the temporal (timestamp) and spatial (geometry + location) information are used for syntactically (and subsequently semantically) integrating different data sources. Researchers distinguish between static and real-time data. The former refers to the built environment, such as the representation of the road network in a graph with linked attributes or derived layers (for instance, walkability and bikeability indicators). The latter account for dynamic factors that decide on the relevance of nudges, such as the current weather situation or public transport services in immediate proximity. Static and dynamic data are integrated and interpreted to describe situations. For this, researchers use thresholds for the different input data, corresponding with lower and upper limits for acceptance. Qualitative information in the nudges or nudge conditions is translated into manageable sets of value combinations. “Excellent weather”, for instance, requires a minimum duration of sunshine, the absence of precipitation, air temperature within a predefined range, and no strong wind.

As outlined before, nudges contain situation-relevant information, either in their content or as conditions. For defining ontologies, which link nudges to users’ situation and mode preferences, researchers extract and formalize relevant information from the nudge texts, user information, and the situation. A value derived from the nudges’ semantic content or related conditions is assigned to each situational factor, which can have different qualities depending on the role. The quality is defined by the design or available location information of a user. A factor can be calculated along a route if start (home) and end (work) locations are known, or it can be calculated for the area near a specific location. Each situational factor is represented by 1–2 attributes from datasets. In the case of two attributes, an operator decides how they are logically connected. The value for situational factors is translated into thresholds for the considered attributes according to the ruleset. Table 2 shows examples of how ontologies are defined:

Communication between clients and the data hub is managed in an interface (API). A schedule defines time frames for when nudges are sent to clients and controls for the maximum number and the unique use of nudges per user. The API sends a request to the client, which returns user preferences and location information. With this, the interface queries the data hub and returns adequate nudges, if available, for the specific situation of the user. To ensure privacy, temporary user IDs, which are deleted every day, are used for communication between the client and the data hub.

The organization for delivering nudges to the client follows layered rulesets, which are linked to the interface and data hub on the one side and the nudging repository with the ontologies on the other side.

To return relevant, situation-aware nudges, a set of rules processes the attributes of the end user, which are conveyed as part of the request to the data hub (see Figure 2). Depending on mode preferences and location information, nudges from the repository are filtered. In addition, rules linked to the schedule, which is part of the interface, define the frequency of nudging, the maximum number of nudges per day, and time frames for certain nudges. These rules are adaptable and can thus be optimized for different user groups or intervention goals. Another layer of rules is linked to the nudge ontologies. These rules are defined as queries for the data hub, in which thresholds are used for reflecting situational factors. Again, these rules can be adapted according to the perception of situations in targeted user groups. The perception of “moderate temperature”, for instance, differs significantly between regions ^[1]. The same holds true for the traffic state ^[2], the distance to public transport stops ^[3], and other situational factors that are perceived and rated by citizens. Applying these layered rulesets leads to a subset of situation-aware nudges from which nudges are randomly selected and delivered to the client.