Real-time system to identify and analyze behavioral patterns to predict churn risk and increase retention

Implementations are directed to identifying potential churn of a user of one or more computer-implemented systems provided by an enterprise. In some examples, actions include identifying potential churn of providing a plurality of event profiles based on historical data, each event profile being representative of interactions of users with the enterprise and corresponding to churn of the users, at least one event profile being representative of an interaction of users with the one or more computer-implemented services, providing a pulse of the user at least partially based on historical data associated with the user, and one or more event profiles of the plurality of event profiles, and determining that the user is at-risk of churn based on the pulse of the user and a risk index value, and in response, displaying an indication that the user is at-risk of churn in a graphical user interface.

BACKGROUND

User churn is a concern for enterprises. When a user ceases to interact with an enterprise (e.g. telecommunications, banking, insurance providers, etc.), not only is future revenue lost, but also the initial investment in technical infrastructure, as well as in acquiring the user is lost. For example, technical resources (e.g., servers, memory, bandwidth) are planned, acquired, and maintained based on the number of users using the technical infrastructure (e.g., interacting with the enterprise through web-/mobile-applications, automated call centers, and the like). In general, acquisition costs are higher than is the cost to retain a user. Consequently, enterprises are motivated to mitigate user churn.

SUMMARY

Implementations of the present disclosure are generally directed to processing user data provided through a technological infrastructure to mitigate user churn. More specifically, implementations of the present disclosure are directed to identifying events and/or patterns that occur before user churn based on data provided from one or more computer-implemented systems of an enterprise, through which users interact with the enterprise. In some examples, actions include providing a plurality of event profiles based on historical data, each event profile being representative of interactions of users with the enterprise and corresponding to churn of the users, at least one event profile being representative of an interaction of users with one or more computer-implemented services of the enterprise, providing a pulse of the user at least partially based on historical data associated with the user, and one or more event profiles of the plurality of event profiles, and determining that the user is at-risk of churn based on the pulse of the user and a risk index value, and in response, displaying an indication that the user is at-risk of churn in a graphical user interface. Other implementations of this aspect include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

These and other implementations can each optionally include one or more of the following features: each event profile is representative of an event associated with a plurality of churned users, each churned user having performed or experienced the event before churning; each event profile includes an impact score, an influence score, and a days-to-churn for the respective event; the impact score is determined as a number of users that have churned and that are associated with the respective event; the influence score is determined as a ratio of a number of churned users that are associated with the respective event to a total number of users that are associated with the respective event; the days-to-churn is determined based on: for each churned user that is associated with the respective event, the number of days between when the respective event was experienced by the churned user and the date the user churned, and averaging the days-to-churn across all churned users that are associated with the event; and the pulse is determined based on at least one influence score of an event associated with the user.

Implementations of the present disclosure provide one or more advantages. For example, implementations of the present disclosure enable enterprises to examine and drill-down into the historical behavior of an individual user (e.g., in terms of their activities and interactions with the enterprise), and pinpoint the behavior that the customer is currently exhibiting that is indicative of churn. With such information and insights, enterprises can enact retention strategies in a timely manner, and tailor the retention strategies to the user at risk, in an effort to prevent churn. Among other advantages, implementations of the present disclosure provide improvements to underlying technical resources (e.g., servers, memory, bandwidth), through which services are provided to users, and through which users interact with an enterprise. For example, mitigating user churn enables technical resources that are implemented to support user interaction with an enterprise to remain in use. That is, idling of technical resources is mitigated by avoiding user churn.

Further, implementations of the present disclosure enable multiple transactions/events to be combined to enable churn risk scoring based on “complex” events. Implementations also support clustering of users to identify users that exhibit similar behavioral/transactional/event patterns, which patterns can be used for churn prediction and early detection of other users who may start to exhibit the same patterns. Implementations are flexible in terms of filtering support (i.e., not limited to specific attributes—customer demographics, product holdings, etc.), variable risk levels (e.g. multiple risk levels may be defined for different customer groups), types of data sources, and/or event types.

It is appreciated that methods in accordance with the present disclosure can include any combination of the aspects and features described herein. That is to say that methods in accordance with the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.

DETAILED DESCRIPTION

Implementations of the present disclosure are generally directed to processing user data provided through a technological infrastructure to mitigate user churn. More specifically, implementations of the present disclosure are directed to identifying events and/or patterns that occur before user churn based on data provided from one or more computer-implemented systems of an enterprise, through which users interact with the enterprise. Implementations of the present disclosure provide alerts that indicate potential user churn to enable, for example, action to be taken in an effort to prevent occurrence of user churn. In some implementations, the user is a user of products and/or services provided by an enterprise. For example, the enterprise provides one or more products and/or services that are provisioned using an underlying technical platform (e.g., web-based application, mobile application, cloud system, etc.), and the user consumes the products and/or services using the technical platform.

As described herein, implementations of the present disclosure apply data analysis techniques to examine historical data records and identify user behavioral patterns that are indicative of churn. The results are applied and compared with current data records (e.g., real-time data) to determine and detect current behaviors that correspond to historical behavioral patterns indicative of churn. In this manner, implementations of the present disclosure use data analysis to identify indicators of potential churn of current users. Implementations of the comparison analysis provides a pulse, which indicates a timeline of predicted churn risk scores unique for each customer. In some examples, a pulse provides the enterprise with deeper insight into the behaviors of their users, and identifies anomalies in a user's usual behavior. In some examples, when the pulse achieves a predetermined risk level (e.g., as specified by the enterprise), an alert is triggered to inform the enterprise that the user is displaying signals that are indicative of churn.

Implementations of the present disclosure enable enterprises to examine and drill-down into the historical behavior of an individual user (e.g., in terms of their activities and interactions with the enterprise), and pinpoint the behavior that the customer is currently exhibiting that is indicative of churn. With such information and insights, enterprises can enact retention strategies in a timely manner, and tailor the retention strategies to the user at risk, in an effort to prevent churn. Among other advantages, implementations of the present disclosure provide improvements to underlying technical resources (e.g., servers, memory, bandwidth), through which services are provided to users, and through which users interact with an enterprise. For example, mitigating user churn enables technical resources that are implemented to support user interaction with an enterprise to remain in use. That is, idling of technical resources is mitigated by avoiding user churn.

FIG. 1depicts an example system architecture100for executing implementations of the present disclosure. In the depicted example, the system architecture100includes a user churn analysis system102, a historical data source104, and a real-time data source106. The user churn analysis system102includes a base analysis module108, a real-time analysis module110, an event analysis module112, a pulse module114, and a risk index module116. In some examples, each module and/or sub-module is provided as one or more computer-executable programs executed by one or more computing devices. As described in further detail herein, the user churn analysis system102provides event profiles118, pulses120, and risk index levels122. The user churn analysis system102provides an event overview user interface (UI)130, an event details UI132, a pulse UI134, and an at-risk UI136.

In some examples, a user140(e.g., an administrator of an enterprise seeking to reduce user churn) can interact with the user churn analysis system102using a computing device142. For example, the computing device142can provide/execute the user churn analysis system102. As another example, the user churn analysis system102can be provided by a server system, and the computing device142interacts with the server system over a network (e.g., WAN, LAN, Internet).

In some implementations, the event analysis module112provides event output data based on the event profiles118. In some examples, the event analysis module112reads the event profiles118(e.g., provided as computer-readable files), and processes the event profiles18to provide the event output data. In some examples, the output data is provided to the event overview UI130, and the event detail UI132, which respectively process the event output data to provide an overview, an in-depth view, and event details (e.g., graphical representations of each). In some implementations, the event overview UI130enables the end user to examine overview details based on events. For example, events can be grouped into categories, and/or can include respective impact score, and influence score, discussed in further detail herein. In some implementations, the event details UI132depicts graphical representations of event details, and enables the user140to examine in-depth details for a specific event. Example in-depth details can include a list of users who most often performed/experienced the respective event, and a list of events commonly associated with the respective event.

In some implementations, each event profile118is provided based on the historical data104. In some examples, an event profile118is provided as a predictive model (e.g., calculated from the historical data). In some examples, the predictive model is based on one or more equations used in classification models, which equations calculate several scores (e.g., impact, influence, days-to-churn). In some examples, features of the predictive model are based on the transactions/activities performed/experienced by the user (e.g., user experienced ATM cash jam (Yes/No)).

In some examples, and as described in further detail herein, each pulse120is provided based on event profile(s)118. In some examples, each event is represented by a respective event profile118. In some examples, an event represents one or more activities performed by a user with the system (e.g., one or more interactions between the user and the system). In some examples, each event is associated with a time (e.g., day/time event occurred), or a time range (e.g., range of days/times, over which activit(y/ies) occurred).

In some implementations, each event profile118includes an impact score, an influence score, a value representing “days-to-churn” (e.g., estimated days until a user will no longer use the respective system), one or more filters, and churn type. Example churn types include hard churn and soft churn. In some examples, hard churn is an event, through which a user ceases to be a user of the system (e.g., the user closes their account). In some examples, soft churn is an event, through which the user exhibits behavior that is indicative of churn, but the user has not yet ceased to be a user of the system (e.g., the user has not closed their account, but there is a period of inactivity).

In some implementations, the impact score represents the impact a particular event has on churn. In some examples, the impact score (e.g., expressed as an integer) is determined as the sum of churned users who performed the respective event during a training period. In some implementations, the influence score represents the influence a particular event has on churn across a plurality of users. In some examples, the influence score (e.g., expressed as a percentage) is determined by dividing the impact score by the total number of users, who performed the respective event during the training period. In some implementations, the training period is a time period that specifies the data range for determining the impact score and the influence score. For example, the training period is a time period over which historical data is selected (e.g., historical data within the training period is used for calculations).

In some implementations, the base analysis module108processes the historical data104to provide the event profiles118. In some implementations, the base analysis module108provides an impact score and an influence score that are associated with a particular event.

In some implementations, the pulse module114reads in the pulse120(e.g., as a computer-readable file), and processes the pulse120to provide pulse output data. In some examples, the pulse output data is provided to the pulse UI134, which processes the pulse output data to provide one or more graphical representations. In some examples, the pulse module114notifies the risk index module116of updates to the pulse120. In some implementations, the pulse UI134displays graphical representations of pulse data, and enables the user140to examine the pulse120of a particular user.

In some implementations, the pulse120is provided as a set of influence values for a respective user during a specified period of time. In some examples, the pulse120may fluctuate over time depending on the events performed/experienced by the user interacting with the system. In some examples, the pulse is a user-specific, time-based series of influence scores, reflecting the events performed by that particular user. In some implementations, the real-time analysis module110reads in historical data104(e.g., provided in one or more computer-readable files), event profiles118(e.g., provided in one or more computer-readable files), and the real-time data106to provide a pulse120for a respective user. In some examples, the real-time analysis module110continuously receives the real-time data106for new data, and updates the pulse120accordingly.

In some implementations, the historical data104includes one or more data sources (e.g., external data sources) that each provides data for pre-processing the pulse120. For example, and as described in further detail herein, the historical data104is processed to provide event profiles118and to initialize a pulse120for a respective user. In some examples, the historical data104can include data for current users (e.g., users, for which a risk of churn is being determined), and/or data for churned users (e.g., users that have already ceased to be users of the system). In some examples, the historical data104is provided as relatively recent data (e.g., a time associated with the data is within a first threshold difference of a current time (time at which event profile and/or pulse are to be provided)). In some examples, the historical data104is not the latest data (e.g., the time associated with the data exceeds a second threshold difference (greater than the first threshold difference) of the current time). Example historical data include transaction data (e.g., data representative of interactions a user has had with a system), and service data (e.g., data representative of interactions a user has had with support and/or service).

In some implementations, the real-time data106includes one or more data sources (e.g., external data sources) that each provides data for real-time analysis (e.g., continuously updating the pulse for the user). In some examples, the real-time data is provided as the most recent data (e.g., a time associated with the data is within a third threshold difference (lower than the first threshold difference) of a current time. In some examples, real-time data is provided as data associated with a user that was received after a pulse was determined for the user, and is sued to update the pulse. Example real-time data includes transaction data (e.g., data representative of interactions a user has had with a system), and service data (e.g., data representative of interactions a user has had with support and/or service).

In some implementations, the risk index module116continuously monitors the pulse120, and determines when the pulse120meets (e.g., is equal to, exceeds) a risk index level122. In some examples, the risk index level122signifies a risk that the user will churn, and can be configured by the enterprise. In some examples, the risk index level122is provided as a threshold influence score, and/or can include low risk, medium risk, high risk, and action required. In some examples, if the pulse120meets the risk index level122, the risk index module116triggers an alert (e.g., indicating that the user is identified as “at risk” of churn). In some examples, the risk index module116receives the pulse120from the pulse module114. In some implementations, the alert is provided to the at-risk UI136, which processes the alert to provide a graphical representation of the alert, as described in further detail herein.

FIG. 2depicts an example conceptual diagram in accordance with implementations of the present disclosure. In the example ofFIG. 2, an example system200is depicted and includes data sources202, an in-memory database systems204, and churn analysis results206. In some examples, the system200is a higher-level representation of the example system architecture100ofFIG. 1. For example, the data sources202can be representative of the historical data104and/or the real-time data106ofFIG. 1. In the depicted example, the data sources202include transactions208, applications210, service212, call center logs214, in-person complaints216, and social media218. For example, the transactions208can include historical data representative of transactions (interactions) that all users of the system have had with the system, as well as real-time data representative of current or recent transactions users are having or have had with the system. As another example, applications210can include historical data representative of interactions that all users of the system have had with the system using applications (e.g., web-based applications, mobile application), as well as real-time data representative of current or recent interactions users are having or have had with the system.

In some implementations, a data source202can include third-party data sources. For example, the social media218can include data provided from one or more computer-implemented social networking services (e.g., Instagram, Facebook, Twitter, Google+). In some examples, the social media218can include data representative of comments posted to the one or more social networking services (e.g., complaints about the enterprise, compliments about the enterprise). In some examples, posts shared on social networking services can be publically available and searchable, such that the enterprise can review posts to identify posts that are about the enterprise. In this manner, relevant social media can be extracted from the third-party service and stored in the social media218. In some examples, particular social posts can be associated with specific users. For example, a user identifier (e.g., username, handle) of a social networking system can be associated with a user identifier of a user of the system (provided by the enterprise).

In some implementations, the in-memory database system204processes historical data and/or real-time data to provide the churn analysis results206. For example, the in-memory database system204can execute one or more of the modules ofFIG. 1(e.g., the base analysis module108, the real-time analysis module110, the event analysis module112, the pulse module114, the risk index module116). In the depicted example, the churn analysis results206include churn insights220and churn alerts222. In some examples, churn insights220can include events and event details (e.g., discussed in further detail below with reference toFIGS. 3A and 3B). In some examples, churn alerts can include alerts that are triggered in response to determining that one or more users are at risk of churn (e.g., discussed in further detail below with reference toFIGS. 3C and 3D).

The in-memory database system204uses main memory for data storage. Main memory may include one or more types of random access memory (RAM) that communicates with one or more processors (e.g., CPU(s)), over a memory bus. An in-memory database system may be contrasted with database management systems that employ a disk storage mechanism. In some examples, in-memory database systems may be faster than disk storage databases, because internal optimization algorithms may be simpler and execute fewer CPU instructions. In some examples, accessing data in an in-memory database system may reduce or eliminate seek time when querying the data, providing faster and more predictable performance than disk-storage databases. An in-memory database may include a row-oriented database, in which data is stored in any number of rows or records. An in-memory database may also include a column-oriented in-memory database, in which data tables are stored as sections of columns of data (rather than as rows of data). An example in-memory database system is HANA™, provided by SAP™ SE of Walldorf, Germany.

In general, implementations of the present disclosure process historical data to determine events that have resulted in user churn. In some examples, a single event can result in user churn, or a series of events can result in user churn. For example, two or more events causing, or symptomatic of user churn can be correlated (example correlated events are provided below).

In some examples, an event profile is specific to an event (e.g. a single activity, a sequence of activities). The event profile includes the impact score, influence score, and days-to-churn for the event. In some examples, an event profile is used to predict is the likelihood of an existing user to churn, if the user performs/experiences the respective event. In some examples, the impact score for a particular event is determined as the number of users that have churned and that had performed/experienced the event. In some examples, the influence score for a particular event is determined as a ratio of the number of churned users that performed/experienced the event, and the total number of users that performed/experienced the event. In some examples, for each churned user that performed/experienced a particular event, the number of days between when the event was performed/experienced and the date the user churned is determined. In some examples, the days-to-churn for the event is provided as the average number of days between across all churned users that performed/experienced the event.

In some examples, a pulse is provided for each user. For each event performed by a particular user, the influence score (from the corresponding event profile) is used to generate the pulse (e.g., influence score plotted over time).

FIGS. 3A-3Ddepict example graphical user interfaces (GUIs) in accordance with implementations of the present disclosure. The examples ofFIGS. 3A-3Dare based on an example use case, which includes users as customers of a financial services enterprise. It is contemplated, however, that implementations of the present disclosure can be realized with any appropriate type of enterprise providing any appropriate type of products and/or services.

FIG. 3Adepicts an example event overview UI300. The example event overview UI300includes a tabular event summary302, and a graphical event summary304. The tabular event summary302provides a list of event types, and their respective impact scores and influence scores. In the depicted example, the event types are listed in rank order based on impact score. Color coding is provided based on influence score to indicate event types having high influence, medium influence, and low influence on user churn. In accordance with the example context, event types depicted in the example ofFIG. 3Ainclude:“No Payroll/Salary For 2 Months” (no payroll/salary deposits into account in the last 2 months), with an impact score of 2 million (2 m) (e.g., rounded up from a lower value), and an influence score of 40%;“80% Transactions Drop Over 3 Months” (reduction in deposits/withdrawals into/from account in 3 month period), with an impact score of 2 million (2 m) (e.g., rounded up from a lower value), and an influence score of 40%;“Standing Order” (a set amount to pay into another account at regular intervals), with an impact score of 625,000 (625 k), and an influence score of 10%;“Priority Order Internet Banking” (an expedited payment order placed using Internet banking), with an impact score of 466,000 (466 k), and an influence score of 8%; and“Point-of-Sale Transaction” (charging from an account at a point-of-sale (e.g., using a debit card), with an impact score of 454,000 (454 k), and an influence score of 11%.

The example event types indicate that the event types “No Payroll/Salary For 2 Months” and “80% Transactions Drop Over 3 Months” have the highest impact and influence on user churn. The example event types also illustrated that, although an event type may have a higher impact score than another event type, it may have a lower influence on user churn. For example, “Priority Order Internet Banking” has an impact score of 466 k and an influence score of 8%, while “Point-of-Sale Transaction” has a lower impact score of 454 k, but a higher influence score of 11%.

In the example ofFIG. 3A, the example graphical event summary304includes a set of circles, each circle representing an event type. In the depicted example, a diameter of each circle is based on a respective impact score, event types having a larger impact score having a larger diameter than event types having a lower impact score. In the depicted example, the circles are color coded based on influence score to indicate event types having high influence, medium influence, and low influence on user churn. In some examples, a detail interface306can be displayed for a respective event type. For example, if a user viewing the event overview UI300selects (e.g., clicks on, hovers over) a circle of the example graphical event summary304, a respective detail interface306can be displayed. In the depicted example, the example detail interface306identifies the event type, the impact score (e.g., 1.92 m, rounded up to 2 m in the tabular event summary302), and the influence score.

FIG. 3Bdepicts an example event details UI320. The example event details UI320includes a graphical representation of correlated events322and a tabular user summary324. In some examples, the event details UI320is displayed in response to user selection of a particular event from the event overview UI300. In the example ofFIG. 3B, the event details UI320depicts details of the “80% Transactions Drop Over 3 Months” (e.g., selected by the user in the event overview UI300).

The example graphical representation of correlated events322includes a central circle representing the selected event type (e.g., the event type that is the subject of the event details UI320), and satellite circles, each representing a respective event type that has been correlated to the selected event type. In some examples, a diameter of a satellite circle indicates a level of correlation to the selected event type. For example, satellite circles having a larger diameter are more highly correlated to the selected event type than satellite circles having a smaller diameter. The example tabular user summary324includes a list of users that are associated with the selected event type (e.g., that have an event matching the selected event type). In some examples, characteristics include user name, a segment and a product the user is associated with, and an income of the user. In some examples, income values can be color-coded to indicate relative level of income (e.g., high, medium, low).

FIG. 3Cdepicts an example pulse UI340. The example pulse UI340corresponds to a particular user (e.g., selected from the tabular user summary324of the event details UI320ofFIG. 3B), and the pulse determined for the particular user. The example pulse UI340includes graphical representations of a pulse line342and a trend line343, and a tabular summary of customer information344. In some examples, the pulse line342corresponds to a particular user, and individual points on the pulse line correspond to the influence score of a respective event. In the depicted example, points on the pulse line342that are highlighted in blue reflect the event “80% Transactions Drop Over 3 Months.” In this example, these points are at the peaks of the pulse line342. The graphical representation also includes multiple threshold lines for the influence score (e.g., 5% —Medium Churn Influence Factor; 15% High Churn Influence Factor; 25% —Action Required).

FIG. 3Ddepicts an example at-risk UI360, which provides information regarding users that have been determined to be at-risk of churn. The example at-risk UI360includes a graphical representation of urgency362, and a tabular user summary364. In the depicted example, the graphical representation of urgency362includes a scatter chart having an X-axis representing “Days to Churn” and a Y-axis representing influence score. In the depicted example, each dot of the scatter graph represents a category of user (as color-coded), and can be representative of one or more users. For example, a dot located at 45 days to churn, and 25% influence score can represent a single user, while a dot located at 64 days to churn, and 27% influence score can represent multiple users. In the depicted example, the at-risk UI provides a tabular summary366indicating a number of users that are at-risk of churn, and an impact (e.g., economic) for the forecast displayed in the graphical representation of urgency362. In some examples, the economic impact is determined as the sum of the operating income (OI), discussed below, of the predicted at-risk users.

In the depicted example, the tabular user summary364provides a list of user names, and for each user, an associated trigger event, an estimated days-to-churn, an influence score, and an OI. In some examples, the OI is provided as the total fees/charges that the user paid to the entity (e.g., bank), less interest paid by the entity to the user. In some examples, the OI is determined on a monthly basis, and is averaged across the previous 12 months.

In some examples, the trigger event is an event type that has been used to determine that the particular user is at-risk of churn. In some examples, the trigger event is the most recent event that caused the pulse to achieve the threshold (e.g., “Action Required” threshold ofFIG. 3C). In the example ofFIG. 3D, the influence scores reflect the most recent event performed/experienced by the user (which are not necessarily trigger events).

FIG. 4is a flowchart illustrating an example process400that can be executed in implementations of the present disclosure. In some implementations, the example process400can be realized using one or more computer-executable programs that are executed using one or more computing devices. In some examples, the example process400is performed to monitor users of a system (e.g., products/services provided by an enterprise) for churn. In some examples, the example process400is executed for each user of a plurality of users.

Event profiles are provided (402). For example, event profiles are determined based on historical data. In some examples, the base analysis module108provides the event profiles118based on the historical data104(seeFIG. 1). As described herein, an event profile is associated with a respective event and includes an impact score, an influence score, and a days-to-churn for the particular event. In some examples, an event profile is used to predict is the likelihood of an existing user to churn, if the user performs/experiences the respective event. In some examples, the impact score for a particular event is determined as the number of users that have churned and that had performed/experienced the event. In some examples, the influence score for a particular event is determined as a ratio of the number of churned users that performed/experienced the event, and the total number of users that performed/experienced the event. In some examples, for each churned user that performed/experienced a particular event, the number of days between when the event was performed/experienced and the date the user churned is determined. In some examples, the days-to-churn for the event is provided as the average number of days between across all churned users that performed/experienced the event. Accordingly, event profiles are determined across all users of the system, and are not specific to a particular user.

A pulse is provided for a particular user (404). For example, a pulse is provided based on one or more event profiles, historical data, and real-time data. In some examples, the real-time analysis module110provides the pulse120based on one or more event profiles118, the historical data104, and the real-time data106(seeFIG. 1). As described herein, a pulse is provided for a user based on events performed/experienced by the user. For each event performed/experienced by the user, the influence score (from the corresponding event profile) is used to determine the pulse (e.g., influence score plotted over time). Accordingly, a pulse is specific to a particular user.

It is determined whether the pulse meets (e.g., is equal to, is greater than) a threshold (406). For example, the pulse is compared to a risk index level to determine whether the pulse meets (e.g., is equal to, exceeds) the risk index level. In some examples, the risk index module116continuously monitors the pulse120, and determines when the pulse120meets (e.g., is equal to, exceeds) the risk index level122(seeFIG. 1). If the pulse meets the threshold, an alert is triggered (407). For example, a graphical representation of a user can be included in an at-risk UI (e.g., the at-risk UI136ofFIG. 1, the at-risk UI360ofFIG. 3D).

Real-time data is received (408). For example, data is received from one or more data sources (e.g., one or more of the data sources202ofFIG. 2). In some examples, the real-time data is data associated with the particular user that the pulse is specific to. It is determined whether new data is provided (410). For example, it is determined whether data used to determine the pulse, or that could be used to update the pulse provided. If new data is not provided, the example process400loops back. If new data is provided, the pulse is updated (412). For example, the pulse is updated based on one or more event profiles, historical data, and newly provided real-time data. In some examples, the real-time analysis module110updates the pulse120(seeFIG. 1).

FIG. 5is a schematic illustration of example computer systems500that can be used to execute implementations of the present disclosure. The system500can be used for the operations described in association with the implementations described herein. For example, the system500may be included in any or all of the server components discussed herein. The system500includes a processor510, a memory520, a storage device530, and an input/output device540. Each of the components510,520,530,540are interconnected using a system bus550. The processor510is capable of processing instructions for execution within the system500. In one implementation, the processor510is a single-threaded processor. In another implementation, the processor510is a multi-threaded processor. The processor510is capable of processing instructions stored in the memory520or on the storage device530to display graphical information for a user interface on the input/output device540.

The memory520stores information within the system500. In one implementation, the memory520is a computer-readable medium. In one implementation, the memory520is a volatile memory unit. In another implementation, the memory520is a non-volatile memory unit. The storage device530is capable of providing mass storage for the system500. In one implementation, the storage device530is a computer-readable medium. In various different implementations, the storage device530may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. The input/output device540provides input/output operations for the system500. In one implementation, the input/output device540includes a keyboard and/or pointing device. In another implementation, the input/output device540includes a display unit for displaying graphical user interfaces.